Application rationalisation: just like high school sex.
I was reading the other day on brianmadden.com how VDI was just like high school sex. You think everyone else is doing it (even though they are not), everybody else pretends they know how to do it (which they don’t), but for those few that have actually done it, the experience was a pretty painful one! I think that the analogy could be easily extended to application rationalisation.
The reality is that even for those organisations that have successfully completed their enterprise Windows 7 migration, the application rationalisation piece probably involved a lot of fumbling around in the dark before anything started to happen. But why is application rationalisation such an issue and what have we learned at Juriba in the last 4 years of helping Windows 7 and virtualisation migrations?
Here are my top 6 tips for application rationalisation:
- Application rationalisation should be a short, fixed term piece of work – placing too much dependency on it can really stall the project
- Identifying what type of application inventory you want as the master source is absolutely critical to successful rationalisation – don’t try to do all of these (MSI package entitlements, MSI installs, add/remove programs installs or executables)
- Multiple versions of the same application consolidating to one is the easiest type of rationalisation and should be the first step
- Usage-based application rationalisation is the biggest hit on the application list, but takes significant time and effort to achieve – enter if you dare, but plan on 3-6 months of lead time to achieve the best results! It’s worth it if you have strategic plans to move the process into BAU
- A significant win can be delivered simply by focussing on the applications entitled to 5 users or less, or installed on 5 machines or less – we recommend a parallel run programme for this piece
- Rationalising multiple, functionally similar applications to one never seems to get the right business sponsorship and can create more hassle than it’s worth to the migration programme – don’t waste too much time on this.
So what really is the issue here? Why is application rationalisation so hard?
Greg (Project Manager): ‘I’ve told senior management that come the end of the Windows 7 rollout, we will have a consolidated applications list and be fully license compliant.’
Mike (Tech): That’s great Greg. Did you build some time into the plan for application rationalising, and budget for new/upgrade licenses?’
Greg: ‘Er…no. Obviously rollouts are the priority, especially as management expect us to be migrated within 12 months.’
Mike: ‘That’s great Greg. Application rationalisation is quite a big deal.’
Greg: ‘Look, it’s only working out a new list of applications – can’t be that difficult! We’ll let the business tell us – they must know what applications they need.’
Mike: (under his own breath): ’Twit’!
Herein lies the problem. For those that understand application management, the thought of doing a proper application rationalisation is the stuff of nightmares. For those that don’t, it’s the simplest thing in the world.
Let me explain. In your organisation, the applications estate is a complex beast. I’ll bunch them into four categories. You have your applications that are delivered through your SMS/SCCM (or equivalent) infrastructure. We’ll call them your ‘managed’ applications. Next you have your managed applications that are installed but you are not sure how they got there (for example, roaming users that have installed apps to a machine or a desktop support analyst that has installed an application from the gold source manually). Of course, you cannot be sure if these apps were installed by the current machine owner or are needed in the migration. Thirdly, you have applications installed from somewhere that you know nothing about such as from the internet. We’ll call these your ‘unmanaged’ apps and they mostly show up in your add/remove programs (ARP) list. Finally, you have those unmanaged apps that don’t even show up in ARP like Excel plugins, activeX controls and the like. We’ll call these your ‘invisible’ apps.
So, four initial sources of inventory, all of which overlap. Sometimes, you may even have a fifth source; list of executables that the users have launched in the last xx days. These ‘applications’ may not even have a title, but an application it is, and as such, you need to worry about it! We’ll call these your ‘in use’ applications.
So we have the question of how we’re going to mash all of this application data together to make something useful in terms of a plan. You need to decide what makes your authoritative application list source, and how you are going to refresh.
Now we need to consider some additional complexity. Some of your users have administrative rights. They can, if the mood takes them, install any application from any source onto their (or your) machine. The higher the proportion of administrative rights users, the greater the size of the unmanaged and invisible application estate. Ask whether these apps are important to your programme.
Most organisations have a mix of ‘off the shelf’ versus ‘in house’ written applications. This places you in the hands of software vendors (who may no longer exist) or resources in your organisation that may have long since deserted. The spectre of maintenance contract reviews, upgrades, internal application redevelopment and licensing review looms large. You contact your procurement department to understand your licensing … and wish you hadn’t! This is where some of the application compatibility tools can provide significant benefit as you can reduce the discussions with the business to what’s really necessary.
We also need to think about different application platforms. Most organisations use a combination of fat client, Citrix and web apps. Hmmm – an inventory of web applications and who uses them … we’ll leave that thought for now! You are also being pushed to consider application usage as criteria for the go-forward list of applications. This involves infrastructure, an agent rollout, data collection period, and a period of heavy lifting to make sense of the vast amount of information you have just gathered.
Getting the picture?
Now we need to factor in the go-forward position. We want to rationalise, we want to virtualise, we want to standardise. We need to take everything above and make it into something that a project manager can understand as the migration requirement. It amazes me sometimes that these projects even manage to get off the ground, let alone deliver major benefit in a reasonable amount of time!
In my next blog, I’ll be exploring how to address application rationalisation, and how to get the best bang for your buck when embarking on such an initiative.