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
- Every technical and non-technical design decision has a risk element.
- VMware technology and other silos should all be included.
- 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.