Application Rationalization: Anyone can save money with
Often, when cutting budgets, someone yells: Well, can’t we do something with Application Rationalization? Do we need all those applications? And that’s when Application Rationalization starts.
Why create your list with rules and guidelines for Application Rationalization
Here are ten rules for Application Rationalization derived from design principles that I have collected during the past 20 years when I have been busy with one thing called: application.
Next to these 10 rules and guidelines, I work with a list of 100 rules and guidelines and an approach to Application Rationalization in the open Dragon1 EA Method. And I urge you to do the same, document the rules and guidelines for your use!
Of course, there is more to Application Rationalization than these 10 rules and guidelines, but it is a fresh start, and with what I have seen in practice always, one or more of these 10 rules and guidelines are overlooked. So, see this as your Application Rationalization Cheat list.
What is Application Rationalization?
Application Rationalization is an organization's strategic process of coming to the lean set of the most necessary applications for primary business processes. If possible, all applications that duplicate functions will be phased out or switched off. The objective is to lower the complexity of the application landscape and the average application cost. This creates a more vital, adaptive, and scalable application landscape.
What are the benefits of Application Rationalization?
Application Rationalization is a topic in every organization. If it is done correctly, it has mainly two benefits:
1) Decrease Complexity - The application landscape becomes less complex, thus becoming more flexible and easier to increase and ensure business continuity.
2) Lower Costs - The application landscape becomes less costly, thus leaving room for more application renewal and other IT projects.
The road to reducing costs and complexity is standardization, migration, integration, and deduplication.
#1 - Be aware that application is short for software application
With Application Rationalization, defining what you are rationalizing is important. A software application is the Application of software . Be sure to create a list of groups and technical and functional types of applications that are present or needed.
#2 - Create a list of applications
After you have agreed upon what an application is and what groups, technical, and functional types of applications fit the definition, compile a list of past, present, and future applications.
# 3 - Find out who owns the application
You can’t do anything with an application if you do not know who owns it. So, if you want to phase out, change, renew, or do anything else, you need to know the person who owns the application. Again, these owners will lead you to stakeholders, such as the applications' users.
You will see ownership is not easy to state.
#4 - Know that every functionality you need is already available in standard (COTS) software
During Application Rationalization, it is necessary to have an application criteria list for application functions and application technology. Certain applications you need or don’t need functionally, and certain applications you need and don’t need technically. For instance, the backdoor application that administrators have surpasses any security so that you can update applications quickly.
You often don’t want self-build, tailor-made software because of its immaturity and skipped testing period before going live. Often, in professional organizations, you only want certified COTS software. Maybe even build in open source technology.
#5 - Take a look at the misusage of applications
Often, applications are misused. They have found their use by users. Email is often misused as ... Excel is often misused as … So if you remove that application, another application will fill its gap. So, you need to look at the vendor-listed functionality and interview users about what and why they use an application.
#6 - Create an Application Architecture Vision and an Application Architecture Framework
A best practice is to develop an application architecture vision and an application architecture framework with principles and rules. This means, compliant with Dragon1, define a set of business, information, and application concepts that, for the long term, need to be present in your organization and require for or maybe require the exclusion of certain functions and technology in applications. Examples of these concepts are BYOD, COTS, ERP, Loosely Coupling, Digital Workplace, Customer Intimacy, CRM, eProcurement, Information Security, Tracking and tracing, EDP Auditing, Operational Excellence, Business Continuity.
#7 - Create an Application Landscape Poster and an Application Roadmap Poster
It is also recommended to have a workable visual overview of the landscape on an A0-sized poster based on the earlier compiled list. At least as overview inventory: f.i. What parts of the organization were not touched when looking for applications? And on that poster showing per application the information needed to make rationalization decisions (and having true cost insight): Why is this application needed?
An application landscape is not an application landscape without processes and users using applications to handle business objects, without the services, actions, information objects, and interfaces of the applications, and without the databases, servers, and locations where the applications are at and without rules, roles, licenses, service contract and costs of applications.
#8 - Map the architecture (total concept) onto the landscape
Next, map the architecture (a total concept) onto the landscape to see what standardization, migration, and deduplication must occur. Also, you can map business process models to the application to see their alignment: costs versus business value. You can also check your application's technical and functional quality with architecture and landscapes.
#9 - Establish the application business value, its quality, and its costs
Determine the cost and value of every single application. Work with a benchmark: what may an application cost in our industry or types of organization?
A common way to establish an application's business value is to link it to business goals. So now you have to create a list with business goals to be able to do that. And for that, we need the owner of the company and the owners (management?) of the applications.
To determine the quality of applications, you can use the practice of references: who else is going to or still using this application? What do specialists think of the application? And is the application certified by any consortium?
A best practice for establishing the application costs is to look closely at all the annual maintenance, services, and license costs. Read more about that in the topic Total Cost of Ownership: on Wikipedia.
#10 - Make Application Rationalization into a continuous process and work from top to bottom
Create awareness of cost vs business value of applications. Do involve everyone in the why, when, and what of applications; listen very carefully to everyone, but do NOT involve everyone in decision-making. Work topdown. Never middle-out or bottom-up!
If it is good for the organization, make a case for enterprise-wide standardizing on certain platforms. Because if done correctly, it can be done.
Also measure the effect of Application Rationalization on certain applications. If it has had no effect, it may not have been done! Users may still be using the functionality or technology in some way or the other.
More information?
If you want to know more about Application Rationalization using the Dragon1 EA Method and Software, check out: Application Rationalization.
Also, I would be glad to hear any comments on my blog. I am curious to hear your top 10 list of rules and guidelines for Application Rationalization. Maybe if we put all these lists together, we can finally win the battle of application costs and standardization in our organizations.
Here is a page about the Gartner strategy for Application Rationalization: https://www.gartner.com/smarterwithgartner/5-year-vision-for-application-leaders, thanks to a tip out of my network. Most importantly, Gartner defines three types of systems for applications based on their role: systems of record, systems of differentiation, and systems of transformation. This is an interesting thought to classify applications on.