Application Modernization

Application Portfolio Management

Application Portfolio Management, or APM, is a methodology to sort development activities by business priorities. By comparing key metrics related to the application portfolio, managers can choose where to invest and modernize in their application portfolio.

Application Portfolio Management is about more than creating a roadmap for your applications. It is about synchronizing IT priorities with business priorities. As a result, Application Portfolio Management should be viewed as an extension of the strategic planning of your organization. After all, your applications automate core business operations, so you should invest to support the operations that matter most to your organization.

This means that you must collect measurements about your application portfolio in the appropriate business context. And these metrics must be geared toward answering strategic planning questions that help you to focus development priorities on business priorities.

Application Portfolio Management must be a business-centric activity. That is, it must answer the questions you need to make intelligent decisions about where to allocate IT resources to support business goals. To understand better, let's look at the constituent parts of an Application Portfolio Management approach.

How Do You Measure Application Portfolio Management?

Application Portfolio Management should not be isolated within IT. It has broader implications across your entire organization. After all, your application portfolio automates every major business process. As such, the determination of where to invest IT resources cannot be made in a vacuum; it must be made based on the right combination of business and technical information.

It is important to begin by determining what the end goal of your APM initiative is. Is it to better manage outsourcing relationships? Is it to cut wasteful spending? Is it to ensure that IT resources are focused on business priorities?

These determinations will influence the kinds of questions that you want APM to answer, and hence the kinds of data that you will want to collect. Let's look at the kinds of data that should be collected and how to organize it to make meaningful decisions:

Business Context Makes APM Meaningful

Your application portfolio should be viewed as a collection of business assets. This means that it should be managed from a business perspective. For instance, if it is important for your organization to keep core business processes agile and cost efficient, then managing from a business process context is important. If monitoring outsourcing providers is important, then managing from a service provider context should be employed.

An effective approach to APM should apply these business filters to the application portfolio. By placing abstractions onto technical assets, you can determine which assets are associated with a given business context. This provides a framework for consolidating metrics and answering business questions that are important to you.

This approach does not exclude technical issues from the decision making process. For instance, you may wish to also manage the application portfolio based on the availability of technical resources to support existing environments. The only difference is that the 'overlay' onto the application portfolio is now a technical one, in addition to the other business-centric contexts.

Technical Metrics Provide Richness for APM Decisions

Depending on your goals for APM, technical metrics can play a more or less important role. The importance will also vary depending on the role of the APM user. For instance, a business analyst or line of business manager may be less likely to require significant technical details. A development manager or application owner may be more likely. Again, it will depend on the decision that APM is supporting.

Technical metrics are typically generated by analyzing source code. In doing so, analysis tools will collect information like cyclomatic complexity, essential complexity, lines of code, dependency levels, function points, and other metrics. Many of these measures are industry-standard measures and can be used to compare applications built on the same environment, and sometimes across environments.

Selecting technical metrics can be important. They can help determine the flexibility of your applications, and hence their ability to adapt to new business priorities. They can also be important for determining the likely scale and scope of application modernization and maintenance activities.

Stakeholder Metrics Provide Business Meaning to APM

Determining where to focus IT resources often is based on corporate priorities. An effective approach to determine the relative weights of these priorities is to solicit input from stakeholders. Similarly, gauging the value and risk of applications, business processes, outsourcing relationships, and other elements will come from feedback.

Typically, this data is collected via surveys. While this can be achieved with spreadsheets, it is advantageous to use browser-based surveys to simplify the distribution and collection of survey data. Surveys will often ask qualitative questions such as, 'How important is sub-process A to the execution of process B?' However, the mechanism can also solicit more quantitative data, such as inventories of application portfolios and cost data.

Data from Other Sources Enriches APM

To improve the quality of your portfolio management decisions, other data may be collected. Again, the kind of decision that you want to reach should be the guide to what kind of other data should be targeted. Examples could include cost of development staff, number of bugs, amount of queued functional specifications, frequency of change, and number of staff assigned to a project.

Much of this information will be available in electronic format, stored in SDLC and ERP systems. The data must be collected from these various sources and associated with the contexts that help answer the APM questions you are interested in.

Combining Metrics Allows APM to Answer Business Questions

The collected metrics only become useful when they are used to answer questions that aid IT planning. As discussed earlier, this requires that the metrics be combined and presented in the right business context in the right combination. We will want to select meaningful measures and associate them by the groupings that are useful in this process.

For instance, if our aim is to ensure that our outsourcers are producing quality outputs, we may wish to trend architectural quality metrics over time. We could then introduce the notion of complexity to contrast quality trends versus initial quality. We could also combine these measures with information about change frequency to adjust for high-pressure maintenance environments.

But these measures are only so useful if left on their own. What makes them meaningful is to associate them with the groupings we have defined. So, to measure Outsourcer A we should pull complexity metrics regarding the source code under management by Outsourcer A. That is, the code in the 'context' of Outsourcer A. Other data, like survey data or data from other technologies, can then be associated with the same context. This provides a rich set of information for making decisions.

Similarly, we may decide to manage our application portfolio by business process. In that case we may pull survey data about business value and associate it with a business process context. Technical metrics could similarly be correlated based on the hierarchy of contexts that we have placed on our source code.

The results are measurements that make sense to the business, address your identified business questions, and provide compelling support for budget allocations.