Professional Documents
Culture Documents
Key Challenges
■ Businesses struggle with the challenges of a bloated application portfolio, which is both
expensive to run, and slow and expensive to change.
■ Individual project initiatives are incapable of addressing the broad, underlying structural
problems of the current application portfolio.
■ The focus on short-term tactical needs over long-term strategic portfolio planning makes the
expensive and bloated application portfolio worse with every new IT investment.
■ Many business management teams place responsibility for rationalizing the application portfolio
on the shoulders of the IT management team, but the real need is for a business-led initiative to
standardize and simplify the business processes.
Recommendations
Application leaders advancing their application strategy with a rationalization program:
■ Find the business engagement tipping point by focusing on the twin goals of reducing the cost
and complexity of the application portfolio while changing the IT and business investment
management processes.
■ Change the focus of rationalization from an IT initiative to a business initiative by focusing on
business process standardization.
■ Ensure the ongoing success of the rationalization effort by gaining the active engagement and
leadership of business executives.
■ Build momentum for the rationalization effort by producing measurable business results, not by
focusing on the low hanging fruit of application numbers.
■ Change the investment management and application governance process to avoid falling back
into the rationalization "hole."
Table of Contents
Introduction............................................................................................................................................ 2
Analysis.................................................................................................................................................. 3
Reduce the Cost and Complexity of the Application Portfolio While Changing the IT and Business
Investment Management Processes................................................................................................. 3
Change the Focus of Rationalization to Business Process Standardization....................................... 6
Gain the Active Engagement and Leadership of Business Executives............................................... 7
Change the Investment Management and Application Governance Process.....................................9
Gartner Recommended Reading.......................................................................................................... 10
List of Figures
Introduction
Here are three common complaints from C-level executives when discussing their need for change
in how IT works:
1. "We seem to spend too much of our IT budget simply running the existing systems, and not
enough on delivering developments that will help the business grow and transform."
2. "At a time when the business is under immense pressure to move quickly to deliver on digital
business strategies, improve business performance, reduce costs, introduce new products and
services, improve customer service, and cope with demands of customers and regulators, our
business applications are very slow to change and very expensive to change. IT applications
are becoming the critical path inhibitor to business transformation."
3. "Every time we invest in a new application, we seem to create a substantial operating cost for
operations, support and maintenance that was not correctly predicted in the business case."
There are two primary causes of these symptoms. The first cause is a bloated application portfolio
with a high level of internal application complexity and architectural complexity. The second cause
is the set of management and technical governance structures, processes and disciplines that have
led to the creation of that bloated application portfolio.
Application rationalization is a multidisciplinary, multiyear program of work that will tackle both of
these problems, and should be part of any continuous modernization effort. An application
rationalization program must change the application portfolio so that it is leaner and fitter. It must
also change the management and technical governance structures, processes and disciplines that
led to the creation of the bloated portfolio in the first place.
Analysis
Reduce the Cost and Complexity of the Application Portfolio While Changing the IT
and Business Investment Management Processes
The twin goals of an application rationalization program (see Figure 1) are:
■ For the application portfolio: To manage the transition to an application portfolio that has
measurably lower total cost of ownership than the current portfolio, while at the same time
being more flexible and therefore faster and cheaper to change when change is needed.
■ For application governance: To transform the way in which both business and IT stakeholders
manage the application portfolio so as to ensure that the bloated and inflexible portfolio does
not return.
These goals are not "nice to have" goals for any business — they are a real business imperative. No
business can thrive with a bloated and crippled application portfolio.
A useful way to communicate this analysis is using the metaphor of a zoo. Think of your application
portfolio as a zoo. You have 2,200 animals in the zoo, but the zoo can't afford to remain at its
current cost level. The problem is that the large animals in the zoo — the elephants and other big
mammals — represent the bulk of the zoo's costs. The mice and gophers hardly feature in the cost
accounts, and so reducing their number is immaterial to the ongoing costs of the zoo.
This advice — not to drive an application rationalization program using the goal of reducing the
number of applications — puts some CIOs in a quandary. They understand the logic of Gartner's
position that the number of applications is not just irrelevant, but actually counterproductive as a
goal for their application rationalization initiative. But — and this is a big "but" — their CEO has
explicitly provided a goal for the target number of applications. Following the logic of the "golden
rule" (that is, "he who has the gold makes the rules"), the CIO must follow the directive of the CEO,
and therefore, must reduce the number of applications to the mandated target. However, the CIO
will know that following this goal is bad for the business, since it will not deliver on the real goals of
an application rationalization program.
Under these circumstances, the application rationalization team should be split in two. A small team
should be established to provide "numbers reduction" — to take care of the "mice" and "gophers"
in the application portfolio, and to achieve the desired reduction in numbers. However, the main
effort must always be directed at the "big game" in the application portfolio — the large, complex
"elephant" applications that account for most of the budget. Even when dealing with the minor
aspects of the portfolio, it is important to pursue the parallel "process" goal of application
rationalization — to change the processes used to acquire small applications so that the portfolio
does not simply bloat again.
It is important to note that with large, complex applications, you may well be able to achieve some
success against the real portfolio goals (lower total cost of ownership and improved agility) without
actually reducing the number of applications. This can be achieved through reducing the internal
complexity of the applications by techniques such as removing customization.
The corollary of this law is this: "If you remove an application from the live portfolio, you must
somehow be changing how the business works." These changes could be to process workflow,
roles, responsibilities, or transparency and accountability. (There are a very small number of
exceptions to this law caused by applications that have absolutely zero use in the business today.
But these applications are unlikely to make a significant contribution to costs or to negatively
impact flexibility.)
The fundamental question for an application rationalization program must be: "Do we have the
authority to drive changes in business processes, workflows, roles, responsibilities, transparency
and accountability?" For example, consider a telco that has five CRM systems. Can an IT-led
application rationalization program drive the necessary level of business change to allow a
substantial reduction in the costs of running these systems, while at the same time improving the
agility of the resulting applications? The answer, in nearly all cases, is categorically "no" — the IT
organization lacks the authority to drive the necessary level of business change.
Consider the hypothetical case above, where there are five CRM applications in one business. While
these systems are all known as CRM systems, they are not identical. Each one has features not
present in any of the others, and even where they apparently share features, the data structures,
processes, workflows, roles and responsibilities are not the same. Imagine each of these five CRM
applications is moved into a single application without process standardization and simplification.
The resultant application would be so horribly sprawling and complex that it would be expensive to
run, unreliable and almost impossible to change due to the high level of internal complexity.
It is therefore vital for an application rationalization program to adhere firmly to the mantra:
Many years of research with Gartner clients across multiple industry domains and geographies have
convinced us that meaningful application rationalization can only be achieved as a byproduct of a
business-led business process standardization initiative.
It's important to note here that rationalization doesn't have to happen as a separate megaprogram.
We have coined the phrase "continuous modernization" to address the concept of modernizing an
application portfolio in chunks, and where it is a business imperative to do so. Rationalization can
be done the same way. Where there's a business need to either reduce costs in a particular
application domain, to improve business fit, to increase business value or to improve flexibility,
rationalization efforts can be used in a targeted fashion.
Frequently, there is, in essence, a standoff between the IT organization and the rest of the business.
Business managers seem to be saying, "We want lower application costs and more flexible
applications, but we don't want to have to change what we do, or cede the right to define local
processes that are different from the rest of the organization." But these two objectives, lower
application costs and local processes, are largely mutually exclusive in traditional application
architectures. If the business managers want the local autonomy to have their own local processes
and associated applications, then the IT organization is faced with an impossible task. Effectively, all
business managers believe that the whole organization has too many applications, but no individual
manager is willing to sacrifice their autonomy and abandon their own miniportfolio.
In some organizations, the CIO may be in the fortunate position of working for an executive
management team that has already committed to a major business transformation program. The
business decision to undertake such a major operation may be driven by market conditions,
mergers, acquisitions, divestments or any number of other reasons. Whatever the cause, the CIO
should immediately link the application rationalization initiative to the business transformation
initiative. The business transformation program will change the organization structure and define the
business processes. These new processes will require application support, whether the processes
are to be externalized (via business process outsourcing), run internally in a new shared-service
center or run locally using a common process model implemented in a single application.
However, if the business is not currently engaged in a recognizable and funded business
transformation initiative, the CIO aiming for application rationalization is faced with an obstacle —
gaining time and commitment from business managers in order to deliver business process
standardization. In these circumstances, it is necessary to be completely transparent about the level
of duplication in the portfolio and the associated costs, in order to shock managers into
engagement. Creating this transparency is a time-consuming task in most IT organizations. It
shouldn't be hard, but it is. Basically, data from an application portfolio management (APM)
discipline is needed to show not only how many applications you have, but also the level of
functional duplication and the costs associated with each application. (For details about how to
undertake such an activity, see "Taking on Application Portfolio Management's 'Wicked Problem' of
Getting Business Engagement.")
It is important to target the right spot in the business with data about the dysfunctional, bloated
application portfolio. Sharing data about applications is unlikely to cause any line-of-business
manager to want to engage in business process standardization. Line-of-business managers are
generally too busy pursuing short-term goals to be able to engage with programs where the value
would not be delivered in the current measurement period. Application rationalization teams need to
target the executive management team: the CEO/CFO/COO, who oversee all of the individual lines
of business and would be capable of understanding the potential value of leading a business
process standardization exercise.
Segmenting the current application portfolio can help focus business executives in the right place.
As previously explained, it is a bad idea to drive application rationalization through pursuit of the
goal of reducing the number of applications. It is an equally bad idea to migrate away from the
current bloated application portfolio toward an application portfolio with an outmoded architectural
style based on 20th century application architectures. Tomorrow's application portfolio is not
yesterday's application portfolio on steroids. It is very clear that the large, monolithic applications
inherited from the 20th century are incapable of delivering the low cost of ownership and flexibility
that are sought as the outcome of an application rationalization exercise.
Application rationalization initiatives are dependent upon business process standardization and
simplification, but that does not mean that there is no need for an application strategy. In fact, the
level of activity engendered by an application rationalization program will result in chaos unless
there is tight control over architecture and design, and unless initiatives are marshaled toward a set
of strategic objectives for the portfolio.
To break out of the mold of inherited application architectures, Gartner has devised a tool called the
Pace-Layered Application Strategy. This tool highlights that application capability needs to be
delivered in three different layers: systems of record, systems of differentiation and systems of
innovation. Twenty-first century application architectures apply different methodologies and tools to
each of these layers, and provide the appropriate level of integration to allow seamless end-to-end
business processes without the lumbering overhead of the monolithic application structure. For
more details about pace layering, start with "What Is Gartner's Pace-Layered Application Strategy
and Why Should You Use It?"
Another tool that can be used is Gartner's TIME process (see "How to Assess Your Current
Application Portfolio Using Fitness and Value Review Processes"). This process places the
application portfolio into tolerate, invest, migrate and eliminate quadrants. Applications to be
rationalized will fall into the migrate or eliminate quadrants.
Build momentum for the rationalization effort by producing measurable business results, not by
focusing on the low-hanging fruit of application numbers. Taken as a whole, application
rationalization is a multiyear, multidisciplinary program of work that seeks to reduce the overall cost
of the application portfolio, while at the same time improving its flexibility. Tackling 40 years of
application management that has resulted in the current bloated portfolio will take time,
determination and patience. Be wary of looking for "quick wins," which are attractive because they
can give the impression of progress but have little substantive value. Scrambling to find lots of little
applications to kill might look like activity, but it fails to address the challenging central problems
associated with large, complex applications. If it is absolutely necessary to play the numbers game
— to reduce the actual count of applications — then make sure that this stream of activity only
consumes a small amount of management time. Focus the main effort where it deserves to be: on
the large, expensive applications.
Application rationalization teams should be wary of making promises that they will not be able to
deliver. Too many application rationalization programs lose drive early in the struggle because they
fail to deliver short-term cost savings. While it is reasonable to have a long-term goal for the overall
reduction in cost for the application budget, the actual achievement of any meaningful goal will take
time, effort and investment. The team needs to develop an overall strategic approach to the
challenges that they face, and then derive tactical initiatives that can be projectized and executed in
pursuit of the strategy. Only then will the team be able to identify the committed savings in specific
budget periods from the funded initiatives.
Changing these processes, and fundamentally changing the culture of application investment
decision making, will require a high level of political and interpersonal skills since such changes will
need to be negotiated with, and implemented by, many different stakeholder communities. The CIO,
the senior IT management team and senior business managers must constantly demonstrate
complete commitment to this goal of business process standardization; otherwise, the organization
will quickly slide back into the comfortable habits of the past.
Application rationalization teams must take a hard look at the current application and product
portfolio, and the projects and major backlog items in the approval pipeline, to establish the impact
of these investments on the goals of the application rationalization program. If the current and
proposed application projects will not make a net positive contribution to the goals of the
application rationalization program, then they will simply create a bigger mess for the program to
sort out. Such a policy leads to "one step forward, two steps backward" progress — in other words,
no progress at all. Put bluntly, if the application rationalization program is incapable of modifying the
investment governance process in order to favor project deliverables, which contribute to the
rationalization program goals, then application leaders may as well shut up shop and go home.
"How to Assess Your Current Application Portfolio Using Fitness and Value Review Processes"
"What Is Gartner's Pace-Layered Application Strategy and Why Should You Use It?"
GARTNER HEADQUARTERS
Corporate Headquarters
56 Top Gallant Road
Stamford, CT 06902-7700
USA
+1 203 964 0096
Regional Headquarters
AUSTRALIA
BRAZIL
JAPAN
UNITED KINGDOM
© 2018 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. and its affiliates. This
publication may not be reproduced or distributed in any form without Gartner's prior written permission. It consists of the opinions of
Gartner's research organization, which should not be construed as statements of fact. While the information contained in this publication
has been obtained from sources believed to be reliable, Gartner disclaims all warranties as to the accuracy, completeness or adequacy of
such information. Although Gartner research may address legal and financial issues, Gartner does not provide legal or investment advice
and its research should not be construed or used as such. Your access and use of this publication are governed by Gartner Usage Policy.
Gartner prides itself on its reputation for independence and objectivity. Its research is produced independently by its research
organization without input or influence from any third party. For further information, see "Guiding Principles on Independence and
Objectivity."