Putting Application Portfolio Management into the picture

Gabriel Morgan knocks one out of the ballpark in this blog post that traces the connection from Business strategy through business process to applications, data, and hardware. 

Highly recommended for anyone who is an Enterprise Architect or aspires to being an Enterprise Architect. 

One aspect that Gabriel didn't address is Application Portfolio Management.  I'd like to wax a little on that subject.

Every Application costs money to own.  If an application ABC stores its data in a manner that is difficult to integrate, and you need to write another application PDQ that moves data around and transforms it, and even another application XYZ that is used to handle the data quality issues and workflow that results from all that data manipulation, then the cost of ABC includes the cost of owning and maintaining both PDQ and XYZ.  That overhead can get pretty expensive, pretty fast.

Application Portfolio Management is an IT practice that views the list of applications in operation within the bounds of an enterprise as assets with individual costs and business value.  This methodology helps to identify applications that should garner further investment, while identifying applications that should be kept running (maintained) without further investment, or even retired.

One valuable activity within Application Porfolio Management is to scan the portfolio looking for redundancy.  Let's focus on this one activity.

The degree to which an application is redundant with other applications is a useful indicator of whether the business is likely to benefit by retiring or trimming the features of one application in support of another.  In other words, if application ABC has four features, and application DEF has four features, and they overlap on two, then you are paying for eight features, but you get only six (plus the possibility that you have to add features in another application in order to reconcile the data from both).  A good simplification activity might be to add two features to ABC and turn off application DEF.  (this is a wild oversimplification, but it will do for now).

The problem comes when you have more than a few applications in your portfolio.  If you have 10, or even 100, then you can probably compare each application with every other one, looking for overlaps.  But if you have over 2,500 applications, as we do, then the cartesian product becomes absurd.  We'd be talking about making over 6 million comparisons.  Assuming each comparison takes two days to do (which would be about typical), then a team of 50 people would take about 1,000 years to complete the task.  Hmmm.  That's not gonna work.

Solution domains provide a mechanism to reduce that comparison overload, making an attempt to scan for redundancy feasable.  Because each domain contains a set of "system features" that a business person can understand, then it is not difficult to map each application to one domain.  (Technically, one application will map to one 'primary' domain with relationships to other 'secondary' domains as needed).  Once you have done this, then you can take your porfolio, break it into 82 parts, and get much smaller groups of applications.  Divide and Conquer. 

Assuming that our portfolio were to map evenly over the solution domain taxonomy (for the sake of public discussion), then we'd have about 30 applications in each domain.  Assuming that about half of those were clearly not candidates for further investment, then we would only need to compare, in each domain, 15 applications with one another.  Each domain would take a couple of months for a small team to analyze for redundancy.  Entirely do-able. 

In addition, you can choose to only analyze one or two 'core' domains to start.  That will allow you to prove the process works, establish value for your simplification efforts, and produce an action plan that people can use to measure return on investment. 

And what change would that require in Gabriel's diagram?  Currently, he has a single line from Application to the services within a solution domain.  I'd add another line, from Application to a new sub-box within Solution domain called 'Feature'.  This is a seperate mapping that is not useful for service management... but for APM, it's priceless.

Comments

• Anonymous
  August 10, 2007
  Hi Nick you might be interested in this: http://erp4it.typepad.com/erp4it/2004/01/delving_into_th.html and I have written a lot also about the application concept in my book. But the most concise statement is Martin Fowler's: http://www.martinfowler.com/bliki/ApplicationBoundary.html -Charlie

• Anonymous
  August 10, 2007
  Hi Charlie, I'm sticking to the definition on wikipedia that I linked from the article above (Application Portfolio Management). For the purpose of this article, it is not about configuration, or the distinction between "uses" and "owns" but rather the notion of how to CONSISTENTLY count the elements in the list. Honestly, consistency matters more than whether we have a mathematically pure definition, because the baseline is arbitrary.  We simply measure APM, and therefore create metrics for cost across the systems, and simplification progress, against the CHANGE in that number.   So, while your post is a fascinating entreaty into the concepts of infinite recursion, it is not a practical definition for the purposes of managing a portfolio of applications for the sake of simplifying that portfolio. Oh, and neither is Martin's.   Respect, --- Nick

• Anonymous
  August 14, 2007
  Nick, You're absolutely right, and I regret if I've given the opposite impression. I have written extensively in other posts about the fact that application is a subjective yet critical IT governance concept. I compare it to a specialized chart of accounts. It is neither right nor wrong, just more or less useful (and in that, Martin Fowler is correct.) And yes, the portfolio needs to be controlled so it is countable - agreed. The discussion I would rather have, is what do you think a Service is? I have been wrestling with this one with the ITSM/ITIL crowd for five years or more now. Have a look at http://erp4it.typepad.com/erp4it/2007/08/the-evolving-do.html and in particular the Troy Dumoulin debate. Do you think an Application is a subtype of a Service? Or are Services composed of Applications? -charlie

• Anonymous
  August 14, 2007
  @ Charlie, I will take a look.  Thanks for the invite. --- N