More on Application Portfolio Management
It's interesting tracing the various threads related to improving the efficiency of enterprise information technology management. From my perspective it's like being at a huge party with different cliques gathered under various banners, all talking about basically the same thing.
For example, I've just been reviewing Frank Patrick's collection of project portfolio management links. Good stuff - but from a metadata perspective, the concept of application portfolio management is much more interesting, and I wonder how one can really do PPM without APM. This led to some further research and thought.
What is Application Portfolio Management? There are differences in emphasis: some (e.g. Pacific Edge) focus on financial modeling and planning that overlap with enterprise architecture, while others (e.g. HAL) focus on asset discovery and correlation. This is all consistent with the convergence model in my ERP for IT article submitted to BI Journal.
On the ground, here's what I'd expect to see in an APM effort:
An application portofolio would start with a definitive list of systems (Systems = applications in my mind). The alternative is many lists, created as one-offs for various IT initiatives. There is great value in creating the canonical application list and backing it with processes for keeping it maintained.
Don't expect this to be an easy task! There may be significant differences in how various parts of IT conceive of "systems." You'll find a need to support a hierarchy of systems and subsystems at least, perhaps with multiple levels (try to control them; indefinite depth is hard to tool and maintain).
The concept of system is a squishy one. We're not talking about mere software components; we're talking about assemblies of them. Some typical characteristics of a system:
1. Originally created by a specific funded project as a whole.
2. Has a specific support team
3. Has a term, acronym, or abbreviation frequently heard in IT meetings, hallway conversations, etc., especially at the midrange executive level.
Beyond that, it gets into very subjective terrain. Good luck! You won't get it "right," but you will definitely have something useful when you are done. The consensus is the important thing.
You'll probably also find several rollup hierarchies, representing your IT shop's reporting relationships, functional areas, and budgeting areas (all three of which may be different!) You're essentially building a reporting "dimension" and you should treat the exercise as such; I strongly recommend bringing in someone from the data warehouse team with expertise in such matters.
Such dimensions become locii of political consensus and (sometimes!) controversy. This controversy is a clear indication of value; get an executive sponsor (such as your IT organization's chief financial executive), stick with it and work through it! The result will be demonstrably greater alignment and agility in your organization.
The next issue is the TCO issue. What is the total cost of these systems? This is a very thorny question in IT. For each system you must consider:
- How much it cost to build: both client-facing resources and its share of underlying infrastructure. Note that a given system may have been built up by multiple projects: that's the key distinction between application and project portfolio management. This also indicates that all projects in your project portfolio must have a critical data element assigned: the system that they are working on. Not all projects result in the creation of a new system!
Pro-rating the IT infrastructure by application alone is a very difficult question, especially with the drive to consolidation of servers and other shared resources. Business applications have a complex web of supporting dependencies; mapping these is the goal of configuration management and your configuration management database would be an important foundation to this analysis.
- How much it costs to run: ongoing support staff assigned, incident volume, break/fix work, maintenance releases. There may be a number of point solutions (help desk, incident management, application support) you'll need to integrate for this data. If these solutions all have the same concept of system underlying them and being used to "type" their tickets, you are well ahead of the game.
- (Non-financial) The volatility of the application: how many changes are made to it. This may be a sign of a valuable application with lots of use, or of a poorly engineered application that should be shuttered.
- What it's worth to the business. A very difficult number, one that may need a balanced scorecard approach. But if you are doing business continuity planning, the business should be willing to tell you how much would be lost if that application were down - there's at least a starting point. This number drives a "criticality" ranking useful for both continuity planning as well as broader portfolio management.
Simply knowing the number of users for the application is important, but this should be validated with operational statistics.
All of these things of course would be part and parcel of a true ERP for IT system.
A note on outsourcing: There are outsourcers such as IBM who will happily come in and do this for you, arguing that "Engaging an independent provider to assist in assessing and governing the application portfolio enables a company to address these concerns while refocusing internal resources on core business functions."
I'm highly dubious that this is an area one should aggressively outsource. If your IT organization isn't at least doing application portfolio management, then what's left? You may as well outsource everything. This is the crux of aligning IT with the business and should be seen as core for the IT organization. As Meta Group notes, "application portfolio management will remain [a] business-critical discipline for Global 2000 organizations."
This is not to say that consultants can't help you with the legwork of inventory. But bear in mind they have no interest in your developing an ongoing capability to track and manage this yourself; instead of a robust integrated database, they may deliver you a bunch of disconnected spreadsheets that require tremendous labor to maintain and drive value from.
There are also vendors (such as Compuware and Fujitsu) who use "Application Portfolio Management" more in the sense of operational data center oursourcing ("we'll manage the applications in your portfolio for you"); this is NOT what I mean by the term portfolio management.
Finally, it seems Application Portfolio Management is a cross-cutting slice of problems and processes described in ITIL, starting with their section on Financial Management of IT Services.
One key difference is that APM focuses on applications. ITSM focuses on services. Services might or might not map to applications; generally, it seems they are coarser-grained.