I recently re-read a book called “The Goal” by Eliyahu Goldratt. I had read it years ago, and at the time it had resonated deeply in my mind. Sometimes it is beneficial to review concepts that resonate.
For years, I have been working in the application development domain within IT. Most of my views on IT are application software centric. I have held these views because it seems natural to me that without some application, all of the physical hardware and infrastructure software and tools don’t really deliver any value. Like principals of engineering, without application, they aren’t terribly useful.
So if we retain that as a principle, it leads us to imply that the purpose of hardware and infrastructure and tools is to support software applications. It does that in two main ways:
1) making application software capabilities available to the user
2) making application software capabilities easier (faster, less costly) to create and maintain
Those are the two main goals of IT infra. If you have another, I am open to see how it plays. If you agree with me, then I believe that infrastructure goals are completely subordinate to application software goals.
Then what are the goals of application software? In my mind, the goals of application software are the goals of the customer organization. Application software does not have a goal, independent of the overarching goals of the company that makes it or buys it. Application software is like any other corporate asset. It is either involved directly in the process of operating the business, or it is involved in some process required to support the process of operating the business.
If the goal of the customer organization is to make money, then the goals of application software are directly or indirectly related to that overarching goal. The thing is that in IT, we are very enamored of our technology. We are proud of our processes. We are fond of our hardware. We all want to believe that our skill and expertise is valuable. We all want to be perceived as important, essential, irreplaceable.
In the terms described in Goldratt’s book, we have throughput, operating expense, and inventory. In order to maximize the money, we need to increase throughput, while decreasing operating expense and investment. When we go on an expense reduction binge, it helps to know that you are not reducing throughput when reducing expense. When we have excess capacity, we don’t want to add make work procedures to our standard process that will inhibit our future ability to increase throughput. While in manufacturing businesses, you don’t want your working capital tied up in WIP or Inventory that can’t be sold (converted to throughput). In service businesses, we don’t want our capital spent on things that don’t increase throughput, or reduce operating expense.
So how does this apply to IT?
If applications are how business gets value from IT, then they invest in having us build those capabilities. The faster we can deliver those capabilities, and the less capital we tie up in them, the less operating expense comes from depreciation. The less the application capabilities cost to support, the less operating expense we incur. The more widely the capabilities are used by the business, the more leverage they provide.
The goal of IT is to increase the throughput of application capabilities (that is both the rate of delivery and consumption), while reducing the cost of maintaining the application capabilities (operating expense) that we need, while ensuring the continued alignment of application capabilities with business goals (we don’t build and we stop supporting capabilities that we no longer need.). Since IT is a service business, there really isn’t Inventory per se, but when we deploy infrastructure that doesn’t support live applications, or build software that isn’t in production yet we can think of that as inventory – it is intermediate work product that is adding no value to the bottom line.
So what about data, information security, performance, scalability, architecture, research and innovation? All of those things to me are nothing more than non-functional requirements for application capabilities.
What about all my acronyms and buzzwords and languages and databases and servers and networks and frameworks? Those things are just tools we adopt to increase the delivery throughput or reduce the cost of support for application capabilities.
What about all the methodologies, process frameworks, quality systems, engineering practices and service management frameworks? Those things are adopted to help us reach the goal of delivering application capabilities in ways that minimizes the cost of operating those capabilities. They have no value in themselves, only the value that they add to our overall goal.