When Standards And Innovation Don't Mix - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IoT
IoT
Cloud // Cloud Storage
Commentary
7/3/2012
06:57 PM
Jasmine  McTigue
Jasmine McTigue
Commentary
50%
50%

When Standards And Innovation Don't Mix

The problem with protocols is that when we need them most, they're least effective. Enter the age of the API.

Whenever we ask IT professionals about standards vs. proprietary, we get people professing their allegiance to network protocols. If my widget wants to communicate with your widget, they need to speak a common language, right?

The problem with standards is that they're the diametric opposite of innovation. As soon as you define a way in which a particular action must be taken, you eliminate other methods of taking that action. Sometimes support of a standard actually inhibits development of creative solutions to system problems.

Take OVF, the Open Virtualization Format for virtual machines. While almost all hypervisors are capable of doing basic functions with a standard .ovf file, VMware's proprietary--and, yes, innovative--VMDK file format brings a ton of additional features, like thin provisioning. However, a VM must be converted to a VMDK to take advantage. Yes, the OVF format remains useful for passing VMs from hypervisor to hypervisor in a standard, structured way. But the OVF format is also fixed, and because it's fixed, when VMware--or Citrix or Microsoft--wants to support a new feature that requires extension of the functionality at the virtual disk level, it can't do so in OVF. If it could, the standard would be broken and therefore useless. Even though OVF is extensible, if every vendor adds its own extensions to OVF, suddenly the thing is proprietary even though it's technically open. How will Hyper-V read VMware's proprietary OVF extensions? How will VMware read Hyper-V's? What if the extension carries critical machine data?

The kicker is, it's during periods of rapid change and intense innovation when we need standards the most. The move to private clouds and heavily virtualized and automated networks certainly qualifies as intense. But how does IT make the right bet in a world where technology is changing too fast to know what the "correct" standard will be a year from now? Maybe tomorrow some upstart will figure out a much better way to do X, and then standards are out the window, just like VMware tossed the first release of ESX Server.

While it's a challenging time for IT teams that need to integrate dissimilar systems to deliver tangible business benefit via integration, I can't help but feel bad for vendors. Cisco, Microsoft, VMware, and others catch heat for "breaking" standards, but the reality is, they face a delicate balancing act between providing enough of a standard to promote far-reaching interoperability without hamstringing innovation. And virtualization has not made this difficult task any easier.

"Let's virtualize the network," says Company A. Engineers get to work and figure out that they want to use InfiniBand as a carrier interconnect. Company B has the same goals but prefers 10-Gbps Ethernet. Company C thinks PCI Express' SR-IOV is going to make life easier, so it goes with PCI Extension. Who's right? Which of these interconnects is going to win? The answer isn't always clear, and in the multivariate world of pervasive virtualization, unclear outcomes have become the rule rather than the exception.

I believe IT teams need to worry less about standards, or lack thereof, and focus energy on application programming interfaces, or APIs, that define the way outside elements can communicate with a given infrastructure element. Just as virtualization provides a layer of abstraction between a virtual machine and the memory it uses, an API provides a layer of abstraction between the request being made and the way in which the device accomplishes that request. I tell VMware to clone a machine with an API call, and vSphere uses its proprietary cloning technology to physically copy the machine. I can ask both vSphere and Hyper-V to do the same logical action: clone the machine. The way in which those two infrastructures actually get the job done could be radically different; if I'm using the right SAN, for instance, VMware can use another API to leverage the power of the storage array to do the task faster, and that's fine. This is the power of the API--and the reason APIs are becoming a standard feature of virtualized infrastructures. Tear down a machine, put a machine up, restart, failover, give me a new network interface. All these actions can be taken via API calls to underlying infrastructure elements without stifling the vendor's ability to innovate.

For networking pros, the problem with APIs is that they're invoked programmatically. And while there are plenty of code jockeys around, this programming is happening in a new place: the core infrastructure. That's scary. Code is buggy, and yet suddenly, the infrastructure team needs to know how to program, at least if your organization wants to leverage the power of APIs to provide concrete benefits such as automation, orchestration, and self-repair. Can you hire programmers to augment your infrastructure team skill set? Certainly. Do those same programmers understand the infrastructure well enough to work efficiently with the existing team? Maybe, but probably not. Time to start cross training? It is undoubtedly so.

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
chachi04
50%
50%
chachi04,
User Rank: Apprentice
7/10/2012 | 7:08:25 PM
re: When Standards And Innovation Don't Mix
Good read on an interesting topic. I work for Juniper and am viewing this from a vendor's lens - while balance is important, innovation should always win out. The lack of mainstream adoption of a standard typically means that the status quo just isn't cutting it. Finding new and creative (and usually better) ways to solve a problem is the way vendors differentiate and continue to add value.

The API is a logical next step in that direction. Bringing the power of users, partners, and other vendors not only opens up access to the (usually brilliant) community, but it provides some tremendous insight into how customers use products and technology.
kathymast
50%
50%
kathymast,
User Rank: Apprentice
7/5/2012 | 3:55:21 PM
re: When Standards And Innovation Don't Mix
Good article on a complex topic. I/T has a strategic need for both innovation and standards. I suggest creating a team solely focused on innovation, training or hiring the expertise needed to achieve a breakthrough or new functionality and use your brightest and best to ensure I/T is innovating for the business. When the innovations are ready for real-time production, analysis must be done in regards to standards - will they fit, need to be adjusted, etc. You have to "break the rules" to innovate and should do so to keep your company competitive - in an innovation environment. Then figure out how to make the innovations fit the standards or standards adjusted to support the innovations for production. You really want the best of both worlds!
MyW0r1d
50%
50%
MyW0r1d,
User Rank: Strategist
7/5/2012 | 2:04:17 PM
re: When Standards And Innovation Don't Mix
"The problem with standards is that they're the diametric opposite of innovation" paints a vague picture with a rather large brush or defines a yard by a single blade of grass. Standards define what are known, proven methods to make something function as advertised. I consider the Steve Jobs, the Bill Gates, the Steve Wozniaks all innovators, but look at their products Cisco, Apple, Microsoft, and almost any other that have made standards (open or proprietary) a critical part of their success. The true innovators are few and far between while there are thousands of wanna bes for each. Standards NEED to be followed in IT production environments where performance depends on service availability and stability. Perhaps you meant ignore standards exclusively in development environments, sandboxes, etc, and perhaps here I could agree, but when you bring it to market or production, set your standards in order to be supportable.
News
IBM Puts Red Hat OpenShift to Work on Sports Data at US Open
Joao-Pierre S. Ruth, Senior Writer,  8/30/2019
Slideshows
IT Careers: 10 Places to Look for Great Developers
Cynthia Harvey, Freelance Journalist, InformationWeek,  9/4/2019
Commentary
Cloud 2.0: A New Era for Public Cloud
Crystal Bedell, Technology Writer,  9/1/2019
White Papers
Register for InformationWeek Newsletters
Video
Current Issue
Data Science and AI in the Fast Lane
This IT Trend Report will help you gain insight into how quickly and dramatically data science is influencing how enterprises are managed and where they will derive business success. Read the report today!
Slideshows
Flash Poll