Application rationalization: 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), and everybody else pretends they know how to do it (which they don’t), but for those few that have done it, the experience was pretty painful! I think that the analogy could be easily extended to application rationalization.
The reality is that even for those organizations that had completed their enterprise Windows 7 migration, the application rationalization piece probably involved much fumbling around in the dark before anything started to happen. But why is application rationalization such an issue, and what have we learned at Juriba in the last four years of helping Windows 7 and virtualization migrations?
Here are my top 6 tips for application rationalisation:
- Application rationalization 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 critical to successful rationalization – 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 into one is the most accessible type of rationalisation and should be the first step.
- Usage-based application rationalization is the biggest hit on the application list. Still, it takes significant time and effort to achieve – enter if you dare, but plan on three to six months of lead time to achieve the best results! Having strategic plans to move the process into BAU is worth it.
- A significant win can be delivered simply by focusing on the applications entitled to 5 users or less or installed on five machines or less – we recommend a parallel run program for this piece.
- Rationalizing multiple functionally similar applications to one never seems to get the right business sponsorship. It can create more hassle than it’s worth to the migration program – don’t waste too much time on this.
So, what is the issue here? Why is application rationalisation so hard?
Greg (Project Manager): ‘I’ve told senior management that by 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 rationalizing and budget for new/upgrade licenses?’
Greg: ‘Er…no. Rollouts are the priority, especially as management expects 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 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. It’s the simplest thing in the world for those who don't.
Let me explain. Your organization's application estate is a complex beast. I’ll group them into four categories. You have applications delivered through your SMS/SCCM (or equivalent) infrastructure. We’ll call them your ‘managed’ applications. Next, you have installed your managed applications.
Still, you are unsure how they got there (for example, roaming users who have installed apps to a machine or a desktop support analyst who 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 if they are needed during the migration. Thirdly, you have applications installed from somewhere you know nothing about, such as on the Internet. We’ll call these your ‘unmanaged’ apps, which mostly appear in your add/remove programs (ARP) list. Finally, you have those unmanaged apps that don’t even appear in ARP, like Excel plugins, ActiveX controls, etc. 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: a list of executables the users have launched in the last xx days. These ‘applications’ may not even have a title, but an application it is, so 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. If the mood takes them, they can 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 program.
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 organization that may have long since deserted. The specter of maintenance contract reviews, upgrades, internal application redevelopment, and licensing reviews looms large. You contact your procurement department to understand your licensing … and wish you hadn’t! This is where some application compatibility tools can provide significant benefits as you can reduce the discussions with the business to what’s really necessary.
We also need to think about different application platforms. Most organizations use a combination of a 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 a criterion for the go-forward list of applications. This involves infrastructure, an agent rollout, a 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 rationalize, virtualize, and standardize. 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 benefits in a reasonable amount of time!
In my next blog, I’ll explore how to address application rationalisation and how to get the best bang for your buck when embarking on such an initiative.