Risk management for the VCDX candidate

During my VCDX journey I took an existing design I created and guided  into production.  It was working and supportable.
A good start, but in retrospect it was a long way  from VCDX level.
I have reviewed several VCDX candidate work recently and most of them are in the same place I was.  In addition, this question pops up from time to time so I thought it would be nice to explore the topic a little.
In my documentation, I originally listed a few risks that were business perspective based,  neatly labelled them RSK001, RSK002 etc and referenced to them in my design.
Done?  Not even started?
Additional thoughts for the VCDX candidate 
  1. Every technical and non-technical design decision has a risk element.
  2. VMware technology and other silos should all be included.
  3. Businesses may accept risks, technical architects minimise, own and mitigate them too.
For the VCDX documentation, I would recommend reviewing design decisions in your design, list them somewhere in your documentation format specifically  to ensure you have provided some evidence you have considered the impact and mitigation process for each one (ie table, risk register document etc).
Personally, I  took the approach to add concerns  to a summary table and specifically give examples of the  approach I would use to mitigate against them.
Preparing for  defense from a risk management perspective 

Consider  the SLAs you have in your design.

RPO, RTO and uptime.

Review your risk mitigations – are there any areas that could be improved here using design alternatives?

What processes, automation or personnel can be used to work within the accepted project?


Prepare to provide more clarity on the risk mitigation processes in the defence.  How do you actually do it?

Consider some ways of expressing this in the defense, both from your presentation and if prompted indirectly / directly  by the panelists.

”I would have manual check with powershell  X , Y.  Z”
“This is /will be  documented and added to manual report sent to the team daily  at day 1”
“A milestone or plan to create an automated report for this is due”
“This is a roadmap item to add a specific view or  custom alert in the vROPs / monitoring solution”
I originally concentrated on business risk items in my first couple of drafts, in retrospect the difference between this approach and my successful VCDX documentation was covering all areas from a design perspective and then  feeding into my standard operating procedures  the risks associated with
  • Physical project based issues
  • Design decision based concerns
  • Business related areas
  • VMware  specific technology impacts
I spent many hours reviewing this small, but important area of the VCDX certification and I feel I am a much better architect for it.
The process gives you an eye to question and review technical implementations from  a different perspective.
By  breaking solutions  down into logical blocks and then merging technical facts (limits, configuration patterns etc  into business / project based issues), I find it helps me review and show  validation of the design and the choices.
RIsk areas, in the real world  also  helps with operationalising  designs for the support professionals we all design for.