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 software applications concerning 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, and 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? Or what do you spend on the so-called 'free' open-source applications? Be true to yourself!
These four topics alone teach 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. 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, database 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 Visualization & Application Services Roadmap Visualization - Also it is recommended to have a workable visual overview of the landscape on an A0-sized visualization available. At least as inventory. The visualization shows per application the information needed to be able to make decisions on rationalization (and having true cost insight): Why is this application needed?
3. Mapping the architecture onto the landscape - You can map the architecture onto the landscape to see what standardization, migration, and deduplication have to take place. Also, you can map business process models to the application 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 just another term for being sensible and thinking 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 to measure results and adjust actions. Also in the architecture repository, you can define your unique enterprise meta-model to relate entities correctly.
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.
Screenshot of the Import Module.
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, excel sheets or exports from CMDB tools or other architecture tools.
Screenshot of the Import Module.
One of the unique things 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 Import 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.
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 Data Manager 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 to have a lot of data present in Dragon1 about your applications. The Data Manager is a module helping you to deal with big data entry.
Screenshot of the Data Manager.
In the Data Manager, 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 Data Manager here.
5. Use the Applications 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 with the architecture. Now you have 'objective' arguments to make the right decisions making the landscape more compliant with the architecture, often resulting in lower costs and less complexity for your applications.
Related Content