What are you working on these days?

A good friend, who I have not caught up with in a long time, asked me “So, what are you working on these days?”. I figured that now is as good a time as any to answer that question. (Or maybe I should have jotted something down when I started in this team over 3 years ago!?!)

Product Management

When I moved from Sydney to Palo Alto for a Product Management position within VMware, I didn’t quite know what to expect. A new place, with a new team and not 100% sure of what was being asked of me. I’d never been a PM before. It was ok, but I didn’t love it. The problem was that it wasn’t scratching that technical itch on a day-to-day basis. Fortunately for me, another role opened up that was a much better fit, still within VMware engineering, still building a “product” but on the solutions architecture side of things.

Solutions Architecture

Known back then as the VVRD team, I was one of a small few that was asked to go and work out how to standardize what a deployment of VMware’s Software-Defined Datacenter (SDDC) should look like. When I say “should”, I say it knowing that at the time, there was no “right” way. I walked in with the mindset of every customer is different, every customer’s requirements are different, and therefore, every infrastructure environment is going to be different. What are we trying to achieve here again?

So, knowing that we were tasked with standardizing that the SDDC should look like, we decided to try and take it back and look at some commonalities between customers that have already deployed an SDDC. We asked our selves, what are the fundamental requirements that don’t change? The ones that every customer has to address as part of their SDDC solution.

Once we had a set of common requirements, we could start looking at the gaps. Where there areas that were always different for every customer? Are there places that we simply can’t standardize? (Thankfully, we came up with very little in this regard.) We asked ourselves, what flexibility could we give without compromising on the design? How strict and prescriptive should we be? How many use cases do we want to design for? Can we make the design modular with the ability to grow and add capabilities in the future?

The VVD Solution

There were many questions like these over the initial development of our “standardized SDDC architecture”, but fast forward a few years and we’ve got really good at building prescriptive architecture for VMware’s SDDC. The VMware Validated Designs (VVD) have solutions for:

If you’re interested, the documentation index is here, and there’s also a quick reference list of all material here.

You see, when you walk into a customer (or your IT managers office) offering them their ability to pick their own adventure design, they do so, but based on their own experience. However, if you walk into a customer (or your IT managers office) or and say “all of the most experienced architects have agreed that this is the right way to do things based on hundreds of deployments and best practices”, the conversation will be very different indeed.

Full Circle

So, I moved to California for a few years, built some really great relationships and a bunch of neat designs and now I’m back in Australia. I’m closer to family (and of course much better coffee) but I’m still working on building the VMware Validated Designs (along with writing a new Mastering vSphere book).

I hope that answers your question Craig :)

In the next post we will explore the details for the elements that make up a VVD along with some more of the how’s and why’s

comments powered by Disqus