Search This Blog

Thursday, April 22, 2010

Application Portfolio Management - Best Practices

It's tough to control your application portfolio. Your systems have been developed over the course of years or even decades. The people that developed the apps may have moved on to other roles and documentation is out of date. So, the portfolio gets more and more complex. And that complexity means they are slower to adapt and more expensive to maintain.

Application portfolio management is an approach to help return control to application managers. In this series of posts, I'll take a look at best practices for managing the application portfolio.

  • Goal: Constant fire-fighting is no way to run a development organization. Especially in today's era of tight budgets and fast change. In this post I'll summarize the goal of APM and set the stage for a discussion of best practices. Read the post.

  • Questions and Metrics: APM data should answer questions that address a specific goal. Say, ‘why is this business process inflexible?’, ‘where can I cut costs?’, or ‘where is my software architecture flawed?’. To answer these different questions requires different combinations and weightings of data (user surveys, application code, or external sources). Sometimes more of one source, sometimes another. Read the post.
  • Decision-Makers: APM data needs vary based on where you are in the organization. Higher level managers require higher level abstractions, particularly of technical metrics. Also, different types of users will have different data needs. An architect may want technical complexity data, but it may only be meaningful to him if it is filtered by architectural models. Read the post.
  • Maturity: There are different levels of maturity for decision-making. This maturity directly affects which metrics are accessible in the first place and also indirectly because it determines the kind of business goals that an organization is prepared to address. Read the post.
  • What’s next: As a particular initiative moves from “decision” to “action”, different data may be needed. More “bottom-up” data may be necessary to implement the decisions at this stage. Further, different metrics can be monitored to ensure the success of a given development or modernization project as it is executed. Read the post.


  1. What does it mean to me?

    This post and the linked ones are great! But so many words!!! I am dyslexic and so by the time I have finished reading posts I have long since forgotten what the start said. Recently I had to try and explain the different functions of parts of Micro Focus to potential employees and simply could not explain APM. COBOL, compilers, runtimes, enterprise server, silk, dev-partner and the corba stuff - NO PROBLEM. But apm - NO CHANCE.

    Someone once asked the Enterprise Architecture group on Linkedin for a justification of EA in 7 or less words - here is mine:

    "You think architecture is expensive, try chaos".

    That ended the discussion. So - please end the discussion on APM - define what it is for in a tweak - aka < 140 characters.

    This is not me complaining here - I REALLY REALLY REALLY NEED someone to do this so I can fulfil my corporate responsibility of disseminating the benefits of the technology. I am also 100% sure I am not the only person who is struggling here.

    All the best - AJ

  2. Hi Alex, sure:

    APM = Measuring applications to determine where to allocate development effort.