Avoiding Platform Rot

(Mirrored from the Iasa Blog)

just never had the time to keep up with the maintenance

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.

Advertisements

14 thoughts on “Avoiding Platform Rot

  1. Pingback: “Avoiding Platform Rot” on the Iasa Blog | Form Follows Function

  2. I am intrigued by the comment that the application team responsible for the development of the application should not only support the application, but also the unpinning technology stack — OS, database, service bus, etc. I have worked in organizations where the application development team were not only responsible for subsequently enhancing the application, but also provided customer support and training for the application, but were not responsible for the support and maintenance of the underlying OS, database, etc. That was the responsibility of the infrastructure team who took an enterprise-centric view for timely OS upgrades and posed it challenges some of which you outline. A DevOps philosophy is certainly worth considering; good article!

    Like

    • Even without full-blown DevOps, I’m of the opinion that the development team should take an active interest in the full stack. For example, where I am now, we have DBA and infrastructure teams that are responsible for the day to day maintenance and who are responsible for the range of choices available to us (the enterprise-wide view you mention). That, however, doesn’t mean that I shouldn’t be aware of what’s becoming available and work with them to bring those capabilities online as soon as feasible if they benefit our apps.

      Glad you liked the post!

      Like

  3. Pingback: When Silos Make Sense | Form Follows Function

  4. Pingback: Design by Committee | Form Follows Function

  5. Pingback: The Never-Ending Narrative of Architecture | Form Follows Function

  6. Pingback: Technical Debt – What it is and what to do about it | Form Follows Function

  7. Pingback: Avoiding Platform Rot | Iasa Global

  8. Pingback: When Silos Make Sense | Iasa Global

  9. Pingback: Design By Committee | Iasa Global

  10. Pingback: Technical Debt – What it is and what to do about it | Iasa Global

  11. Pingback: Technical Debt – What it is and what to do about it · Another Day in the Life of a Programmer Gal

  12. Pingback: Building a Legacy | Form Follows Function

  13. Pingback: Stopping Accidental Technical Debt | Form Follows Function

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s