Succeeding with standards

In previous posts, we’ve talked about why standards are valuable and the main reasons that organizations fail to implement standards. While driving standards can be challenging, the reward is significant enough to make the effort worthwhile. In this post, we’ll talk about some techniques that can make this succeed.

To provide a concrete example, we’ll talk about the attempts to adopt next-generation system and storage management standards.

Lessons Learned – Current system management standards

There are two current management standards for systems: DMTF’s Systems Management Architecture for Server Hardware (SMASH) and the SNIA’s Storage Management Initiative specification (SMI-S).   They share a common infrastructure.  DMTF SMASH specifies monitoring and control over low level platform hardware.  SNIA SMI-S specifies comprehensive standards for the monitoring and control of block and file storage systems, both physical and virtual.  Additionally, it specifies standards for the monitoring and control of storage area networks.

When we discussed the reasons that prevent the adoption of standards, we covered:

  1. Single Product Bubble. For a product where most customers have only one platform, product organizations generally will significantly lower the priority assigned to implementing standard interfaces. On the other hand, it’s the large customers that utilize multiple products; they complain about the lack of uniform interfaces. As we’ve said in prior posts, standards are best if built in from the beginning. Planning for a successful product demands that developers assume that new products will be utilized together with similar or related products. The result should be intrinsic support for relevant standards.
  2. Inability to cover new innovative features and techniques. It is hard to imagine that an interface that conforms to a standard will cover the special, innovative features of our products.   This limitation is often true if an interface focuses on the underlying implementation. However, if the interface focuses instead on what is provided and visible to the client, then innovative features can be translated into a desirable quality of service delivered by the interface without exposing how the feature is implemented. This strategy is captured by the Information Technology Infrastructure Library (ITIL) and is the basis for isolating the next generation of standard interfaces from implementation details.
  3. Complexity – People complain that standards create as much complexity as they solve. This is a big enough area, let’s cover it in more detail below.

Lessons Learned – Complexity in Standards

The current generation of storage management standards offers many “ease of use” lessons. Both standards derive from a 15 year old effort to create a common dictionary of reusable components. When conceived, the focus was on maximizing reusability and on completeness.  Inherently this would seem to be a good thing.  However, in practice these standards allowed a high degree of variability on how these small grains of information are composed into a management interface.   The result was very general and flexible interfaces, but which require a knowledgeable client.

Unfortunately, flexibility is the enemy of standardization. To drive this point home, imagine if there were not a standard set of bolt sizes.  Socket and open-end wrenches would not be economical.  This would leave the ubiquitous adjustable wrench, which needs a lot of room to use and is not very precise.  Relying on the adjustable wrench would severely limit the design of things like engines.

The current standards allow too much vendor customization. As a result, both SMASH and SMI-S are widely viewed as inefficient and hard to implement.

Next generation system management standards

The DMTF and the SNIA have embarked on developing the next generation of system management standards. They are driven by customer demand for an efficient and consistent management interface across heterogeneous systems. Again, they plan to share a common infrastructure.

The DMTF is developing a new standard called Redfish that is designed to meet the expectations of end users for simple, modern, and secure management of scalable platform hardware. The interface is Restful and relies on the OASIS Open Data (OData) protocol for communication with the client. Redfish is intended to replace the older SMASH specifications.

The SNIA is working on a new standard for Scalable Storage Management (SSM). That work is currently focused on managing block storage systems, but is expected to eventually expand to cover the features of SMI-S. Like Redfish, SSM has a primary goal of simplifying the interface for both client consumption and for provider implementations.

We are optimistic that these new standards will have greater success than their predecessors because storage itself is becoming increasingly common and we’ve learned the lessons from the past.

Recommendation: If you want a successful standard, things really need to be standardized – avoid complexity.

Driving implementation of standards

Customer needs drive the implementation of storage management standards, but the requirements usually do not come directly from end-users. This is true for SMASH, Redfish, SMI-S, and SSM.   For storage systems, end-user requirements are typically a second order effect.  In other words, it is the direct consumers of the storage systems, for example Microsoft Windows, which requires the use of SMI-S interfaces.  That class of clients is motivated by simplifying the work to adapt their product to the native management interfaces of every storage platform vendor. Another example is VMware’s VASA interfaces.  VMware requires that vendors implement a VMware interface called VASA.  VMware gets the benefit of simplifying their integration with storage.  However, each storage platform then has the burden of implementing the VASA interfaces.  Unfortunately for the storage vendors, VASA is not a general purpose standard, it cannot be reused by non-VMware customers. This type of de facto standard is increasingly common in the industry.

Another driver for standards is to reduce cost, accelerate time to market, and improve quality. This factor has driven the successful adoption of agile software development processes, a standard software engineering practice. Within product organizations, however, development optimization has been significantly less influential in driving the implementation of standard interfaces for storage management.  Various layered products must access storage management features of the heterogeneous storage platforms within the client’s data center.  Common management interfaces would reduce the cost and time to integrate with each kind storage platform.  But instead, we often resort to using available platform specific interfaces in order to get products built sooner.  This increases the test and support matrix for each layered product.

Recommendation: If you want to implement standards, it’s best to have customer justification.

Successful implementation of standards – think intrinsic

Standard interfaces are implemented in one of two ways, either as an added service or intrinsically.

Most often, standards support is added onto an existing implementation as an added service. A group separate from the core product team implements that service.  The argument for this is that a ‘native’ interface has already been implemented and that existing customers cannot tolerate the disruption of switching to a new interface. There is also often an argument that the core team is simply “too busy” to understand and implement the standard. The obvious drawback to this approach is the added costs, both to implement and maintain the added service.  Additionally, there is the added footprint and performance penalties resulting from going through the added service.

The other strategy is to incorporate the standard interface intrinsically. Here, the same team that implements the interface also implements the standard interface.  This has a primary benefit that performance issues with the interface can be addressed more efficiently.  If a native interface also exists, it can be maintained in parallel.  If the standard interface covers the native interface, a choice can be made to continue to support the native interface, or to eventually remove it.   In this strategy, once parity is achieved, new functionality should be first supported by the standard interface.

A key feature of most successful standards is that they are implemented as an intrinsic part of conformant implementations.

Recommendation: If you want your standard interface to succeed, implement it intrinsically.

Conclusion

Standards will not succeed as a grass roots, “best effort” initiative. At high levels within a company, decide on a set of systems management standard interfaces that should be implemented intrinsically. Once selected, the organization must invest in sufficient training and must make roadmap implementation commitments towards intrinsic support. And, of course…

Recommendation: People must be held accountable.

George Ericson @GEricson

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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