In our previous post, we talked about the value of standards. Of course, any EMC customer can see the gap between the promise of standards and what they’re using today. Where do things go wrong?
Barriers to standard implementations
So, what the heck? It’s not like this “…standards good…” is a new revelation. We’ve been pushing this rock up the hill for a very long time. However, for most product companies, implementation of a standard interface, even if proprietary and internal, for similar features across products has never been a priority. This is true at all levels in the implementation stack, from high-level system management features to low level protocol extensions. For example, at EMC we have more than five different and non-interoperable RESTful protocol implementations. That doesn’t even include all of the other platform specific protocols that we’ve implemented. Each has to be separately tested and maintained.
So, why are we in this pickle?
The first and primary issue is product-centric roadmap optimization. Our list of customer requested features is (and hopefully will always remain) longer than our capability to implement those features. The short term benefit of implementing the next top-priority feature has almost always trumped the longer term benefit of implementing a standard.
Prioritizing implementation of customer requested features is not wrong. Satisfying customers is important. However, we should be looking at both the short and long term effects of these decisions. Longer term, implementing standard features frees up more resources to provide higher level functionality or additional customer features. Additionally, it reduces the cost of building and maintaining layered products, since the number of different component product types is reduced.
Another issue is picking the right standards to implement. New standards get a lot of hype. But not all attempts result in creating a lasting and relevant standard. We obviously benefit every day from good standards, from screw sizes to grades of gas, from C to XML. The first two of these examples demonstrate the difficulties of changing standards that have been adopted. While we have successfully transitioned to unleaded gas, we have not (at least in the US) fully transitioned to the metric system. This stickiness is not just a problem for transitioning standards; adoption of any new standard is generally expensive. The expense is not just in terms of time and money, but also emotional. People naturally become invested in the way things are.
You might ask why we don’t implement relevant standards whenever we implement, (or re-implement) product features. The answer is usually because we cannot afford to, or that a standard doesn’t exist yet, or sometimes it is that a relevant standard is not yet mature enough. On the issue of maturity; the worry has been that changes in the standard will lead to delays or higher costs due to having to adapt the implementation. An ameliorating factor is that most standards have strict backwards compatibility rules. As a result, adapting to evolution of a standard is likely to be lower cost than having to add-on support for a standard to a non-standard product.
Another issue often raised is extensibility. We innovate. Our products provide leading edge features. The concern is that conformance to a standard will affect our ability to provide or expose features not yet envisioned by relevant standards. This is certainly an issue for selecting which standards to implement, but the reality is that all modern standards have extensibility built in.
Related to this is how support for a standard is integrated. Often a standard is implemented as a layered product over a native implementation by two separate organizations. This doesn’t work well for several reasons. One is that it increases the overall resource usage footprint for the product. More importantly, the separation between these organizations results in divergence, more work, and more lag-time to full support of the product through standard interfaces. It is much better to integrate support of a standard so that it is an inherent attribute of the product.
There are many reasons why organizations fail to implement standards. While the causes are understandable, the effect is still non-optimal, expensive, and frustrating to customers and users. In the next post, we’ll talk about ways to drive consistent support for standards in our organization and yours.
–George Ericson @GEricson