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.e.
”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.

Knowing Your VCDX Design

While I was studying for the VCDX, pretty much every successful and unsuccessful VCDX experience blog post or workshop conversation has these words as advice.   “Know your design!”

What does this advice actually mean to a VCDX  candidate ?  Should you sit there and memorise your documents.  Keep reading it over and over again?

Personally I think not.So, in my opinion  “knowing your design is….”

“Presenting evidence to the panel that you know your  project  from a business and technical perspective and  how it illustrates you as an architect”.

The aim is to  Illustrate knowledge  in each of the areas from the blueprint so you achieve  VCDX.   A potential mistake here is to assume a working  real life solution will hit all areas and pass, yeah it works, but will it make the certification review.

How do you prep for this and study your own design.    Personally, I dedicated a week or so purely to below  process prior to my successful defense. It helped me find areas of weakness and identified technical areas I needed to review / brush up on.

Knowing your design objectives

  • Know the main design requirements that drove key logical decisions.
  • Understand how the  physical design decisions were implemented technically.
  • If it’s an unique implementation choice  that differs from common  reference documentation know why  it was chosen  and what would  be done if things were different.
  • Show the impact of the choices.
  • Discuss the submission risks and risk mitigation approaches for key risks.
  • Understand alternative approaches to physical implementation.

Where to start?  Personally, I created an excel spreadsheet listing,

  • Requirements
  • Constraints
  • Assumptions
  • Risks
  • Design decisions
  • Logical list
  • Physical list
  • Mapping each physical choice to the logical design decision.

From here, I  came up with a list of weaknesses and questions.    A lot of people use quizlet for some of this.  I didn’t really get on with it, but I do see the potential for others.

Once I gathered this information and identified questions I prepped standard answers  and ensured I had both business and technical elements.

This technique consolidated my design into a set of decision  thoughts and configuration elements  I could work on studying, and memorising.

I also used this list and example questions to identify subjects that technically I needed  to study and increase my understanding of ( i.e. shared fate concepts, STP and availability  impact with dVS configurations).

In my opinion a  VCDX  candidate going into a defense is aiming to illustrate how they are capable of being the lead architect of a project,  although the panel are  architects, you are the lead in your  submitted  project.

As lead architect you  set your presentation approach and provide opportunities to score.  You need to  try to remain in control of the presentation and cover  all areas in blueprint.

While prepping for this  I created presentation note cards to discuss the key areas and created / practiced some standard logical and physical diagrams for the whiteboard that matched the content.

I used a minimum of one diagram   per level (MVCNS) and covered  the major silos (AMPRS) with practiced annotations on the whiteboard.

It nice having a PowerPoint, but in my opinion displaying you are capable  of a  flowing explanation and  whiteboard drawing at the same time is essential.   it really helped my confidence level and in the real world it is expected daily as an architect.

  • Practice explaining the submitted  design and key technology’s for each area.
  • Be critical  of knowledge and the submission – plug the gaps for the defense day
  • Create potential  questions and  standard answers.

One useful approach I used that really helped  was to ensure  I  could  display  expert level physical knowledge for each area I  referred to  at a relevant time, rather than waiting \ hoping for a panelist to question me.  I  found this can be  blended into the conversation with ease.  i.e.

  • Use cases
  • Max  and mins
  • Restrictions and impacts
  • Design choices
  • Submitted  project  hardware with  main vendor alternative examples.

Whatever I  studied  here,   i ensured I had some deep dive detail and justification  in case of probing from the panel.

One final aspect of knowing you design is confidence.  I found this  is similar  to prepping to teach a  course.

Preparing yourself for the potential of the panellists / audience  agreeing or not agreeing with you,

Sticking   to your guns with evidence.  It’s your design, but confidence with technical understanding.

I.e.

“I understand your point of view however consider  X, Y , and Z ”

“Understood, I   Considered  X.   It is   listed  as a risk, mitigated using  y and road mapped to be potentially  removed or automated using  scripting or solution in Z

The panellists  are architects too, not full time examiners.  They will have personal thoughts on approaches and why things are better or not.  There will be reasonable and friendly, but allow no  bluffing – it won’t help scoring just waste time and decrease scoring opportunities.

Summary of my approach  for “knowing your design”

 

  • Learn the main   design decisions from submission – I made  charts, mind maps. lists
  • Identify  the weaknesses in the design   submitted and how to improve it (evidence),
  • Know key  risks  and how   mitigation worked  –  just accepted by the business is not mitigation (A daily standard check using powerCLI, or a vROPs alert with specific badge reference maybe easier to justify).
  • Practice  standard drawings that illustrate the submission – blend into conversation  for evidence.
  • Practice and study to create  detailed explanations of  key areas from blueprint using submitted  project implementation as the example.

This process worked for me in my successful defense.  Hopefully this is useful to others.

VCDX passed – #234

vcdx_smallAmazing week.

Monday morning  – VCDX defense  in Staines,

Then  in ultra quick time – Friday afternoon was here and the email arrived.

I passed – VCDX-234 

I will no doubt blog about my journey and anything I picked up on the way over the coming days, weeks and months.

In the meantime,  thank you to my wife who enabled me to spend the time working. She looked after our kids and kept everything going!

Thanks very much to Rene – VCDX-133 for being my mentor this time round and helping me up my game prep wise.

Now celebration.

vRA Mind Maps

I am currently teaching a vRA 7 ICM course live online.

It’s a very interesting platform and a challenging course to teach, particularly online.

As an attempt to consolidate the material I have created some mindmaps for use in the course and in the field.

  1. vRA Mindmap – Summary of Roles
  2. vRA Mindmap – Install / Architecture thoughts
  3. vRA Mindmap – NSX integration
  4. vRA Mindmap – Extensibility
  5. vRA Mindmap – Reclamation
  6. vRA Mindmap – Blueprints
  7. vRA Mindmap – App Authoring

The complete mind map is also available here as one big file.