Application Compatibility
Getting Apps to work...
Thursday 1 October 2009, 7:11 AM
6 Laws of Application Compatibility
And this is where I think there is some general confusion. Application compatibility is not simply about getting applications to function or work correctly on an Operating system such as Windows 7. Unfortunately, you more work to do. Getting applications to work really means getting the application to work on the target platform which involves the following;
1. Ensuring Operating System (e.g. Windows 7 ) compatibility
2. Ensuring the availability of the complete and correct versions of middleware
3. Ensuring that applications do not conflict with each other (on install and un-install)
4. Ensuring that user environment is correctly setup and available
Breaking the application compatibility question into these four layers delivers a fundamental step change in the understanding and resolution of application compatibility issues. No longer can we just get one application to work on a desktop, we need to get several or even tens of applications to successfully install, update and un-install without breaking other applications. We now have large, complex and constantly changing middleware layers (Java, Crystal Reports, ODBC) that applications depend upon.
Adding to the confusion, differing applications may require different versions of middleware components or worse, may ship from the software vendors with incomplete ("middleware fragments") dependencies which may allow the application in question to function but may prevent another application from working or even installing successfully. Viewing application compatibility with these four layers in mind requires a paradigm shift; to the Platform Integrity model which takes into account all of the requirements to successfully install, use and maintain applications.
To further this goal, we have developed the "AOK Laws of Application Compatibility" which include;
1. Enable the installation package to install successfully
2. Provide the application the required privileges and security access levels
3. Ensure that the required dependencies (middleware) are available and complete
4. Ensure that applications do not conflict with each other on installation, updating/patching or un-installation
5. Ensure that the user environment is correctly configured
6. Ensure that future changes/patches/updates do not adversely affect any of the four layers; the OS, the Middleware layer, Applications or the User Environment
When you follow these guidelines, your chances of successfully developing, deploying and maintaining your application portfolio are significantly increased; today and when dealing with future changes.
PreviousComments on this post
Among the biggest issues will be the shock change from XP, which is where most upgraders are likely to be coming from.
With a different user file structure, custom-built apps in particular are likely either to break, or to install pieces of themselves in odd places. Additionally, although Win7 is not as intrusive as Vista, the need to run large numbers of applications under XP mode and/or using admin privileges will confuse many.
Particularly at risk are older apps that have run happily for years under 95, 98, NT and XP, some of which will need to be hand-tweaked to perhaps turn off Win7 themes to accommodate changes in fonts and other graphical elements.
Once users get used to it, however, increased productivity should result from its increased usability over the Win95-XP interface.
I have heard of several large companies that have been using XP, and are flatly refusing to spend the money to upgrade to 7. The majority of them gave the reason that they were fairly sure that 7 would not run 100% of their current software. And given these economic times I can understand a company not wanting to throw away a couple of million to see if it will work. Some of these have switched over to linux in order to save money and stay competitive. After the vista fiasco I suspect a lot of companies will simply stay with what works.
