The Difference Between a Standard and a Preferred Vendor

Recently, I attended a customer workshop where the customer declared that they standardized on x86, VMware and Linux.

That got me and my colleague thinking about what standardization really means and whether that actually makes sense.

The workshop was actually about defining a PaaS platform for the customer, and early in the process they just said: Fine, but it’s gonna be x86, VMware and Linux, because that’s our standard. WTF?

What Standards are Not

x86 is not a standard, it’s a processor architecture. VMware is not a standard, it’s a hypervisor implementation. And Linux is not a standard either, it’s an operating system.

J2EE is a standard, and the only one that is relevant to the particular project we were talking about: The goal was to create a Private PaaS Cloud for the customer, and J2EE is the standard that establishes the interface between the PaaS cloud as a service provider and their customers. Nothing else.

Once the interface between you and your internal customers is defined through a standard, it doesn’t matter what processor architecture, what hypervisor or what OS you are using to deliver against that standard. At least not to the consumers of your service, because the purpose of defining an interface is to abstract away all implementation details from your customer so you get to choose the best possible way to provide your service!

Standardization is a Common Language

Standardization is about agreeing on a common language so you’re free to use whatever you want to do your job. Standardization should not dictate your choice of CPU, Hypervisor or OS. It’s that simple.

So the next time you say “We have standardized on x86”, you’re really saying: We have limited our choices of CPUs and stopped thinking about them. Think twice because you may be missing a lot of opportunity.

And that brings us to another important principle in building clouds: After you define the standard that abstracts your service away from your customers, there’s no point in using any type of standardization at a lower level than that. This is best explained in this blog post about PaaS is not Middleware over IaaS.

Which means: If you’re about to create a PaaS service, you should do whatever is necessary to make it as efficient as possible, without resorting to someone else’s service. Because that would limit your choices, limit your service level and limit the opportunities you have in making your approach to delivering your service as efficient as possible.

So here are some good architecture principles for building clouds and establishing standards:

• Standardize on one thing only: Your interface between you, the service supplier and your customers, the service consumers.

• Don’t accept any standardization below the level of the interface you provide, because it limits your choices and your opportunity to deliver quality.

• Learn to distinguish standardization from choosing a preferred vendor. They are different things with different purposes.

And here’s the plan on how to build clouds:

• Define the service that you want to deliver as a standard. It could be Database as a Service, J2EE as a service or even dogfood as a service.

• Make that service definition as product agnostic as possible. It should survice at least ten years of usage.

• Stop caring about your service consumers (they have the manual, right?) and start optimizing the heck out of your service delivery stack, without any restrictions on what technologies, vendors or stuff you use.

Really, it’s that simple. But it’s not “We have standardized on x86, VMware and Linux.”