This is an excerpt from a presentation I give to explain the value of VMware Professional Services and why a customer needs the services of an Enterprise Architect. It uses cars as an analogy for people who aren’t very familiar with vSphere, because most technical people I’ve met have some frame of reference when it comes to automobiles. I’ve also found it useful when illustrating the proper mindset expected of a VCDX.
Requirements
The categories of Maneuverability, Speed, Storage, Fuel Economy, Interior Capacity, and Safety represent the areas in which our customer will specify requirements. For instance, they may say that they must have a quarter mile of under 15 seconds, or that they plan to drive through a war zone, and therefore need their car to be bulletproof.
Let’s just pretend for a moment that only 4 models of car exist. These represent the options we have to address the requirements of our customer. Let’s also ignore cost and just look at specifications.
Car 1 clearly wins in terms of Maneuverability and Speed – Similarly, some customers only care about performance
Car 2 is the smallest and will fit into the tightest spaces – In the same way, datacenter footprint is the primary concern of other customers
Car 3 runs on diesel and gets the best fuel economy – we could relate this to a customer’s desire for Capacity
Car 4 is by far the safest as it actually has bulletproof glass and has been uparmored. – some customer environments place Security at the top of their list
All of these are cars. All of them will start up and drive. On day 1, the customer may be so excited that they have a new car that runs they don’t immediately see the problems that may develop a few months from now as they use the car more and more.
Constraints
You can now see the actual models and costs of the cars we were comparing before purely on specs alone. In the real world, of course cost matters, so let’s apply a budget to our decision.
We have been handed a Constraint of $50,000 maximum budget. Therefore, Car1 and Car4 are out of the running. Now between the two that are left, we can see that the 328d wins in the most categories and is likely to meet more of the customer’s requirements.
Maybe the customer sees that $15k and insists we go with the Yaris. We know based on our discovery that they like to drive across 600 mile wide deserts with few gas stations. They may get stranded if they don’t shell out for the 328d. This represents a Risk that must be documented.
It may also be that it is totally unacceptable to the customer that our quarter mile is over 15 seconds. They may have to bend a little on the budget Constraint and give us the additional $10k we need to buy the Corvette.
These are things that must be hashed out on a line item by line item basis during the design phase of any project. All customers will have unique situations in their environment that require compromise and documentation of the rationale for why a compromise was made. It is the job of the Architect to identify these conflicts, present them appropriately, and negotiate their resolution and documentation.
Many times the reason a deployment of something gets the reputation as having failed is because this process wasn’t executed. The person deploying it just got something running within the budget, but did not give all stakeholders the data they needed to make intelligent decisions and possibly modify their requirements and constraints based on this process. Later on, problems emerge and finger pointing starts.
