How to explain the “what” and “why” during the VCDX Defence...

I am not a VCDX now as the time of writing, but I will be one when I am ready to be.

It's funny how I am trying to learn to argue everything these days based on a customer requirement. If the customer that I am doing the project for does not have a requirement I create them on-the-fly and make sure the customer signs off on this.

For some customers (actually a lot out there) they are trying to build a solution without having any requirement in place. To be honest, I was like this in the past. Coming from a technical background it is easier to build the solution as cool as possible with the risk building a solution with features that the customer is ending up paying for but actually not required or used at all.

I guess the analogy of building a Ferrari while the customer needed a Volkswagen is a very known one for most VCDX's out there of the ones who are studying for it.

Now when presenting a solution (with having a technical background) to C-level executives is extremely hard. At least for me it is... because I tend to go technical right away even tough C-level executives don't care about the nuts and bolts. I knew this already and it was highlighted to me once again yesterday when I was talking to my good friend Manny Sidhu. All they care about is that their application meets a certain SLA, so that an application is up for a certain period of time on a yearly basis (depending on how the SLA is agreed on). They don't care about that you used LACP between your hosts and your Top of Rack (ToR) switch.

Now the fact that they don't care does not mean that you as an architect are free to choose whatever you want without knowing or explaining why you made certain choices. A (design) choice (or design decision) should usually be made to satisfy a certain requirements and should respect the given constraints. A choice can impact other choices across the main design qualities (availability, manageability, performance, recoverability, security). A choice can also introduce risks that you as an architect should be able to identify and mitigate where possible or at least make sure everyone is aware of the risk.

Now back at the defence. During the VCDX defence exam you as an architect should be able to defend your choices and relate everything back to a (business (or technical if there are any)) requirement. Whenever you present you should be able to answer in some kind of structure that hits all of these elements. Something like:

WHAT? I have chosen to to connect my ESXi host with two 10 Gbps interfaces

WHY? The requirement was to meet an SLA of 99.9% and with only having one link in place the SLA timer starts kicking in right away in case of a link failure so we are trying to avoid the disaster so the SLA can stay in tact.

OPTIONS? Use more than two interfaces. Four for example. A reason that you have not gone for four bit for two is that the (application) bandwidth requirements are 8Gbps. So why should we introduce more interfaces, consume more switch ports affectively spend more money when the requirement was only half of it.

RISKS? With having two interfaces you can introduce a risks. Some may see that this can be seen as configuration complexity, or management overhead. It depends how you argue it and from what perspective you are looking at it. Yes it is more work to configure two interfaces in stead of one but this is a one-time task. And yes the configuration becomes more complex because suddenly you need to have knowledge of interface teaming options.

MITIGATION OF RISKS? Lets try to mitigate the configuration complexity risk. With having proper trained engineers this can be mitigated. Having good implementation documentation with clear description about the operation is also a must. Now every complex configuration first needs to be tested, this testing can be done in a PoC or after the actual deployment with a proper validation plan.

Now this is typically the information that you need to be able provide during your VCDX defence. I have made a diagram to make the approach a bit easier to understand...