Submitting a VCDX design with key components using Beta software probably not a good strategy for success

[MichaelW007]

Yesterday I and a number of other VCDX holders and Panelists were having a discussion with a hopeful candidate about the implications of submitting a design for VCDX that included core foundational components that were proposed to leverage beta software. The short version of the outcome of this discussion is that it's not a good strategy for success. It has a very low likelihood of success in fact. Ask anyone who's gone through the VCDX process, it's hard enough to defend designs made entirely of production ready GA component software that has been thoroughly tested by the various vendors and been around for a while. For those of you that are curious why this is the case if it is not self evident, it's clearly spelt out in the VCDX blueprint and many other information sources. To save you having to look up the specific page here is the key point.

For a design to have a chance of success in the VCDX program the design must be driven by business requirements and implementation decisions must be suited for mission critical applications in a managed environment. This is the key point. Suited to run mission critical applications in a managed environment. It is hard to argue and justify that running beta software code as part of a core foundational component that every other component is dependent upon is suitable for mission critical managed environments. Even if the beta code was used in a minor component it would require very strong justification and mitigation of risks. Remember when you submit a VCDX design package you are not just submitting an architecture design, you are submitting a complete end to end project. Architecture Design, Test/Verification Plan, Implementation Plan, Standard Operating Procedures etc. As Mark Brunstad, Program Manager for VCDX Certification at VMware said during the discussion "Beta code supporting mission critical apps in a prod environment = big risk, big unmitigated risks make it hard to pass review."  Why would you want to make the process harder on yourself than it already is?

If you really want to defend a design using foundational software components that are currently in beta then I would recommend you wait to submit until after those components go full GA into production. Even then you'd may have to justify being an early adopter of the software and mitigate any risks it might pose to the mission critical applications that it will support and the business that will rely upon them. My very strong advice as a VCDX and as a panelist is that you don't over-engineer your designs, don't make them any more complicated than they need to be, don't make them any more risky (or costly) than they need to be, and make sure all designs are traceable back to a bonafide business requirement and that any risk areas are thoroughly documented and mitigated.

There will always be trade offs, and every aspect of a design, requirements, constraints, assumptions and risks can have an impact on other components of a design. You need to know this for your design, and for the alternatives like the back of your hand. Don't make it any harder than it must be.

I wish all candidates great success with the upcoming VCDX applications submission deadlines and the defences for those of you who make it past the review stage. Do arrange mock defences, do review your deisgn thoroughly, do buy and read the VCDX Bootcamp book, do attend a VCDX bootcamp and review the online recordings and the presentation deck. Don't reach out to panelists for a design review, we can't review your design, we are only able to discuss already public published information that is already well known, generic, and already part of the VCDX Bootcamp. We can't give specific advice. Your best chances of success will come if you attend a VCDX bootcamp before your defence and leverage the combined experience of a number of VCDX during these invaluable events.

Kind regards,

Michael Webster, VCDX-066

This article will also be republished on my blog at longwhiteclouds.com.