Jul 7th, 2008 |
Welcome to my GTEC blog. This is the first in series of brief articles that will present some of the key concepts behind Application Portfolio Management (APM), Project Portfolio Management (PPM), and Enterprise Architecture. Over the course of this series I will touch on a number of topics centered on enterprise architecture and application portfolio management, including, federated CMDBs, distributed application architectures, communication and stakeholder involvement, risk management, IT governance, application lifecycle management, and architecture transformation.
I will begin this series with a brief description of application portfolio management and its benefits, and describe an approach to continuously review and improve the application portfolio within an organization.
APM and PPM are rapidly growing areas of IT management, as organizations turn their thoughts towards reducing costs, improving business and IT alignment, and increasing business agility within their organizations. Today, as much as 75% (or more!) of an organization’s IT budget is spent on routine maintenance activities – just keeping the lights on for existing applications. That leaves only a small portion for new application development.
APM and PPM give management the tools they need to make strategic decisions about what work should be done, which projects to fund, and how to improve their existing applications to better meet business and IT objectives. These tools encourage a holistic view of the enterprise, and focus on deriving business value through IT.
The key concept behind APM is that you cannot manage what you do not measure. Stated a bit differently, you cannot control or improve what you do not know. Application Portfolio Management is about gaining an understanding of all of the applications within your enterprise, and helps to reveal risks, opportunities, patterns, and trends within the portfolio. This information allows senior management to establish corrective action plans at the enterprise level and make strategic investment decisions to enable IT to better meet business objectives.
Let’s have a look at what is required for effective APM. A definitive and authoritative registry of applications is needed as the base for APM. Most organizations have multiple lists, and these lists will most certainly not agree with each other. They all present a partial picture of the enterprise. Application development has their list. Operations has a different list. The legal department has still a different view. These lists are maintained by different groups, each with a vested interest in one aspect of application management. The names and application properties used by these different groups will most likely be different, and this can be a difficult problem to reconcile. We will talk more about this later when we discuss federated CMDBs.
The second thing that is needed for APM is a means by which to measure application metrics. I suggest a set of metrics to create a balanced view of application qualities. Metrics can be gathered in Technology, Operations, and Business areas. There is no magic set of metrics that should be collected – the rule of thumb I use is that they should be a) readily available, or b) easily obtainable at a low cost. If few metrics meet neither of these conditions, a separate initiative to establish quality control measures, and supporting metrics, may be advisable. We will discuss metrics and measurement in greater detail throughout this series.
After collecting the metrics for each of the applications in the registry, it is now possible to put together a “portfolio view” of the applications within the organization. This view can be sliced and diced by technology platform, line-of-business, cost, or just about any other dimension that you care to measure. This provides the basis for portfolio analysis, which will expose risks, opportunities, and patterns within the portfolio.
Action plans can then be established at the enterprise level to address the findings of the portfolio analysis. For example, it may be discovered that applications written in PL/1 have greater difficulty hiring and retaining skilled resources. This may result in an HR initiative to attract and retain resources with these skills, a service contract with a third-party vendor, an executive decision to rewrite PL/1 applications in a different language supported by the organization, or a blend of the above. The decision is made with the entire portfolio and organization in mind.
Finally, by reviewing the portfolio on a regular basis, it becomes possible to track changes through time in the portfolio. Maintenance cost and quality (as measured through incidents and defects) are good indicators to track. Three two five measurement points at regular intervals will provide a good trend indicator. The release cycle within your organization will help determine a meaningful interval, and may also provide a convenient opportunity to collect additional metrics about these applications, such as financial data for the period. Reviewing quarter-over-quarter or year-over-year trends can highlight areas of risk before they bubble, and provide the organization with an opportunity to proactively address these risks. For example, if a group of applications in one line-of-business have experienced an exponential increase in maintenance costs for two years in a row ($10M, $12M, $16M), this could point to an underlying problem, such as high design complexity or lack of agility of these applications to meet new or changing business requirements. Effective Application Portfolio Management is made possible through this in-depth understanding of the individual applications and how they contribute to the enterprise portfolio.
Next week: bottom-up vs. top-down
