|
|
One approach is for the company to transfer knowledge gained by very early adopters to early adopters, and from them to mainstream customers.
However, there is a difference between early adopters and mainstream enterprises: the latter tend to run older software for longer, and that can put them in a bind. For example, an organisation may want to adopt Office 365, which rules out the continued use of Office 2003 and Internet Explorer 6. But there may be compatibility issues with other old software that prevents the use of newer versions of Office or IE.
Mr Jackson noted that there are significant differences between commercial software and public facing web sites on one hand, and in-house applications and web apps on the other, with compatibility issues more likely in the latter.
The average time between a mainstream enterprise establishing a business case for a new product and actually putting it to work is 12 to 18 months, Mr Jackson said. "They're not idiots, they're trying to do due dilligence" including checking for compatibility.
Page 2: "We aren't afraid to make decisions that break things".
|
"I want your technology infrastructure to allow you to be as agile as your business needs to be," he said.
Another issue that if Microsoft changes just one line of code, there's the possibility that it will break compatibility with some other piece of software. "That's always going to happen," said Mr Jackson.
Sometimes the change isn't actually in the code - he noted that the version number reported by Windows 7 is 6.1 in order to avoid causing compatibility problems with the large number of applications that have the same faulty logic for testing the OS version.
Mechanisms are built into Microsoft's platforms to allow the delivery of new features while retaining backward compatibility. One example is the way certain bugs in older versions of Windows relied upon by application developers are preserved in Windows 7 unless an application specifically identifies itself as being written for that version.
"We aren't afraid to make decisions that break things," he said, pointing to the introduction of UAC to improve security, but Microsoft does have processes in place to determine whether breaking compatibility is an acceptable regression - in other words, whether the benefits delivered by the proposed change outweigh the implementation pain that must be endured by customers.
Page 3: Immature technologies cause compatibility troubles down the track
|
Organisations are now investing in HTML5 "which we're still figuring out" and so could be sowing the seeds of a set of future compatibility issues. "There are lessons that they can't learn yet," Mr Jackson suggested.
In some cases, Microsoft has been able to address issues. For example, applications written in Visual Basic 4 generally try to write to restricted locations (ie, they assume the user has administrator privileges) but they still work in current versions of Windows because that issue was "fixed for free" by microsoft, he said.
Organisations should consider hidden dependencies, he said. For instance there is a lot of Visual Basic 6 code in use, and while it is fully supported in Windows 7, support for the VB6 development environment ended years ago. So how will you fix any bugs, especially those with security implications?
Mr Jackson also sees some organisations decide to standardise on a specific releases of software such as Java to ensure application compatibility, but he says missing out on subsequent security updates leaves them open to real risks.
Disclosure: The writer attended Tech.Ed as the guest of Microsoft.
