Should Application Portfolio Management Start With Business Process Assessments?

Murphy_p_small  I heard an interesting comment from an executive at one of the big services firms - that application portfolio management (APM) efforts must begin by mapping business processes for the applications. I really don't agree, but thought it would make an interesting topic to discuss here. Part of the argument stems from how services firms are routinely engaged - to take action against one application or a group of applications to transform, re-engineer business processes, reengineer, refactor or otherwise modernize an application. All are useful activities and techniques, but they are not portfolio management techniques - they are modernization techniques. Modernization and APM live together on a continuum of application activity that includes in order:

  • Modernization - the actions we can take against an existing application - monitor & maintain, modernize in some way, replace (rewrite/pkg) or retire.
  • APM - which collect metrics about all of the applications to enable better management of the apps in the portfolio. APM collects metrics on all apps, but the goal is to isolate anomalies (duplicate apps, waste, costs not in line with business value, etc)
  • Rationalization is streamlining the portfolio and driving better modernization decisions - the actions that stem from th transparency created by APM
  • Strat Planning aligns the application information to business perspectives - the goal being to completely recharacterize business/IT discussions so that spending occurs in the context of business need (not necessarily business-unit need).

Interest in APM has grown over the past several years because IT orgs:

  • Don't know what they own - in fact they don't even have a basic, accurate apps inventory
  • Don't have any metrics about the apps (condition, cost, value to business, resource consumption, number of duplicate apps) So decisions are made based on technical criteria or seat-of-the-pants
  • Spend too much on the portfolio, but cannot defend where, when or why to the business - the portfolio is a black hole for resources

APM is not equivalent to BP, does not begin with BP, and cannot take a back-seat to BP mapping activities. In fact I argue that APM should be established first as a governance mechanism:

  • Why would you map business process against 10 duplicate apps? (I worked with a client who owned 17 duplicate apps in 16 geographic locations.)
  • Why map BP for applications you plan to retire or replace with a package?

I see and appreciate the value of mapping BP in the right cases - to match features required in a new or replacement package, make sure we don't lose a function through application retirement and as a prelude to consolidating 2 apps, etc. but that makes them techniques for modernization, not the starting place for APM. What are your thoughts?


re: Should Application Portfolio Management Start With Business

NOTE: One of our clients had a problem posting to this blog, so while the mechanics of repairing his access get worked out, I'm posting this on behalf William El Kaim.How can you select one of the 17 applications duplicated over the world if you do not know who is doing what with each of them?APM is necessary for IT management, to globally understand the portfolio they manage and relate it to their maintenance budget (vs. innovation). But if you need to make some decision to decommission applications, you will need to understand the impact at the business level. So you need to map them to BP. You also need to map to understand what will be the cost and benefit of doing it.Finally, I like this approach since it forces IT and business to talk. In my company APM failed twice because business was not involved.William El Kaim| Lead IT Architect, Global Products IT DevelopmentCarlson Wagonlit Travel

re: Should Application Portfolio Management Start With Business

Thanks for your comments Wiliam. It is indeed, important to understand the business "function / purpose" of an application to discern whether it is a duplicate application. But that statement is very different than saying that the starting point for all APM efforts is to map the business processes within and between all applications. That kind of mandate would doom most APM efforts before they began.In the case I mentioned - they performed a rudimentary inventory of applications (paper-based, 3-ring binder) and the inventory surfaced the fact that over time, they had purchased and implemented 17 COTS software packages that enable travel & expense entry (T&E).Their APM effort surfaced the duplicate apps and communicated the information in terms the business understands - the wasted money, time, and people-resources consumed by the duplicate apps. The business made the decision to eliminate the duplicate systems based on that information. The backing of senior business management (not an IT-led mandate) provided the political power to make it happen.So in this context, identifying the "function" of the applications - T&E entry - provided enough information to label them as duplicates. It was completely unnecessary to map the dozens, perhaps hundreds of "business processes" within each T&E application to move forward.APM is an intelligence gathering exercise to make more informed decisions WITH the business - it is not a technically-driven discipline, even though it gathers information about technical assets. Once APM surfaces the intelligence, business and IT management spawn Rationalization / Modernization projects to take remedial action.See my research on the topic - "The Application Management Continuum Offers CIOs A Contemporary Approach To Modernization" and "CIOs Must MAP A Strategic Application Plan".As an aside - it is not my intention to denigrate Business Process Mapping in this response - it has its place, but it is not the starting point, or even a prerequisite for APM.Feedback from all viewpoints is welcome.