Application Rationalization Solution

Application Rationalization as Solution

When applications are increasing in numbers, user licenses go through the roof. If you cannot oversee anymore the complexity and interfaces of your landscape, and introducing a new IT service takes months instead of days, you might consider doing Application Rationalization.

On this page, you can read how you can use Dragon1 for the design, visualization, realization, communication and management of your 'Application Rationalization' strategy.

What is Application Rationalization?

Application Rationalization is an organization's strategic process of coming to the lean set of the most vital and necessary software applications with respect to primary business processes. Read more about the Application Rationalization definition here.

A. Application Service Catalog. Is your front door closed? If a manager wants a new application, can you check if what is requested, is already in some form of application present? Is there a policy available that a manager needs to justify that an on-premise application cannot be used for what he wants? Are budgets for buying applications centralized or decentralized?

B. Application Criteria Standards. Is your backdoor closed? Do you have a list of application criteria that every application must meet, or else it may not be bought or implemented in the production environment? No?

C. Ownership. Who owns the applications? Who may decide to upgrade, update, phase-in, phase-out, migrate, connect applications? Not knowing this can cause showstoppers in your application strategy.

D. Benefits. Do you have insight into what the benefits are for the business and the processes of using the application? No?

E. Costs. Do you have an overview of all the (hidden) costs of your applications? How expensive are self-build software tools really? Or what do you spend on the so-called 'free' open source applications? Be true to yourself!

These four topics alone learn us that having just a list of applications is not enough. We need to have a list of application benefits, application costs, application ownership and application criteria. And if you are going to use a tool, you need to be able to store, manage and visualize these lists next to the lists of information systems, applications, databases modules, components, suites and vendors.

What are general visual architecture products to create for Application Rationalization?

1. Application Architecture Vision & Application Architecture Framework - A best practice is to develop an application architecture vision and an application architecture framework with principles and rules.

2. Application Landscape Poster & Application Services Roadmap Poster - Also it is recommended to have a workable visual overview of the landscape on an A0-sized poster available. At least as inventory. The poster shows per application the information needed to be able to take decisions on rationalization (and having true costs insight): Why is this application really needed?

3. Mapping the architecture onto the landscape - You can map the architecture onto the landscape to see what standardization, migration and deduplication has to take place. Also, you can map business process models to the application in order to see their alignment: costs versus business value. And you can check the technical quality and functional quality of your application with architecture and landscapes.

Application Rationalization is really just another term for being sensible and think over why you should need a certain application.

Use Dragon1 to design, visualize and communicate your Application Rationalization Strategy

When you want to rationalize applications you need to administer issues and objectives for rationalization in order to measure results and adjust actions. Also in the architecture repository you can define your own unique enterprise meta model to relate entities correctly.

Click to enlarge the Screenshot of the Architecture Repository

1. Use the Architecture Repository to administer issues, objectives, principles and standards for Rationalization

Watch an example of Application Rationalization in the Architecture Repository here.

2. Use The Import Module to reuse application information in files from other tools or architecture products

The first thing done with Dragon1 in application rationalization is often reusing available information on architecture products by importing files, like powerpoint, excelsheets or exports from CMDB tools or other architecture tools.

Click to enlarge the Screenshot of the Import Module

One of the unique things on Dragon1 is that you can set your official data sources that you will reuse time and time again for importing data.

Watch an example of Application Rationalization in the Application Manager here.

3. Use the Visual Designer to generate a landscape based on your meta model, a view template and imported data

With the Visual Designer you can create but also generate architecture visualizations such as application landscape visualizations or process landscape visualizations.

Click to enlarge the Screenshot of the Visual Designer

First you define a meta model, fill a model with the imported data and then generate a visualization using a view template.

Watch an example of Application Rationalization in the Visual Designer here.

4. Use the Catalog to enrich your data with details to know the true costs and business value of applications

To significantly rationalize your application landscape, it is important having a lot of data present in Dragon1 about your applications. The Assets Catalog is a module helping you to deal with big data entry.

Click to enlarge the Screenshot of the Catalog

In the Assets Catalog you can enter a lot of information about the different costs of the application and the business value of the application: how, when and why is it used? Also you can alter the forms and add or remove attributes from the catalog forms.

Watch an example of an application profile in the Assets Catalog here.

5. Use the Application Landscape to decide on lower costs and complexity reduction

If you have created an application landscape overview and you have mapped the application architecture onto the application landscape, you will see where the landscape is compliant and where it is not compliant to the architecture. Now you have 'objective' arguments to take the right decisions making the landscape more compliant with the architecture, often resulting in lower costs and less complexity for your applications.

Related Content