Application Normalisation: In Search of the Panacea

When companies begin their transition planning for a new operating system such as Windows 7, much of the initial focus will be on the applications. Usually, this means trawling an unholy mess of ‘application’ data incorporating security fixes, driver packages, multiple versions, same versions with different names, language differences and vendor names.

As an example, here is a common scenario:

These two applications look identical. But to a data warehouse, they are distinct. The ‘Inc.’ in the vendor name for row 2 makes it different.

So what is application normalisation?

Application normalisation is an automated or manual process that takes the initial list of application data and amalgamates it where similarities are discovered.

Why is it so important?

Imagine a company with 10,000 users in a relatively locked down environment (i.e. maybe 20% of users have administrative rights to their desktop). How many unique application rows would you expect to find in this organisation? If your guess is somewhere between 30,000 and 50,000, then full marks – you’ve obviously done this before! More often than not, this is the scale of the issue facing our Windows 7 migration project management teams.

What are the options?

The first option is to trawl the list manually. You can get rid of thousands of rows very quickly. It’s a perfectly workable option if approached in the right way. This mean that decisions taken during the manual trawl must be maintained across the project. However, it is likely that you will still be left with a huge number of applications. Unfortunately, too often we see a company perform a manual trawl, only to never link it to the future state data, or maintain the current state data, meaning that it is stale and irrelevant within weeks.

The second option is to perform an ‘automated’ normalisation. This involves taking a product, loading in your application inventory and having the product normalise the data for you. It’s a task performed by multiple products on the market today but the question on most lips is, ‘how successful will be it be for my organisation’s application data?’

How does application normalisation work?

In most products, the normalisation works on two key principles:

1. A global catalogue of application and application vendor mapping
2. Fuzzy logic which can identify applications that ‘look’ similar

There are some obvious flaws to this. Number one, your guaranteed normalisation will only ever be as good as your global catalogue. Most of these will have hundreds of thousands of apps, and I would expect that for the common applications you will get a big hit rate reduction.

However, what about your internally written applications? Clearly these will not exist within any global catalog, so now you are dependent on fuzzy logic. Here is an example:

Are these the same application or different applications? Maybe R2 is an upgrade of R1 and just hasn’t been fully deployed. Maybe R2 is a brand new application that needs to be tracked separately. Fuzzy logic could give either outcome. The reality is that only you and people within your organisation know the answer to this question.

So how successful can application normalisation really be?

The answer to this probably depends on your mix of vendor vs in-house written apps. The higher the number of off-the-shelf applications, the better the normalised output. The bigger the estate of in-house apps, the less successful the exercise.

For your organisation it becomes a question of value: how much manual effort will automated normalisation save you? What will be left? At Juriba we are currently pondering this and many other questions of how to help customers accelerate their Windows 7 migration. So my final question to you is: is this a feature which you feel would be important in helping to achieve your goals? If so, leave your thoughts below, and who knows, we might just consider it for inclusion in the Dashworks Windows 7 readiness tool.