Removing Application Entropy

Introduction

Organizations have become more and more complex: the diversity of processes, products and applications has significantly expanded. The duration and costs of implementing change are growing, which increases time-to-market and hinders innovation. Additionally, the corresponding complexity is leading to operational risks.

From an IT perspective, we see a natural tendency for the application landscape to swell, resulting in a rigid, inflexible and costly IT environment tied together by a large number of interfaces. This natural tendency to add more applications, whilst not rationalizing them, can be referred to as “application entropy”. Not surprisingly, a simplification of the application landscape ranks high on the wish list: a simplified landscape shortens time-to-market for the business and enables swift implementation of innovative changes.

Application portfolio management is a discipline aimed at a continuous monitoring and moderating of the application portfolio in order to prevent entropy. Application rationalization is an intervention that removes this entropy in the relatively short term. In this article, we define application rationalization as an instrument to retire or consolidate applications, with the goal to reduce complexity and total cost of ownership, and to increase the value and agility of the application landscape. Modernizing or replacing applications is not considered part of application rationalization.

This article focuses on removing the entropy through application rationalization. It describes the reasons why application entropy (still) exists in many organizations, and contains a pragmatic approach to how to start an effective application rationalization initiative. The emphasis in this article lies on creating commitment to rationalization, finding rationalization candidates using fact-based insights, creating the preconditions for decision making, and governing the execution of rationalization projects. The approach described in this article is based on the “real-life” experiences of the authors, and contains several lessons learned. This article does not contain information on how to technically consolidate and migrate applications.

Root Causes of Application “Entropy”

Maturity of the IT Environment

In most (incumbent) organizations, the application environment has organically evolved into a complex and diverse environment. Historically, the application portfolio has grown over time, based on multiple technologies using many (non-standardized) interfaces. Often, there is only limited knowledge of legacy systems within a company, and IT activities take place in several places throughout the organization. The IT discipline in many companies has often not matured sufficiently to have standardized and professionalized this IT diversity.

Targets and Budgets

Many companies focus mainly on increasing revenue and profit. In that sense, IT maintenance is often only regarded as an expense, whereby the costs cannot directly be assigned to the product the business is selling. Although the IT department does aim to reduce IT maintenance costs, the budget to realize simplification has not been allocated to the IT department. Moreover, IT costs are mostly only transparent for the IT side, ensuring that the business does not have a direct interest in reducing those costs. Experience has shown that, in the allocation of budgets, projects to rationalize IT are regularly de-prioritized in favor of projects that generate extra profit.

In addition, the business is often driven by fast time-to-market and expects IT to implement changes quickly. However, the implementation of changes in rigid legacy IT landscapes is complex and time-consuming and the business does not accept extensive timelines. As a result, IT may be inclined to implement a new application in a “quick and dirty” way, instead of integrating new functionality in existing applications. This increases entropy even further.

Fear of Change

Moreover, business/users and the IT staff may fear a change of the status quo. The business can lose flexibility if it is no longer the sole user of an application and has to share it with several departments. The workload for IT staff (consultants, administrators, developers) decreases (job loss), which can lead to resistance to application rationalization.

Operational Risks

Furthermore, every change implies a potential risk. The business is generally averse to risk, and is hesitant about any change that does not directly bring additional revenue. A change in the IT environment may result in operational incidents and continuity risks.

The result of this is that the application landscape keeps getting larger, more complex and more expensive. The rationalization of applications has low status, is not sexy, and does not contribute to the KPIs of the business or IT.

A High Level Framework for Rationalization

The model in Figure 1 can be used as a high-level framework for application rationalization. It connects four key elements of each organization: deliver products using people, processes and IT. Rationalization can be driven from each of these domains.

Figure 1. Application rationalization high-level framework.

Products form the raison d’être of any organization. However, the product portfolio may have resulted in (product-specific) process and application chains that were appropriate when introduced, but may now require to be revisited as a consequence of the current lifecycle stage of the product. If a product can be discontinued, the underlying applications and processes can also be decommissioned. However, the business may be averse to discontinuing a product if it still generates revenue, even if the revenue is low. The reluctance will decrease if the revenue is confronted with the benefits of decommissioning the underlying systems.

Processes are abundant in an organization, and each process has its own specifics, but also shares commonalities. However, these commonalities are often supported by different applications. Recognizing these commonalities is the key to application rationalization. To identify them, applications can be mapped to processes. In the case of application rationalization, the “business function” level is of major importance. Business functions are, for example, the human resource management function, investment portfolio management function, and the finance function. Business process harmonization seeks to combine similar application functionalities, resulting in the decommissioning of applications with redundant functionality.

From an IT angle, applications are rationalization candidates because the application is near its end-of-life from a technical perspective, or they may be based on non-core technology, or are supplied by non-desirable vendor.

The people within the organization unite these three domains: they create products, execute processes and use applications, and initiate rationalization. But people can also be a hindrance. Therefore emotional and political concerns cannot be underestimated.

Approach

The four elements from the high-level framework have been translated into a pragmatic approach for application rationalization. The approach consists of the five steps depicted in Figure 2. Each of the steps is illustrated in this chapter.

Figure 2. Rationalization approach.

1. Create Commitment

Top-down

The problems surrounding application entropy are not easy to solve, and apparently do not “hurt” sufficiently for the organization to take measures on its own. Therefore, it is essential to define a clear rationalization vision. By communicating this vision and the “sense of urgency” across the entire organization, rationalization will be perceived as an important and “sexy” topic. In order to quantify this “sense of urgency” at the top, it helps to compare the (IT) cost level and complexity with others, by means of benchmarking for example. In practice, this will be initiated by the CIO or CFO.

Commitment and communication from the top is only part of the solution. Translating the rationalization target into explicit KPIs on a business unit or personal level will clearly address the “What is in it for me?” question. Based on experience, it is advisable to ensure that the reduction of FTEs is not presented as a primary goal of rationalization. This will prevent rationalization ideas dying a premature death or not being presented at all.

In order to create traction, a focused program team is essential to give rationalization priority over other cases, targets, projects etc. A working practice is the creation of a mandated and independently positioned “Rationalization Office”. This is a small team that is independently positioned within the organization and reports to the CIO or CFO. The role of this team is to initiate, direct and boost the rationalization and to perform fact-based analyses of the application landscape, in cooperation with IT, business and finance. Besides that, the team should contain people who know the organization and who dare and are able to influence the organization. The team will have to position itself in a way that the organization does not perceive as threatening but rather supportive. If necessary, the team will have to be mandated to push the rationalization agenda when confronted with resistance, though this should be a last resort.

Bottom-up

Top-down commitment alone is insufficient. Bottom-up involvement is a must. A lesson learned is to identify several “promoters” throughout the organization who embrace rationalization objectives and can influence operational teams. The role of these promoters is two-fold: first, they can assist in identifying “quick wins”; and second, they are important in pursuing the culture change often associated with a rationalization program.

Promoters could be functional application managers, architects, designers or consultants. In this phase, it is important to also involve procurement and finance departments, since they often have a clear overview of the costs and revenues of IT.

The rationalization office can facilitate in identifying promoters and “bond” with them. In conjunction with the promoters, the rationalization office identifies rationalization opportunities. In order to actually execute these opportunities it is desirable to have a central budget available.

Quick Wins

In order to create momentum and to demonstrate that rationalization is not a mission impossible, it is important to show appealing results as soon as possible. The promoters play an important part in this: they know the daily operations and are perfectly capable of identifying the first rationalization opportunities.

It is essential to communicate the initial successes. Successfully realizing initial quick wins creates confidence that rationalization is indeed possible.

2. Create Insight

The actual accomplishment of the rationalization is inherent to several components. Apart from the “sense of urgency” and the “quick wins”, the tougher applications will also have to be dealt with. To be able to rationalize at all, it is essential to create insight into the application landscape. It is necessary to build a 360-degree view for every application, one that provides insights into the value for the business (present and future), maintenance costs, expected investments, quality and state of maintenance. To gain this insight, it is important for every application to collect the facts as stated in Table 1.

Table 1. 360-degree application view.

Important sources to obtain the required information are architectural overviews and internal databases such as the configuration management database (CMDB). Please note that, for many organizations, the required information is not readily available. An often-seen issue is that too much time is consumed by gathering information, resulting in the fact that rationalization is simply not achieved. In cases in which the required information is absent, scoping decisions about where to start will have to be made. This can be defined through workshops with the above-mentioned “promoters”, enterprise architects and process owners, for example.

Within this “insight” phase, it is of importance that information is recorded and maintained in a structured manner: in the IT CMDB for example. The (regular) asset management process should make sure that the application information remains up-to-date and complete.

3. Select and Classify Applications

On the basis of the information, the applications will have to be examined from different points of view in order to identify candidates for rationalization. The framework depicted in Figure 3 can be used to classify each application into one of the four categories (enhance, maintain, modernize or retire) based on measuring only two values for each application, the business value and technical viability. The application with the lowest business value and technical viability is most likely to become a prominent candidate for rationalization (classified as “retire”). Additionally, it is important to determine a plan to reach the target situation. An approach may also require a decision not to phase out a “non-target” application yet, and possibly even make investments in that area.

Figure 3. Classification framework.

The two main perspectives to structure the above-mentioned classification are “processes” (business functions) and “products”. The objective from a process perspective is to determine a choice for the target application per business function. Overlapping application functionalities usually form the core of the business case of successful rationalization projects. After all, it is often not cost-efficient to maintain two or more applications for the same or similar purpose. Consolidating similar applications reduces hardware and licenses and decreases knowledge accumulation within both the maintenance group and the user group. Additionally, data quality may suffer due to duplicate entry. Applications supporting similar functions with low technical viability are candidates for the “retire” classification (see Table 2 for an overview of examples).

Many rationalization initiatives are limited to the process perspective and, as such, miss an important aspect: the products. When a product or service can be discontinued, all the underlying elements can often be discarded as well. This makes it possible to terminate processes and decommission applications and hardware. Obviously, abandoning a product or service often does not happen without financial consequences. Therefore, it is essential to classify the applications based on the current and future value of each product and on the service related to the application. Products or services with less (future) revenue or added value than the costs of the underlying IT landscape may be candidates for rationalization.

A good-practice approach for classification is to conduct well-prepared workshops around business function and product clusters. It is important to conduct these workshops jointly with key users, process managers, product managers, IT administrators and architects. A potential pitfall is that the classification phase may not deliver the expected results, because of the above-mentioned reasons for resistance, described under “1. Commitment”. Again, make sure that the “promoters” play an important role in the workshops.

Table 2. Typical rationalization candidates.

Suppliers can also be consulted to identify rationalization opportunities. However, rationalization often leads to a reduction in volume (and profit) for the supplier. One way to remedy this conflict of interest is to agree financial incentives when suppliers identify rationalization candidates and actively cooperate in rationalization projects.

4. Create and Manage the Application Rationalization Roadmap

On the basis of the insights provided, it is necessary to build an “application rationalization roadmap” for all applications that are not classified as a future proof target application. This roadmap should not only provide insight into which initiatives are currently active or are planned in order to realize rationalization and who is responsible, but it must also contain at least:

• The applications that will be phased out (with a link to the application CMDB)
• The benefits of phasing out (business case)
• The (estimated) costs of phasing out
• Phase-out planning
• The dependence on other projects
• The project stakeholders (owners, administrators, project leaders)
• The current phase of the project (i.e., suspect, opportunity, planned, running, completed)

It is likely that insufficient funds, resources and capacity will be available to complete all the rationalizations at the same time. Consequently, choices will have to be made with respect to which rationalization initiative has priority over others. The roadmap, in combination with effective governance, is necessary to achieve actual prioritization for rationalization projects.

The cause of the rise of application entropy often lies in the fact that rationalization is managed with too little attention. In order to provide rationalization with structural attention, it must have its place within the organization’s governance.

For rationalization to have significant results, it is indispensable that rationalization be included in the goals of senior management, by means of targets or KPIs, for example. This also entails that management should be prepared to adjust processes or, in case of product rationalization, accept loss of revenue in favor of cost reduction.

In addition, it is vital that (additional) budget and capacity be made available for rationalization. The allocation of this budget and, with that, the prioritization will have to be anchored in regular budget cycles. Rationalization does not only affect IT, but also impacts processes and/or products. Making rationalization decisions requires governance bodies that make integrated decisions on these three subjects. If such governance bodies do not exist, a separate rationalization board may be required.

The central rationalization office will play an important part in that governance process. The rationalization office manages the roadmap and prepares for fact-based decision-making.

5. Execution

Whenever possible, the actual execution of rationalization projects should be part of the “business as usual” change processes and organization. Creating a separate rationalization organization is often unnecessary, although sharing best practices among rationalization project teams is vital.

During project execution, the rationalization office monitors progress and benefits of rationalization initiatives. With this information, the rationalization office creates an integrated view of the progress of rationalization, and reports to top management.

Conclusions and Lessons Learned

Application rationalization has proven to be a successful instrument to simplify an organization and increase its power to innovate and reduce costs at the same time. However, rationalization is not a simple task that can be done “on the side”. To actually achieve results with application rationalization it is necessary to have a set of important prerequisites in place:

1. Ensure the Board communicates a clear simplification vision.
2. Add rationalization targets to the planning of business, process and IT owners.
3. Allocate a separate budget for rationalization, apart from regular change budgets.
4. Identify content knowledge carriers (promoters) that embrace the rationalization.
5. Communicate rationalization successes; make rationalization “sexy”.
6. Execute rationalization projects as regular projects and maintain the usual change processes.
7. Make rationalization part of your sourcing partnerships (e.g., through rationalization incentives).
8. Create a fact-based 360-degree view of the application landscape.
9. Set up an independent rationalization office to create traction and monitor benefits realization.
10. Ensure that the reduction of FTEs is not regarded as a goal of the rationalization.

Without governance and a structural rationalization process, the entropy will return over time. Application portfolio management may be the way forward to embed rationalization in the DNA of an organization. However, application rationalization is an essential first step to resolve the application entropy.