Five Things Every IT Professional Should Know About Application Compatibility
My job is to help enterprise customers around the world accelerate their deployment of new versions of our platforms—Windows, Windows Internet Explorer, and Microsoft Office. Admittedly, I am a bit of a nerd, so I spend a fair amount of time understanding the technical underpinnings of compatibility challenges, troubleshooting and remediating failing applications, and finding ways to share this technical knowledge with our customers and partners. However, over the years, I have learned that there is more to solving the problem than simply improving our technical knowledge and troubleshooting skills.
By managing the project and making wise decisions up front, you can dramatically reduce the amount of technical skills required. This makes you happier, because things go faster, but it also makes your technical team happier since they spend their time doing interesting and different things rather than performing the same task repeatedly. Therefore, when I was asked to type up the five things IT professionals should know about application compatibility, I immediately defaulted to higher-level principles that make everyone happier.
In this article:
There Is No Such Thing as Being "Compliant"
Being "compliant" with a particular platform is a phrase I hear quite a lot. Now, I am not trying to be pedantic here, and I know that in many situations people use this terminology as a shortcut to indicate whether something works. Nevertheless, I have run into a large number of customers in which this language is used in far more absolute ways, as if there is a state of being that is "compliant with ..." for a given platform.
To be compatible with a given platform means that you have:
- No bugs...
- On that platform...
- That stop you from getting your work done.
Because it is impossible to prove that you have no bugs on a particular platform, you have to focus on that final qualifier and what stops you from getting your work done. Whether you are compatible—"compliant"—depends entirely on the work you do. Many applications are compatible with some tasks, but wildly incompatible with others. In fact, you are probably finding compatibility problems with your existing platform all of the time! That does not mean it is not compliant.
Takeaway: Focus on determining whether you can continue to get your work done on the new platform, rather than on achieving some higher level of "compliance" or idealized level of compatibility. As it turns out, just about the only people who can prove that you can get your work done with software on a given platform are the people who do the work. Therefore, your focus is on getting the software to these users as quickly as you can. Everything you do before that is, on some level, merely an investment in cooperation management.
Compatible Means Different Things to Different People
To expand on this theme, compatible can also have subtly different meanings to different parties. To you, as indicated above, it means you can get your work done. However, there is another important party to consider: The folks who make the software. To them, the primary concern is supportability. The software might appear to work fine. It might pass every test that somebody has. Supportability is more than just an appearance of correct behavior, though—it's a financial decision based on risk-management principles. The less software you support, the less your support organization costs you. Since most customers demand at least some support, most independent software vendors (ISVs) try to scope their investments in order to satisfy customers, determining where they can get away with not making the bet that everything will work correctly and putting themselves on the line to fix it when it does not.
So, for third-party software (or even sometimes in-house software), compatible means ISVs decided they can afford the risk of supporting it on a specific platform.
Takeaway: Decide which of your applications require vendor support. For the applications that do, always look for the support statement first: It does not matter whether it works if that version is unsupported. When support does not matter, then you have the choice—and a vote of "no support" does not necessarily mean you will not be able to get your work done.
It's OK if You Don't Test Everything, Really
Most of the customers I speak with have taken a "boil the ocean" approach to app compat. They look to find everything they have, and then place an obstacle on the critical path to deployment by testing and fixing it all. Any failure will delay deployment.
The fact of the matter is that you can almost get away with that on Windows. Some of the most out-of-control inventories of Windows applications have numbered in the tens of thousands of apps. While certainly large enough to fret about, you can eventually finish that project. What about websites? Most "inventories" of places people go on the web number in the tens and sometimes hundreds of millions. What about Office "apps"? The numbers are similar. Finding and testing everything does not only slow you down: For all practical purposes, it makes it impossible to finish the project!
Takeaway: It makes sense to incorporate a risk-balanced approach that incorporates proactive and reactive testing. You should consider carefully which applications would stop you from issuing a single seat in a pilot deployment, and address compatibility in those applications. Once you've done that, you can start deploying pilot seats, and let people discover true compatibility issues (when they are not able to get their work done) using the same mechanisms you use today for your help desk. Your risk is managed because you have already addressed work stoppage, which is prohibitively expensive in the proactive portion of the project, and the data is more practical and of higher quality. Accelerate or slow down based on help-desk capacity. If you ask yourself honestly, "Could I live without this app / document / site for half an hour after I discover a problem while the help desk gets me sorted?" and the answer is yes, then that app should go in the reactive bin.
You Probably Have More Browsers and More "Offices" Than You Think
No, I do not mean that your inventory has failed you. Rather, I mean that Internet Explorer and Office have compatibility built in to them, and that means there are several different "modes" in which the products could be operating.
In the case of Internet Explorer, Internet Explorer 8 has three different rendering engines, while Internet Explorer 9 has four. This gives you compatibility with websites designed for really old browsers—even all the way back to Internet Explorer 5.5! Since each webpage renders using only one set of rules, it is possible that you will be using an older one when a newer one would work better, or vice versa.
In the case of Office, you have the ability to read and work with documents from all the way back to Office 1997. (If your document were your child, it would be a teenager right now, probably asking to borrow your razor.) Of course, you can convert all of your documents to the latest versions, but there is absolutely nothing forcing you to do so.
Takeaway: It is not enough to just say "It works in Internet Explorer." Rather, you should start to collect an understanding of which rendering engine each of your applications is running in, and consider how you are going to move your platform forward to reduce your dependency on older engines. Not by breaking them now, but instead by putting rules in place that specify that the introduction of new applications shouldn't be based on the older "compatibility" technologies. (Hint: It is going to keep getting harder to find college hires who have practice writing for the Internet Explorer 5.5 implementation of web standards.)
If you are keeping Office documents around for archival purposes, you do not need to convert them. While there are some benefits to document conversion (such as lower disk space utilization) there is also risk that is often not outweighed by the benefits. I wouldn't convert by default; I'd convert as necessary, and otherwise leave things alone and utilize the compatibility features. In short: You should default to having more applications work, and then actively manage new applications and document creation to leverage newer technologies.
Duct Tape Doesn't Last Forever
It is usually sensible to have a "backstop" technology in place for when something does not work. One of the more common backstops is machine virtualization, in which you keep an instance of, say, Windows XP or Windows Server 2003 around to run a Windows XP or Internet Explorer 6 application. Perhaps you keep a virtual copy of Office 2003 around in case there is a complex document. Doing so gives you the opportunity to "get out of jail free" when you hit an obstacle, which is much better than cancelling your deployment. What I do not see as often is the plan to get out from underneath that backstop. In other words, that server becomes the place where old apps go to die, but they end up living on as zombies for years or even decades. There is no plan to get rid of them!
Takeaway: Having a backstop to keep your applications working is helpful, and in some cases critical. Make sure you have a plan for how to make that platform obsolete. Until your backstop is gone, you have not actually finished your deployment.