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.

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.