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."