Post VCDX defense thoughts | You will be notified in 10 days.

You will be notified in  10 days……
Now breathe, the defense is over.  However, the  process isn’t…
VCDX panelists are very friendly and polite, but, they are not going to give any clue on whether you passed or failed.
So, until you have that VCDX welcome email,  it’s still prep time.

 

Post defense thoughts

Write all the questions and answers you can remember down now.  

These are vital clues into design and knowledge weakness the panel thought after their review. These were areas they wanted answered to get you a pass. If you were unsuccessful – weave the answers and areas into your accepted documentation set and ensure you have them covered in your next presentation at a minimum.  

List in the order of probing questions what infrastructure quality or datacenter layers  were  mentioned.

This will give you specific areas for improvement.   These are areas  that your documentation / design needs to give you a better chance of passing.

 

List  the  “I don’t knows”

Look up the answers and links for study.

 

Spend another 1/2 hour or so on the design question they gave you.  

How would you solve it now under no pressure?

Draw out a high level conceptual diagram and a logical diagram sketch for each datacenter layer

Have this as a past exam paper for studying next time – just in case …  

If you were successful 

Congrats  

If you were not successful,

See how the the overall VCDX panel feedback aligns to the above.

Discuss this with a VCDX mentor.  

The VCDX defense is  great  experience – pass or fail.

If it didn’t go your way, get grumpy for a day or two, but  please don’t give up,  just  take it on the chin, and go in again.

Have a resubmission  action plan.

You may have one of same panelists next time.
Make sure you plug the holes that were asked to be filled in the room, before you re-enter.

VCDX Supporting Docs | Validation Plans

The validation plan in an important document for an architect.
Often a solution will be configured by a number of different providers, personnel, and external contractors
The lead architect still has a level of responsibility to ensure the design phases pass through to the actual configuration.
It should be possible to plan, prior to implementation,  a suitable method to prove the solution,  when  presented to the client, complies to the physical design.
The approach I took for this area in my successful VCDX documentation was to create a validation  strategy document for the solution that I could use to prove each of the  key areas from the VCDX blueprint.
This approach is more than just a selection of tests in a table for each of the settings I gave as design choices in the architectural document.
It was my attempt of showing evidence of ensuring  solution quality and how as a lead architect I would plan this phase of work with a number of testers.
Areas to consider
  • Scope of testing
  • Configuration items (i.e. settings applied etc)
    • Performance  (Load, transactions)
    • Recovery  (RTO, RPO,)
    • Security  (Pen testing, Scans)
  • Risks  (i.e. professional testers,  testers are the implementers etc).
  • Responsibility  (who tests what, owns the faults, and remediation tasks)
  • Entry criteria  (What is required prior to testing – Design docs, implementation  sign off?)
  • Exit Criteria  – This is the statement of quality, how many faults and how severe can they be,  i.e.>  S1- Show-stopper  a crash. data loss,  S3 – Minor issue – workaround.
  • Test Suspension  – Major faults which suggest meaningful testing cannot take place
  • Test deliverables – Test plans, Reports,  Fault logs etc
Test Cases
Ensure each of the track blueprint silos are covered and review the requirements to ensure each one can be proven.
Present each  test case in a easy to read format which covers ;
  •     Reference No
  •     Silo Area (i.e. MVCNS, Performance, DR)
  •     Test description
  •     Expected Result
  •     Actual Result
Validation and the defence 
Understanding and knowing these tests and your validation approach  will help you in the defence.
Q:     Are you sure you can recover from a failure?  How are you sure the RPO, RTO, SLA is met?
A:     This was validated using the documented  test  plan with successful recovery by a number of testers.
        Test plan reports were reported back to the client and  remedial steps taken to ensure there were as detailed in the physical design.
A Workaround for X number of test faults  were documented as standard operating processes and logged as part of regular health check reports.
Q:    Can you walk me through your process for this?
A:     High level process on whiteboard,  “This is also documented in my test plan and was reported back to the project team as part of the operational readiness phase”.
Useful links 
Documentation Examples 
Useful Book  for concepts  – aimed at networking silo

VCDX Supporting Docs | Config, Install, & SETs

The next submission date is approaching and a few people are asking how important are the supporting docs.
The design document is in my opinion the most important area, however it is just one area of the submission.
Once a design is created,  how does an architect prove the design meets the requirements in the real world?  How does an architect ensure the solution  is not an operational nightmare for other teams?
In large projects, it is quite common, for the architect to create the design documents and not actually implement the solution.
How does an architect ensure that the design is operationally ready?
This is where the supporting documentation comes in.
Installation & Configuration Documents
Depending on the type of company,  outsourcing or operational structure the level of detail in these documents vary.
Personally,  the approach I used for my successful  VCDX submission was a joint  installation and configuration guide.
To create a valid document I used the following approach.
  1. Assume some pre-reqesuite knowledge (cited in the auidence section of the document).
  2. Give a high level overview / component interaction diagram.
  3. Outline the order of configuration (Installation approach )
  4. Provide links or references to standard documentation (URLS provided  / exact pages)
  5. I did not  recreate the standard install information (no point its in the Urls provided)
  6. Provide the necessary configuration \ inputs  information to install the design components.
Put yourself in the documentation review panel position.
Would you want to read through install steps over and over again looking for information, or would you rather have a link to a doc and some clear tables / inputs to configuration items and installation approaches?
Configuration Areas Example Ideas.
  • Racking information  and Rack layout
  • Host Names
  • IP Config
  • DNS / NTP constants
  • Storage parameters  –
  •     cabling references / Ports
  •     Multipathing  configuration (PSP/SATP)
  •     WWN
  •     Initial Datastore configurations
  • Networking parameters
    • vSwitch mode
    • Port Groups
  •     SRM – Recovery plans and site link configurations
  • Virtual machine – template configuration
  • vROPS
    • initial nodes  and IPs
    • VIP

I’m sure there are other approaches to this area.

I’d recommend to make the documents your own. Avoid generic templates, and don’t just use the partner SETS and reference architectures. Inspiration yes – copying I would avoid it.

Is my project good enough for VCDX?

The VCDX certification is to many ‘validation’ of a skill set.  To others its a ‘certification’  that gives them an area to study for and aim towards.
Personally, I  think both are valid and there are blog posts are out there that discuss  this very subject.

Once you decide you are on the VCDX journey, its time to address “Is my project suitable for VCDX submission”.

Can you hit all areas of the blueprint from your documentation?  Is a common answer I have heard – but what does that mean?

 

Thoughts to consider  

  • Is your project  platform running applications that are in production and critical to the business?
  • Does it need specific personnel roles for access or user variants?
  • Did you have a specific SLA the platform was built to?
  • Was there a DR plan?
  • Did you have a specific speed / response or other metric to show performance was being satisfied?
  • Do you have metrics or sizing calculations?
  • Do you have an understanding of the business use case, challenges?
I am currently helping a few people with their VCDX preparation.  Some are early in the process, others are about to go in the room next month.
One thing I have noticed, is the similar thoughts and questions  from the  candidates that have yet to submit.

 

So from the blueprint, my design is missing key criteria?  Do I just make it up?

My design worked, it was running for a large enterprise. However, like most real life projects  I had challenges and business accepted aspects.

This didn’t complete all the silos in the blueprint originally. So I developed the  areas to make it a more complete design,  the key aspect for me was the real life use case to frame this approach.

Isn’t this just making it more complex? Adding on items?
I have heard this a few times, I thought so too originally. Now after the process, I   personally feel the  VCDX does require a level of complexity to show the skills of a designer.
Unnecessary complexity, no.   However, areas detailed  within the  blueprint are not unnecessary.
 
Does everything have to be VMware? 
No, my back up design was using technology from another vendor, so was my syslog and operational management  providers etc.    
 
Do you need to have SME knowledge of said vendor , product etc.

SME no , however beware  it is not a place to hide away key areas from questioning.  You will need to know details of data flow,  components and show how it integrates with the rest of the design.  

I thought the VCDX was real-life! This means it is not.

Depends on how you think.   It is in my opinion the way you should aim to design every project.   Life  and costs etc may get in the way and be deemed over the top, however the VCDX is also a showcase that you have the architect skills.  It is still a certification though.

Also a real life design with its unique challenges may not be the best example for all silos.

Personally,  I had a few designs to choose from. One was for a major sporting event, it was then turned off.  Back up retention and DR wasn’t really a big deal.
Great  use case, lots to talk about, but may not score well  for recoverability areas.
  
Most projects will be driven in certain directions, architects have a variety of skills – projects may need more of one skill , less of another. 
A VCDX must show they can hit  all  the silos.
 
What about my work , its all NDA?
Don’t break it,  The certification is about a methodology and showcases skills. Not who you did it for.
Change the names , IPs and personnel to protect the innocent. The use case will show though and the experience will make it easier for you to defend.
 
I have never completed  a full design before.  What about completely fictional?
Personally, do you really need completely fictional? 
I would have found the business use case,  the little tweaks and areas of risk assessment  petty tough  with no use case.   
Considering using  a place you have worked at,
    
Review the platform, perhaps look at creating a refresh design.
Maybe look at the physical workloads remaining  and consider making them  virtual.
Any new apps coming in ?  Consider virtualising them  as a pod and use that to start your design process.
 
 
I have both VCAPs,  lots of experience as an admin, but not really sure how to start the documentation?
 
Create a conceptual design  2 – 3 pager,  fill out the below headings.
 
    Vision / objective 
    Requirements 
    Constraints
    Risks (at least 5-6)
    Assumption 
    Constraints (avoid hardware, money etc)
    Conceptual and logical diagrams.
 

Send this 2-3 pager to a VCDX mentor and ask for an opinion.   

In summary, If you  have an interesting use case that can be used to display you have knowledge in architectural processes / datacenter technologies and  can be discussed for at least 20 minutes –  Go for it.
If  you are not yet ready, up-skill and you will learn loads.
No one was born with this knowledge –  get it down on paper and validate it.

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.