I originally wrote this piece in November of 2007. I wanted to revisit it today because of the strong emphasis in the downturn on two major themes:
* Consolidation and
* Modernization
Both of these are ways of dealing with the past–consolidation is a way of rationalizing and reducing the ongoing burden of the past, while modernization is a way of bringing the past into the present.
In any event, these thoughts, penned a few years ago seem to still have resonance for me in thinking about customer problems in large scale software projects.
In reflecting on this post, I think measuring entropy solely in terms of “people” needs to be revised, and virtualization is a good way to ensure that utilization of systems is maximized, therefore maintaining a high level of energy available for work. I think this might be a valid way of looking at the overall IT budget.
Increasingly I’ve been referring to SOA using a folk definition that includes “a way to maximize the business value of the existing and ongoing IT investment”. Keeping that in mind, Entropy is a key variable to watch.
As a final note which I hint at in this piece, the natural conclusion is that if there is no way to reverse entropy, the entire system achieves “heat death”. Another source of inspiration is the evolution of biological systems, where local entropy is reversed through the addition of solar energy. The thing is, we get more and more IT funding and budgets each year (not that the budgets get bigger mind you, I’m just pointing out that there is such a thing as ongoing funding) so what remains is how we apply that funding to the system as a whole.
Now on to the original post:
How is time measured in IT?
The key unit of time in IT is the “project”. Projects are funded, each of which seeks a specific ROI and each project succeeds or fails on it’s own.
How is time measured in Physics?
In Physics, the concept of the “arrow of time” is modeled using Entropy. It’s how we know time is passing, which is the increase in the Entropy of systems. You put a drop of ink in water and it spreads out.
So what can we learn from physics through applying the analogy of Entropy to IT systems?
First of all we must understand what is axiomatic about Entropy:
* Definition: Entropy is the measurement of the energy in a system that is unavailable for work.
* Tendency: A closed system tends towards maximum entropy.
If Entropy is defined as the energy in a system that is unavailable for work, it means that some quantity of your IT systems are unavailable for work. I would suggest that you could roughly measure this by the number of IT persons dedicated to supporting, maintaining, troubleshooting and otherwise babysitting unmaintainable messes left by previous generations of IT projects.
Now you could blame the business projects for causing Entropy in IT systems, but you’d only be partially correct. The mechanism for reversing local entropy is adding energy. You could consider the influx of capital (project funding) to be a way of locally reversing entropy and putting more of your IT systems to work.
The problem is that without a structure in place, the energy is just converted into heat, not into more structure.
Therefore business projects have the potential to reverse entropy locally in IT systems… but it has to be applied correctly.
What I tend to see are Business Projects which are funded and executed without any respect for the implications to IT and I see additional unmaintainable complexity being shoved down into IT in order to meet short term business goals. Some of this complexity is shoved down into offshore teams. This is an attempt to reverse entropy locally within a subgroup. For example, the business team can push entropy to the development team and they can push it to the offshore team. Unfortunately, unless you optimize the whole system towards local decrease in entropy, you will eventually degrade the ability of the entire system to produce work.
This is a perhaps the most important principle in SOA–that unless you’ve aligned your business and IT organizations you will continue to increase entropy in your IT system. The implication is that less and less of your IT system will be available to do work.
This means that eventually IT will grind to a halt.
The organization that is unable to reverse this process will not be competitive.
