by Gene Hughson
Is your OS the latest version? How about your web server? Database server? If not now, when?
A “no” answer to the first three questions is likely not that big a deal. There can be advantages to staying off the bleeding edge. That being said, the last question is the key one. If the answer to that is “I haven’t thought about it”, then there’s potential for problems.
“Technical Debt” is a currently a hot topic. Although the term normally brings to mind hacks and quick fixes, more subtle issues can be technical debt as well. A slide from a recent Michael Feathers presentation (slide 5) is particularly applicable to this:
Technical Debt is: the Effect of
Unavoidable Growth and the Remnants
of Inertia
New features tend to be the priority for systems, particularly early in their lifecycle. The plumbing (that which no one cares about until it quits working), tends to be neglected. Plumbing that is outside the responsibility of the development team (such as operating systems and database management systems) is likely to get the least attention. This can lead to systems running on platforms that are past their end of support date or a scramble to verify that the system can run on a later version. The former carries significant security risks while the latter is hardly conducive to adequately testing that the system will function identically on the updated platform. Additionally, new capabilities as well as operational and performance improvements may be missed out on if no one is paying attention to the platform.
One method to help avoid these types of issues is adoption of a DevOps philosophy, such as Amazon’s:
Amazon applies the motto “You build it, you run it”. This means the team that develops the product is responsible for maintaining it in production for its entire life-cycle. All products are services managed by the teams that built them. The team is dedicated to each product throughout its lifecycle and the organization is built around product management instead of project management.
This blending of responsibilities within a single team and focus on the application as a product (something I consider extremely beneficial) lessens the chance that housekeeping tasks fall between the cracks by removing the cracks. The operations aspect is enhanced by ensuring that its concerns are visible to those developing and the development aspect is enhanced by increased visibility into new capabilities of the platform components. The Solutions Architect role, spanning application, infrastructure, and business, is well placed to lead this effort.
Re-posted from Form Follows Function
“Things”, especially enterprise-wide ones, must be architected for the evolution. Platform will rot because of the lack of architecture (word which is not mentioned at all in the article) and inability of the management to establish necessary governance. Certainly, platform architect role should be mentioned as the life-span for a platform is longer than for a solution (see http://improving-bpm-systems.blogspot.com/2014/03/enterprise-patterns-ear.html ).
BTW, a lot of pictures with ancient ruins were imagination of medieval painters….
Thanks,
AS
Alexander,
I would argue that the rot occurs due to neglect/inertia. Obviously, poorly architected platforms and solutions, by virtue of being harder to change, make it easier to surrender to entropy.
if an organization has the platform architect role, then the person(s) in that role should be useful in maintaining it – with caveats: as the components of the platform evolve, the solutions running on those platforms may require work to transition to the next version and a solution architect would be better placed to evaluate this. Likewise, as those components evolve, a platform architect might not be intimately familiar with all the variations in play at a given time. For example, I’ve had solutions running on Windows Server/IIS/SQL Server that have been through 3 versions of each (not to mention transitions from the VB6 runtime through 4 versions of the .Net framework). Those platform components typically had different release schedules which would have made it difficult to maintain a homogeneous platform across multiple solutions.