Watch as we shift to Application Portfolio Management inside IT

For the last 10 months we have been actively focusing our software inventory (focus on End of Life) to be less reactive and more proactive. We have had great successes, as I've discussed in past articles, and last year we did indeed approach our 50% reduction in inventory based on our initial inventory.

We are happy, but we can do much better.

If we keep doing the same things we did in the past (prior to our program kick-off in 2007), then we will end up with the same results:

  • Bloated inventory
  • Poor management controls
  • Underutilized or abandoned systems
  • Slow to react

The Application Portfolio Managment (APM) approach looks at our software inventory and calculates the benefits compared to the costs. Knowing what you spend, and the value that that software solution provides, now means you can determine if there is any value with keeping the same application (of if there is overlap). Since we already mapped our applications against a set of cabability frameworks, we are using those to drive our process.

Let me stop and give a quick explanation of our capability frameworks since it is so imperative to our process (and success). From an architectural perspective, we have three different frameworks (enterprise, infrastructure and cross-enterprise) utilized to map applications to. Each framework has multiple, hierarchical, tiers with increasing levels of detail. Any application can be mapped to any single-framework and many different nodes. We have specific owners of each hierachy who is responsible for managing the nodes and who work with the individual application owners to obtain and record the applicable information (in future posts I'll get more specific).

Here is an example of one node (two level-4 items) of our Enterprise Capability Framework:

  • Enterprise Capability Framework
    • Information Systems
      • Managing the IT Capability
        • Technical Infrastructure Management
        • Enterprise Architecture Management

What do we do with this? When thinking of IT as a business, there are certain capabilities that we need to deliver for our internal customers. These are as wide as the complete set of activities performed in our worldwide organization. There are many features which we off-source, such as the manufacturing of our processing equipment, but many we manage internally, such as email, architecture or telephony services. Knowing how the complete landscape exists means we also know where we have gaps (or growth opportunities). This is the focus of the framework mapping and as-is analysis in this area.

Now understand, this is but one component of the overall process. The actual mapping is the easy part; knowing that an application has certain functionality and delivers capability to businesses. The harder part is taking that data and sitting down to deterine the breadth and width of that capability along with how well (health) it does that job. With health assessments in place, coupled with cost assessments, we can begin to get a better picture of how our APM process will play out. This also means we need to start considering areas we have not historicaly played in, such as licensing management and the costs associated with that.

Our journey into this area started with a few key areas under a pilot approach to hammer out process issues and train the key architects in how to manage their own Level-2 capability nodes. We are learning as we go.

Have you taken your software management to the next step? If so I would love to hear about your lessons learned.