Application-Portfolio-Governance - Software Ag

Application portfolio
governance
for business value
Table of contents
2 Introduction
2 APG defined
7 Getting started
16 Executing the APG program
24 Integrated IT portfolio management
White paper
Application portfolio governance
An overview of application portfolio governance.

This document provides an overview of application portfolio governance
(APG) and common approaches for ensuring that it delivers business
value to the organization.
The goals and nature of APG are briefly discussed to establish the
definition and limits. This part is deliberately brief as the document
assumes a background in APG and is intended for the reader who is
looking for insight, hints and tips on how to be successful with the topic.
Reflecting this focus, the core of this white paper is in the sections on
getting started (page 7) and executing the APG program (page 16).
Introduction
The practices discussed in this document reflect the hands-on experience of leading
practitioners in the financial services industry. These individuals have learned from
their successes and set-backs while establishing the APG discipline in their respective
companies. These practitioners met several times to exchange their experiences on APG.
This document is the structured result of those discussions. It is applicable across all
industries. In creating this practitioners' perspective, the participants received support
from Software AG in the form of moderation and structuring of topics.
APG defined
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.
2
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 IT portfolio planning process is
illustrated in the diagram below.
Business Business IT IT Enterprise

strategic relationship planning architecture
planning management management
Business model Demand Target architecture Application portfolio
definition management design governance
Business strategy Operating model Scenario Information portfolio

validation planning management governance
Business capability Business IT Agile portfolio & Technology portfolio

management synchronization feature management governance
Innovation Project & Service portfolio

management release design governance
Project portfolio
governance
IT financial Contract & vendor management Investment optimization

management
Cost driver analysis OpEx optimization
IT risk Application risk management Project risk management

management
Information risk management Compliance management
Figure 1: Enterprise architecture and IT portfolio management capability map
Complementary to this, other planning information exists within the IT organization that
could impact the application portfolio, e.g., solution architectures, project proposals and
demands. Although relevant to the APG discipline, for the purpose of this practitioners'
perspective these will not be considered as part of the APG discipline. This boundary was
set because such planning information is not typically managed as part of the APG
discipline but rather as part of an overall IT portfolio planning process.
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.
3
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 in dedicated sections of the document.
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?
4
Capability Requirements
Align to Business
Increase Agility
Reduce Costs
Reduce Risk
Which applications are at/near end of support?
Which applications are running on technology which is at/near

end of support?
Which applications have exposure to risky vendors?
Which are the most expensive applications to run?
Which applications have a high number of change requests?
Which applications have failed compliance controls?
Which applications are not meeting agreed SLAs?
Which applications consume high levels of resources?
Which applications generate the most incidents?
Which applications are business users dissatisfied with?
Which business capabilities/processes could use new or

improved IT support?
Which new business demands affect the application portfolio?
Which applications have few or no business users?
What duplication of services exist in the portfolio?
Which applications are providing services to business areas

outside the portfolio responsibility?
Which applications run on preferred technologies?
Which applications produce the most project risk when a change

is required?
5
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
(page 15).
Application Portfolio Governance
APG program Information Portfolio Application

governance gathering assessment management
govern portfolios document & classify analyze and rate sundown

applications applications application
manage gather application create & iterate change application

APG program goals information proposals life cycle
govern attest applicaton monitor proposal create a new

data quality information implementation version
govern roles & manage changes coordinate

responsibilities activities
Corporate Program Level

Portfolio Level
Application Level
Figure 2: APG breakdown
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.
6
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.
Getting started
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.
7
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.
Questions that indicate that a software/system is... an application a technology
It supports one or more business processes ✓

It offers functional support to users executing a
business process
✓
It offers functional benefits ✓

Its budget is owned by business ✓
End-users know its name ✓
End-users work with it directly ✓
It is a standard IT product can be used by all
organization units, e.g., email, Word
✓
It can be re-used in more than one application ✓

It is infrastructure, e.g., operating system, DBMS ✓
Another aspect that should be considered when building the inventory is the granularity
of 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.
8
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 tasks
and 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).
9
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 straw-
man 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.
10
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?
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)?
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. 11
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?
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?
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.
12
• 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?
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?
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.
13
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
On this and the following page 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 on this and the
following page represent an organization of medium maturity.
Role name Description Typical activities
• Coordinates the setting of program

The manager responsible for goals, their communication and
the overall APG. This may also monitoring
Program
be represented by a board of • Defines the governance framework of
manager
managers from different IT the program. Monitors quality of the
organizations. application inventory and the results
produced
• Analyzes functional overlaps and

Architect responsible for a gaps. Makes proposals for better re-
Domain functional domain and functional use and redundancy elimination
architect governance of applications • Contributes to the application
providing support for that domain. strategy for a functional domain in
coordination with business owners
14
• Analyzes requirements and creates

proposals for new application versions
• Coordinates development effort/cost
assessment
This is the person in IT (or in • Documents basic application
Product business) that is responsible information, the business supports
manager for the product road map of the and the functions the application
application. provides
• Documents non-functional
requirements
• Supports assessment of applications
from a business perspective
• Monitors performance of the

application via management reports
• Reviews defined supports for
This is the main contact for IT the organization (for inventory
Business completeness)
issues for an organizational unit
owner
and owner of the budget. • Approves proposed road maps and
spending of the budget
• Makes and reviews business
perspective assessments
This is the person on the business

• Performs tasks for specific
Business side who is the Subject Matter
applications as delegated by the
contact Expert (SME) for the business
business owner
needs and usage of an application.
• Documents information architecture,

technology platform and relevant
operations information
• Assesses application alignment to IT
This is the person in IT who is strategy
IT owner
responsible for an application.
• Assesses development effort/cost
• Identifies development or operational
short-comings and communicates
them to the product manager
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.
15
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.
Executing the APG program

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.
16
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 on page 14).
• 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.
17
- 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
Fundamental to the APG program is the inventory of applications. Building the inventory
requires that applications be documented and classified in terms of functionality, business
ownership and other classifying taxonomies important for analyzing and governing the
application portfolio. It is common approach to use a process that is based on the following
principles:
• 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
18
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.
Some helpful practices when gathering application information are:
• 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.
19
Portfolio assessment
The assessment process
Portfolio assessment has more to do with analysis than process. It is the stage in which the
information available is looked at from different viewpoints, using different methods and
with a specific question in mind in order to drive portfolio change. The three main steps
involved in the process of portfolio assessment are:
Analyze and rate applications
The analysis will depend on the goal of the portfolio assessment. Is the goal to reduce
risk, to increase agility, to reduce the number of applications or another specific objective?
Dependent on the goal, you have to choose the indicators, reports and most insightful
analytics in order to best highlight candidates for action that will deliver the wished-for
improvements.
Create and iterate proposals
From the ranking, a “first cut” list of proposals is created that needs to be iterated with
stakeholders. The form of the proposals depends on the objective, it may, e.g., be a list of
candidates for sun-downing. At this stage feasibility is checked in order to come to a list of
approved proposals that will improve the portfolio.
Monitor proposal implementation
Not all portfolio managers are directly responsible for operationalizing the changes that
they have proposed and that have been accepted. In this case it is particularly important to
monitor the implementation of changes in the different parts of the organization. Failure to
do so will inevitably lead to portfolio improvements not being realized.
Assessment types
Below we describe some of the assessment types we have observed.
Application strategic guideline assessment
This assessment aims to analyze the application portfolio in order to set guidelines for future
investments in the application landscape.
This assessment looks at two main dimensions:
• 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 on the next page 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
20
Decommissioning assessment
This assessment is focused directly at finding candidates that can be decommissioned in

order to reduce the number of applications in the landscape. The goal is to produce a first-
cut assessment of the top candidates for decommissioning. Below is a table with some of
the factors to be considered for each application:
Factor Description If score is high then:
Redundancy = is
Application Number of applications providing the
a candidate for
overlap same primary functional domain
decommissioning
Number of users and user Decommissioning is harder

Usage
organizations using the applications = should not be a candidate
Migration to another
Number of issues open, e.g., failure application may be cheaper
Risk issues
to meet run time objectives? than mitigating issues = is a
candidate
Migration to another
Number of technologies in the
application may be cheaper
Technology application platform near the end of
than upgrading = is a
or out of life cycle
candidate
Costs of the application higher

Cost compared to those with a similar Is a candidate
functionality
Target Alignment score for alignment to

Should not be a candidate
architecture strategic target architecture
21
Factor Description If score is high then:
Architecture Alignment score for alignment to

Should not be a candidate
standards platform architecture standards
Mission
Score for criticality to business Should not be a candidate
criticality
Score for number of integrations, Migration costs high =

Complexity
interactions with other systems should not a candidate
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 is provided on the next
page courtesy of Software AG. Areas of high operational cost are colored red.
22
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
23
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
Integrated IT portfolio management

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 integrated
IT portfolio management by ensuring that the APG efforts are integrated to the other
portfolio governance efforts going on in the organization.
ABOUT SOFTWARE AG
Software AG began its journey in 1969, the year that technology helped put a man on the moon and the software industry was born. Today our infrastructure software makes a world of living connections possible. Every day, millions
of lives around the world are connected by our technologies. A fluid flow of data fuels hybrid integration and the Industrial Internet of Things. By connecting applications on the ground and in cloud, businesses, governments and
humanity can instantly see opportunities, make decisions and act immediately. Software AG connects the world to keep it living and thriving. For more information, visit www.softwareag.com.
© 2020 Software AG. All rights reserved. Software AG and all Software AG products are either trademarks or registered trademarks of Software AG.
Other product and company names mentioned herein may be the trademarks of their respective owners.
2020_08_WP_Alfabet_Application-portfolio-governance-EN

Application-Portfolio-Governance - Software Ag

Uploaded by

Copyright:

Available Formats

Application-Portfolio-Governance - Software Ag

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Application-Portfolio-Governance - Software Ag

Uploaded by

Copyright:

Available Formats

Application portfolio

16 Executing the APG program

24 Integrated IT portfolio management

An overview of application portfolio governance.

In APG the application landscape is organized into smaller portions—portfolios—each

A fundamental requirement for such analysis and decision-making is an inventory of

Business Business IT IT Enterprise

Business strategy Operating model Scenario Information portfolio

Business capability Business IT Agile portfolio & Technology portfolio

Innovation Project & Service portfolio

IT financial Contract & vendor management Investment optimization

IT risk Application risk management Project risk management

Figure 1: Enterprise architecture and IT portfolio management capability map

The goals of APG

• Improve application alignment to business strategy and to required business capability

• Which applications should be retired?

Which applications are running on technology which is at/near

Which applications have exposure to risky vendors?

Which are the most expensive applications to run?

Which applications have a high number of change requests?

Which applications have failed compliance controls?

Which applications are not meeting agreed SLAs?

Which applications consume high levels of resources?

Which applications generate the most incidents?

Which applications are business users dissatisfied with?

Which business capabilities/processes could use new or

Which new business demands affect the application portfolio?

Which applications have few or no business users?

What duplication of services exist in the portfolio?

Which applications are providing services to business areas

Which applications run on preferred technologies?

Which applications produce the most project risk when a change

Main activities in APG

Application Portfolio Governance

APG program Information Portfolio Application

govern portfolios document & classify analyze and rate sundown

manage gather application create & iterate change application

govern attest applicaton monitor proposal create a new

govern roles & manage changes coordinate

Corporate Program Level

Figure 2: APG breakdown

APG program governance

• The bespoke financial trading system

“Improve application alignment to business strategy and to required business capability

Questions that indicate that a software/system is... an application a technology

It supports one or more business processes ✓

It offers functional benefits ✓

It can be re-used in more than one application ✓

Whether deciding on whether an application is an application or deciding on the name of

Understanding current APG maturity

Such an assessment can be very labor-intensive so in this guide we recommend a more

Knowing the information requirements

Where to get the information

• How large is the functional scope of an application?

Where to get the information

• Which applications should be migrated due to aging technology usage?

Where to get the information

Technology perspectives are usually provided by someone in IT responsible for the

A medium maturity for application portfolio governance is usually sufficient to assess