The gray scale of interoperability and IT standards
In this article, I want to take a look at what interoperability and IT standards really mean for business users and the benefits that adopting standards may (or may not) bring to an organization.
In order to stay sane and keep the ratio of content-to-terminology ratio fairly high, I need to take some liberties with language. In particular, I will use the word 'standard' to cover everything from ISO International Standards to IETF RFCs to W3C Recommendations. This use of language may be distasteful to some, but life is too short to write about standards in full-on pedant mode.
I will also use the phrase 'de facto standard' to cover things like Microsoft Excel, Adobe Photoshop, etc. This too may be distasteful to some but again, life is too short.
Let us start with the business case. What is the business case for IT standards? Standards are things that help us get complex IT systems to 'just work' - to inter-operate. We want to take X and put it into/onto/under Y and for the whole X/Y thing to 'just work'. The idea is as applicable to hardware as it is to software - USB keys, JPEGs, Excel files, HTML pages, the IBM PC are all examples of standards or de-facto standards at one level or another.
In the software world, there are two main approaches to getting the simple idea of things that 'just work' together to, well, just work. The first is to build applications from the same base application code. Microsoft Office and Open Office are both common examples of this. If I have the same base software as you, we stand a better chance of plugging our stuff together than if we did not share a common base of software.
The other approach is to build everything from the same base data/protocol. HTML, HTTP, CSV, MP3 are examples of this. If I have software that understands the base data/protocol, and you have software that understands the base data/protocol, we stand a better chance of plugging our stuff together than if we did not share a common base data/protocol.
Now things get complicated. Applications can be proprietary and applications can be non-proprietary. Either way, they can be used as the basis for interoperability. Although it is often faster to get interoperability off the ground by using the same application base, you can end up tied in to that application base. It is important to realize that this is true even if the underlying application is non-proprietary.
How is that possible? It is possible because any non-trivial real-world application is a tight embrace between business logic and data. Separating one from the other is not always possible without losing important information. Anybody who has struggled to make HTML look the same in different browsers has encountered this relationship. So too has anybody who has 'saved' a spreadsheet as CSV. So to has anybody who has sent a data file produced with version X of some application, to somebody using version Y of the same application, only to be told that the data does not 'look right' at the far end. True interoperability results from the subtle and complex interplay between application code and application data.
Interoperability is a gray scale. On one end there is the white light of simplicity that results from everyone having the exact same applications as everyone else. On the other end is the pitch black of rampant incompatibilities between applications. The gray areas in between are where most of the world's data and applications live. There is no clear divide between the proprietary ones and the non-proprietary ones on that gray scale. No black and white distinctions that can be made.
When it comes to interoperability, everything is a shade of gray. Developers working on proprietary systems know this. So too do developers working on non-proprietary systems. Words such as "standard" are used freely by both camps. Most folk engaged in this area are trying to make a living. My advice is to follow the money. That will help you figure out what words like "standard" really mean in the context of any particular vendor/consultant pitch you might be dealing with.
Be careful out there.
ITworld.com
Symantec Backup Exec 12 and Backup Exec System Recovery 8 deliver industry leading Windows data protection and system recovery. Download this whitepaper to find out the top reasons to upgrade and how to get continuous data protection and complete system recovery.
Data and system loss — from a hard drive failure, malicious attack, natural disaster, or simple human error — can happen anytime. Don’t leave your business vulnerable. Make sure you have a secure recovery strategy in place. Symantec's latest backup and system recovery technology can efficiently restore critical applications, individual emails and documents and even restore your entire system in minutes in the event of a loss.
Businesses face a growing challenge to ensure that the IT environment is properly protected. Backup Exec 12 integrates with other applications in the Symantec family of products, to complement your current data protection strategy, keep your data securely backed up and make it recoverable when you need it most.
