One standard, or multiple standards?
It seems like a pretty cut and dried debate, if there was a single standard for everything in the software world then life would be simpler. Wouldn’t it?
Back in the early 90s we thought that we had the whole single standard thing pretty much sorted out. For email we would use X.400, for ethernet communications we would use TP4 and so on.
I was working with many of our public sector customers in the UK at the time, and assisted with a number of projects aimed at delivering X.400 enabled mailboxes broadly across the UK civil service.
In the mid 90s along came the internet, bringing with it with the stack of protocols that we are all aware of today.
The agencies that I had been working with mostly had one of two strategies, either a pure X.400 implementation which at this point would be mostly redundant, or a broad strategy of interconnection with Notes, MSMail, Groupwise, X.400 etc., in which cases SMTP was just one protocol in a list of many and as such could be folded into an existing project plan.
Even then it was not the end of the road for X.400, as recently as three years ago we were still seeing the protocol being implemented in military environments where features of the X.400 specification remained crucial for email in the battlefield.
Moving to today, even given the pain that a number of technologists felt during the 90s, the debate around one or multiple standards in a given technology domain still goes on.
In many cases, if we play this debate out in a technology domain that we all know well then it makes very little sense.
Lets use high speed local area networks as an example. There is an obvious choice for a single standard that will work for everybody in this domain, it is TCP/IP. Isn’t it?
Choosing and mandating only TCP/IP has a couple of effects on my ability to communicate with the array of devices that I might find in any corporate datacenter today. Starting with legacy systems, I might have just restricted my ability to talk to those older systems which could be running protocols like IPX, Netbeui or various mainframe communication protocols that have existed through the years. On the other end of the scale, we’re starting to see and increasing number of devices implement the next version of TCP/IP, IPv6.
So for something as simple as networking it seems we have a need for a range of protocols to deal with all of the systems we might be planning to work with. The majority traffic on the wire will obviously be TCP/IP on any network today, but a percentage of it will be something else, and over time I would expect to see the majority migrate to IPv6 or a protocol that has yet to be developed.
This becomes the case for at least three reasons.
First of all, any evolving datacenter will either have existing legacy systems, or will have a need to connect to external third party customers or partners who are using legacy technologies.
The second is that developers (companies and individuals) continue to innovate in every area of the technology itself. Sometimes that innovation is incremental, sometimes it comes from another group and is ostensibly competitive.
The third is that while many standards look similar at the outset (Netbeui and TCP/IP are both just networking protocols for example) it quickly becomes clear as you delve into the details that they exist because at a point in time a development group perceived a scenario that could not be addressed by the many protocols that had already been defined and made available to the market.
My conclusions are by no means empirical, but I do find that this argument tends to fall on the side of preference for a “single standard” for a given technology domain in a handful of scenarios;
There could be a preference for a particular technology. This one is generally pretty obvious, you will hear something like “there should be a single standard in this area, and it must be my standard” thrown into the debate.
Simplicity of implementation may carry the highest possible priority for a small subset of projects, with a relative disregard for factors like legacy integration or future innovation. This is an interesting line of argument, and in my view only works for stand alone solutions that will have a short life span. Solutions that will never have to communicate with a legacy user community or technologies, and do not have to be ready to deal with innovative technology changes that might come along in the future.
Finally, it can sometimes come down to a lack of information being presented to the group making the decision. When you glance over a particular technology domain, choosing a single standard in that area generally looks pretty straight forwards but when you dig deeper it is rarely the case, as with my example of networking protocols.
Many of the software products that have enjoyed success in the market over the last couple of decades have done so in part because of their support for multiple standards and formats, I suspect the same will eventually be true for enterprise and eGovernment technology solutions that are being implemented today.
Sphere: Related Content