Getting to the Goal: Application Portfolio Management

It’s almost impossible to differentiate between business processes and the applications that automate them. Your business and its application portfolio have become so closely intertwined. So it is imperative that IT managers maintain a firm control over their applications. But rising complexity in the application portfolio threatens to undermine these systems and your control of them, making them expensive, inflexible, and unstable.

The Problem

Application portfolios contain complex relationships between hardware, software, people, and processes that have been adapted over many years. For instance, a Java-based order management system may relay data to a call center’s COBOL application, which relies in turn on a PL/I order fulfillment system.

Over time these systems only grow more complex. New requirements arrive, hardware is modified, new programming languages emerge, and architectural standards erode. So, portfolios become overloaded with duplicate, redundant, undocumented, and fragile systems. This rising complexity has significantly negative impacts on the IT organization:

• Development costs rise as previously simple changes require senior development effort
• Development risks increase as changes can disrupt the portfolio in unforeseen ways
• Infrastructure costs rise as operations cannot shut off the hardware that supports inefficient or redundant applications
• Business users can’t get new capabilities because development is trying to keep the lights on

Surely IT managers want to focus resources on producing new business services, and not on maintaining existing ones. Of course they do, but the sheer complexity of their portfolio means resources can’t be spared. And even if they could, it’s hard to know where to start. So, where do we go from here?

Getting Ahead of the Problem

Application Portfolio Management (APM) offers a path. It is a best practice that helps users intelligently prioritize development and modernization initiatives. APM works by measuring and trending key performance indicators about your portfolio. This data points IT management to where they should focus effort to get the most return for the business.

But what are these metrics should we collect? First, you should take a step back and start with the goals that you want to achieve for IT and business. What metrics you’ll need will come naturally when you take a goal / question / metric approach to understanding the portfolio. These goals come from interplay between IT and business stakeholders in the organization and will likely tie to the most pressing pains you feel now.



Common goals that I’ve seen at financial services and public sector organizations include:

• Shift development focus from maintenance to innovation: This goal aims to reduce the cost of supporting existing applications. For instance, through the removal of redundant systems.
• Cut the risk of business process failure or performance loss: This goal looks at cutting the complexity of a given set of applications. This is often achieved through architectural improvements and refactoring.
• Lower the cost of completing a business requirement: This goal aims to reduce the effort needed to move a work item through development. This is often addressed by enabling lower cost resources to work on a change.
• Lower the cost of IT infrastructure: This goal looks at ways to cut ongoing costs for hardware and software support costs. In addition to removing redundancy, this goal may aim to move applications to better supported and more economical architectures.
• Choose IT projects that are supported by business requirements: This goal looks at a strategic planning approach and how to ensure that new activities are weighted by their relevance to the business.

Goals will vary depending on not only the nature of your company, but also by other aspects of the organization. For instance:

• Level in the organization: Senior managers will likely have cross-organizational objectives versus more focused goals for middle-level teams.
• Role in the organization: Development, architecture, and operations teams will each have different requirements. For instance, lowering the cost of IT infrastructure may
• Maturity level: Whether your organization is looking to put out fires or align strategically with business goals will depend on the maturity of the organization.

Naturally, your own goals will depend on the specifics of your organization. Collaboration across these various facets of your organization will help to ensure that goal determination is synchronized and sufficiently complete.

Once determined, you can understand the questions you want to ask and the measurements you want to track that answer these questions. In the following posts in this series I’ll take a look at how we can determine the right questions to ask and the right metrics to collect to help get toward our defined goals.