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?
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.