Application Rationalization: Anyone can save money with
Often when cutting budgets someone yells: Well can’t do we 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. All applications that duplicate functions will be, if possible, phased out or switched off. The objective is to lower the complexity of the application landscape and to 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 that wanders around 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 the reduction of costs and complexity is one of standardization, migration, integration, and deduplication.
#1 - Be aware that application is short for software application
With Application Rationalization it is important first to define what you are rationalizing. A software application is the Application of software . Be sure to create a list of groups, and technical and functional types of applications present or needed.
#2 - Create a list of applications
After you have agreed upon what is an application 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. These owners again will lead you to stakeholders, such as the users of the applications.
You will see, ownership is not an easy fact 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 you can update applications quickly.
And often you don’t want self-build software, 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 take away that application, some other application will fill its gap. So you need not only to look at the vendor-listed functionality, but you need to 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
Also it is recommended to have a workable visual overview of the landscape on an A0-sized poster available, based on the earlier compiled list. At least as overview inventory: f.i. what parts of the organization were not touched looking for applications? And on that poster showing per application the information needed to be able to make decisions on rationalization (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 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.
#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 to establish the business value of an application 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 costs of application is to look closely at all the annual costs for maintenance, services, and licenses. 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 the decision-making process. Work topdown. Never middle-out or bottom-up!
And if it is good for the organization, make a case out of enterprise-wide standardizing on certain platforms. Because if done correctly, it can be done.
Also measure the effect Application Rationalization has had 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 what your top 10 list is 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 important is that Gartner defines three types of systems for applications based on the role they play: Systems of Record, systems of differentiation, and systems of transformation. This is an interesting thought to classify applications on.