A new taxonomy: the Build to Buy continuum

Human beings are pattern detectors. We seek to create order out of chaos, and our minds are always trying to create systems, rankings, lists, groupings of things that seem disconnected and random.

It can go sideways – where our brains see patterns in randomness. What do you see in this picture? I see burnt toast.

Other people see a pattern :-) BTW – this is one of the strongest “pattern detection” algorithms in the human mind: face detection.

I know I’ve used this analogy before, but I’ll use it one last time (then it’s retired) – its very apropos… One other form of pattern detection is the creation of the scientific taxonomy of all life on earth:

This created a pattern out of something amazingly variant, and at the surface, delightfully random – all the variation of life.

All life on earth are in three domains: Archaea, Bacteria, Eukarya (hey, that’s us!)

Then, those domains break down into Kingdoms, Phylum, Classes, Orders, Families, Genus and Species.

If you want to follow that pattern to get to us:

Life –> Eukarya –> Animalia –> Chordata –> Mammalia –> Primates –> Haplorhini –> Hominidae –> Homo –> Homo sapiens (again, “hey, that’s us!”)

This is human “pattern making” taken to an extreme.

In our IT business, there’s a lot of confusing stuff out there – which is compounded by the ecosystem that always want to suggest that something is new, and totally different (versus trying hard to make it an extension of things that people already understand).

Then you have the machinery of analysts (great pattern detectors themselves), who create systems and taxonomies of all sorts.

Image result for hype cycle

To top that off you have the natural hype-cycle which Gartner has immortalized and formalized.

This is also a taxonomy – a system of ordering things.

See the July 2015 example to the right…

Note to self: the “obsolete before plateau” category is just a bummer – sucks to be there :-)

When you take ALL OF THAT, and multiply that all by “marketing” and you get for a confusing world indeed!

That’s why building structured ways of grouping ideas is so appealing – particularly to nerds like me :-) Groupings recognize the fact that the world is indeed complex. It doesn’t fall into the ideologue’s trap of building a system that is “black and white” or “binary” – that’s a path that appeals to people who struggle with complex systems.

Groupings and taxonomies attempt to take complexity and narrow it down – simplify as much as possible, but no further.

One taxonomy I did a while back that has held up over time (people still using it, and the truest measure of value in a taxonomy, people are actually adding to it) was the “4 Phylum of Storage” post here: Understanding Storage Architectures.

Today I want to put out another proposed taxonomy: The 5 Stops on the “Build” to “Buy” Continuum.

This is a reflection of something I’ve been noodling on since the beginning of 2016 (when my perspective became very focused on the CI and HCI business, as well as working to make the on-premises hybrid cloud stacks work better), and ramped up as Dell and EMC came together and the charter of the team broadened out (and my focus zoomed out to include validated solutions and the Dell Blueprint program).

Perspective changing is a beautiful opportunity – it forces your brain to look at the world in slightly different ways, and ask different questions.

We started to really noodle on this in a new way… What is the thing that “links” and “connects” things like reference architectures to CI and HCI? What is the idea that “connects” customer’s desires for Hybrid Cloud models to the products that compose them? How can the mental state of the customer and their preferences be captured? How is this a function of hype-cycle and maturity of markets?

Ok – here goes.

I’ve come to the conclusion that there is a “Build” to “Buy” continuum across customers. This can be broken down into a taxonomy with 5 “Phylum” of how they look at their IT. It’s not a function of size or market (and even at a given customer can vary by workload/use case) – but rather how the customers see the world.

At the left end of this continuum (“Build”) you have the experience of building your own car. If there was a single word to associate with this end of the spectrum it would be “Flexibility”. It’s the natural home of people who like to tinker, and like to build.

At the other right end of the spectrum, you have the experience of buying a car. If there was a single word to associate with this end of the spectrum, it would be “Outcome”. It’s the natural home of people who view the whole offer as a commodity, and don’t want to tinker. In fact, it’s usually because they want to tinker above that layer of the stack – but not below it.

I think there are 5 clear and distinct “stops” on this continuum: 1) Reference Architectures; 2) Bundles; 3) Validated Systems; 4) Engineered Systems; 5) Platforms.

The no-BS statement which is important to absorb is that that on this continuum, as you move from left to right, you inherently trade off “Flexibility” for “Outcome” – and anyone who says otherwise is wrong, delusional, or trying to sell you something :-)

As the leader for Dell Technologies for this portion of the business – this point of view is now seeping into our fabric, so I feel compelled to share (ideas are best when they are put out there and percolate, share, collaborate, iterate).

Reference Architectures are one step beyond basic component level-products. There is work that is done to do basic testing and qualification. The primary purpose in life for reference architectures is to slightly de-risk multi-product deployment customers who are completely building stuff themselves. They are very flexible – as you can deviate from the reference architecture and nothing will stop you. But – the flip side of that is simple: nothing will stop you :-)
Bundles go a step further, and make the commercial acquisition easier. They simplify and standardize the procurement process. Still pretty darn flexible, but some reduced optionality.
Validated systems take bundles, and make configurability and even build processes (i.e. loading software, rack/stack) and some basic on-site automation possible. But the customer themselves remain responsible for the lifecycle (test/patch/update/support) of the components in the stack. If you take a step back, the products in the recipe are still very evident. These are only somewhat flexible, dramatically curtailed optionality.
Engineered Systems are a big step – not because of the tech in them (which are often the same as a validated system or a reference architecture), but because the ingredients in the stack become an integrated system – designed as one, engineered and manufactured as one, sustained/lifecycled as one, and supported as one. This FORCES an operational change in the customer. Sophisticated, mature VxBlock customers don’t care what is in it – only in the parameters of the overall system (which the ingredients influence, but don’t define). And while Converged Infrastructure still has the ingredients as “physically visible” (ie. you can visibly “see” the blades and storage as distinct elements), in HCI Appliances and Rack Scale Systems – you cannot decompose them at all. With HCI models the operational change is mandatory, and the lifecycle process is done via software, not services – this is a powerful forcing function. It’s also the thing that makes HCI have a huge operational impact relative to CI (which has a huge operational impact relative to “Build”). The main idea of the “Engineered Systems” category is the component-level details and lifecycle and the responsibility that comes with it completely shift from the customer to the vendor. Engineered Systems deliver on business outcomes (that’s what the customer is choosing), but have a trade off of almost all flexibility in the ability to vary what is in the stack. Net: Engineered Systems are available in any color you want, so long as it’s black – and if that’s your stop on the “Build” to “Buy” continuum, that’s not a bug, it’s a feature.
Platforms take that step on more step further, and go beyond the infrastructure to what more and more customers want – which is the outcome orientation, but all the way up to the IaaS/PaaS layer of the stack. I choose the word “Platform” carefully… Because like any Cloud platform, the customer hands over ANY ability to vary what is below the API/functional layer of the platform, but in exchange has very outcome-oriented acceleration of what is ABOVE that line. BTW – all Public Cloud IaaS/PaaS offers I can see are Platforms. Ditto with all SaaS offerings.

There’s another observation – the market keeps moving from left to right (i.e. more and more growth towards the right), but the vast majority of the market today is still MOSTLY off to the left end of the spectrum (though this is slowing). Visualize a constant conveyor belt moving things from left to right, with new things always appearing on the left. How much is in the “Build” world, and how much is in the “Buy” world? Answer = interesting. Here’s our internal model:

Wow. While the buzz (and growth) is all in the “Buy” end of the spectrum of engineered systems and platforms (after all does ANYONE really think that how they build their storage/server/network and how they deploy vSphere or even the IaaS/PaaS layer is the thing that really differentiates them?)… the reality is that the vast majority of the customers, revenue, and workloads are still on the “Build” end of the spectrum. Huh!

This is yet another example of how people confuse “movement”/“momentum”/”buzz” with “size of the market”. Yes, the growth rates clearly suggest that indeed more and more customer ARE getting clear that hand-stitched and homebrewed servers/network/storage/virtualization are less valuable every day, but the chart highlights that there’s a lot of “Build” out there. Most of it isn’t even on my continuum – it’s at “stop zero” – which is total product level acquisition and integration.

Ergo, the insight is that serving the market is really about “Build” AND “Buy” – and that making this debate an OR proposition is a mistake. YES, we need to try to shift as many customers, as fast as possible to the right, but being pragmatic, helping them at whatever is the “rightmost” point on the continuum they can jump on – and accelerate their journey to the right.

There is a hazard here – from both the customer and the vendor point of view… that hazard is in not being brutally clear and consistent when setting expectations about where you are on the continuum, and what you are getting. It’s worth saying again:

The no-BS statement which is important to absorb is that that on this continuum, as you move from left to right, you trade off “Flexibility” for “Outcome” – and anyone who says otherwise is wrong, delusional, or trying to sell you something :-)

Example from the vendor point of view: when a vendor wants to focus on delivering turnkey agility for a IaaS/PaaS offering (whether it’s on or off-premises), but they don’t have the stomach to confront and challenge customers who want all sorts of optionality/flexibility… They get themselves in trouble. At Dell EMC – all our Hybrid Cloud Platforms going forward will be only available on Engineered Systems (and the direction bends towards HCI). Yes, that means you can’t “tweak this or vary that” below the platform definition – but you can’t with AWS, Azure, Salesforce.com, Workday. The delusion is that when it’s on-premises that’s somehow different. Nope – it’s the same. And when customers think that’s somehow “lock in”, they are confused about where they are on the continuum.

Example from a customer point of view: when they think they want an outcome, but start to specify processor types, media types, get into deep philosophical arguments about VMware versus OpenStack. Those questions and debates have a place, but those debate clearly indicacte that if they matter to you – you are at the “Build” end of the spectrum, and you better make sure that your organization isn’t instead trying to “shift right”.

I’ve been learning a lot of lessons over the last few months:

Our happiest Engineered System customers are where we hold the line HARD on “no dissassembly rule” even when that messes with the customer’s operational model. The customers who are the least happy is where we didn’t get on the same page on the fundamental question: “are you trying to ‘Build’ or ‘Buy’”. When I visit those customers – they say “didn’t deliver the benefit”, but when I double-click, they still have server, storage, networking, virtualization teams – and their VxBlock is dissassembled or their VxRail has become servers with vSAN. If they originally thought they were getting a reference architecture or a bundle – they are happy. But if they thought they were getting a turnkey system with lifecycle management – OUCH, those customers are unhappy. I blame myself, my team – as much as I blame the customer. We were not clear on what they wanted and needed. That’s why I will always support our field teams in turning down a customer who doesn’t accept that with VxBlock, VxRack, and VxRail – you are adopting OUR standard, not us adapting yours.
When we try to move things towards the right before we are ready, or the ecosystem/market is ready – it’s hard. What’s an example? An interesting one right now is the Cloud Native container/container manager/cluster/cluster manager ecosystem is moving at the speed of light, and hasn’t settled down. it will – but right now there’s too much variation, too much tinkering going on – and that’s natural. Expect a lot of stuff around reference architectures, validated systems around this ecosystem – because people want it de-risked, but it’s just too dynamic a space for standards and sufficient commonality to mature. This will emerge – maybe just not quite yet.
We have a lot to do (and are working furiously) to make our Hybrid Cloud Platforms more turnkey, simpler, and more consumable (both operationally and economically). On a recent Speaking In Tech Podcast (always on my playlist), the discussion turned to the fact that it’s still as hard as it is to deploy – and more importantly sustain an on-premises IaaS/PaaS stack is an indictment of the industry… I agree. SDDCaaS on AWS is a big move by VMware, we must match that simplicity, and customer can count on the fact that we are cranking on it – and VxRail annd VxRack SDDC figure prominently. Don’t misunderstand – our Enterprise Hybrid Cloud stack is a very, very good stack – but it’s a “Cadillac”, we need to carefully handle a small number of very big customers, and the best of them run on VxBlock. We need to industrialize EHC and curate it, and we must make it available on HCI starting at small scales… This is true of the Enterprise Hybrid Cloud stack (which is the “most curated VMware Validated Design” you can find) but it will ultimately also true of all of our other Hybrid Cloud Stacks – inclusive of our efforts in partnership with Microsoft and Azure Stack. Stay tuned for a lot on this front throughout all of 2017 – I’m passionate on this topic and I can be a stubborn dude. It’s worth fighting to crack.
Bundles (ScaleIO-Ready Nodes, vSAN Ready Nodes, Windows Server 2016 and Storage Spaces Direct, SAP HANA, what we do with Cloudera/Hortonworks and others in the Analytics space) are really, really important to a lot of customers – and we need to continue to execute.
Validated Systems like what we do around Redhat, around HPC use cases, around vSphere and the Microsoft stack, around are a great way to tackle getting the flexibility of a reference architecture, but a more turnkey experience day one… but are not willing to accept the reduced optionality that comes from the engineered system approach.

So – there you have it, a peek into some of the stuff the team in the Convverged Platforms and Solutions part of the company are working on, and our strategic PoV through the lens of a simple taxonomy:

The 5 stops on the “Build” to “Buy” continuum.

Dear reader – what say you? Am I/we off our rockers? Is this a good way to look at the world and look at the needs of our customers? Is it a useful tool to frame things?

Comments

You can follow this conversation by subscribing to the comment feed for this post.

Very interesting, thanks!

As you pointed out, "Most of it isn’t even on my continuum – it’s at “stop zero” – which is total product level acquisition and integration."

With this in mind, why not include something like "Bespoke Infrastructure" as the left-most stop on "The 6 stops on the “Build” to “Buy” continuum."?

Posted by: Erik Smith | November 29, 2016 at 11:24 AM

Another great post. Thank you. I will never understand how you manage to crank out these long, technical, objective posts while keeping your many "day jobs" running. Are you from WestWorld?

Posted by: Dennis Faucher | November 29, 2016 at 03:56 PM