"Open" is a four-letter word

By Ronald Schmelzer, Senior Analyst, ZapThink, LLC 01 Apr 2003 | ZapThink LLC, special to SearchWebServices.com

Digg This!     StumbleUpon     Del.icio.us

Market Analysis

The past three years have certainly been boom years for the IT industry. Not from an economic perspective, but rather in the growth of the number and variety of standards that have been proposed. One of the key properties of Web services and the service-oriented architectures built upon them is the fact that they are based upon open standards. After all, standards are an essential element of the maturation of any technology. In the case of distributed computing, open standards promise to increase interoperability, reduce TCO, widen the base of skilled developers, and increase vendor choice. With so much riding on the power of open standards, you would think that there would be broad agreement as to just what "open" and "standard" mean. Unfortunately, there is still plenty of confusion about the meanings of these two terms.

What exactly is a standard?
A standard is simply an agreement on common practices among multiple parties. Standards have been around for a long time – electric current, railroad gauges, the metric system, and even musical notation are examples of standards. However, the processes that interested parties follow to establish standards can differ dramatically. Standards can either be de facto (occurring as a result of natural market movement and adoption) or prescribed (established by formal agreement). De facto standards often result when one vendor dominates a market, while prescribed standards develop in competitive environments where market participants realize that agreement upon a standard will benefit all of the participants. De facto standards incite little argument, because the market as a whole decides them. However, prescribed standards cause much consternation, because of the often contentious processes that lead to their establishment.

What makes a standard open?
Adding to the contentiousness surrounding the standards process is the fact that the word "open" has no commonly accepted meaning in the phrase "open standard." For many organizations, "open" means that they aren't the only organization that supports the advancement and development of a given technology. However, this is an all-too-broad definition that puts Microsoft's .NET in the same camp as Java – since there are millions of developers for each of those platforms. For others, a standard is open only if a vendor-neutral third-party organization (or even governmental body) creates and manages it. However, this definition is too strict in that it excludes the term "open source" from its meaning. Finally, many organizations consider a standard to be "open" if the specification has merely been published for review.

A fourth definition of "open" takes into account the fact that what is important is not the specification or technology itself, but the means that participants follow to create and manage the standard. What we are discussing here is an open process. An open process means that the practices and procedures that participants employ in the creation of the specification itself are open: any interested party can join the standards creation body, which publicizes its meetings and circulates its conclusions to members and non-members alike. Most importantly, any interested party may contribute in the decision-making process, where all participants have equal weight, guaranteeing vendor neutrality. Unfortunately, this view is an unrealistically idealistic vision of standards, and very few standards bodies truly follow open processes. And for good reason – the market simply doesn't work in such an altruistic fashion.

In reality, it is very difficult in practice for a standards organization to maintain true vendor neutrality. Vendors will serve on standards bodies and produce work only if it is aligned with their organization's competitive needs. Consequently, standards organizations must align their activities with the strategic imperatives of their member companies in order to produce standards the market will adopt. Thus, we have entered a new era for standards – one that is characterized by the use of the standards creation process as a competitive weapon for pre-emptive strikes on immature markets.

From Competing Products to Competing Standards
The actions of vendors in today's emerging markets are like those of the historic American land rush in the mid 1800's – every vendor is looking to grab a stake in some opportunity that may or may not prove fruitful in the long run. Since they don't know which area will provide the most financial reward, these vendors are grabbing as much "land" as possible – in this case by proposing and promoting an inordinate number of specifications. As a result, we find ourselves in a world that is much more perilous than dealing with competing vendor implementations – a world dominated by competing specifications. The result is a jumble of specification puzzle pieces that are too focused on competing implementation details and miss the overall picture entirely. Many of these proposed standards overlap in their scope, causing confusion in the marketplace. In supporting one standard, a company may be inadvertently closing the doors on accepting another, conflicting standard, thus locking themselves into a particular implementation approach. Until a "standards shake-out" occurs, companies must choose among immature standards.

ZapThink Take: Putting the Standards Cart before the Implementation Horse In the final analysis, it just doesn't matter whether a standard is "open" or not. What matters is whether the market at large adopts the standard. TCP/IP, HTML, and PDF are standards that were created and adopted in very different ways, but they all clearly play a significant role in IT organizations today. We must first look to understand the value of a technology and then seek to understand how standards can increase the adoption of that technology. The goal of a standard is not to remove an organization's competitive advantage, but rather to facilitate the realization of the benefits of interoperability, lowered TCO, an increased skill base, and increased customer choice. At the end of the day, the standards that companies should adopt are the ones that help them realize business benefits.

ZapThink believes that market pressures will force standards consolidation, rather than the decisions of the standards organizations themselves. Vendors that call for adoption of "open standards" simply on moral grounds need to re-evaluate their strategies – they should limit the creation of standards to those that resolve current interoperability issues. End users that blindly implement "open standards" due to an ill-conceived mandate for vendor-neutrality should focus on standards that meet their business needs. Furthermore, standards bodies should limit their development of new standards to those that are truly breaking new ground, rather than seeking to fight internal battles at the expense of customers simply to justify their value to their membership.

For more information:

• Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
• Are you tired of technospeak? The Web Services Advisor column uses plain talk and avoids the hype.
• For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
• Hey Codeheads! Start benefiting from these time-saving XML Developer Tips and .NET Developer Tips.

• Visit our huge Best Web Links for Web Services collection for the freshest editor-selected resources.
• Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
• Couldn't attend one of our Webcasts? Don't miss out. Visit our archive to watch at your own convenience.
• Choking on the alphabet soup of industry acronyms? Visit our helpful Glossary for the latest lingo.
• Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.

Digg This!     StumbleUpon     Del.icio.us