Posted by cliff
on August 12, 2003 at 3:05 AM PDT
When an ISV tries to sell a new piece of software these days, they are likely to be asked whether the product is based on "standards". I'd like to try to explore what qualifies as a standard in a customer's mind. To do this, I'll try to break down the Who, What, Where, When, Why, and How of standards.
When an ISV tries to sell a new piece of software, they are likely to be asked whether the product is based on "standards". I'd like to explore what qualifies as a standard in a customer's mind. To do this, I'll answer the Who, What, Where, When, Why, and How of standards as concisely as possible (although, not in that order). While this is obviously an over-simplification, in the future I'll address each in more detail.
- Investment Protection: not being locked into one product in order to continue to
access data that was created using it, or to use an application that was built using it.
- System Integration: making multiple systems talk to each other when they are under
one's control. With some configuration, systems can safely exchange data.
- Interoperability: making multiple systems talk to each other when they are generally
not under one's control. Ideally, interop standards should not require configuration changes
or coordination on both ends of a communication to exchange data. WS-I is an example of a
standards organization attempting to narrow the configuration options to achieve true out-of-the-box
- Skills Transfer: investment protection for brains. Developers and end users would
prefer to reuse their knowledge and experience from one system to another. Just how important
is this concern? It was certainly useful for the SQL language, even though full code portability
was never realized. Do customers still care about skills transfer?
- Protocols: allow two disparate systems to exchange data. Standardization is essential
to creating an open network.
- Formats: allow the data to be understood by the systems after being exchanged;
also enables investment protection by allowing open access to data. The widespread adoption of XML
and HTML demonstrates the value of standardizing formats.
- APIs: could be considered formats for source code; APIs enable code portability. Without
standardized APIs, customers risk locking themselves into a vendor's programming model.
J2SE and J2EE are examples of successful API standardization efforts. Do customers reject all
nonstandard APIs, or can a vendor offer a solution so compelling that a customer would rather
take advantage of productivity gains than wait for standardization?
- Tools: how much do customers care about standardization of tools or tool environments?
What concerns would this address?
- Accredited Standards Organizations: relatively few standards bodies are actually
accredited by national or international organizations; exceptions include ISO/IEC, IEEE, and NIST.
- Consortiums: W3C, OASIS, WS-I, and the JCP are all non-accredited organizations for
fee-paying members to participate. Some consortiums are more open and vendor-neutral than others.
Intellectual Property policies also differ across these various consortiums. Since none are accredited,
what makes a customer decide whether to invest in standards from these organizations?
- Volunteer Communities: the IETF is the classic example of the volunteer, de facto, standards
organization. With the widespread use of Struts and other Apache technologies, one might wonder if
the Apache Software Foundation is another example of a volunteer de facto standards organization.
- Vendor Agreements: when Microsoft and IBM agree to a specification, is that accepted as
a standard? What about when BEA and SAP join them? At what point does a spec go from being
proprietary to open? How large and how diverse does the party need to get?
- Market Leaders: without at least a few of the major players behind a standard, customers will
not be willing to invest in it. This is true whether the standard comes from ISO/IEC or the IETF.
- Broad Market Adoption: customers get concerned when a specification is not being adopted
by a large enough ecosystem, even if there are one or two major players supporting it.
- Shipping the Standard before having Implementation Experience: while standards organizations
like the Java Community Process require a Reference Implementation as a proof of concept, real-world
use of a technology cannot be substituted for a code drop.
- Shipping the Product before Standardization: Of course, the side effect of getting real-world
implementation experience is that users will begin to become attached to the nonstandard technology
and will likely run into compatibility problems as the standard evolves.
How (the 6th "W")
- Degrees of Compliance: how does a customer feel about 95% compliance? how about 110% compliance
(the standard plus vendor extensions)?
- Innovating Ahead of the Standard: should all innovation occur within standards bodies?
If not, how does the responsible ISV innovate without threatening customers with vendor lock-in? Is
there an acceptable period of time that an ISV can ship a non-standard technology (one that would
qualify as a technology requiring standardization)? How much pain can a customer put up with when
migrating from the original innovation to the new standards-compliant version?
While there are more questions here than answers, I'm hoping this exercise will help me in future
blogs to dig into the details of what makes a "standard".