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.
- Unless asked, keep conceptual and logical. Physical can be referred to in a later workshop or discussed once you have hit the areas.
- Cover all areas of the blueprint – Practice this.
- Ask probing questions to pull out requirements, constraints, Risks and assumptions – Show a method on the whiteboard how you gather them
- Try and draw one conceptual high level diagram at first – refer to this with questioning to expand
- While covering each area of the blueprint try and draw at least one individual logical diagram.
- Dont forget about operational management thoughts – i.e. standard operating procedures you may need, changes in team structure and potential training requirements.
- Control the room, but be polite.
- Create lots of clear but basic diagrams on the whiteboard
- 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