John F. Sowa wrote: (01)
> The standards that have proved to be the most valuable in practice
> have been based on successful technologies that many independent
> groups have adopted, used, developed, and extended on major
> applications. In most cases, those standards started with a
> successful implementation (e.g., SQL or HTML), polished up the
> rough edges, made it more systematic, and added new features.
>
> About 20 years ago, some people working on standards got the idea
> that it would be good for the standards organizations to take a
> "proactive" stance in developing and promoting cleaner, more
> elegant systems that take advantage of the latest theories and
> practices. But the results have been decidedly "mixed".
>
> I once thought that "proactive standards" seemed promising,
> but after observing many attempts, I have very serious doubts. (02)
I fully agree with this. (03)
I would also point out that there are situations in which several
software tools have been on the market, all performing essentially the
same function and all having incompatible representations of the
information they capture and produce. A variant situation is the
existence of a common established practice, with emerging software tools
to support it. In such situations, getting the implementors to agree on
a common exchange form can produce a valuable standard (some CAD
standards, some HL7 standards and some HR-XML standards leap to mind).
To avoid giving anyone an advantage, the standard will match none of the
existing forms. Some such standards have been very successful -- those
that get "critical mass" among the major players. But they are not
"proactive" in the sense that John means. The functions and concepts
they need to support are mostly well understood and well tested; the
primary concern is only to agree on a representation. (04)
The truly "proactive standards" are based on only preliminary analysis
of the problem space. Their first concern is to identify the functions
and concepts that will need to be supported, based on little experience.
And many of these efforts begin by assuming that the needed functions
and concepts are well-understood and the only issue is to agree on
representation, and founder on the discovery that the primary players
well understand very different requirements or very different approaches
to solution. (05)
> Among the problems with proactive standards is that they are
> inevitably designed by committees. The basic strength *and*
> weakness of a committee is the diversity of people with
> different backgrounds, views, and requirements. That gives
> them great strength in *evaluating* proposals from many
> different points of view. But it also means that committees
> inevitably have "too many cooks" who "spoil the broth" when
> they try to do the design. (06)
I agree that this is common and the results are almost always shelfware. (07)
At the same time, there are examples in which a cohesive leadership team
of a few largely like-minded individuals, coupled with some external
pressure, can result in an effective standard. But the leadership team
consciously suppresses the noisy committee members and effectively shuts
them up or drives them out. OWL and BPMN are the obvious examples. (08)
Unfortunately, there are also many such examples in which the effective
leadership team doesn't have a significant share of the market (or the
practicing hearts and minds). They get their standard, but it is
shelfware that is snubbed by the leading vendors and practitioners. (09)
> I don't believe that any proposed system should be adopted as
> a standard until *after* there has been a considerable amount
> of experience in using and testing it on a wide range of
> practical applications. Instead of "deliberate planning",
> we need extensive testing, comparison, and evaluation of
> proposed alternatives on major applications. (010)
Well, there is a tradeoff here too. Once there is a set of software or
hardware products in the field, even if it is open source, there is a
sunk investment cost. And choosing a standard direction that will lose
most of that investment for some body of investors will create discord.
If one or more of them has a significant market share, there will be a
viable competing standard, whether formal or proprietary. The examples
of SGML and ODA leap to mind -- structured document markup is simply
better, but it is not what Word, Wordstar and WordPerfect did. (011)
So the secret to success is market timing. (What a surprise.) You have
to strike when there is enough communal knowledge, agreement, motivation
and market strength to make a viable standard. And then you have to
make it happen in 2 years, before the window closes. And since it
always takes a year to bring a community together, you have to have the
prescience to start the standards effort, or some forerunner community,
at least a year before the window really opens. And after you publish,
it will take 2-5 more years to observe success or failure. Not many
communities have people with the perspicacity, political skills and
management commitment to make such a thing happen, and even those that
do have a low success rate. It is like starting a business, without the
potential for getting rich. (012)
-Ed (013)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 (014)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (015)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (016)
|