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.

Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine