Implementation plans for the vcdx documentation.

The VCDX is a validation of the ability to lead a project within a large enterprise.
A couple of questions popped up regarding implementation plan details  on Slack and I thought it was a perfect subject to delve into a little.

An implementation plan for the VCDX is the opportunity for the candidate to illustrate the knowledge of project methodology,  from conceptual to physical.

Depending on the scale and use case there will be specific phases with potentially multiple personnel or teams involved.

In many cases, a technical architect or technical professional will have this aspect created for them by a project or program manager.  Sometimes completely, other times the project manager will have a planning meeting to pull out the tasks into a workable process.

My take on this, for the VCDX process is, Imagine  you are the technical consultant advising a non-technical project manager to run the project from a business perspective.  What would they require to get started and run with it?

Within my documentation set, I created  a specific document which outlined;

Overview of project.
Service Description.
Project team & responsibilities
Staffing requirements and training needs.
Project Phases.
Project Schedule & Milestones
Project plan with estimated effort and  the dependencies – task view and gantt chart example

This for me was more than just a project plan printed from  Microsoft project.  It was a way to prove I knew the process of planning a design phase, and the movement to install, validation, and operationalizing the actual solution.

Each of my project phases were described from a business perspective with associated tasks.  Additional information added for operational management staffing requirements so a potential project manager could look for additional project resource if required at any time during the project.

From a real-life perspective this process and format is very useful for new projects where multiple project managers are looking for information, but are not completely familiar with the associated technology.

As a architect , even  if a project or program manager are  maintaining the plans, you are leading the platform from conceptual to physical to go live and day 2 operations.

Thank you again for the considerable time and effort…..

You have worked many hours,  spent time away from the family, lived the journey and made it into the defense.  You are even ok after the torturous 10 day wait time.  

Then you get the dreaded result of “ Unsuccessful”   

Most VCDX certified professionals will have failed at least once.  There is no shame in it ( Like that helps when you have just spent 6 months + on it).

Once the emotions have subsided, it’s time to regroup.

Thoughts to consider.

Documentation  – Was this your best work?  
Personally, when I was unsuccessful I tried to keep my full time work going, upskilling on new courses for my teaching and keep the kids happy.  So, on reflection it wasn’t my best work prior to the defence.

I thought, once accepted, I could make it using my defense.  
That just adds pressure. I needed to focus my efforts for making the defence a validation rather than making it a busy time to score points.  

Did you get multiple reviews of your documentation – technical and non technical?
When you are spending hours and hours on the same document set, you can become blind to the specifics. Simple, mutual exclusive settings may slip through that can be picked up easily by people with a fresh set of eyes.

Non-technical people should be able to understand your project  use case and give you an understanding if your design makes sense from a business point of view.

Having a single review from a VCDX or Non-VCDX is just one opinion.  It is still your documentation.  Get multiple reviews for your next submission.

Was all the feedback incorporated?
Sometimes you can push through and think you have answered all  the questions.  
Ask you mentor or reviewers to check that you actually answered their feedback in the revised documentation.

Did you get any surprises?
From your defence, did you find yourself struggling with one of the silos (i.e. Security or Networking).

Use this as a training plan for next time. Discuss this with the VCDX community on Slack or your mentor. We all have useful references that may help.

Did you mock with VCDX and non VCDX people?
I wasn’t successful until I focussed and mocked. I really didn’t like this kind of practice, but in hindsight it was required and helpful. Some of the best feedback I had was from candidates at the time. Do at least a day of rehearsals with time factored in to amend presentations and recover/review for upskill.

For the defense did you study the surrounding subject not just your design.
This is more of a soft skill aspect. By studying around the subject, listening to podcasts and “living in the IT community” you will find yourself being able to weave information, references, understanding of various areas while communicating. This helps with getting your message across to the panelists and validating your role as a lead architect. 

Could you whiteboard your whole design from conceptual, logical, physical perspectives?
In my opinion, if you can’t whiteboard it. You are not ready for the defence. Any area should be able to be summed up in a number of diagrams.  
Practice the diagrams on whiteboards so on the next defence you just flow.
Powerpoint slides take too much time to navigate and just looking at your documentation is not really active learning.  

A flowing whiteboard diagram, building up while explaining questions on content is much more impressive for validation of an architect.

Did you practice white boarding and questioning techniques for design scenario?

Depending on the track there are always reusable options and starting blocks you can use.
For the next defence, ensure you study and  deep dive on the main deployment strategies for your track and develop your own diagrams based upon this.  
Practice and practice.   In the defence you can use one of these as a starting point in your head.  

Plan a whiteboard strategy which gives you structure and illustrates a methodical way of working to show the panelists.    

Have at least 5-6 key questions in your head to ask for any design scenario.  Write down the conceptual attributes from these questions.

Armed with a process, some starting example diagrams for different situations and some probing questions will make you feel much more confident here.   You know how to start!

What next, when to  re-submit ?

Get a mentor, regroup and review.
You may want to go straight back in, because you you feel you  know what your mistake were.

You also may feel your documents are ready.

Consider spending a few weeks re-writing and weaving the feedback areas into the documentation.  

Get it validated and get ready to perform the next time.

Jumping on the the next submission date is again pressure, the submission date is normally a week or so after a result date.

Rushing to meet this you may lose an opportunity to increase documentation score. 

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 


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.