The architecture that people fight about

It's kinda easy to pick a fight inside MS.  We are a very passionate lot, and no one walks around pretending to have the "official right answer."  For every question, there are usually many right answers, and a wide array of folks who defend them.

Some words, however, are sure to get the juices flowing.  Few things stir passions in IT like saying "let's kill your pet project / application / feature."  I suppose it is inevitable.  Folks get married to the work they've been doing.  No one ever wants to come up to the realization that they did an excellent job of creating high quality software that the company or market does not want or need.  That realization is not something that folks will never come to easily.

So when it comes time to break the news, you need something to back you up.  You need some business reasons or elegant principles or even a basic notion like "alignment" or "simplification" to justify the statement.  Otherwise, you are going to get people either shooting at you, or ignoring you (which is worse).

I like measurements for this job.  A measurement is an elegant way to show folks that their app has to be sacrificed because "we made a committment and the only way we can keep it is to remove our four overlapping apps and replace them with one.  Sorry..."

Challenge is: what to measure.

Here's some suggestions:

The number of applications in IT (see my definition of an application).

The number of stream-specific data connections between applications

The number of places where a single business capability is supported by more than one application (business-capability-application-overlap-count or BCAOC). For example, if you have two systems in which you enter an order from a customer, you overlap on the business capability of order entry. 

The number of places where a generalized application feature set is provided by more than one infrastructure system (application-capability-infrastructure-overlap-count or ACIOC).  For example, if you have two systems that store contracts and allow retrieval of them according to permissions and lifecycle, then you overlap on the application capability of document records management.

You also want to measure architectural capabilities of the apps, across the portfolio.  For example, distance between the current load and the maximum load (as expressed by a percentage of max load), as a measure of scalability.  System X is running at 26% while System Y is running at 84%.  We expect to have to upgrade System Y sooner.

In this camp, I'd consider things like: scalability against maximum, throughput against maximum, downtime inside SLA, downtime outside SLA, and Number of people-hours needed for each function point of change request submitted in the past two years as a measure of maintenance costs.  Demand can be measured by the number of outstanding change requests, or the total size of the change request queue (in function points) as a percentage of the function points of the app that are implemented so far.

Measurements against an app need to be rolled up to measurements against a portfolio of apps broken up by high-level process area, like Product Development, Marketing, Sales, Operations, Support, Legal, Financial, and HR. 

I think this is a good start on a balanced scorecard for IT application portfolio management.  It gives you the fuel you need to fight the inevitable battle that comes when you point a finger at "Joe's favorite order entry system."

Comments

• Anonymous
  September 06, 2006
  The comment has been removed
• Anonymous
  September 06, 2006
  Hi Nick
  
  Very interesting topic. One of our aim as Enterprise Architects is to killing infeasible projects and dublicate or obsolete applications, of course driven by business drivers.
  
  U mentioned a balanced scorecard for IT application portfolio management. Can u show a example on this?
• Anonymous
  September 06, 2006
  Is it always a good idea to reduce redundancy in application portfolio's? You give up flexibility. What if a company decides to split up? When parts of the organization are out-placed? Or give them full autonomy? When you consolidate the application portfolio the concerning parts of the organization will need to be able to access the application-infrastucture. You make them dependent, which in these cases is not desirable. I think you always have to think twice before deciding to give up redundancy. I believe a more viable solution would be to focus on automatic synchronization between the redundant systems. Or to make use of an independent accessible application service provider. Only in these two cases you preserve flexibility.
• Anonymous
  September 07, 2006
  At our company, we call the mapping of application functions to common global system that should be the one and only one system performing the function the "Bill of IT". The BoIT Scorecard measures how many apps provide overlapping functions and has been used to drive down from over 6000 system to less than 3000. If we have the functions defined correctly, we might even be able to say for the first time exactly how many systems it really takes to provide a baselined set of business capabilities, which is the Holy Grail for those who want to figure out what our sustain costs really should be if we drive out all duplicative efforts.