Don’t we all agree that less is more? Einstein certainly thought so when he attempted to develop a “unified theory” that could explain the world of physics. Tolkien embraced the concept when he came up with the idea of “one ring to rule them all.” And performers like Beyoncé, Madonna, and Cher obviously subscribe to the maxim by requiring us to remember only one name instead of two. Even in the data center business there are those who would like to see a reduction in the number of standards we use to compare, contrast, benchmark, and certify our facilities and their performance. In fact, I recently read about an organization that is attempting to develop a single standard to enable companies to assess the performance of all of their IT infrastructure. This is an ambitious goal, but like I always say, “If you’re going to dream, dream big.” I wish these folks well in their efforts and, having seen many proposed standards come and go over the years, I’d like to offer them the benefit of my experience by providing them with my five rules for the development of a successful standard.
Rule #1: Keep it simple. The ultimate purpose for the development of any standard is for it to be popularly adopted and used as a common point of reference. What this means in actuality is: if you want your standard to succeed, it needs to be understandable to even those who define the term “lowest common denominator.” I think that’s a major reason behind the success of the Tier standard. Although the actual requirements are quite detailed and specific, even the layman appreciates UI’s packaging them in a “Good, Better, Best…” type of format. I’ve read that the average newspaper is written at a sixth grade level, so the lesson is clear: aim lower. As my trusty marketing guy regularly proves, marketing people are always good subjects for any type of “ease of understanding” testing so lean on them to see if you’ve hit a denominator truly low enough.
Rule #2: The less math the better. Some of you may think that this goes without saying but you can’t be too careful. For example, why has PUE been so well received? Because it’s simple division with a result that maxes out at two decimal places. Very non-threatening to even the most “algebra traumatized” user. Too much math — especially too many big numbers — can be the death knell for even the best potential standard. In summary, if determining the result of your standard resembles a story problem, you probably need to think about dialing things back a bit.
Rule #3: Keep everyone on the same page. Successful standards aren’t developed in a bubble and typically require input from multiple individuals and organizations. Management of these types of cross functional projects is always tricky, and sometimes, even though everyone is working toward the same goal, somebody goes off the reservation. The end result of this unwitting divergence of effort is a standard that is too open to interpretation. The OpenStack folks experienced this issue and almost had to tell some of its proponents that they didn’t have the right “OpenStack.” No one wants to go through this type of embarrassment.
Rule #4: Use visual aids. Some concepts are just better explained graphically. All the best standards contain interesting visuals to illustrate key concepts. In many instances, they don’t even have to be all that understandable — the psychometric graph for acceptable temperature and humidity ranges for TC 9.9 isn’t something that you can decipher at first glance, for example — but their ability to simplify your concepts is invaluable.
Rule #5: Quit while you’re ahead. Just like in show business, it’s very easy to let success go to your head. In the standards world, this usually translates into the “sequel syndrome.” A good case study here is the Green Grid. The industry welcomed PUE with open arms, WUE, not so much. ASHRAE’s efforts to specify thresholds in the early drafts of 90.4 are also a good reference for any ambitious young standards creator.
By their very nature, individuals or groups that embark on the treacherous path that is standards development are risk takers. Very often they undertake these efforts with no blueprint or guidelines to follow, and they deserve whatever help we can offer. If these rules can aid in the development of the data center industry equivalent of a unified theory, then I can rest easy at night knowing that I’ve done my little bit to aid the cause. And to all you standard developers out there, keep at it. You may never reach the level of Beyoncé, Madonna, or Cher, but we appreciate the effort all the same.
