February 7, 2016

APM (Application Portfolio Mgt) – a pre-requisite for cloud migration

While most people are reasonably familiar with the term PPM (Project Portfolio Management), fewer have heard about its poorer cousin, APM (Application Portfolio Management). The main reason is that PPM is about shiny new initiatives, which everyone wants to be associated with, whereas APM is about managing production applications and understanding their cost base. Or, put more crudely, nobody ever got promoted by keeping the lights on – even though it accounts for 80% of the IT budget.

In simple terms, APM is a framework for inventorying and managing a portfolio of applications from a value perspective (ie costs vs benefits) as opposed to a pure cost perspective (ie what it costs to run them). The objective of APM is to justify ongoing operational and investment funding of applications from cradle to grave. In the absence of APM – unfortunately the norm – applications fall into a black hole after project delivery, and many years later you end up with a smogasbord of different systems built at different times, by different people, for different reasons, which essentially end up being funded by default year after year. Hence the CFO’s burning question to the CIO: “where does all the money go?”


So what has APM got to do with cloud computing? A lot actually, because any strategy for migrating applications to the cloud logically needs to start with an analysis of the existing application portfolio. This will enable a clear understanding of what can be migrated to the cloud and what cannot (not all mainframe and mini-computer apps moved to client/server, and not all client/server apps became web-based. Similarly, not all current apps will move to the cloud).

The figure below (click to enlarge) shows a typical APM analysis which positions applications based on costs vs value, thus showing which applications you want to maintain, replace, tolerate or retire. Similar analyses can be done on other dimensions like, for example, architecture, available skill sets and technical quality.

APM example

APM example

The apparent simplicity of the above analysis belies the complexity in getting it done; in most organizations, there is hardly any benefits monitoring on the value side, and very little ongoing application cost management. And doing a quick “APM-light” based on estimates is unlikely to be credible. For example, the business might rate an app as high-value because to declare the opposite could be politically risky. And on the IT side, fully costing an app from a TCO (Total Cost of Ownership) perspective is no mean feat. Properly done, this would cover not just the usual suspects like hardware, software and operations – and hopefully infrastructure too – but also some sort of burden rate or allocation, however basic, for overhead. This would include data centre operations (people), vendor management and admin (people), space (sq. meters or feet) and utility costs (power and cooling). To complicate things further, your average project- or service-manager probably doesn’t have the financial expertise to do a proper analysis: most don’t know the difference between capex and opex, or how depreciation affects costs, and why a decision to retire an app which is not yet fully depreciated could have unacceptable P&L impact from the resulting write-off.

A proper APM initiative is therefore a project in its own right, which can easily take 3 months or more in terms of both duration and consulting effort. But it’s a pre-requisite to any cloud strategy; otherwise what are you going to base your decisions on?


Once you have completed the traditional APM analysis described above, you can apply the cloud-related migration criteria to see which sets of applications can potentially be moved to the cloud – public or private. Here are the most common:


  • How realistic is the business case (ie in terms of ROI, business agility, initial project costs and ongoing operational costs for vendor-, application- and service management)?
  • How realistic are the numbers provided by IT for current application TCO, which will impact the business case?
  • The timing of capital refresh cycles for hardware.
  • Enterprise-wide capex restrictions.
  • The ability for the P&L to absorb write-offs of assets still being depreciated.
  • The costs of implementing a disaster recovery plan for mission-critical apps to cope with critical events like service outages or vendor insolvency.


  • Executive sponsorship and leadership for strategic cloud transformation.
  • Data privacy and confidentiality (regulatory, legal and contractual).
  • Productivity/commodity apps vs competitive differentiation apps.
  • Business agility that cloud apps could bring over current on-premises apps.


  • The variability of usage patterns (ie daily, weekly, monthly) and workload (ie CPU, storage), and the uncertainty of predicting growth (ie the business’ need for services and resources). Addressing these criteria might require the elasticity and scalability of the cloud.
  • Level of – justified – customization needed.
  • Data migration – even with good quality data, it’s unlikely to map neatly to the cloud provider’s data structures. And at the other end of the scale, the migration of poor quality data has to be preceded by a clean-up – when at all possible – thus becoming a project in its own right. There is a saying when it comes to data quality: no matter how bad you think your data is, it’s worse.
  • Level of integration to other apps and data sources, both cloud and internal. This is especially true for MDM (Master Data Management), eg unique customer and order numbers across CRM and ERP (see previous point).
  • Security.

In conclusion, Application Portfolio Management – predicated on a credible understanding of the IT cost base – is a pre-requisite for any cloud migration strategy. Only then can we start building the business case applying the above criteria, and obtain the executive sponsorship and leadership required for strategic cloud transformation.





Speak Your Mind