Business doesn’t stand still.  It is dynamic and constantly evolving to keep pace with changing times.  Changes in society, market opportunities, competitive threats, and legislative requirements all influence the direction of a business.  The business must be agile enough to address these pressures to stay competitive, or in some cases, just to stay alive.  This means the whole organization.  The organization needs to respond as a whole, like an organism (ever notice these terms have the same root word, organum, meaning “instrument or organ”?), to evolve organically with changes in its environment.  The speed with which the organization is able to respond to these changes can be called the agility of the organization.

How can this agility be improved?  Elements from Business (business objectives, policies, strategies), Technology (computer systems, infrastructure), and Operations (people, procedures, efficiency of execution) combine to fulfill the delivery of business services.  The alignment of these elements, and their ability to work together as a whole, dictates the efficiency by which the organization can delivery its services.  The IT systems which automate or support the delivery of these services must therefore be aligned with these business, technology, and operational elements.

Application Portfolio Management will help measure and align these elements to improve service delivery.  Begin by creating a balanced view of each application in the portfolio.  Each application should be assessed against an agreed-upon set of metrics covering business, technology, and operational elements.   This will provide a well-rounded view of the overall health of each application, and will reveal strengths, weaknesses, trends, and patterns among applications within the portfolio.

Application portfolio management is not a one-shot deal.  It must be a sustained and continuous endeavour, to continually monitor and actively manage the applications within an organization.  This will ensure that the portfolio has the right amount of agility and quality at the right cost.  Agility just for the sake of agility is an expensive undertaking.

Because of the ongoing nature of APM, it is a prime candidate to be driven by a continuous improvement process, such as Six Sigma’s Define-Measure-Analyze-Improve-Control (DMAIC) process, shown below.  You can use any continuous improvement process.  The key point is that the portfolio needs to be continually monitored, and an ongoing formal process with a feedback loop is the best way to do this.

The APM process described above measures metrics in business, technology, and operations.  The continuous improvement process must ensure that the relevant stakeholders are engaged throughout the process, that the proper metrics are collected and analyzed, and that senior management is provided with the right information to make strategic decisions to improve the performance and alignment of the application portfolio with business strategies and objectives.  To be effective, the continuous improvement process must have a way of creating action plans to address the findings and recommendations resulting from the analysis of these metrics. This is done during the “Improve” phase of the DMAIC cycle.

It is important to realize is that all parts of the organization are vested stakeholders in the successful delivery of services.  Application Portfolio Management is not just about the applications.  It is about how well these applications align with the overall organization.  Just as we collect metrics from business, technology and operations, the resulting portfolio action plans should address improvements in each of these areas.  For example, a portfolio analysis may reveal that there is a shortage of resources with a particular technology skill, such as the PL/1 programming language.  A multi-pronged action plan to address this problem might include human resource initiatives, such as hiring and training programs, policy initiatives to consider outsourcing PL/1 application development and support, and technology initiatives, such as converting PL/1 applications to a new language platform.  These are just some of the possible action plans.  Each risk identified in the portfolio analysis will give rise to additional action plans.

Risks and patterns revealed during the portfolio analysis present symptoms of one or more underlying problems within the portfolio.   A recurring theme of lack of availability of resources with technical skills may highlight other underlying problems, such as a reliance on outdated technology, or problems with staff hiring, training and retention.  It is important to treat these underlying problems, and not just the symptoms.  Action plans should not be spun off in isolation from one another, as this may result in money being spent in the wrong place on the wrong problem.  These action plans work together to form an enterprise-wide strategy to mitigate risk, reduce cost, and improve performance of the application portfolio.  The iterative, continuous improvement nature of this approach allows the organization to establish a rolling, multi-year strategy to improve service delivery and agility.  This is the real value of APM.

You cannot manage what you do not measure.  This seems to be a recurring theme here, and that is really what APM and PPM are all about.  How many applications does your organization have?  Who uses them?  How much money is spent on maintenance, development, and operational support?  What programming languages are they written in?  How are the applications related to each other?  What parts and pieces constitute each application?  For many organizations, these are surprisingly difficult questions to answer.  But they shouldn’t be, and they don’t have to be.  Basic asset management principles are easy to employ to help manage the application portfolio.  An application registry forms the basis for effective application portfolio management.

The concept of asset management is not new. Thousands of years ago, shepherds watched over their herds of sheep.  They constantly surveyed the landscape for threats and enemies.  They knew how much food and water the herd needed, and made sure they were getting enough.  They watched for births and deaths, and looked after the health of each sheep in the herd.   They had an understanding of the overall state, count, and wellbeing of the herd.  And, of course, they kept all of this information in a database, or at least they would have if they could.

The application registry is a modern-day equivalent to the shepherd’s database.  Organizations who have adopted ITIL will refer to this registry as a configuration management database, or CMDB.  The registry keeps essential information on all of the IT assets within an organization, including hardware and infrastructure details, software configuration and interdependencies, budget data, quality data, a detailed technology profile, transaction volumes, service level agreements, etc…  It is the central and authoritative source of information about these assets.

This is very difficult to pull off.  The fact is that different parts of the organization are responsible for each of these areas.  Each of these groups manages their own area, but in most organizations there is a lack of higher-level coordination between these activities.  Each group has their own view of the world, which is not necessarily in agreement with the views of the other groups.  Thus, each group may have a different list of applications, with different names, gaps, and conflicts with the other groups.  These lists can even track information at different levels of granularity, which make the problem even more difficult to resolve.  And, in the end, each group is the owner of their own information.  It is a real challenge to build a holistic view of the enterprise.

The solution is to create a federated view of these diverse registries.  This is notably different from a central, single master registry.  To help build a holistic, enterprise view of the application portfolio, you need a way to link these separate registries and resolve data quality issues.  First, establish a central authoritative master list of applications and have all stakeholders rally around this list.  This means that all groups must agree to use the names and ids from master list.  Each group must respect the boundaries of information ownership, and avoid duplicating data for which another group is responsible.  Establish links between these information sources to create a real-time, federated view of the application portfolio.

The application registry is the key integrating and unifying force used to create a federated application portfolio view.  It is very important to establish clear governance processes around maintaining the application registry, and to include the registry in internal processes impacting the application portfolio.  This includes the budget planning cycle, PMO activities, software development, release management, incident and problem management, application lifecycle planning, etc….  This will make sure that the registry is as accurate and up to date as possible.

Next: Communication is a Key to Success

Last week I presented a basic continuous improvement cycle for Application Portfolio Management (APM).  This week I will contrast this approach with that of Project Portfolio Management (PPM) and demonstrate how these two disciplines can be combined for maximum effectiveness.

Application Portfolio Management is a bottom-up approach.  You start by counting all of your eggs, and then go about measuring certain things about them.  By nature of this approach, a certain view of the world is created.  You see what you have, and what state it is in.

Project Portfolio Management creates a different view.  This approach looks at which projects are being proposed or are underway, how these projects align with business goals and objectives, and what business value they bring to the organization.  With this in mind, strategic investment decisions can be made to select which projects should receive funding, and which ones should not.  PPM acts as a filter to maximize business and IT alignment.  This view of the world is quite different than that produced by APM.  APM looks at the assets that you have and how effective they are (“are we doing things right?”), and PPM looks at the projects that you should be doing (“are we doing the right things?”).

The best approach is to combine the top-down Project Portfolio approach with the bottom-up Application Portfolio approach.  This will help ensure that you are “doing the right things right”.  I will be talking about Project Portfolio Management in greater detail in a future blog, so stay tuned.

Next: What is an application, anyway?

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