IT Expert Voice

Any company aiming to upgrade its operating systems first has to get control over its application library. Here’s what you need to know about the process of identifying the company’s applications – not to mention upgrading them to support the new OS – before you undergo one of those painful “learning experiences.”

It’s going to happen, sooner or later. Your boss will turn a baleful eye at the development and IT staff and say, “I’m sure all our software will run under the new OS. Won’t it?” You’ll be tempted to gulp and stammer out a half-hearted answer that confirms the executive’s preconceptions about IT (oh dear) and leaves them with an opportunity to later wail, “What do you mean, ‘We can’t run payroll’?!” We can’t have that, can we?!

There’s three steps in the process of application migration: information discovery, research and rationalization, and the actual application migration or upgrades. (I leave the how-to on the last item to another discussion, though I like to think that Windows 7 Development Gotchas is a start in that direction.) In this article, I provide you with some guidelines about how to approach the problems of “What do we have, and what are we going to do about it?” courtesy of a conversation I had a few weeks ago with Jefferson Raley, Manager of End User Computing at Dell’s ProConsult (and a presenter in the first IT Expert Voice webinar [free download, registration required]).

Whatcha Got?

The first step in any company trying to assess its inventory of software is to determine exactly what applications are installed and being used, Raley explained to me. There’s several ways to go about this, some of which seem clever but don’t necessarily solve the problem.

For example, you could use various software tools to examine the applications listed in any given PC’s “Add/Remove Programs” – except that lots of applications don’t use the Windows installer routines, especially custom in-house applications. In addition, some items displayed in “Add/Remove Programs” aren’t precisely applications; they’re components and drivers. This discovery method will give you an incomplete list and, probably, a false belief that you know what you have in inventory. The technical term for this situation, methinks, is “tempting fate.”

Another obvious “solution” is to use your favorite scripting language to search PCs for every .exe file. It won’t take long for you to put the kibosh on that idea’s effectiveness, though personally I fear that someone higher-up in your corporate organization chart may not twig to the problem. Any “count the .exe” game will generate, says Raley, “an infinitely long list of garbage,” collections of meaningless file names, and no clue whatsoever about the applications the company actually uses. Microsoft Word alone has about 50 .exe files, for instance. This discovery plan is actually a distraction, because what you really want to do is check a single tick-mark for “Yes, we have Microsoft Word installed on this computer.”

Your real intention is to count applications, not executables, and it can be hard to know when to stop looking. According to Raley, in Dell’s experience a company with 10,000 employees typically has about 800 applications. Moreover, that application-to-employee ratio holds true across industries (at least for medium-to-large firms). That is, a company with 1,000 employees should expect to find that they have about 80 applications, perhaps 100 at the most. A few industries will support more than that 8-10% ratio, particularly any business in the medical field and tech firms (presumably because we geeks love to create applications at the drop of a hat, such as command-line utilities to count how many .exe files there are on a computer). That 8-10% percentage alone should give you a yardstick to work with, anyhow.

Dell approaches the problem with its large enterprise customers by using its Titling Engine service, which runs against client PCs, identifies the executables, massages it with metadata, and creates a report including the type of application. Dell’s isn’t the only solution, of course – Microsoft bought Asset Metrics a few years ago and turned it into a Software Asset Management system, for instance, and there’s also similar functionality promised by Express Metrix. Whichever one you choose, keep in mind that the primary goal for these enterprise applications and services is software license management; they were built to help a business ensure that it isn’t running 100 copies of Whatever Pro but paid for only 50 copies, and vice versa – either of which is a Dire Emergency On The Hoof. However, Raley says, these tools also do an excellent job at this “figure out what apps we really have” task during an OS migration.

I don’t think those solutions have a way to measure the in-house applications your own developers created, though I could be wrong about that. And there’s no way to evaluate whether the old Web applications your company wrote for IE6 necessarily will run on IE8, which is included in Windows 7. But it’s a start.

That’s What We Have. But What Do We Need?

The list of applications-installed is just the start. As individuals, many of us have old applications installed that we haven’t run in years, but are too lazy, unmotivated, or bound-by-IT-policies to uninstall them. Multiply that by a thousand enterprise users, and it’s likely that you’ll find 11 PC backup applications installed across the company, with none of them in use. (What do you mean – I don’t need those backup tapes anymore?!)

The next step, therefore, is to filter your list of corporate applications into three piles:

• What can I get rid of? For example, the company probably can get rid of 10 of those 11 backup utilities. Pick one to be the company standard and chuck the rest.
• Which apps are the no-brainers to keep? To use our original example of an enterprise with 10,000 employees, it’s likely that the IT department already supports 100-200 of the company’s 800 applications.
• Now, deal with everything else.

Naturally, it’s the third category which will take all your time and (I’m sorry to depress you like this:) require a bunch of tedious meetings with the IT staff, development team, and the user community. (At least you can count on plenty of doughnuts during those interminable meetings. Make mine chocolate.)

Of the remainder: On how many seats is that application installed? According to Raley, if an application is installed on 70% of seats, IT probably should be supporting it anyway. Your IT department should be ready to (or at minimum, resigned to) spend money on application testing and possible software upgrade expenses, whether that means upgrading a third-party application, convincing the development department to test the old application for compatibility with Windows 7, or taking the time to consider alternatives (such as, “If we have to change, maybe we should migrate this old ASP.NET site to the cloud”).

Raley cautions: The long tail is very long. You’re sure to find plenty of real, necessary applications that are used by only a handful of users. Deciding what to do with the remaining applications – whether acquired from a third-party or home-grown – may involve quite a bit of user foot-stamping, CFOs carrying on cranky, and other reasons for you to collapse at the end of the week thinking, “Thank God It’s Friday.” Don’t say I didn’t warn you.

For each application, your migration team has to decide whether to retain it, retire it, or rewrite it. From the CIO’s viewpoint, the primary decision criteria are:

• the application’s licensing costs
• for what purpose the business (or department) is using the software and whether they can justify it (i.e. exactly why are we paying for the Accounting team to have PhotoShop installed on all their PCs?)
• support costs (does this application make the Help Desk cry?), and
• the vendor’s roadmap. (This assumes the vendor has a roadmap; if the vendor is out of business, it’s definitely time to move to another, supported application.)

According to Raley, large enterprises rely largely on in-house developed applications; typically, a third to two thirds of the company’s software is custom-written. Still, he says, that leaves hundreds of commercial, off-the-shelf applications, most of which can be checked against Microsoft’s application compatibility charts.

This research-and-rationalization phase doesn’t have to be awful. IT managers may choose to see the Windows 7 migration – and the budget allocated for that transition – as an opportunity to clean up all the “junk” that the company has collected over the years. Think of it as a trigger event, suggests Raley, the way that a house move is a good excuse to clean out the garage. After all, if you deploy one of the software inventory applications and discover that you’re paying for, say, twice the number of Microsoft SQL Server licenses than the company actually uses, you may be able to crow about a significant amount of long-term savings. You might not be able to justify the use of one of these tools on its own, but the Windows 7 migration gives you a good excuse.

Want more like this? Sign up for the weekly IT Expert Voice newsletter so you don’t miss a thing!