Adventures in Infrastructure Design – VCDX Defense Day

It is VCDX defense week and as part of my mentoring activities I organised a webinar with a number of VCDXs.   

I was very happy and honoured to have had the help from 4 recent VCDXs (Lior, Rebecca, Sjors, & Shady)  and 40+ attendees online.  

We covered final mentoring sessions, final study,  tips for the design defense and the design scenario.  

We finished off with a smaller session running  2 design Mocks (Thanks to Brian & Bali for doing this in front of  a few people online).   

Some of the content was recorded and I have clipped it together for reference.  (Click here to view).

The document Shady used to present is available here,  while my mind map on the VCDX design scenario is here. 

All presenters are mentors,  we have no knowledge on how the panelists score the defense.  We are just helping based on experience on our way to passing the VCDX.

Thanks for all you support.    Hopefully we can all get together again soon.  

The vcdx presentation deck

As part of my mentoring activities, with the defense week approaching I have been reviewing a lot of slide decks.

Now I have seen quite a few , have experience of my unsuccessful approach and my final successful defense I thought it may provide some value to review the process in more detail as a mentor post.

As normal the first place to review is the VCDX blueprint.

This document provides the context , it states,

Concisely explain the design and justify the decisions made to create it”.
(Plan on spending no more than 15 minutes on this part.)

In my opinion, considering the above,

The VCDX slide deck is,

* A secondary presentation and defense aid
* A place to help you provide evide details and save time
* An area to show off your skills as an architect
* Provide some reminder of contents, main point prompts

However, the slide deck is not ,
* The main aspect of the design defense
* Going to have all the answers the panelists ask
* A sales document
* A typical customer facing document (the panelists are peers).

Once your design submission is in the hands of the technical reviewers, you have to spend time ensuring your know your design and plugging gaps in your knowledge or design weaknesses.

Do not waste time making fancy graphics and sales slides.

So , you are faced with a blank slide deck ahead of you, what do you do?

Have a story for your presentation.

In the real world, as a lead architect you will often be asked to just present the current thoughts and areas of a design, whether it’s at the end or in mid-flight.

You may need to

* Get the project team engaged,
* Bring  them back from a destraction that is not delivering requirement value
* Fixing a misunderstanding
* Preparing for a big activity (DR, audit, sponsor review)

As someone who knows your design better than anyone else, you should be able to

* Whiteboard on the fly key areas (i.e. Logical Components, data flow, dependancy relationships).
* Explain why a certain area was chosen for the project.
* Explain the alternatives
* Show the impact to the business , teams, and technology.

How do you prepare for this?

Start by, taking each area of the blueprint,
Create a couple of whiteboards and just think about talking for 2 minutes about them freely.

Review details about design choices, impacts and risks for each area

This is where you want to get to. For any section of the blueprint, you should be able to just chat about it freely.

The slide deck is an added benefit to give you some reminders of the areas you ar covering or useful diagrams.

Don’t rely on the slides having all the words, make it feel natural.

You may hear “You have to control the audience “.

That means, to me – get them engaged and keep them interested.

The more questions the better, its not that you have made loads of mistakes, its an opportunity to get more points.

I have seen a fair few people plan their presentation around the PowerPoint slides.
The risks with this approach for me is “You will not know if you will make it through your slide deck without being asked questions”.

This is not VMworld and questions are not just at the end. It’s a technical conversation.

When you have a story, and you are interrupted or questioned in depth within the defense, you can go back to the story and carry on. Otherwise you may get side tracked, cost yourself some valuable time, look like you have lost control and miss key areas.

At a minimum , go through the blueprint and have a slide per objective – covering the blueprint is imperative.

If you have a slide that does not directly answer something from the blueprint – ask yourself why you are bothering?

Consider practicing without slides and use the whiteboard for everything. This can help consolidate approach and evaluate your understanding of the design

Summary Tips
1. Less text is better – simple, easy to read colours.
2. Think Conceptual, then logical –  Design Choice, Why, Impact, Risk, Migitation.
3. Don’t worry about a nice “About  Me” page – the panelists know who you are. Give a quick hello and move on to score points.
4. Check each slide – if it’s on the blueprint – fine. If it’s not – Delete it
5. You are using the slide deck to prove design skills – not documentation or reference info. It is design choices, and impacts for infrastructure that is being reviewed.
6. Create a way of moving between the slides – bouncing between areas (I like a Small menu on each screen).
7. Practice delivering this slide deck on webex or other recording – remember 15 minutes
8. Review the slide deck – check for inconsistencies with design
9. Cover the weakness or risk areas of your design specifically – dont hide – show how your overcome these areas , just like in real life.
10. Have a couple of  summary diagrams for logical and physical to refer too when answering questions. This could save time
11. Don’t spend hours on the slides when you could be studying the design
12. Do not use the phase “I have a slide for that, erm erm”.

Preparing for the VCDX Defense Design Scenario

I am working with a small group, preparing for their VCDX defense and it’s mock time.
 
Although the majority of mocks tend to concentrate  on a specific candidate design submission,  there is another area for the VCDX candidate to prepare for – the design scenario.
 
This is an important area to show to the panelists that you have skills to lead a customer facing  design  workshop, and create a design from conceptual to physical solution.
 
Basically, get up and do a bit of adhoc design!
 
In the design defense section, the panelists are your peers.  They are their to validate you and ensure you have given evidence on the day combined with submitted documentation that you can go and lead a real life project.
 
In the design scenario, it is a little bit different,  you  are the lead architect and working directly with a  customer (portrayed by panelists).
 
You are there to be polite, courteous, clear and show understanding (soft skills).  However you also have a job to do, get the information for a design workshop and potential proposal post workshop meeting. All within a constrained time limit.
 
Develop your presentation and “go to” architect skills – it’s quite common in the real world to be given minutes to be on a sales call, technical review sessions or business meeting,  if  this is not a normal day to day task for you, it an area for  your development on the vcdx journey.
 
Start to develop a set of probing questions, have them ready  In  your head for the defense.
These questions should  and could be used for any solution, not just the VMware technology track you are working on. This approach is aimed to provide immediate structure, hit scoring areas, and get the conversation going.
 
These will quickly become your go-to questions which can give you  a picture of a potential solution or thought process (See Rene’s great post of go-to designs – you need to develop your own  based in experience and VCDX track).  
Try and cover all areas of the blueprint within these base questions.
 
A few thoughts that spring to mind, 
 
High level  and business 
  • Type of application?
  • Data loss / service tolerance ?
  • What’s main concerns for client
  • Skill set of personnel now?
  • Current contracts and vendors ?
  • Datacenter locations and connectivity ?
  • Appetite to change / any other areas?
  • Key milestone dates for business
  • Brand awareness of application
  • Competing projects?
Lower level 
  • Understanding of data flow of application
  • Components of the app
  • Sensitivity to areas (latency, location -layer 2 adjacent, IP changes , licensing, interoperability)
  • Support requirements (replicate in physical )
  • Integration points – physical world
  • Types of existing controls and methods. 
Use the  whiteboard 
This is an important area.  When I was unsuccessful in my VCDX Journey, I failed to use the whiteboard and got distracted in  the process.  When I was  successful, I created flowing whiteboard diagrams while developing  questions and progressing.  This, in my opinion, is an extremely important skill for the VCDX and really builds confidence.
 
How do you develop this?  Especially if this is new to you, and you have a few weeks before  you are in the room?
Using the questioning technique above, give  feedback to the panelists to ensure that you know the relevance of the question and why you are asking (they will already know – they need to see you do and you are in control).
 
 
Show  a methodical way of working & divide the whiteboard into a structure that suits you   
One example of a structure I like to use now in real life is shown in the quick whiteboard image above.
The blueprint areas (AMPRS and MVCNS) should be covered, showing conceptual, logical and if you are doing well elements of physical (you may not finish this scenario in reality).
 
Consider
  • Creating a simple conceptual diagram,
  • Call out requirements,
  • Call out constraints.
  • Identify  Risks.
  • Show appreciation for security,
  • Show operational impact
  • SLA impact –  Back up and recovery areas.
Follow and develop  in same manner for logical areas going deeper for each silo area.
 
If the customer (or a panelist) changes their mind, or contradicts themselves.  Show you have noticed it, show impact to the design at that point, verify that’s the driver or show you are  assuming that’s the driver, and illustrate the resulting  approach difference.
 
Overall Tips  to Consider.
  1. Unless asked, keep conceptual and logical.  Physical can be referred to in a later workshop  or discussed once you have hit the areas.
  2. Cover all areas of the blueprint – Practice this.
  3. Ask probing questions to pull out requirements, constraints, Risks and assumptions – Show a method on the whiteboard how you gather them
  4. Try and draw one conceptual high level  diagram at first  –  refer to this with questioning to expand
  5. While covering each area of the blueprint  try and draw at least one  individual  logical diagram.
  6. Don’t forget about operational management thoughts – i.e. standard operating procedures you may need, changes in team structure and potential training requirements.
  7. Control the room, but be polite.
  8. Create lots of clear but basic diagrams on the whiteboard
  9. Give explanations of not what and which button, but why, the impact and thought process throughout – its a design certification.
Useful links
Rene Van Den Bedem – Go-to designs 
Simon Long – Common  VCDX mistakes  
 

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.

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.