In a previous post, we made the business case for application rationalization, and highlighted the key levers to save. This post details a comprehensive guide to application rationalization for your enterprise.
THE GUIDE TO APPLICATION RATIONALIZATION
Almost every organization has taken inventory of their application landscape at one time or another. Unfortunately, many businesses carry out one application rationalization endeavor just once, then revert back to previous practices of amassing excessive applications afterward. Application rationalization is best achieved through a step-by-step process with continual adjustments based on a robust application inventory. A successful approach for application portfolio rationalization involves to properly define the scope of the rationalization efforts, build the inventory, assess individual applications, plan the target portfolio and eventually plan implementation, and after that implementing processes that ensure lasting success.
Figure 1: Application Rationalization in Six Steps.
1. Set application rationalization scope
In consideration of time, companies may choose to rationalize all applications at once. This method initially sounds appealing, but experience has shown that likelihood of success is low. This hasty approach may introduce high risks and sink large amounts of money in an up-front investment, thereby even introducing more redundancy.
A more practical approach is to develop a strategy that involves multiple iterative projects for a focused scope. Which means each concentrated rationalization effort only focuses on applications that support specific business capabilities or organizational units - of course, always considering strategic and tactical business goals. When deciding on the scope of your application rationalization efforts, it is beneficial to consider your operating model.
One way to look at the operating model is the degree of process standardization and process integration. There are four generic operating models as laid out in figure 2 below.
Figure 2: Overview of generic operating models
Standard scoping considerations
After seven years of performing application rationalization projects on organizations of all sizes in various industries, LeanIX has assembled a list of best practices, although organizations should not limit themselves strictly to them. Consider unique individual business goals and challenges that will have a strong impact on your organization’s particular application rationalization scope.
A: Diversified operating model: independent business units with different business models (e.g., GE) The best-fit application rationalization project for this model includes optimizing processes and applications within each business unit individually with the objective of improving efficiency. There will most likely be an individual rationalization project within each business unit.
B: Coordinated operating model: unique business units with strongly coordinated transactions (e.g., Merrill Lynch) The best fit application rationalization project for this integrated operating model includes rationalizing information assets with the objective of establishing a single-version-of-the-truth that provides easy access to key information across the enterprise.
C: Unified operating model: single business with global process standards (e.g., Delta Air Lines) Unified operating business models would benefit from a broad scope of application rationalization that enables enterprise systems to enforce the standards and maximum possible improvements.
D: Replicated operating model: independent but very similar business units. (e.g., Marriott) This model will benefit from establishing standard infrastructure and application components for global efficiencies one business unit at a time. One definitive goal of this model is to share and avoid the replication of systems. All organizations, regardless of their operational model, would benefit from rationalizing the technological architecture within a business domain (such as: Financials, Human Resources), with the objective of standardizing processes and consolidating the applications. Another general consideration for initial rationalization projects is to focus on the “quick wins.” These wins enable progression at an appropriate pace and generate early gains that can finance further innovative projects.
During the scoping phase, it is imperative to involve business and IT leaders in the planning process to prioritize, scope, and support ongoing rationalization projects. With the added help of other business points of view, the full picture will always be aligned.
2. Build your inventory
The process of rationalizing your applications begins with capturing key information about the current inventory of all applications deployed in the first elected scope. In this step, you will gain insights into the application and their business relevancy to improve businesses support and plan the roadmap for the future state.
Virtually every organization has executed an application inventory collection effort at some time or another. One element that characterizes these efforts is that they are usually one-time events marked by a push to collect application data, which results in a new spreadsheet (one that is probably different from and unrelated to the one collected 18 months earlier). Collecting spreadsheets alone is an insignificant task. Therefore, it is highly recommended to begin the inventory process with proven professional tools, like LeanIX, as it can vastly improve the inventory process, by (semi)automatically loading and collecting data via surveys or its various integrations.
The typical process looks as follows: Gather the available documentation (e.g., from Excel, Sharepoint, Visio) into LeanIX. This step forms the basis of the inventory. LeanIX allows automated integrations to other helpful tools, like CMBDs, Business Process Modeling Tools and ERPs help to form the initial baseline.
Great tools aside, there is no substitute for human intervention when it comes to determining basic information such as completing the application portfolio, adding business support and application owners. In LeanIX, this is as well supported by userfriendly workflows.
Which data to collect
During an application rationalization endeavor, your organization will need to collect pertinent information about every single application deployed in your company. That will be covered in more detail in the following chapter. But in addition to applications, some structuring element is needed. In general, categorizing applications by business capabilities is much better suited than categorizing by processes. Gartner defines business capability modeling as a technique for the representation of an organization’s business anchor model, independent of the organization’s structure, processes, people, or domains. Business capabilities show what a business is currently doing and what it should do in order to meet current and future goals.
Rather than get lost in the details of business processes, a target business capability model helps structure the application rationalization process. From this model, it can be decided which applications are vital, which are not useful, and which should be decommissioned. Business capabilities can serve as the structuring element to uncover redundancies in IT, as well as discussing the areas of strategic investing or divesting. In addition to that, it is recommended to collect the information about user groups (e.g., organizational units). The information ‘which application is supporting which business capability and used by whom’ is crucial to decide on application rationalization.
The minimum dataset is to be collected: Applications, Business Capabilities they support, and User Groups that use the system. Applications should be linkable to a specific business purpose and business users strategically utilize them to create direct business value. Therefore, applications are the perfect conduit between business architecture and technology architecture. By linking your applications from the lowest level to the business capability they support, you’ll gain a complete overview of which capabilities are currently supported, which are missing, and which applications should be added.
3. Assess the application portfolio
Application evaluation can be simple or elaborate, depending on organizational maturity and needs of the organization. For some organizations, simply reviewing support for their mission objectives and capturing an estimate of application costs will be a substantial accomplishment, and enough to identify where to decommission applications that don’t fit. If recommendations for your company’s applications aren’t that obvious, a more-detailed evaluation is required, and every single application needs to be thoroughly assessed. Deep assessments call for an advanced application rationalization model.
The pragmatic approach As a standard, LeanIX captures the functional and technical fit at each application. This information provides a lot of input and direction for an initial assessment. Values produced can either be set by a responsible party or calculated based on more detailed inputs. No matter the complexity of the project, LeanIX survey module simplifies the collection process.
• Functional fit. The degree of support for business capabilities or processes. If you only consider one criterion, it should be the functional fit.
• Technical fit. How does the application fit with technical standards, is it based on aging technologies?
These are the definitions we suggest for each category:
• Functional fit
o Unreasonable (1): Not enough or wrong functionality.
o Insufficient (2): Rudimentary functional support.
o Appropriate (3): Supports all major functions.
o Perfect (4): High number of functions available.
• Technical fit
o Inappropriate (1): Replacement mandatory to satisfy the business requirements.
o Unreasonable (2): Replacement recommended to satisfy the business requirements.
o Adequate (3): Some parts of the application could be optimized.
o Fully appropriate (4): No change needed apart from regular maintenance.
In LeanIX software, we rate application criteria on a simple scale from 1 to 4, in order to avoid a tendency to the middle. In combination with the functional fit, these criteria allow you to rank your applications in an application portfolio view. As a result, you can score applications on two axes from high to low, dividing your application portfolio into four generic types that each have different recommended actions. We will elaborate more in the fourth chapter about deciding the target state. In figure 3 you'll see an example of a LeanIX survey to query the above information. The survey is designed in a way that makes it as easy as possible to fill by the responsible party. All information is automatically updated in the LeanIX inventory.
Figure 3: A pragmatic survey for application rationalization
Further assessment criteria
The criteria mentioned above helps facilitate preliminary initial scoring of applications, as they are easily understood and will prevent the tendency to spend excessive time on the assessment phase. But it is also important to go deeper in your analysis.
The following criteria apply to digging deeper into your application analyzation:
• Strategic value. Does the application support the business strategy?
• Available skills. Do employees have the necessary skill set to use it to best advantage?
• User satisfaction. To what degree are users satisfied with the application performance and benefits?
• Availability of alternatives. Are there better alternatives, e.g., commercial off-the-shelf solutions?
• Total cost of ownership. What is the sum of all cost that is attributed to the application?
• Conforming to architectural principles and standards. How is the application conforming to defined architectural principles and standards (e.g., standard technologies, cloud first strategy)?
• Security risks. Does the application pose any security risks due to its architecture?
• Documentation and training. How well are the available documents and training materials?
In figure 4 below, we have summarized a catalog of criteria that you can apply to these assessment criteria. Figure 5 shows how LeanIX Survey can be used to easily collect further, custom data on applications.
Figure 4: Overview of potential application assessment criteria
Figure 5: A more detailed example for an application rationalization survey
Advanced model to assess applications by functionality (Beyer- Smertnig model)
While scoring applications on their functionality may seem easy, in reality, it can be a difficult task. Different stakeholders and users have different preferences and the perceived functionality of systems can be rather subjective. Sometimes the functional assessment falls on a simple scale, e.g., a rating of complex applications from 1 to 5. At times this simplicity is not enough.
For complex application rationalization processes, it is imperative to use a rating system that is objective and focuses fully on business support. In this case, if there are multiple alternatives for an application, the best will be selected. Use the applications for the most important business capability to your organization begin this assessment, as this allows concrete conclusions for the systems of record.
All considerations are based on being able to arrive at a statement regarding the functional coverage and adequacy of a company’s application landscape within a very short time span - one to two weeks. Many models used in practice seem very complex, not truly target-oriented, too subjective because they rate “soft” factors, or require very complex analyses to create.
Comparability is a fundamental requirement for decision-making. This statement may seem predictable; however, most attempts to reach a decision fail because the two objects being compared are not designed in a sufficiently comparable way. Co-developed by LeanIX Co-CEO Jörg Beyer during his time as CIO, The Beyer-Smertnig model optimally supports these goals and has been successfully utilized in numerous application rationalization projects.
The Beyer-Smertnig model applies to the functional suitability of all IT applications. All of the main functionalities of the applications should be listed. You can use the existing function names; it is not strictly necessary to align the terms. A list will serve as the basis of the assessment. Here too, assessments are made in two dimensions: support and criticality.
Simplified, this assessment takes the following form:
• Criticality:
o Not relevant to success (-2)
o Obligatory (0)
o Critical to success (2)
• Support:
o Not supported (-2)
o Standard support (0)
o Excellently implemented with no need for change (2). Intermediate values of 1 and -1 can also be used.
Figure 6: Example of an application rating
A decision for or against an IT application should be made as far as possible using differentiating characteristics— both negative and positive.
Therefore, the numeric values of zero are very important, as they ensure that obligatory functions are neutrally rated. It is assumed that the superiority of an IT application manifests in its success-critical functions. The second value is, therefore, the respective level of support.
The value of the Beyer-Smertnig model lies in identifying what is necessary and good. Over time, large numbers of obsolete functions tend to build up in IT applications. Therefore, merely analyzing the functionalities is insufficient, as their implementation must also be assessed. Is this a useful function? If so, is it well implemented?
The simple formula application rating = support * (criticality + 2) delivers the resulting values. What looks so insignificant is in fact very powerful. Important functions that have been inadequately implemented are badly rated. The same applies to insignificant functions that have been excellently implemented. Unnecessary items are thus downrated.
Underlying this formula is the simple assessment that insignificant functions can be neutrally rated zero, regardless of their support, whereas inadequate implementations of highly significant functions are rated very negatively. This means there are penalty points for implementing functions that are not critical to success. This also helps cut down on source code that would otherwise have to be needlessly maintained, reducing the complexity of an application and enabling greater flexibility in its further development.
Under the Beyer-Smertnig model, penalty points are assigned for implementing functions that are not critical to success. This also helps cut down on excessive source code, which reduces maintenance cost, reduces the complexity of an application, and enables greater flexibility in its further development.
The limit range is -8 to 8. In figure 6 you can see that the fast “Special Quick Client Data Input” form receives a high rating thanks to its excellent support and high significance. To fully assess both system functionalities, first, calculate the average value.
System 1 = 8/4 = 2
System 2 = 5/7 = 0.7
This calculation gives us a very good indication of whether one IT application is superior to another, and provides a basis for selecting a target application and deriving dependent applications. Realizing which interfaces applications share with other applications and what data flows between them will affect the future selection of applications.
Interim conclusion
If you followed the exercises so far, you will be able to show the application portfolio for your planned scope, in helpful matrix and landscape views. These views already provide an overview of the health of your application portfolio and potential areas for rationalization. If you have followed the Beyer-Smertnig model, you will have very detailed decision support, when in doubt.
4. Decide the target state
During the rationalization process, you have determined the value of each application. In this chapter, we introduce several methods of how to derive the final target application portfolio from this assessment. At the end of this phase, you will decide what to do with every application. The four possible outcomes are described below. From these outcomes, you can define your target architecture.
Keep, Update, Migrate, Eliminate – your basic options
At the end of the evaluation process, your organization will have gathered enough pertinent information to recommend actions for each deployed application.
The recommendations will be one of the following:
• Keep:
o Keep the application and consider further invest in it (high-value application in good technical shape)
o Tolerate the application as it is doing its job (a certain amount of value in good technical shape) or if there is no reasonable alternative
• Upgrade
o Modernize applications as they are of high value to the business (high-value application supported by aging technology)
• Migrate
o Retire application, migrate data and users to an existing application (redundant applications)
o Standardize multiple applications on a common version/ technology platform
o Merge applications (either physically, logically, or both)
o Replace the application with a commercial off-the-shelf solution
• Eliminate
o Retire low-value application without replacement (e.g., not used, low value, based on aging technology)
Decision Flowchart
The flowchart below details a high-level decision tree for deciding the outcome of a single application. If the decision tree leads you to multiple outcomes, consider the relative business cases such as unique business goals, application lifecycles, and availability of domain experts.
Application Matrix
The application matrix is an invaluable tool to discover redundancies. The matrix displays the application in question in the middle, forming a matrix with user groups (e.g., organizations or teams) and business capabilities (the supported business function). This view uncovers redundancies (e.g., multiple HR systems are used across all regions) for the selected scope. Different views (e.g., functional fit, technical fit, business criticality, and cost) will illuminate the problem from different angles.
Figure 7: Decision tree for application rationalization
Figure 8: LeanIX application matrix
Enforce out-of-the-box solutions and reuse
Too many projects adopt customization as a first rather than last option. A company can’t make all its business units embrace standard, completely customized applications immediately, but customization should only be considered only when necessary to meet legal requirements or provide meaningful competitive advantages.
Approach customization as a last-ditch effort. Sometimes a large global enterprise cannot select one application for each business capability for all sections of business for every supporting user group, however, EAs and CIOs should look for cost-effective solutions before automatically opting for costly customization efforts. Many IT projects fail because of excessive customization.
5. Plan the implementation roadmap
Application rationalization efforts will most likely be carried out in several waves – immediate, mid-term, and long-term. The immediate wave focuses on elimination (e.g., the retirement of unused applications), the mid-term wave includes migrations and consolidations (e.g., to move all local applications to the same version) and the long-term wave consists of full rewrites and technical upgrades.
It is imperative to gather business leaders, IT leaders, and EAs to review the recommended actions of each application and formulate a best-fit roadmap for implementation going forward. Involving various business leaders while creating a supporting architecture establishes transparency and will efficiently align the business to IT.
At the end of the mapping phase, there should be defined architecture standards and a set structure for future analysis.
APPLICATION RATIONALIZATION ROADMAP
Figure 9: Three waves of the application rationalization implementation roadmap
6. Make it stick
Now that the application portfolio has been surveyed and optimized, it is crucial to continually maintain the landscape. Onetime application rationalization endeavors may save the organization money in the beginning, but they lack the long-term value that continual application rationalization offers. Application rationalization improves the overall effectiveness of IT and ensures that the IT landscape is actively aligning to business goals and objectives.
The continual governance of the application portfolio is equally important as the previous steps. Be sure to track the operational quality of your remaining applications to help determine the most appropriate adjustments going forward. This new landscape provides the backdrop to assess the necessity of new applications before they are purchased. A clean organized IT landscape prevents wasteful purchases.
Having a data-driven portfolio allows your company to collect high-quality data, analyze real-time metrics, and identify opportunities to improve. Having a clear view of your application portfolio will prevent your company from falling victim to application sprawl.
SUMMARY
In this business climate, operating an agile landscape is key. With digital transformation driving customer demand, the IT architecture will need to dynamically adapt to the rapidly changing needs of the market. Most businesses spend 70-80% of their IT budgets on supporting aging low-value legacy applications, leaving very little money to invest in optimizing business processes. The goal of application rationalization is to articulate an architectural vision that enables the business goals, responds to the strategic drivers, conforms with the architecture principles and standards, and addresses the stakeholder concerns and objectives. Application rationalization efforts will help you optimize your application stack, establish transparency between stakeholders, deliver value to the business leaders, dramatically cut costs, and uncover money to invest in trending topics.
