Application Rationalization - 10 Rules and Guidelines

vrijdag 1 mei 2015 | Likes: 0 | Comments: 0

Mark Paauwe

VP Product Development

Dragon1 Inc

Application Rationalization: Anyone can save money with

Often when cutting budgets someone yells: Well can’t do we something with Application Rationalization? Do we really need all those applications? And that’s when Application Rationalization starts.

Why create your own list with rules and guidelines for Application Rationalization

Here are ten rules for Application Rationalization derived from design principles which 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 of Application Rationalization in the open Dragon1 EA Method. And I urge you to do the same, document the rules and guidelines for your own 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 ten rules and guidelines are overlooked. So, see this as your own 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 vital and necessary applications with respect to 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 more easy 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 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 https://en.wikipedia.org/wiki/Application_software. Be sure to create a list of groups, technical and functional types of applications present of 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 that surpass 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 life.  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 really need to interview users for what and why they use an application for.

#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 to Dragon1, define a set of business, information and application concepts that for long-term need to be present in your organization and require for or maybe require 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 take decisions on rationalization (and having true costs insight): Why is this application really 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 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.

#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 in order 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: https://en.wikipedia.org/wiki/Total_cost_of_ownership

#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 is has had no effect, it may not have been done! Users may still be using the functionality or technology 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, 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 differentation and systems of transformation. This is an interesting thought to classify applications on.

Two more interesting quality links on Application Rationalization are Application Rationalization Key Initiative Overview.

 

Di, 2012-12-21 12:21