Write to me if you can find a word in the computing business that has been abused more than the word "standard."
Standard used to stand for something, didn't it? Not anymore. The sarcasm rings truer than ever in that old industry axiom: The great thing about standards is that there are so many of them. One reason that Tech Update has identified standards-based computing as one of the top seven priorities for technology managers and decision makers is that the meaning of the word "standard" has been lost. "Standard" once carried significant implications. First and foremost, it meant that some well-known and respected standards-setting body such as the IEEE had endorsed a technical specification in such a way that guaranteed interoperability between different products supporting that standard. For users and buyers, "standard" also implied that compliant vendors would compete on implementation and price.
For all the showmanship, ego, and hype that Oracle CEO Larry Ellison is capable of, he deserves a lot of credit for his keynote remarks at last year's Oracle OpenWorld.
Referring to the market for application servers based on Java 2 Enterprise Edition technology (which he considers to be a standard), Ellison talked about how Oracle was late to the game compared to the current market-leading solutions--BEA's WebLogic and IBM's WebSphere. As part of his pitch for the "unbreakable" newest release of Oracle's application server--Oracle 9iAS--Ellison noted that if a vendor is going to be late to market, it had better deliver something superior to whatever's already available. Ellison challenged Oracle's engineers to come up with a product that complied with J2EE, and that competed on reliability, speed (the implementation parts) and price. The result, claims Ellison, is a product more reliable and less expensive than the competition. Ellison says he had no choice; if 9iAS wasn't the best alternative, buyers could easily replace it with some other J2EE-compliant application server.
I'll set aside the question of whether what he says about Oracle 9iAS' speed, reliability, and J2EE compliance is true, or even whether J2EE is actually a standard. (Is it? What do you think?) At least Ellison's message embodied the spirit of standards-based computing.
Standards are not a vendor thing. They are an end-user and buyer thing. If you--the end-user, buyer, or manager of technology--can't easily substitute one competitive offering for another, then you should immediately question the benefit of a vendor's claim to be standards compliant.
The ability to make such substitutions--often referred to as a rip-n-replace or RnR--puts you in control of your technology's performance, reliability, security, and total cost of ownership. But the ease with which you can RnR a currently deployed solution will vary, depending on how much of that solution's core functionality is standards-based, how much you rely on the non-standard parts (if any exist) of your current solution, and who is running your IT.
In the spirit of complying with standards and competing on implementation and price (a.k.a. Comply and Compete or CnC), there are very few products that don't have some sort of proprietary feature. How much you depend on that feature is a different question. The more you rely on a solution's proprietary features, the more difficult it is to perform an RnR.
For example, most Ethernet switches have proprietary features. But network managers rarely deploy those features that would interfere with the switch's Ethernet standards compliance. They might, however, deploy a switch's proprietary management features. Performing an RnR with another vendor's switch is still possible because the core functionality and interoperability with other devices on the network isn't compromised. The bottom line is that widespread acceptance and usage of the Ethernet standard puts you in charge of your network's performance, reliability, security, and cost. If you don't like one vendor's switch because it's too expensive or unreliable, you can RnR it with one from another vendor.
The more you rely on proprietary features, however, the more difficult an RnR becomes. When the thought of performing an RnR on some part of your IT becomes unfathomable because the cost and disruption is simply too much to bear, you and your company now have a major problem. That solution's vendor is now in control of that part of your IT's cost, performance, security, and reliability.
The most glaring and public examples of this today are Microsoft's e-mail and Internet server solutions. Thousands of companies have established an almost irreversible reliance on MAPI (a proprietary protocol that facilitates the connection between an Outlook client and Exchange Server) and VBScript (the scripting language behind Internet Information Server's ability to dynamically serve Web pages). As a result of this reliance, these enterprises are virtually powerless to RnR their e-mail or Web servers--should they ever become dissatisfied with their performance, reliability, cost, or worse of all, their security. Are you one of those companies? If so, those parts of your IT are only as fast, as reliable, as affordable, and as secure as Microsoft makes them.
This is not a ding on Microsoft. The company, like Ethernet switch manufacturers, has every right to offer additional functionality through proprietary features in the hope that you'll become addicted to those features. In fact, Exchange Server not only supports the standard mail retrieval protocols POP3 and IMAP4 that you can use in place of MAPI; it activates them upon installation. It's up to you to determine which protocols to deploy. In the wake of Outlook's various security problems, companies smart enough to avoid relying on MAPI have some RnR options (and control over performance, reliability, cost, and security) that other companies don't. There are plenty alternatives when it comes to POP3 and IMAP4-compliant clients and servers.
For those entrenched in IIS, your fate was sealed the day you started writing VBScript. While you can ding Microsoft for the litany of security problems, you can't ding them for embracing the HTML standard, and extending the functionality of an HTML page with the proprietary VBScript. Ding yourself for relying on a technology with no RnR options. The most prevalent alternative to Microsoft's Active Server Pages are Java Server Pages (and to some extent TCL, Python and Perl, all of which can be run with IIS). Had you chosen Java over VBScript, you would have had many more RnR options at your disposal (numerous Web servers support JSP) if you grew dissatisfied with your Web server's performance, reliability, cost, or security.
Exactly what is a standard? Java may be an alternative to VBScript, but is it a standard? No standards body has ratified it. In fact, Sun submitted it for ratification to the European Computer Manufacturers Association, only to later withdraw the submission before it could be considered. (As a side note, ECMA recently ratified Microsoft's successor to VBScript, C#, as a standard.) Sun considers Java a standard because Java's evolution has been subject to multi-vendor scrutiny by virtue of the Sun-created Java Community Process (JCP).
Sure, that process makes it feel more like a standard, but the JCP isn't really like ECMA, ANSI, IEEE, or any of the other more recognised standards setting bodies. JCP falls more into the consortia camp. On the other hand, does it even matter? Remember that the acid test for whether something is a standard shouldn't be whether some standards body says it is. The test is whether the end-user can enjoy benefits most commonly associated with a standard. Is there enough support for the "standard" from alternative solution providers to ensure that technology decision makers have a choice of several compliant options in a way that puts them--not the vendor--in control of their IT's performance, reliability, cost and security? Some would argue that the more evolved forms of Java, like J2EE and J2SE (the standard edition), pass this test. As Ellison said, "if you don't like my J2EE server, I know you'll buy IBM's or BEA's."
Just because a standards-setting body says something is a standard doesn't mean it is, and just because no standards setting body has ratified something else as a standard doesn't mean it isn't. If you're thoroughly confused, I completely understand.
