Skip to main content

What do Customers Mean by "Standards"? (the 6 W's of Standards)

Posted by cliff on August 12, 2003 at 3:05 AM PDT

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".

Related Topics >>