Simplification reduces the cost of maintenance.  The business probably doesn’t want to think about it, and they really don’t want to pay for it.  However, in many situations, IT has no choice.  By reducing the number of applications, reducing the number of redundant data stores, making data paths simpler and more measurable, and driving for more consistence in non-value-add processes, the company can reap real benefits in cost savings. 

However, simplification requires a couple of things.  It requires project teams to change processes and code.  It requires support teams to manage the data shifts and all the ripple effects.  It requires release management coordination to make sure that new features and simplified systems do not conflict.

Where does the money for that come from?  This requires the business to pay for this work.  It requires that IT have staff and resources to dedicate to it. 

Think of it like aircraft maintenance.  When a jet airplane is being repaired, it has to be pulled out of service… for a day or two or ten.  But the airline cannot simply cancel the flight because the aircraft needs a routine tune-up.  The airlines have some capacity, in terms of aircraft seats, set aside so that they can allow the aircraft to be inspected, maintained, and returned to service. 

So when an airline decides how many flights per day to set up, it has to plan on a certain amount of excess capacity just to cover the number of planes needing service.  It does not apologize for these costs.  The cost of your airline ticket includes the cost of maintaining other aircraft. 

And you don’t complain.  Why?  Because you want YOUR aircraft to be working when you get it. 

Similarly, the IT department needs to have excess capacity, in terms of project teams and hardware space, to cover the costs of simplification. 

This requires real leadership to pull off, but it has to be done, especially in larger IT departments where there are many developers writing code.  In these environments, the amount of overlap is substantial, so the benefits are large.

So for every five project teams that you can use in business-requested maintenance or new features (airplane flights), you need a sixth team for IT driven simplification (aircraft maintenance).  That team needs project managers, product managers, developers, testers, release and code management, and support members.  Full out teams.  The business does NOT get to drive the efforts of these teams.  IT does, as needed, with the guidance of Enterprise Architecture or the EPMO.

Without this capacity, you will never be able to solve, or fund, Simplification.  It’s a cost of doing business.

Last note, when I say “Simplification”, I’m not talking about consolodation.  Sun is spending a lot of time talking about the savings that a company can earn by moving software from multiple servers to a single Sun server (lower power, lower rack space costs).  That is consolodation, and it is not specific to Sun servers.  You can get the same benefits from any server consolodation. 

This reduces ongoing run costs, but not the costs of maintenance.  In fact, it may increase the costs of maintenance somewhat by placing more complexity on a single server and decreasing the redundancy.

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

3 thoughts on “Simplification requires dev capacity – like aircraft maintenance”
  1. It would certainly be nice.  Your point about having that team IT driven is well taken, and the need to have some extra capacity for this sort of thing.

    One thing that we’ve tried in the past is to have a concerted effort (projects) to improve particular aspects of our technology infrastructure.  Of course, that requires endorsement from business, but has been effective in improving particular areas of irk in our infrastructre in the past…. without requireing a lot of slack time on the part of our development teams.

  2. Your point about having a headroom is well taken. Keeping reserve h/w capacity may be an easier task. However strategy of keeping reserve work force is a hard sell with management. But you can boot-strap this reserve by taking help from external agency (e.g. contractors). This initial headroom will give you chance to create more headroom and then you can argue with your management to keep this newly freed workforce as reserve. The flip side is management may want to cash on it as achievement by making this workforce redundant and you will be left with no reserve again.

Leave a Reply

Your email address will not be published. Required fields are marked *

2 × 5 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.