Back when I was in college, there wasn’t a lot of debate about what a ‘program’ was. It was pretty clear. As time went on, however, our ‘programs’ became much more about systems of programs that met a business need, so we started using the term ‘application.’
Now, in the age of Service Oriented Architecture, we are faced with dual challenges. We want to increase the agility of the organization to meet ever-changing business needs, while reducing the overall complexity of the application portfolio. Deep under all of this, is the portfolio itself… the list of the applications.
An application is the most basic unit. It is what we build in our projects, and deploy into production. It is what we track, secure, manage, maintain, and retire. It is the unit that we use when calculating roll-up statistics like average size, average cost, and average complexity. We even talk about things like “reducing the number of applications” or “reducing the average application complexity” because they appear to capture the intent of reducing the total cost of ownership.
And there’s the rub. If we change the definition of ‘application,’ then we change the list. Our data has to be recalculated. Our cost of ownership calculations need to be recalibrated. Our understanding of complexity has to be challenged, validated, and re-applied.
On the other hand, most of the definitions of an application come from the days when we spoke with ease of a system that had its own database and its own user interface. We didn’t have layers like collaboration or messaging. We didn’t consider integration to be part of the basic application architecture, but rather placed integration as “that thing done on the outside edge.” Not any more. The old definitions don’t work now.
I’m not sure that an application still needs to be our most basic unit. Just as scientists once considered an ‘atom’ to be the smallest component of matter, only to have smaller and smaller particles described and understood, perhaps an application becomes a term that we keep around, but we no longer use in calculating the statistics of IT management. Instead, we’d need to understand the number of connected components in the infrastructure, and the complexity of them. (pick you word du jour)
On the other hand, perhaps it is more difficult to reeducate everyone to explain why “reducing the number of applications” doesn’t mean very much. It is hard to fight against the marketing coming out of articles in CIO and InformationWeek and various vendor presentations if they keep talking about ‘applications’ as the smallest unit of measure.
So, here’s the question:
Do we redefine ‘application’ so that it remains the smallest unit of measure, or do we redefine it so that an application contains smaller units of measure, units that replace it in calculating the cost and complexity of our portfolios?
If you believe you have the answer, please let me know.