Application development has a profound impact on data center efficiency and costs. New application deployments, releases of new versions, and maintenance updates all require more hardware, more facilities space and change management. As the owners of the processing power, it feels like we are never able to provide developers the amount of flexibility or new capacity that they want. The frustrating part is that we are on the receiving end of the demand driven by the work of application developers, so it feels like we are in a response mode. We control the hardware and facilities, but feel like we have no control over the applications using that computing power.
But that is not true. Control can be direct or indirect.
For a number of years I ran an application development team. It was a small but very focused group of third party developers who coded an application monitoring tool. Lots of code was created and tested and re-written through the development cycle. Once the final product was put into production we immediately started to write more code to enhance and expand its capabilities. Several of us were awarded patents on the project because it was such an innovative approach. I still remember it as one of the top achievements of my career.
While we were taking that application from whiteboard to full production, I kept watching the number of lines of code increase at a phenomenal level. Unexpected issues needed to be addressed and additional features became desirable. The solution was just a few lines of code away. It was all about risk at that point. How much of a delay or additional cost would doing that next element mean, and will that be offset by the value?
In the back of my mind a little voice kept asking, “What is being taken out?” We were adding code to an inventory of applications that was already swollen and growing year on year. I started to think about application retirement strategies and where the problems were.
The Classic Strategy is Faulty. Make it a Tax
Application and data cleaning should be an ongoing process. As a result, they need to be funded as part of the operating model. My solution is to implement an application retirement tax. There are two aspects to this tax.
First, every new application development project should be burdened with a cleaning tax. A portion of the total project cost should be used to fund a separate team of “undevelopers”. The undervelopers are a software patrol dedicated to removing old applications and data, streamlining current code, and keeping applications in synch with current architecture. This team measures and codifies what they have done to keep their efforts out in the open.
The second form of taxation focuses on old infrastructure. There may be servers and hardware in place that is old and difficult to maintain. In many cases, this is because the application running on that infrastructure that is impeding upgrade. I suggest implementing a progressive tax that starts at the end of the depreciation cycle and increases each year as that specific infrastructure ages. Yes, to some degree it is artificial, but we are talking about incenting the business to keep current.
We are addressing risk. As data center managers we know better than anyone how difficult it is to recover old infrastructure after an event. Likewise, the number and complexity of applications has a direct relation to availability. That risk finds its way into our cost to maintain the infrastructure.
We continue to install millions of lines of code on an ongoing basis. It is just as important for us to assure that code is being managed so the business sees consistent performance and our data centers run in the most efficient way possible.
