Application portfolio governance for business value

APG in context 

APG is an essential strategic planning capability of an IT organization. It ensures that investments in the application landscape are in line with business strategy and that investments are made in a way that minimizes cost and risk, while at the same time delivering the required functionality and flexibility to fulfill business goals.

In APG the application landscape is organized into smaller portions—portfolios—each having a clear functional purpose and business ownership. This creates the governance structure for the application landscape within which analysis and decisions can take place.

A fundamental requirement for such analysis and decision-making is an inventory of the applications with their associated performance indicators to support evaluation. Maintenance of the application inventory and associated application information is core to APG success. This is reflected in the attention paid to the topic of information governance in this document. 

Once analysis has been done and decisions have been taken, plans are required to facilitate communication and implementation of these decisions. Such plans are manifested within APG in the form of application life cycles and statuses which are communicated in the form of application road maps. Such road maps ensure that the different IT road maps are synchronized (e.g., technology road maps and project plans) and that business and IT activities are aligned. The place of APG in the overall strategic portfolio management process is illustrated in the diagram below. 

The goals of APG

The purpose of APG can be split into the following core goals: 

• Improve application alignment to business strategy and to required business capability support
• Reduce business risk exposure caused by threats related to applications in the portfolio
• Increase the agility and flexibility of the application portfolio in responding to changes in business requirements
• Reduce the running and project costs of the application portfolio—often primarily by reducing the number of applications.

Which of these goals is given priority at any given point in time depends on both events (e.g., an acquisition or a change in market conditions that requires rapid cost savings) and on the portfolio in question (portfolio strategies are not uniform across the enterprise, rather they depend on the strategy of the business represented by that portfolio, e.g., some portfolios may require investment and flexibility while others may require neither). Hence the targets set for the application landscape need to be set at the individual portfolio level to better match business needs and also to give individual portfolio managers a framework to guide their work. Some of these goals (e.g., costs, number of applications) will also be aggregated to overall values for the entire application landscape to enable alignment to corporate targets. 

Whichever of the four basic goals are given priority, effective APG requires more detailed information on the level of cost, business alignment, risk and agility of an application in order to be able to target those goals. This means answering much more specific questions on the applications. Examples of such questions and the goals they support can be found in the matrix on the following page.

Looking at the matrix, two things become apparent. First, the information being analyzed is definitely not known by one single person. Within just these few questions very different perspectives on the application are represented—e.g., business, technical and operational—and different stakeholders will know this information or it will be available in other management systems and needs importing. Secondly, there is a lot of information on applications that could be gathered and analyzed.

Both of these observations are reflected in the practices described in this document. Indeed, special care is needed to structure the information required to meet APG goals and to identify the stakeholders responsible for the information. Equally important is pragmatism— understanding the maturity of the organization and understanding the granularity and quality of application information the organization is capable of successfully maintaining. Both of these issues are addressed below.

To close, the information gathered is analyzed within the context of the portfolio and of the goals set in order to make the decisions such as:

• Which applications should be retired?
• Which applications should be invested in?
• Which applications can be consolidated or optimized?
• Which applications are to be tolerated in the landscape but need observation?
• Which applications have risks that should be mitigated?
• Which applications need to have their life cycles extended or reduced? 

Main activities in APG

The diagram below shows a breakdown of the tasks that belong to APG. This breakdown is colored by the level at which the tasks are performed: corporate, portfolio or application level. The overview focuses on the main areas that need to be covered to ensure that APG can function and deliver reliable results. A brief description of the four main tasks is given in Figure 2. Each of them is covered in detail in the section on executing the APG program.

APG program governance

These are all the activities pertaining to establishing the APG program and ensuring that it can run effectively. It covers areas such as setting and monitoring goals, policy management and governance of portfolio structures. These activities are essential in ensuring the success of the APG program and they are done at a corporate level to establish a standardized approach to APG. In large organizations, this “corporate level” would probably manifest itself as a council of responsible managers (e.g., CTOs or chief architects) from the company’s different IT organizations who collaboratively define the parameters and policies governing the APG program for the organization. 

Information gathering

This covers all the activities required to ensure that a complete application inventory exists; that it contains all the information needed to assess the application portfolio and that this information is up-to-date and reliable. To do this, the information requirements to assess the application have to have been defined along with the source of the information—either from a person who has a role with responsibility for an application or imported from another management system. These issues are discussed later in the next section on getting started. The activities around information gathering are done at the level of individual applications and typically coordinated by an application owner or other responsible staff. 

Portfolio assessment

These are the activities that convert the information available on the applications into ratings and analytics that can be used for prioritization and decision-making. This provides insight and guidance on the strengths and weaknesses of the application portfolio and enables portfolio managers to be able to justify proposed changes to the applications. Communication of road map proposals and monitoring approval and implementation is an important task of portfolio management that ensures optimization of the application landscape. These activities are done at the portfolio level. 

Application management

These are the activities that implement changes to applications in the portfolio—either as a result of the portfolio management processes or based on analyses done by application owners at an application level. Examples are activities such as sun-downing an application or creating new versions of an application. The main responsibility within the scope of this APG capability is to document and monitor such changes, not the execution of the change itself. Application management activities are done at an application level by an application owner or other responsible staff.

Deciding what are applications and naming them

Essential to APG is an inventory of applications that are to be analyzed and optimized for better business alignment. To build this inventory it is fundamental to understand what an application is, i.e., what belongs in an application inventory and what doesn’t? For example which of the following applications would fall under the governance of application portfolios? 

• The bespoke financial trading system 
• The email application 
• The SAP^® system
• The BI engine
• A desktop Microsoft^® Excel^®-based application for calculating sales provisions

To answer this question, let’s revisit the first of our APG goals: 

"Improve application alignment to business strategy and to required business capability support."

The focus of APG is alignment to the business and thus for an application to be an application, it has to be used by the business to fulfill a specific business function or support a specific business process.

Based on this, any sort of software that the business does not use directly, e.g., a Web server or database system should not be considered an application but a technology. Typically such technologies are part of the infrastructure on which an application runs but they are not applications. This does not mean that there is no governance for technologies. Indeed, there should be a program for technology portfolio governance to ensure that technology roadmaps are aligned to application needs, future technology trends and vendor roadmaps, and also to avoid technology redundancy and overlap. But this is not in the scope of APG or this practitioners' perspective.

Similarly, software that the business uses, but that does not fulfill a specific business function or process, i.e., if the software does not contain any business logic, should not be considered an application. Examples here are the basic business enablement tools such as Microsoft^® Word and email systems.

Based on this, let’s return to our question above and decide which items in the list should be in our application inventory.

• The bespoke financial trading system – Yes. This clearly is used by the business and fulfills a specific business function.
• The email application – No. This has no specific business logic
• The SAP system – Maybe. The SAP system is certainly used by business and supports business functions and processes. Where it may fail is that it is not specific enough, in which case it needs to be inventoried as not one application, but as several applications, e.g., SAP CRM, SAP HR and SAP Financials.
• The BI engine – No. The BI engine itself is a productivity tool, it is infrastructure. However, in many organizations you can often find complex financial analytics/management reports built on top of the BI engine that are used in, e.g., the financial consolidation process. These should be considered applications.
• A desktop Excel-based application for calculating sales provisions – Yes. Although Excel itself is a productivity tool, the implemented logic is fulfilling a specific business function. Knowing that such applications exist and how they are used is in fact critical to fully understand the IT risk.

In most cases it will be pretty clear which systems in use are applications and which are not. For the cases that are not clear the following schemata may help—but is not definitive.

Another aspect that should be considered when building the inventory is the granularityof the applications to be maintained in the inventory. Is it sufficient to have one inventory item for all versions, variants and deployments of an application? Or do we need an entry for all of these? As the topic of APG is one focused on business alignment and planning, the level of deployment is in general too detailed. The level of deployment serves operative management of applications, e.g., change and configuration management. The use of application versions and variants is definitely relevant to APG and how extensively they are maintained in the inventory will depend on the use cases in focus and on the maturity of the organization.

When naming an application, practice it to ensure that the name means something to the business users that use it. This facilitates their contribution to the application portfolio tasksand processes. Often there exist different names for the same application across business, application development and operations. The goal should be to harmonize these names. If that is not possible, ensure that a mapping between them is maintained in the inventory to ensure all stakeholders can easily identify them and to support any synchronization of data with other application management systems.

Whether deciding on whether an application is an application or deciding on the name of an application, one practice is essential: Be pragmatic. Make a decision and don’t waste valuable time on long, unproductive discussions. If the decision turns out to be sub-optimal, you can always revise it further down the line.

Understanding current APG maturity

Understanding the current APG maturity of the organization is essential to getting results. The better the understanding of the maturity, the better you know which results can be delivered. It is also essential to the successful implementation of a system supporting APG such as Alfabet from Software AG. Trying to implement a solution requiring high maturity in an organization of low maturity will fail. Alfabet from Software AG can be configured to support different maturity levels—choosing the right level ensures success.  

Maturity of a discipline such as APG can be assessed using a maturity model such as CMMI which is based on the existence of certain report types, tool usage, roles and processes. The result is usually a maturity score between 0 and 5 (indeed usually below 2!).

Such an assessment can be very labor-intensive so in this guide we recommend a more pragmatic approach based on the application information that can be gathered and maintained. The assumption here is that if the information can be gathered and maintained (or could be with an acceptable amount of effort and a good tool), then the processes and responsibilities are already in place—formally or informally—that represent a certain level of maturity. 

This pragmatic model being a blunter instrument than a full-scale assessment, it contains only three levels of maturity: 

• Low – absence of a basic application inventory or the inventory is patchy, incomplete and not up-to-date. In this case the program needs to focus on establishing the roles and responsibilities to create and maintain a basic inventory. 
• Medium – an inventory exists with information on various dimensions such as technical platform, business criticality and usage. The inventory may have gaps and not always be up-to-date. In this case the program focuses on filling the gaps and ensuring the inventory is maintained. It also focuses on extending the inventory with new information to fulfill specific use cases.
• High – the inventory exists and is well maintained. There are very few gaps in the inventory and the granularity of information is high. Information models and detailed functional models are also in place to support the granularity of application information.

In assessing maturity, it is also important to keep in mind the goals to be reached and the information requirements to meet those goals. There is no point in assessing maturity based on information that is not required and so should not be maintained. Having a complete and comprehensive inventory is—for its own sake—not a goal that should be followed. 

In federated companies with large independent IT organizations, the maturity can be very different from IT organization to IT organization and so each IT organization should be assessed independently. If the differences are blatant, then the APG approach will need to be different for the different IT organizations and any tool implemented to support APG will need to be able to support different APG maturities in parallel (e.g., Alfabet from Software AG). 

Which maturity level should be maintained will depend on the costs and benefits involved. A medium maturity will almost certainly pay for itself in the benefits delivered. The highest maturity may only be required to address critical problems in projects initiated after the portfolio decision is made or to support core differentiating business capabilities in delivering competitive advantage. 

Knowing the information requirements

The information requirements of APG depend on the goals being followed.

If the goal is to reduce costs and risks by migrating from old technologies, information on the technology platform is required. If the goal is to reduce the number of applications, then it is important to understand business usage (high or low) and how much overlap there is in application functionality. Being clear on your goals is critical to success and helps avoid maintaining information that will not be used.

Once information requirements are known, it is good practice to structure this information according to different perspectives such as business, cost, risk and technology perspectives. This structuring helps to understand the person or system that is responsible for the information. More importantly, it is the basis for assessing applications from different perspectives to support trade-offs, e.g., accepting an application with a sub-optimal technological platform due to its superior business support. The core practice perspectives are described in the following sections. 

Business perspective

The business perspective has the aim of understanding the business usage of applications, how critical they are to the business and what business requirements will affect the applications. The questions below help to build the business perspective:

• Which organizations use which applications and for what purpose, e.g., business process?
• Which applications are most critical to business operations, i.e., cause the most damage when not available?
• Which applications provide the most value to business, e.g., contribute most to revenue streams? 
• Which applications have the highest number of users?
• With which applications is the business most/least satisfied? 
• Which applications need to be “agile” (i.e., easily changed) in order to support changing business needs? 
• Which applications are crucial to future business strategies?

Where to get the information 

The business perspective has to come from business owners and users. This is the key to business alignment. However, getting business engaged to provide the business perspective is a significant challenge. One way to approach this is to initially provide a strawman assessment and get business to review it. This can be done in workshops business area by business area.  

Required maturity

Assuming business gets involved, an organization of medium maturity can answer most of the questions asked. The questions on required agility and future strategies probably require a high maturity level. 

Functional perspective 

The functional perspective aims to understand the business functions the application supports including any overlaps and gaps. Its main usage is in support of consolidation or SOA initiatives. The questions below help to build the functional perspective: 

• How large is the functional scope of an application?  
• Which applications have functional overlap and could be consolidated?
• Which applications have functionality that is not used (i.e., redundant, obsolete or not accepted by business users)?
• Which applications are not well aligned to the primary business capability they support (i.e., lack capsulation)?
• Which functional gaps exist in the support for a business capability, a product or a business process? 

Where to get the information

People with a direct application responsibility and good functional know-how would usually define the functional scope of an application (e.g., manager of a development or support team for the application). This is done by assigning the application to a functional domain (or domains). For a more granular approach the services provided by the application can be described. For both of these tasks, a functional domain model is required, usually provided by a domain architect. Most organizations will focus on mapping applications to a less detailed domain model. Domain models are often industry-specific and may be acquired from public sources. 

Required maturity

Designing a global, generic functional model and describing application services requires a high maturity level and much effort. It is therefore recommended to do this only for a specific part of the landscape to tackle a specific issue. 

Technology perspective 

The technology perspective aims at aligning the technology platform of the application to the IT organization’s technology strategy and standards. It also helps reduce the risks and costs of older, non-supported technologies and aligning technology strategy to business needs. In this context questions such as these are looked into: 

• Which applications should be migrated due to aging technology usage?
• Which applications are not in line with current technology standards? 
• Which applications best match business needs in terms of non-functional requirements such as agility and scalability?
• Which applications are easy to maintain in terms of skills required?
• Which application areas have the highest project and/or operational risks (from a historical perspective)?

Where to get the information

Technology perspectives are usually provided by someone in IT responsible for the application, i.e., someone in development or operations. An approach for understanding the technology perspective is to document the technology platform of the application and to assess it within the context of a technology portfolio governance regime.  

Required maturity

A medium maturity for application portfolio governance is usually sufficient to assess the technology perspective and often goes hand-in-hand with a medium maturity of technology portfolio governance. 

Information perspective

The information perspective is used to analyze dependencies between applications due to the data flows between them (especially those dependencies which could impact the application, e.g., in meeting recovery time objectives). It also supports defining applications that are the system of record or classifying applications for data protection or other compliance reasons. The following types of questions are addressed: 

• Which applications process which data?
• Do we have more than one application which is creating a particular type of information (CRUD analysis)?  
• Which applications fall within the scope of laws that protect personal data? 
• Do the information objects being processed have to conform to an industry standard? 
• Which applications are dependent on others due to information flows feeding them?

Where to get the information

The information perspective is typically provided by the product managers or development owners of an application. A common approach is to properly document the information architecture of the application and to assess it within the context of an information portfolio governance regime.

Required maturity

In an organization of medium maturity, typically the information flows are documented. A more detailed information architecture analysis typically requires a high maturity level and more effort. 

Cost perspective

The cost perspective is used to apply governance to spending on applications. It ensures that costs drivers are recognized and that spending becomes aligned to business priorities. In this context questions such as those below are addressed: 

• What are the operating costs of the applications?
• How much is being invested in new features?
• What is the ratio of investment to operations?
• What are the application costs per functional domain?
• How are costs trending over time?

Where to get the information

Costs are usually imported from a system responsible for company financials (ERP) or for calculating chargeback (IT asset management). However, due to the nature of financial reporting and cost accounting, these are typically not provided on a per application basis. This results in the need to map costs to applications. The IT finance manager should govern the mapping process. 

Required maturity

The cost perspective is usually available in an organization of medium maturity. 

Operations perspective

The operational perspective aims to provide insight into the operational performance of the application in order to identify areas that need attention. In this context questions such as those below are addressed.

• Which applications have the most incident tickets?
• Which applications fail most frequently?
• What priority classes do applications have for operations and do the classes match business needs? 
• Which applications do not meet recovery time objectives?
• Which applications have or do not have described business continuity management procedures?

Where to get the information

This type of information is usually provided by the operations personnel responsible for the application or it may be imported directly from the systems supporting operations (CMDB, helpdesk).  

Required maturity

The first two questions above represent a medium maturity level whereas the last three a higher maturity level. One question that needs to be addressed here is the level of granularity. Is the information analyzed at the level of individual deployment or assessed by operation owners at an aggregated level? For APG the assessment at an aggregated level is as a rule easier to execute and sufficient for portfolio decisions. 

Risk, security and compliance perspective

This perspective is used for several reasons: for documenting application information required for risk assessments, for understanding applications that have risk or compliance issues from a portfolio perspective and for documentation of security levels/classes to ensure the right actions are taken to protect applications. In this context questions like these are addressed:

• Which applications have the highest need for a complete risk assessment?
• Which applications have failed compliance controls?
• Which applications carry extra risks due to where they are sourced or used?
• Which applications are subject to compliance regulations?
• Which applications have proprietary internal authorization/authentication systems?
• Which applications do not use the standard provisioning or single-sign-on systems?

Where to get the information

This perspective is provided by personnel in development and operations responsible for the application or the application product manager. An IT risk or security manager would be involved in defining the type of information required.

Required maturity

These questions depend on the maturity of the IT risk and compliance program. This is typically high in e.g., financial services companies. A question that needs to be addressed here is the level of granularity. Is the information required at the level of individual deployments or assessed at an aggregated level? This will vary depending on the nature of the use case.

Assigning roles and responsibilities

In the previous section on information requirements we touched on some of the people who may be responsible for certain types of information. In this section we take a closer look at the different roles and responsibilities that are part of APG.

The roles will vary from company to company in terms of their title and in terms of organizational units they belong to. Also, there will be organizations where each role is constituted by one separate person and others where many roles are bundled on one person. Generally the following can be said: 

• Ownership of the APG discipline will usually reside in the IT organization
• The enterprise architecture team, the applications management team or a dedicated IT portfolio organization will typically be responsible for APG in the IT organization
• Contributors to APG are spread across both IT and business. Various contributors are required to provide a 360-degree view of the applications within the portfolio 
• Governance will ultimately rest with the budget owners (business owners) of an application portfolio 
• Organizations of a higher maturity will also implement some form of functional governance to help identify re-use and redundancy across the areas of business ownership 

Following is an overview of the main roles participating in APG together with a description of the associated responsibilities. These are the role names used throughout the rest of the document.

There are other roles within IT that will become involved in APG. Either they will require information on applications for their own jobs or they will have a governance role that has touch points with the application portfolio. Examples of such roles are technology owner, technical domain architect, IT finance manager, IT risk/security manager, information architect, release manager or project manager. These roles are not described in more detail here as they play only a background role in the practices described.

One important question to consider when fixing the roles to be used is: For how many applications can a real person be assigned to the role? For example, instead of an IT owner you may consider having two roles: a development owner and an operations owner. This would indeed be more precise in terms of assigning roles, but if the roles are not assignable for the majority of the applications in the landscape, many roles will be left vacant. Practice here is to be pragmatic and do what is possible in the organization. This is strongly related to the maturity discussion earlier in the document. The roles in the table represent an organization of medium maturity. 

Choosing a portfolio governance model

In the discussion on roles, we stated that: 

• Governance will ultimately rest with the budget owners (business owners) of an application portfolio
• Organizations of a higher maturity will also implement some form of functional governance to help identify re-use and redundancy across the areas of business ownership.

This indicates that there are usually two dimensions of governance. One dimension is budget ownership—usually represented by the organizational model—and the other dimension is according to business domain or function. Of these, budget ownership governance will be the deciding instance.

Functional governance will be the guiding instance. Business ownership governance in line with the organizational model is an approach that is undisputed. In organizations with a low maturity or at the beginning of their APG efforts, this may be the only governance model implemented.

The functional dimension, however, can be supplied by different business architecture models such as business process, market product, sales channel or business capability (functional domain). To choose the governance model for the functional dimension two questions should be considered:

• Is the model appropriate for the entire landscape?
  Governance models based on channel or market product fail to cover the whole landscape effectively 
• Is the model stable?
  The business capability model offers more stability than the process organizational model

For these reasons, we recommend the business capability model (domain model) as the second dimension covering functional governance. Dimensions such as market product and sales channel can then be used additionally for further analysis as required. 

APG program governance

Govern portfolios

Breaking down the application landscape into portfolios with clear responsibilities is the key to implementing governance on application planning and spending. Portfolios represent a set of IT assets—applications—that require a clear investment strategy for the best business result. Similar to financial portfolios, decisions need to be made on which applications to invest in, and which not to. And just as with a financial portfolio each application portfolio needs a clear strategy and a responsible manager. This manager is responsible for exacting the best ROI. 

In defining portfolios of applications and their managers, whether from a functional perspective or a business perspective, certain practices have proven themselves to be effective and are described below:

• Ensure that the portfolio structure is hierarchical and not radically different to existing organizational or functional structures in the organization. This promotes better acceptance and increases the speed of implementation. Also the hierarchical nature enables KPIs to be aggregated in order to monitor performance against organizational goals. 
• The number of levels in the portfolio hierarchy should be between two and four depending on the complexity and size of the organization. The aim is to have portfolios that are small enough to be manageable (less than 60-70 applications) but also large enough to offer synergies (greater than 15-20). There will, of course, be exceptions.
• Portfolio ownership of an application should be controlled by a governance process. One way of doing this is to get the approval of both the manager of the portfolio where the application currently resides and of the future portfolio manager. Such governance is required as goals, budget allocations, competencies and other resources are typically associated with an application or an application portfolio. Indeed, due to implications on, e.g., the budget, other roles may also need to be involved in the governance process, e.g., the IT financial manager.

The portfolio ownership of an application for the two portfolio dimensions recommended in this practitioners' perspective (business perspective and functional domain) is usually described by assigning an owning business organization and an owning functional domain to the application. Although business ownership is usually clear, functional ownership may not be clear for applications that have a broad scope (i.e., that are not clearly functionally capsulated). In this case it is recommended that a lead functional domain be defined and the responsibility for governance lies with the domain architect of this lead domain. 

Manage APG program goals

The APG program is established to improve the application landscape in terms of costs, risks, agility and business alignment. Goals serve as a means to motivate, manage and measure such improvements. Communicating goal achievement supports justification of APG costs. Here are some of the approaches seen in the area of goal management:

• Set goals at the portfolio level. This enables clear assignment of goals to respective portfolio owners. It also supports differentiation of the goals based on the needs and strategy for a particular business or functional area
• Aggregation of goals enables reporting and monitoring of achievement at different levels of management and for the entire enterprise
• Monitoring of goal trends and goal achievement trends provides managers with better tools to forecast goal achievement
• Goals provide an effective way of monitoring implementation of architectural policies

One of the most common goals set is the overall number of applications. While this is useful and helps to push out redundant or ineffective applications, monitoring success of the program by only monitoring reductions in numbers of applications is not considered a best practice. This is due to the fact that the real problem may be a small number of complex and expensive large applications. In this case, setting targets only based on application numbers pushes efforts away from the major benefits that could be reached by first tackling these large applications, e.g., solving the disentanglement and capsulation problems. An ABC analysis of applications and their costs is an effective way of identifying cost-driving applications.

Govern data quality

Fundamental to the success of the APG program is data quality of the application inventory and associated indicators. The more reliable this information is, the more likely it is that problems in the application landscape will be recognized and addressed. However, attaining and maintaining the required level of quality is not a simple task and usually the greatest challenge to the APG program. Below are some of the approaches observed: 

• “Trust is good, control is better” – data quality will not be attained without measuring and regularly monitoring data quality and using this information to set and report on goals. Obviously this requires buy-in from the organization, but once in place it provides the basis to “name and shame” those who are not taking their responsibilities seriously. 
• Only by implementing clear governance for the information in the inventory can data quality be reached. That is, it has to be clear who is responsible for which data and what those responsibilities imply. One fundamental concept here is the “data steward,” i.e., the person responsible for a particular part of the inventory. Within the scope of an APG program main data stewardship usually lays with the product manager whose duty it is to be responsible for basic information on the application, supported by the business owner and the IT owner (for more information on these roles refer to the section of assigning roles and responsibilities above.
• Attestation – for core data, regular attestation of its correctness by its data stewards provides a method of installing responsibility and ensuring data quality. This can also be used to provide auditors with evidence of due diligence in maintaining data relative to compliance thus providing extra benefits and motivation.
• One significant data quality challenge to the APG program is ensuring all applications are in the inventory. Here a top-down and bottom-up approach can lead to improved completeness of the inventory. 
  –    The top-down approach involves generating reports for process owners, organizations and business capability owners on the applications in the inventory that support their part of the business. Reviewing these reports—often in workshops with the affected organization—exposes applications that are not in the inventory (or that are in the inventory, but the support for that part of the business is not documented).
  –    The bottom-up approach compares the inventory to other existing inventories and escalates gaps. The most common source here is probably the CMDB. An added benefit of this comparison is that it provides the basis for linking planning and strategy to operations. It can also be used to impose governance by using the reliance of projects and operations on data in the CMDB as a lever to ensure applications and technical components are registered there.
• Usage – the best way to ensure data quality is to ensure that the information be used in the regular planning and management processes. The more the data is embedded within such processes, the greater the pressure will be to ensure the data is correct. One problem observed within this context is inflation of the data to be maintained on applications (and as such inflation of the work involved). Therefore focus on the goals to be met and avoid trying to do too much too soon. One practice observed is the monitoring of attribute usage (by attribute owners) and removing any attribute where usage is not seen or where usage does not justify the effort. 

Govern roles and responsibilities 

As discussed in the section on assigning roles and responsibilities there are various roles that need to be involved in APG. Deciding who gets which role and educating the people getting APG roles is critical to the success of the program. Once this has been done there are some practices that help to ensure the sustainability of APG in the organization, namely:

• Ensure that there is a manager responsible for assigning people to roles. Include this manager in education efforts and governance processes. 
• Govern changes in the people who are to fulfill the roles. How strict the governance is can be decided on a case-by-case basis, e.g., is approval by the responsible manager required or should he/she just be informed? 
• Support self-service to reduce administration as much as possible, e.g., a self-service request to support role transfer 
• In cases where governance needs to be strong, an option is a hand-shake process between the current role owner and the new role owner (an example of this was discussed previously under the section on governing portfolios) 
• Manage fluctuation in personnel by involving HR in a process that monitors changes in staff to see if role responsibility has been affected. One reaction to such a change could be to automatically inform the manager responsible for a vacant role that he/she needs to name a new person and the consequence of not doing this in a specific timeframe will be that the manager him-/herself will be given the role. 
  

Information gathering

Document & classify applications

• A documentation status (with values such as “draft,” “approved,” “rejected”...) is used to manage the process of documentation. Being of status “Approved” informs the organization that the minimum quality levels for the application description have been met and makes the application available for management processes based on the application inventory.
• The minimum quality level for application documentation should be enforced using data input validation and approval by stakeholders as required. This minimum quality level should include:
  - Name, description, version
  - Life-cycle and status information
  - Governance information  – business and functional ownership
  - Roles – according to the role governance chosen
  - Supported business areas
• As part of this process, the business and functional owners should approve the application being added to their portfolio

Gather application information
Once the information is in status “approved,” non-mandatory information on the application can be gathered. By doing this in a second step, you save the effort of gathering information on applications that for some reason do not get approved. Deciding which information is mandatory and which not depends on the goals of the APG program and may, in fact, change in the course of APG program as maturity increases.

• The product manager should take on the role of monitoring the completeness of application information and its quality—iterating with the stakeholders responsible for specific information. Implementing workflows with reminders and data quality reports assists the product manager in this task.
• Supporting granular gathering of application information, e.g., just the business perspective, is useful in reducing the effort of achieving a specific goal within a set time period.
• Put special effort into gathering information from the business—these stakeholders are probably the most difficult to engage. Using workshops, pre-filled information (i.e., “review” instead of “do”) and explaining the benefits are some of the methods that can help.

Attest application information 
Regular attestation of the correctness of application information—i.e., confirming that information is correct—is one method of increasing the quality of the application inventory. This is quite often accompanied with the justification that the information is required to support regulatory compliance efforts as this facilitates getting buy-in from the managers whose employees are involved in such attestation. This is a quarterly, half-yearly or annual exercise. Using workflows is an approach here as the workflow audit trail can be the evidence that a compliance officer or auditor requires. As this is an effort-intensive method of ensuring data quality, it usually focuses on core parts of the application information.

Manage changes
The main task in managing changes to the information in the application inventory is to decide under what governance that change can be made. Does it need approval, e.g., for changing the domain ownership? Do stakeholders need to be informed, e.g., for changes in the life cycle? In this practitioners' perspective we do not make a recommendation on the right governance for each piece of information in the application inventory but do recommend that the effort be made to decide the governance for each piece of information—implementing strong governance using workflows and the other methods available as required. 

Portfolio assessment

The assessment process

Assessment types

• Alignment of the application to technology strategy
• Factors such as alignment to platform and technology standards, alignment to preferred vendors and alignment to the technology strategy required for business needs (e.g., agility) are analyzed and a rating is made.
• Alignment of the application to business strategy
• Factors such as contribution to revenues, contribution to future business strategy, functional alignment to business needs and business satisfaction are analyzed and a rating is made

Using these dimensions a bubble chart (the example below is provided courtesy of Software AG) is created and used to split the applications into four groups:  

• Invest (top-right) – applications aligned well to business and technology strategy
• Migrate (bottom-right) – applications aligned well to business strategy but not to technology strategy
• Review (top-left) – applications aligned well to technology strategy but not to business strategy
• Eliminate (bottom-left) – applications with low business and technology alignment 

The scores made for these factors are normalized, weighted and brought together to create a single “decommission candidate rating.” This is then reviewed with managers for feasibility and execution.

ABC cost assessment

An ABC cost assessment is used to identify areas of focus for cost-reduction initiatives.

Costs may be driven by sheer numbers, but can also be driven by a very few, very expensive applications. An ABC analysis on application spending is used to split the portfolio into three categories (A, B, and C) by listing the applications in descending order of application spending and then:

A = the applications that make up the first 70% of costs (going downwards in the list)
B = the applications that make up the next 20% of costs
C = the applications that make up the bottom 10% of costs

If the number of applications in the first group is very low – then these applications deserve detailed analysis as any cost reduction in this group will have a large effect on total costs. Similarly, if the number of applications in the last group is very high, say 80 percent, then reducing application numbers is unlikely to impact overall applications costs.

Cost alignment assessment

Another form of cost analysis is to check the alignment of costs to business strategy. An effective way to do this is to map costs onto a capability map and highlight the business capabilities which have the highest application running and operational costs. This provides a good basis to discuss spending priorities with the business and identify areas where spending should be reduced. An example of such a capability map follows courtesy of Software AG. Areas of high operational cost are colored red. 

Application management

In this section on application management we look at some of the processes that can be driven from the application inventory. The life-cycle management processes support the product manager of an application in synchronizing different parts of the organization when there are changes to the application road map, e.g., synchronizing development, operations and business. Below we take a look at such processes.

Sundown application

The aim of this process is not approval of the application sundown, but rather to coordinate the activities associated with an application sundown in a timely manner. This process would aim to:

• Inform business users in the run up to the application sundown, e.g., at three months, one month and one week before sundown
• Track the stage gates of the migration project if a migration is involved
• Confirm the sundown date with operations before the event, e.g., one month before, and on the day
• Possibly synchronize with operational repositories, e.g., a CMDB

Change application life cycle

The aim of this process is to inform and get approval from the main stakeholders of changes to an application status or life cycle. The main steps would be to: 

• Inform the business owner and domain architect (according to the governance model chosen) of planned changes to the life cycle or status of the application with a justification 
• Get their approval
• Inform other stakeholders, e.g., owners of technologies used in the platform or owners of applications that interface to the application so that they can check if the change impacts their own road maps and if necessary escalate any issues

Create a new version

This process is essentially the same as the process for changing an application life cycle only instead of changing the life cycle of the application a new version of the application is being released. On top of the steps described in the previous section on changing the application life cycle, the following may be required:

• Approval of changes to the application information (or request changes)
• Track the stage gates of the migration project if a migration is involved
• Approval of the business owner on functional changes or usage changes
• Approval from budget owner (could be IT in case of platform migration)

Coordinate activities

Apart from the life-cycle management processes, there are other processes that can be driven using the application inventory to coordinate IT management activities that are application-centric. Implementing workflows that automate such activities do not only increase the quality and efficiency of such processes. They also raise the quality of the application inventory. The more it is used the better the data. Here are some examples: 

• User survey process to support gathering application information related to a specific, one-off initiative, e.g., surveying IT owners for information related to a migration of the desktop environment.
• Application risk profiling to support the operative risk assessment 
• Approval of requests for application API (or data) usage 

In this document we have provided approaches for APG. We are confident that by following these, readers with responsibility for application portfolios can achieve significant improvements in their application portfolios.

However, application portfolios do not exist on their own—they are impacted by and have an impact on project investments, technology investments, business strategies, information governance, vendors and other objects core to IT planning and execution.

Each of these objects has its own portfolio governance. Only by managing these different portfolios in an integrated way—as one integrated IT portfolio—can success be assured. Failure to do so will lead to more risks, costs and reduced IT agility due to a failure to synchronize plans and priorities across the whole IT portfolio.

So to close the document, the last but by no way least important lesson: practice strategic portfolio management by ensuring that the APG efforts are integrated to the other portfolio governance efforts going on in the organization.