I wrote this letter in response to an article I had read in in some computer magazine decrying the failure of some standard which had been championed by the author. I actually don't recall which magazine or which standard. I don't think it was ever published. As you can see, I have been quite interested in successful standards design for quite some time.
Why Standards Fail
An Open Letter to OAG and Other Standards Committees.
By Grant Robertson
(written sometime between 1993 and 1996)
Why is it that, often, even good standards fail while, at the same time, obviously inferior ones thrive. Perhaps it is because those creating the standards forget three very important factors for success in the world today: Marketing, marketing, and, of course, marketing. What many don't realize is that a standard is a product that must be sold like anything else. It must be sold to the vendors who will implement it and it must be sold to the customers who will pay for it. What good does it do to make the worlds biggest mouse trap if there are no mice that big? And how do you expect to sell the world’s best snargthik traps if no one would know what a snargthik was even if they saw one.
It is the same with standards. You could create a huge, voluminous standard. But if it has to be implemented on an all or nothing basis then most vendors won’t touch it, or will only implement random parts of it, and most customers wouldn’t want to pay for it if they did. Why spend a fortune on software that adheres to some new standard if it’s going to fall flat because no other vendors adopted it? And why pay any money at all for software that does something no one has heard of or thinks they’ll ever need just because it does so in a standardized way.
Imagine that you decide to manufacture a whole line of traps to catch all different kinds of critters. From mice, to beavers, to bears, to ostriches, to crayfish. Critters that people recognize and may actually want to catch for one reason or another. And, in a stroke of genius, you find a way to use the same general mechanism in all your traps. You can start with some all-purpose generic traps and branch out to others as customers see the benefit of your line and the market grows. That way a customer who learns how to set a mouse trap will know how to set an ostrich trap and vice-versa. I realize I am starting to sound like an ad-man for Apple’s Macintosh, some office productivity suite, or maybe just Havahart (animal traps). The point is, what sells for these things sells for standards as well.
If you want a standard to take hold – and then take off – I really feel it is important to start small. Choose a succinct set of features that can be easily implemented and offer the most recognizable benefit to the most customers. This is not the lowest common denominator (LCD). That would be choosing the few things the vendors already have in common and calling them a standard. Of course we’d end up with a pretty small “standard” that way. Instead, it is important to carefully choose what functions to standardize in the first, or core “standard set.” Do not choose standards based on technical merit or elegance. (A difficult temptation to avoid considering that standards committees are usually comprised of very technical people.) Choose standards based on relevance to the customers, first and foremost. The set should include just enough features to cover the basics while giving the customers a real benefit they can see. Like HTML, SQL, or the .VBXs that came in the box with Visual Basic 3.0. Sure the early versions were pretty basic, and you couldn’t do a lot of fancy stuff with them, but they could do enough of the things that people wanted and so the standards caught on. If the original core standard set is too large then vendors will be tempted to implement only parts of it and then it wouldn’t be a standard at all. It might also be more than customers could bite off in one chew. People don’t want to buy more than they think they’ll need, especially if they don’t know if it will catch on. However, if the core standard set is too small it might not be useful to the customer. So choose wisely, and don’t be afraid to bring in the marketing people. But only to select the functions most important to the customers. Don’t let them anywhere near the standards themselves.
Remember, though, that a “first” has a “second” and a core has an apple around it. Once the core set has taken hold it will be important to release additional standards sets. Now this is not an update to the original set. That should have been done right in the first place and you should leave it alone for quite some time. No, the additional sets should be just that, additional. Get the marketing folks to help you select other sets of functions that customers will find valuable. They could be more basics, higher level features, more difficult to implement basics, or specifics for a particular industry or genre of software. A taller cage for ostriches or a more complicated trapping mechanism to fool the raccoons. Wait till the customers are just starting to get used to the core set and see its value, then start releasing the additions. The customers will start asking the vendors to implement these features and you won’t have to sell to the vendors at all. Pretty soon the customers will be taking the core set for granted and clamoring for all the additional sets they can get. And the vendors will be falling all over themselves to implement them. Now here is where things get tricky. If you can’t come out with standard sets fast enough (remember, keep them small but big enough to be of value by themselves) then the vendors will be tempted to release their own ‘standard sets.’ This will be fine if they follow the general plan of the standards but that is a big “if.”
The main difference between all these “standards sets,” as I call them, and the myriad other standards out there is that these are consistent and organized throughout. No overlaps. No missing links. Each one should grow naturally from the ones that came before. Therefore, it is very important to design the core sets for maximum future growth and flexibility. This should have a priority higher than ease of implementation and second only to the customer value factor. When a new set is released it should follow the “plan.” It should work smoothly and consistently with all the others. If a vendor releases a “standard” as an extension to yours, you should review it and accept it or reject it as quickly as possible. Don’t dilly-dally around. Any delay on your part will be taken as tacit acceptance. Soon other vendors would be releasing their own “standards” that are really only proprietary designs. All will be chaos and it will be the end of your standard as you know it. So keep a tight rein and react quickly. Don’t let intra-committee bickering and vendor politics slow you down. If necessary, make up rules to deal with those vendors on committee members who won’t work with the team. Remember, when the standard starts taking off these malcontents will be begging to get back on the team. Except maybe Microsoft, who will just copy what you’re doing, give it a cutesy name and act as if they invented it.
About possible implementation tactics for vendors or developers: Think of a “standard set” as a type of “object” or library. Include the whole thing or none at all. Allow customers to chose standard methods, their own, or your proprietary methods based on their needs. You could eventually replace your original proprietary functions with those written to the standard by simply not including the old ones. If you had separated out the proprietary functions as separate .DLLs or other libraries then customers could just hang on to the old libraries if they still needed to use the old functions for some reason.
Notes:
- If the standard set is too big then vendors will be hesitant to accept it. It will take too much time and money to implement it with no guarantee of success. They may choose to only implement random parts in various ways which will result in chaos.
- If you settle for merely “mapping different models” then it will only add YALA (Yet Another Layer of Abstraction) at the cost of many computing cycles.
- The best approach would be to break the standards into smaller groups (what I call ‘standards sets’) based on industry and levels of functionality. I believe that the standards that succeed are those that are easy to sell. And I mean that in two ways. Vendors must be able to sell their adherence to a standard to their customers. And the committee must be able to sell the standards to the vendors. If the customers aren’t interested in it then why should the vendors go to all that trouble. But for the customers to be interested, it must be easily recognizable as well as having a benefit. The standard has to be all encompassing and adopted as a whole or not at all. Or in small, succinct, organized, consistent sets. This gives the customers something to sink their teeth into while allowing the vendors to pick which sets to implement when. The idea is to take advantage of feature-creep while still controlling the beast. Just think about what happened with HTML. It started out with a core, LCD feature set. While standards committees were working on overly large, all-encompassing standards, Netscape and others were adding feature sets of their own. Each of these feature sets were small yet complete enough to be taken on their own. Colored text, backgrounds, tables, columns. Competing browser vendors could chose any or all of the sets individually. Most all have implemented backgrounds but not many have columns, yet. And customers can easily recognize each set.
This post is Copyright © 2009 by Grant Sheridan Robertson.
No comments:
Post a Comment