Application Interoperabiilty – How it can bite you.
Twice in the past 6 weeks or so, I’ve heard horror stories about application co-habitation (you can use that). The first pertains to an organization that does application development for their customers. We were showing them the value of application compatibility reports, including interoperability. The interop reports highlighted some interesting issues that these apps had with shared components. Each of the two apps had components that were used by the other but they were “not marked as shared or permanent”. The problem here is that removal or upgrade of either could potentially have a negative outcome on the other application. That’s not something that would show up in deployment necessarily, but further on down the road.
The second issue was a bit more serious. In another organization, an in-house application had mistakenly been deployed to an entire line of business instead of a few users as intended. When the mistake was realized a short time later, the app was pulled back. Like a tidal wave going back out to sea, it took a lot of stuff with it. This custom application used some components that were shared by other custom applications installed throughout the deployment group, and the un-install took those components with it when it left. It took the rest of the weekend to repair the damage.
Could this have been avoided? Yes, with interoperability testing. Luckily for the first company they found out before anything happened. Unfortunately for the second, they did not. Interop testing looks at a group of applications to determine whether or not there are potential conflicts with shared components, registry keys, .ini files and so on that are used by other applications. Again, these issues may not manifest themselves at deployment time, but perhaps down the road during a change within your environment.
As an ongoing operational tool, you can use interoperability testing to check for potential conflicts in your application portfolio. If you are adding a new application, test it against all of the others it will be installed with to see if it “touches” any of them. If so, investigate the potential for damage in the lab before you roll it out. The same applies when planning the removal or upgrade of some of your apps. It could save your weekend.
