The challenge of standards

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

One Reply to “The challenge of standards”

  1. George once again nice job. A few comments.

    1. Common infrastructure that is shared across groups can definitely help to ensure a more uniform implementation and better conformance to a spec.

    2. The larger issue that we face is each group first wants to produce a REST API based on how their storage array works. Then if they want to produce a standards based model of the same functionality they have to go through the process again. Depending upon the infrastructure that they are utilizing the cost of implementing an SMI-S model may be just as large as the effort to produce the REST API.

    3. All the API’s that we have produced to date are all based on how they array works with some degree of abstraction built it. The individual REST APIs produced by the various groups describe how the array works with no abstractions. The SMI-S model is highly abstracted, but it still describes how an array works.

    Both approaches require you to stitch together the pieces that you need in the order the array needs them to get what you want. Essentially we have been teaching programmers how the array works and how to glue the functionality together to get what they want.

    Our new SSM (Simplified Storage Model) hold great promise as it solves several problems at once. The SSM model no longer teaches programmers how the array works but instead let’s them focus on what it is they are trying to do which is provision applications using five to six application centric concepts instead of hundreds of calls based on how the array works. This new model will greatly ease the burden that has been put on our clients when trying to consume our storage array features.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s