VCDX: Design Scenario

The 75 minutes for the defense section just finished, now a short break while the panelist gets the next part ready, The Design Scenario, where you get to show how you would approach a specific set of business and technical requirements. Fast.

The 45 minutes (Extended from 30 min to 45 min in 2016) alloted to this part go by quick. Quick really isn’t fast enough to begin to describe it. But there is no need to have fully functional environment ready for deployment either.

As far as I know the goal of the defense scenario is not to see how fast you can design, its more about how you approach the design requirements and how you verbalize your thought process. But then again you can cover more ground if you can do it really quick 🙂

The VCDX design scenario will give you access to 1-3 slides containing a set of requirements and constraints, both business and technical. Also you might get access to number for an existing environment that need to be accounted for in the design. Your role is to ask additional questions for more information about the problem that the fictional customer is facing, additional business requirements or even a set of constraints.

The VCDX blueprint explains this section like this:
Respond interactively to a presentation of requirements and constraints to show the ability to produce a design which satisfies a customer’s needs.

Real world design sessions take hours, even tens of hours of different meetings with a different people to be able to fully understand the requirements for a complex environment. This is usually done with a set of specific guidelines in place, what should be asked, who to ask and who will approve the final conceptual design. The design scenario is somewhat that process but only in 30-45 minutes and with less emphasis on a fully designed solution in the end. Process is key here and to be able to cover as much as possible the guidelines need to be become more streamlined as well.

Rene Van Den Bedems blog post about the design scenario is a great resource that has a lot of good recommendations to do just that, and I used them as the basis to create a whiteboard layout to be able to show the process as fast as I possibly could.

Here is a picture of the layout:


On the left there are specific notes and recommendations and below that is the process itself. So the plan was to be able to go through that process as fast possible.

On the right are potential questions to ask regarding a specific technology stack to be able to fulfill any requirements.

The whiteboard layout has several sections:

  • On the left there is the conceptual list with possible design goals, success factors, requirements/constraints/assumptions(if any)/risks. This does not mean that these topics will be on the slides themselves as you might need to ask around for them.
  • Next to that is the design characteristics part where the plan was to use specific markings to be able to mark each design decision taken with a specific characteristic.
  • Below those two were the design decisions themselves and those were supposed to be classified based on blueprint sections. I never even got close to be able to categorize them. Still the logic around it seemed to make sense at the time.
  • The rest of the whiteboard contains a logical design diagram with specific room for storage and network and additional room for management layers. Design choices were located near the corresponding stack.

I practiced drawing the layout on different sizes of whiteboards just to be ready, and so that I could draw it as fast as possible and knew what should go where.

The plan was to have something remotely similar to that during the scenario itself. Due to the nature of the design scenario I got I never got close to being able create it though. But I had a plan in regards for the process and the layout I wanted to use to show my design skills and I think that made a difference.

Practice a design scenario mock with the study group at least 3-4 times before the defense day. Once with the process in front of you, the other time with nothing but a whiteboard. Always a whiteboard. And coffee. Always coffee.

Some additional pointers:

  • Plan for dual site designs as well. Space becomes scarce when drawing everything twice.
  • Not all designs are just about the infrastructure, the workloads are important to.
  • If you have access to two whiteboards please do use them both.
  • Talk, talk, talk. Tell the panelist what you are thinking, and why. Requirement->Design decision with justification and an alternative if applicable. Short explanations, no technology deep dives explaining a specific feature in vSphere.

And finally here are some other helpful resources for the design scenario:

And also many of the VCDX’s post their recommendations and experiences about the design scenario in their “experience post”, so you can find a detailed list of such posts over at Gregg Robertsons blog:

Leave a Reply

Your email address will not be published. Required fields are marked *