As the need for computers to communicate with one another grows, so
too does the need for universal standards. Easier said than
done.
It is hard to believe in the 21st century that when travelling to a
foreign country you still have to take an adapter so that you can
plug your modem into the hotel telephone socket. You also have to
take another adapter to plug your laptop computer into a power
socket. For all their red tape, sombre debating sessions and
paperwork, standards bodies still have a lot to do when it comes to
interoperability.
The IT sector makes other industries look streamlined and
efficient. Computers are complex and the suppliers will not let
customers forget it. The industry is littered with jargon and
acronyms, many of which refer to particular standards implemented
to solve specific computing problems.
It is odd that since the emergence of the open computing movement
in the early 1990s things seem to have got worse. Then, individual
suppliers had their own standards (such as IBM's systems network
architecture), but there seemed to be fewer of them. Customers
signed up with one supplier and used everything they had, so there
were no cross-platform issues. Now, there is a standard for
everything from personal information management software
synchronisation to digital resource management.
"Are standards all about connectivity?" asks Peter Jones, president
of software integration company Mercator and vice-president of the
Computing Services and Software Association (CSSA), a trade body
for software and services companies. It is a valid question. One
reason why standards have proliferated is the increase in
connectivity in an Internet-enabled world. As the need for
computers to talk to each other continues to grow, the demand for a
lingua franca increases proportionately.
The problem is that you cannot have a single communication language
covering a complex set of functions. This is why, when the need for
standards became apparent, the International Standards
Organisation's Open Systems Interconnectivity (OSI) stack became so
useful. The OSI stack was a way of categorising different levels of
functionality into layers, from a low to a high level of operation.
At the bottom (layer one) was the physical transport layer - the
physical link used to connect one computer to another. The system
went up through several layers, each one reliant on the one before
it, until it reached the application layer at the top, which used
the technologies in the layers underneath it to accomplish
application-specific tasks.
Layer seven - the top - contained its own standards, such as the
X.400 standard for e-mail delivery. It is impossible to cover the
OSI in depth here, but it is an important industry development. For
more information see John Larmouth's excellent guide to OSI at
www.isi.salford.ac.uk//books/osi/all.html#head1
.
Twenty years ago if you looked at any layer in the OSI stack you
would have seen different technologies on offer for corporate use.
Each supplier had its own way of tackling a problem, which is why
IBM came out with Token Ring, which was eventually adopted by the
IEEE consortium. The standards landscape changed dramatically when
TCP/IP came to the fore.
Originally invented by the US Defense Advanced Research Projects
Agency as the basis for the Internet project, TCP/IP grew in
popularity, due in no small part to the efforts of the early Unix
community which promoted it as part of the system.
Many people assume that TCP/IP is simply the transmission protocol
for the Internet, but in fact it is a whole stack on its own. The
TCP/IP stack, which became prominent at the beginning of the 1990s,
has all but replaced the OSI stack in many areas as a framework for
different protocols, with standards such as the simple message
transfer protocol, Internet protocol (IP) and others becoming
dominant.
The adoption of TCP/IP on a universal basis was vital if the
Internet was to grow, and Microsoft's inclusion of a TCP/IP stack
as an out-of-the-box component of the Windows client in 1995 sealed
the deal; TCP/IP became one of the most important sets of standards
in the past decade.
So, with the world centred on the Internet, why are things so
confused in the standards sector? Chris Gabriel, regional manager
at Enterasys Networks, thinks he knows. Enterasys is involved in
defining many networking standards, including the forthcoming
10-Gigabit Ethernet standard. He believes that at lower levels down
the stack, simple interoperability was the key. Few stakeholders
cared about low-level standards such as Ethernet, as long as they
worked and meant that different suppliers' equipment could work
together. As you move further up the stack, functionality becomes
more complex and each stakeholder has a more vested interest in
what goes into a standard.
Peter Sharpe is chief scientist at extensible markup language (XML)
editor software company SoftQuad and was a co-founder of the XML
standard, thrashing out the protocol with a team of nine other
experts on SGML (XML's predecessor). He draws a distinct parallel
between the definition of the original XML standard and the XML
Schema standard, recently passed as a recommendation by the
World-Wide Web Consortium (W3C) after a long period of political
wrangling.
"XML was in its first working draft within four months," Sharpe
explains. "It took in total a year and a half, but most of that was
working out details. XML Schema took two years and it took a long
time for even the first draft to come out."
He says that most work on XML was done without interference from
the W3C due to a lack of interest in the language at the time. The
small committee created a 30-page standard, which was relatively
simple as software standards go. By the time XML Schema came up for
discussion, everyone wanted a say.
"The Schema group was a huge committee - there were 40 people on it
and everyone had their own agenda," Sharpe says. "There were big
companies there, with IBM, Oracle et al pushing hard with their
stuff."
The origin of a standard will affect the speed of its development
and its range. Standards come from a variety of areas, including
industry consortia, government-sponsored bodies such as the United
Nations and even individual companies. But you can subdivide these
sources further, according to Brian Whetten, chief scientist at
middleware company Talarian. Whetten is heavily involved in the
definition of standards within the Internet Engineering Task Force
(IETF), but has also worked on the Java Messaging System technology
that is at the heart of Sun Microsystems' J2EE server-side Java
suite.
Different standards definition bodies have different cultures that
can affect the types of standard they consider and the way they
develop them, says Whetten. At the IETF, the majority of people are
on some company's payroll, but they come from an academic
background (75% of IETF members have a PhD). Such qualifications
make those people suitable to define fundamental standards that
would sit at a low level in the stack. These technologies need to
be very robust, well thought out and comprehensive, which is what
the academics are good at, but they often face huge deployment
challenges. The definition of IP version 6 is a prime example; it
needs a very thorough, academic mindset to address the protocol
definition that is so fundamental to the Internet future, these
people will focus only on technology, leaving its transfer into the
commercial world to others.
Whetten has seen an evolution in the way standards are defined. In
the past, standards have been defined using this academic approach,
on a "bottom-up" basis, starting with low-level technologies and
building up requirements until they reach cosmetic areas such as
the programmable interface. This process has worked well in the
past, because academics were pioneers at the frontier of the
Internet, developing technologies and standards to be implemented
in new territories. (Before IP was developed there were commercial
systems with proprietary networking standards, but no Internet.
Hence, there was effectively no legacy.)
Now, with a plethora of existing systems and platforms so well
established, such fundamental, non-commercial standards definitions
become less appropriate, argues Whetten. Instead, a "top-down"
approach is needed, where business requirements are defined at the
start and the standard definition process is more
supplier-driven.
Such a business-centric model is not without challenges. "Top-down
development has a political risk - you can get separate camps,"
Whetten says. "If Microsoft decides that it has a standard, and Sun
has one, you end up with these islands of connectivity. That's the
real challenge - how do you breach the top-down standards that
create these islands?"
This is what makes XML an interesting standard. It was developed by
a technical committee with a strong academic background in a
bottom-up scenario but, says Whetten, the business-centric,
industry-specific document type definitions were developed in a
top-down model. Hence, the XML standard is unassailable and easy to
follow, but the complex fabric of vertical market XML-based
languages is confusing and has possibly hindered the growth of
XML-based integration.
One good thing has come out of the top-down approach - increased
opportunity for customer input. Although different committees and
industry bodies vary in attitudes towards end-users, the companies
participating in a given standard definition process are
accountable, says Whetten. You can think of it as a parliamentary
system, in which the companies are the MPs and the customers are
their constituents.
"Certainly, if a company has a large customer that is demanding
something that could be achieved through a standard, then that
company's representative on the committee will push very hard,"
Whetten explains. "There is lobbying at each level."
This contrasts sharply with the role of government in computing
standards definitions. Government does not have the knowledge base
to legislate on standards, says Jones. "Because it doesn't, it ends
up trying to recommend an answer that doesn't get support from
suppliers or customers in the industry."
The most streamlined standards definition process of all involves
the creation of a technology by a single company with enough power
to push it through or with the luck or intelligence to introduce a
technology just when it is needed. Good examples are Microsoft,
which has created numerous standards including everything from open
database connectivity through Soap and even arguably to Windows
itself; the Win32 API may be proprietary, but unless you code your
programs to comply with it, sales will suffer.
Another example is Sun Microsystems, which introduced Java and then
hyped it up as a necessary technology for the network computing
revolution, which fell flat on its face in the mid-1990s.
Nevertheless, Sun made Java stick by switching the emphasis to the
server and touting it as a platform-independent e-commerce
development environment.
But for all of its "openness" with Java, Sun is still selling a
proprietary technology. It has made it popular by making licences
available to everyone, while failing to hand the technology over to
standards bodies such as ISO or the European Computer
Manufacturers' Association. No matter; the company has managed to
get the best of both worlds, creating technology from which it can
still make a profit, while simultaneously promoting its openness
through a technology definition process (the Java community
process) that is open to input from other companies. Such a
strategy is the ultimate logical conclusion of the top-down
approach - if you cannot get the industry to do what you want to
do, then become a for-profit standards body yourself.
Jones sums things up nicely when he talks about what drives
standards. Standards become vital when the cost of running systems
in a fragmented market exceeds the cost of developing and
implementing a standard. Now, with companies being encouraged to
increase internal efficiency and to do business with each other,
adherence to standards is increasingly important.
<br>Industry is inefficient when it comes to defining
standards for hardware and software interoperability, it is not
customers that are slow to take up standards. Some standards
initiatives have worked well and produced admirable results, but
others (typically those defined in a top-down process, as
characterised by Whetten) have generated confusion and frustration.
In a world where complexity is a constant, this is the last thing
customers need.
HOW TO BE A STANDARDS POWERHOUSE
Few customers have the
time or the resources to spend on standards definitions. They
require large amounts of employee time for meetings and paperwork
and unless you are an IT firm, it does not make good business
sense.
The best way around this problem is to cement a relationship with a
supplier whom you know to be politically powerful. Generally money
talks and if you spend a sufficient amount with one company it will
fight your corner in the committee room. Fostering personal
relationships with key technical staff can do you no harm and
highlights the similarity between the parliamentary process and the
IT standards world.
Alternatively, if the technology standard is sufficiently important
to your company, find out if there is an industry-led initiative. A
good example of this is the Global Commerce Initiative, formed in
1999, which facilitates end-user input on global electronic trading
standards to the major standards bodies.
The other option, if you are powerful enough, is to start up your
own vertical market initiative. This could take the form of a
standards definition process or could involve the implementation of
a business-to-business trading hub, which will give you the
opportunity to pull in trading partners and suppliers, persuading
them to make use of your facility. This provides you with a
platform from which to define trading policy and standards in the
future.
STANDARDS TIMELINE
IT standards have come a long way
since the
industry first realised that computers had to work together. It is
impossible to document all computing standards and bodies without
taking up a whole book, but here are some milestones:
1865
International Telegraph Union (now ITU) formed (www.itu.int)
1947
International Standards Organisation launched (www.iso.ch)
1974
IBM introduces systems network architecture
1983
US Department of Defense standardises on TCP/IP
1986
Internet Engineering Task Force formed (ww.ietf.org)
1988
The European Standard Telecommunications Institute (ETSI) formed
(www.etsi.org)
1991
European nuclear research laboratory CERN releases the World Wide
Web
1992
Internet Society formed, providing legal framework for IETF
(www.isoc.org)
1994
World-Wide Web Consortium formed (www.w3.org)
1995
Version 6.0 of the Internet Protocol released
1998
XML 1.0 becomes a W3C recommendation
2001
ebXML e-business exchange standard ratified.
A SOFTWARE STANDARDS WISHLIST
In spite of the
proliferation of different standards in the IT sector, there are
still areas that could do with some universal protocols to unite
the market. This is what the bureaucrats have not yet
covered:
Software quality
One of the things holding back the
market for third-party, component-based software and the new Web
service frameworks is a quality assurance standard. Many companies
may feel uneasy using third-party software components unless there
is some guarantee that they will work under specific conditions
without crashing. To our knowledge, no such rubber stamp for
software quality exists
Virus standard
Wouldn't it be great if virus writers
produced viruses, worms and trojan horses that operated along
specific lines, as defined in the Standard Template for Unsolicited
Programming Intrusions and Destructive Generic International
Trojans specification? At least that way anti-virus companies could
deal with them more easily. But that would never happen - most
virus writers wouldn't even be able to spell it, let alone follow
it
SpamML
Similarly, it would be useful to have a standard
for unsolicited commercial e-mail (spam) in an XML format supported
by all the major e-mail clients. Spam could contain an e-mail
header with information about the subject matter. An XML-based
syntax may help in the creation of an "opt-in" system for
communicating legitimate marketing e-mail to end-users
Instant messaging standard
The world needs an instant
messaging standard. At present, with messaging systems from
companies including AOL, Microsoft and Yahoo, people often know
friends, workmates and family signed up to different services,
meaning they must run all the clients at once. A single
interoperable standard would make things easier for the end-user.
The IMUnified initiative has produced an interoperability proposal,
but AOL is not a member. It plans to introduce its own proposal
this summer, while the IETF is also work on an interoperability
document
Meta standard
A standard for standards development is the most necessary standard
of all, given the disingenuous nature of today's many different
standards definition activities. If the industry could agree on a
way to develop standards that every supplier stuck to without
confusing end-users and managed to avoid replicating its own
efforts with multiple rival standards, the computing industry would
be a happier one.