It's time to solve the application rationalisation problem.
When you have been involved in as many enterprise desktop migrations as we have at Juriba in the past few years, you start to see certain patterns emerging. This ranges from the general underestimation of work effort through to a familiar lack of project deployment strategy. The resulting impact is unfortunately one of business disruption, increased cost and a longer project than anticipated.
One of the most common patterns we see is in the application rationalisation arena. There is an almost unwritten expectation that the post-migration world will be much cleaner than the pre-migration world. This is entirely reasonable. In even the best managed environment, 10 years of running an operating system and thousands of desktops is inevitably going to drive complexity into the application estate. Essentially, you cannot rally against human nature. It is much quicker for a support analyst or business user to install an application manually than tell your customer (the end user) that they must wait 15, 30 or even up to 90 days (in some organisations) to get their packaged application distribution.
Unfortunately, this leaves every project in the world with a serious dilemma and a decision that no desktop migration programme in the world really wants to take: do we give the users what they officially have, or do we try to give them back what they had installed prior to migration? The former breeds a cleaner desktop migration project of known states but likely user disruption. The latter places a huge amount of additional workload on the teams in analysis, categorisation, identification and possibly licensing of applications.
So we end up with a choice where neither answer is particularly appealing. Do we take a big decision to take on the add/remove programs mess or do we take the expected business impact of users not getting back what they had previously by replacing the like for like official application entitlements? We consider a third option – can we collect usage data to do the application rationalisation for us, requiring a 60-90 day minimum lead time for trustworthy information?
If we decide to go down the add/remove programs or discovery/usage route, we are left with a mass of data. Typically around 2.1 times the computer count (in other words an estate of 10,000 computers will yield an application count of 21,000 unique application entries). A quick scan around the room generally identifies the poor individual(s) that will be charged with categorising the list!
Time passes, money gets burnt, resources are employed and we end up with a normalised list of applications. A common pattern here is that the output of this work is in spreadsheets. Unfortunately, this effectively means the programme is stuck with static data for the foreseeable future. Many normalisation efforts use a combination of logic and human choices which are not repeatable for refreshing the data. Some usage tools will do a certain level of normalisation out of the box but very rarely get anywhere near to your required result without further manual intervention.
So we now enter the application packaging phase. Of course the applications team are used to MSI packages, some of which include multiple add/remove programs entries. They don’t understand the list of normalised applications from ARP that you have provided, and now need to manually map those entries to something that they recognise – a difficult job. Further, it is much harder to find source code for an ARP entry than it is to find an MSI you have already packaged!
Now of course, these applications do eventually get completed. The team works through the mess and delivers the required end result with a lot of effort. But it all feels so wrong – an incredibly painful journey, but a path that the vast majority of organisations will tread in the coming couple of years.
The moral of the story is that as an industry, we need to get better at desktop applications management. Moving to Windows 8 or 9, or moving to virtual should not be the huge effort that it is today. Let’s get our heads around the problem and start solutioning. I would love to see a concerted effort to uniquely identify applications – whether it be an executable, Excel macro, add/remove program entry or packaged MSI, the world would be a better place if we had a central database somewhere! A place where you could upload your app metadata and store it for reference later. If we don’t start solving this now, I fear that the next rollout will be another wheel re-invention. Nobody wants that!