« Overlooked: What is the relationship between DCML and the Microsoft SDM? | Main | Useful resources on Application Portfolio Management »

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.

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/t/trackback/234815

Listed below are links to weblogs that reference More on Application Portfolio Management:

» IT Portfolio Management from Windley's Enterprise Computing Weblog
Charles Betz is talking about IT portfolio management , both top-down and bottom-up. [Read More]

Comments

Cross listed from http://www.erp4it.com

In my experience at fortune 500 and Global 100 organizations, I've observed and worked on (in one case led) initiatives to thoroughly analyze project portfolios and application portfolios from financial, data asset, personnel and software lifecycle perspectives.

There are some ubiquitous corporate characteristics that keep these two concepts separated, though how we might track them in an 'erp for it' world might have less distinction. These characteristics are:
The choice our financial markets have made to focus on quarterly earnings instead of intrinsic value or long term prospects when valueing corporations
The choice investors make to look at stock price growth instead of future business prospects when deciding which stocks to buy
In this context, I boil project portfolio management down to the act of managing the list of investments for which capital and expense dollars are going out the door today. There is a finite pie in any given quarter. Projects are prioritized in a portfolio based on one of these two common themes (There are probably others, but these are the two I've seen.):
What can I invest in projects that benefit next quarter's earnings directly, while I leave just enough in budget for the projects I HAVE to do?
How can I minimize the stifling burden of the projects I HAVE to do in order to squeeze out a tactical initiative that will improve revenue and/or earnings in the following quarter?
Application portfolio management, in the above context, focuses on the 'middle and end of life' timeframe. When organizations talk of managing an application portfolio, they are usually considering this question:
How can I reduce the cost of owning all of these diverse, haphazardly connected applications so that I can spend more money on new projects?
The challenges of application portfolio management often boil down, in a practical space, to personnel and depreciation decisions. Pure budgeting matters.
Any proposal to manage the metadata characteristics of these systems, such as what was envisioned by the OIM (open information model) prior to agreements to focus first on OMG's CWM (Common Warehouse Metamodel), would benefit the business objectives addressed by both project and application portfolio management.

The next phase of development would convert these activities from reactive exercises to proactive exercises, increasing the ability of the IT organization to positively impact the overall strategic direction of the corporation. Good stuff.

With regards to your note on outsourcing...

There are outsourcers such as IBM who will happily come in and do this (application portfolio management)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."

...I have two observations

First, some organizations don't have the application portfolio management capability or raw skill set in house and need to buy it.

Second, no matter what, some stuff will have to be outsourced in order to be successful because you'll never hire the internal bandwidth to tackle these problems.

Choose the right firm. Can't underestimate the value of that.

Choose a firm who will work with your team and get their hands dirty. There are plenty of large firms formerly associated with Accounting practices who are adept at "selling to the top levels of your organization", and less good at delivery. You're better off with a team that's over-reaching and being candid with you about it than one who is selling your internal capabilities down the river in order to maximize their billable revenue this quarter.

Thanks!

Sean


-----Original Message-----
From: Charles T. Betz [mailto:charb@visi.com]
Sent: Saturday, November 01, 2003 9:42 AM
To: dm-discuss@yahoogroups.com
Subject: [dm-discuss] Application portfolio management


Is anyone out there doing Application Portfolio Management by name? I've been looking at this and how it relates to metadata, see http://erp4it.typepad.com/erp4it/2003/10/portfolios_proj.html.

-Charlie

Yahoo! Groups Sponsor
ADVERTISEMENT


----------------------------------------------------
Post message: dm-discuss@yahoogroups.com
Subscribe: dm-discuss-subscribe@yahoogroups.com
Unsubscribe: dm-discuss-unsubscribe@yahoogroups.com
List owner: dm-discuss-owner@yahoogroups.com
----------------------------------------------------


Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Sean,

Thanks for your comments. Regarding the APM/PPM distinction, however, most projects at mature firms are incremental enhancements to existing systems. So how do you do PPM without APM? It's kind of like saying "I'm going to invest in these stocks" without taking into account their past performance or current financials. I'm a little baffled...

Not that I've got as much experience as you in these things. Did any of the initiatives you cite result in the creation of an ongoing, supported repository of any scale?

Re: outsourcing. I agree there might be IT shops that don't have the internal expertise. But I think my point still stands: everything else can very easily be outsourced. But portfolio management, especially in its aspects of business alignment, should be the last thing you outsource; it's like outsourcing your business strategy. IT shops that don't get this are really not doing their job. They are focusing on the things that "don't matter" per Carr.

Is there an enterprise architecture listserv where this discussion might be of more interest?

Regards,

Charlie

Post a comment

Comments are moderated, and will not appear on this weblog until the author has approved them.

This weblog only allows comments from registered users. To comment, please Sign In.