In my previous post, I discussed how you can analyze the business and technical value of your applications, and how architecture models are key in calculating metrics such as the business criticality or strategic value of applications. In this post, I want to focus on financial analysis, and in particular on cost models.
Of course, we do not advocate to replace your regular financial calculations and metrics. Even if that were technically be feasible, your financial department would never relinquish control of this (and rightly so). But what we can do, is to ensure that you have an accurate overview of IT cost and the effects of changes on that.
For example, if you want to consolidate your application landscape, what are the cost drivers for these applications, what would be the best order in which to phase out or replace applications, and how will the overall IT cost develop? The structure of your architecture helps to get a clear insight in this, as I will show below. Another typical business question is how to distribute IT cost across different business units. Architecture models help you here as well.
To calculate the total cost of ownership of an application (or of your entire IT landscape), you would typically consider cost factors such as:
These metrics can be assigned to applicable elements in your architecture. For example, software cost would be associated with application components and system software elements; hardware costs would be related to devices and networks; data center costs would be assigned to facilities; support costs to the actors and processes in your IT organization; and service provider costs to (external) business, application or technology services.
But next to assessing these basic metrics, you can do more with your architecture models. If you know the relationships between, say, the applications and their supporting infrastructure, you can distribute the infrastructure costs across these applications. In its simplest form, that would be an even distribution, e.g. if five applications use the same server, each gets 20% of that server’s cost assigned. If you know more about the actual usage, you can put that as an attribute on the relationship with the applications and do a more fine-grained calculation. The same holds for the various other costs involved, e.g. for maintenance and support or for the use of external services. Adding this all up provides you with an accurate picture of your application TCO.
The model below gives you an impression of how this works. We look at the capacity needed, and based on that we assign the relative cost contribution to the application.
Relative cost contribution for financial analysis
If you do this for the basic elements in your application landscape, you can of course aggregate the cost at higher levels as well, by simply adding up the cost of the components that make up larger applications, application groups/domains, etc.
Combining these cost numbers with the lifecycle analysis I discussed in a previous blog, provides you with an even more powerful instrument. You can follow the evolution of IT cost over time and compare alternative future scenarios, for example different ways to reduce your application landscape as in the example above, and thus maximize potential cost savings. One of our clients, VIVAT, has been very successful with this approach in rationalizing their IT landscape. For more information, see their customer success story.
Of course, models like the one above is probably not something you would show to the financial professionals or executives in your organization. Rather, you would create management dashboards with charts that depict the data in more familiar form. There, you can also cross-reference this data with other information, e.g. combining application cost with business and technical value, size, age, complexity and risk. The figure below (click to expand ) shows an application portfolio dashboard that combines several such metrics.
Application portfolio dashboard
As an aside: You could even do this type of calculation for the cost of the IT organization, computing for example the cost of incident management per incident, based on the cost of personnel, their office space, the tools they use, etc. However, most organizations will already have some numbers for this and duplicating that effort makes little sense. Moreover, this kind of data is typically the responsibility of the HR and/or finance department and it might not be wise politically to come up with alternative calculations.
When you have an insight in these IT costs, the next step can be distributing these across the various business processes and business units of your enterprise based on the use they make of that IT, again using the relationships in your architecture model. This may land you in even more politically charged territory, however, since this will rapidly become a discussion about who should pay the bills…
Nonetheless, in our experience creating these kinds of insights is very valuable, and if you show what could be done to responsible management, they might rapidly ask for more. In the example of VIVAT mentioned above, this approach rapidly gained the attention of the board room. So, if you struggle to get heard by your executives, this may be one way to get their ear.