How do you break down the costs of owning your application portfolio into a components that can be calculated?  I have a simple expression that I believe encapsulates the TCO of an architectural component (legacy application, SOBA, service provider, etc).

The Total Cost of Ownership of your portfolio of applications is

   For Each n in Portofolio: sum( BaseCost(Environment(n)) + CpxCost*Complexity(n) + ConnCost(Environment(n))*Connections(n)) 

where

  • Complexity(n) is the complexity of application ‘n’ in the portofolio
  • Connections(n) is the number of systems that are connected to this one either by code or data dependencies
  • BaseCost is the cost of owning an app in each production environment.
  • CpxCost is the cost to maintain the app based on each ‘unit’ of complexity
  • ConnCost is the cost for each connection in a particular environment.
  • Environment(n) is a function that simply returns the environment in which the app runs (on an App Server, within SAP, in IIS, as a rich client, as a smart client, etc)

I’m proposing this formula.  It would require proof that it would accurately capture the cost of owning the portfolio. That said, it makes sense, and is fairly simple to understand.  The formula is based on the following ideas:

  1. The environment in which an app runs dramatically influences the cost of ownership
  2. The complexity of an app is a major factor in its cost of ownership, and not other considerations like the time it took to write it or the language it was written in .
  3. The number of dependencies between an app and another app is a factor in TCO.  Therefore, if you have a connection from app A to app B, the connection cost counts twice: once for A and once for B.    However, the nature of the dependency is not particularly key to the cost… just the fact that it is there.

I’d love to hear opinions on this formula.

 

 

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

4 thoughts on “TCO and the number of applications”
  1. Great post. I was planning on writing about this very topic of TCO of software. Couple of points. 1. I think the language and platform does effect the TCO because of the ease of introducing illusive bugs in languages like C++ compared to managed platforms and languages such as C# or VB.Net. And 2. I The nature of the dependency to its connecting systems probably is a factor. If the connection is stateless for example then the complexity of the connection is reduced because there are less variables. What do you think?

  2. Hello John,

    I am not sure about the cost of a particular language platform.  The cost of creating the code, both in dev and in maintenance, is a fairly small part of the overall cost of a project, and projects take up only about one third of the total cost of ownership.  I’d say that lack of usability of the admin interface or incomplete requirements gathering in support are two areas of key cost that have a greater influence on the TCO than the language chosen.

    You are probably correct about the cost of connections being variable by type.  That said, if I have a stateless call from one system to another, there are two aspects of the ‘connection’: the protocol and the schema of data.  Web services have some promise here, but they don’t adapt in real time.  COM+ interfaces are touchy at best, though.  Neither will hold up if the schema changes, and that’s the most frequent change.

  3. Nick,

    I think the language and platform have are a big influence on the agility of the product, during the maintenance phase. As the business evolves, having a system that cannot evolve at the same pace is a liability and a large factor in TCO, don’t you think?

    Knowing the requirements upfront is extremely important I agree, in terms of its effect on the stability of both the schema and the code base.

    It might also be interesting to see what effect the adoption of design methodologies such as TDD have on the TCO, given they have some potential to reduce the gap between the requirements and the implementation.

  4. Interesting, but I’m curious as to how one uniformily measures application complexity. Function points? LOC (hope not)? Something else?

    Capers Jones took a whack at this many years ago from a function-point perspective. He makes interesting, but not totally convincing arguments in his books on software assessment and quality.

    How do you propose to measure complexity since it is a big part of your formula. Intersting concepts!

Leave a Reply

Your email address will not be published. Required fields are marked *

3 × four =

This site uses Akismet to reduce spam. Learn how your comment data is processed.