SWVMUG Presentation – vROPS & VLI – Its Installed now what do I do?

Recently I was invited by a fellow vExpert friend of mine Simon Eady to present at the SWVMUG session on a requested topic of vROPs and vLI.

I have been spending my time on these products  within a couple of client projects recently  and they are discussed regularly in VCDX mentoring sessions. 

Most technical how to content is already covered in detail by VMware and the wider community.  

I  took the approach of the day 2 operationalising  for the business and design validation / risk mitigation.  

This is an area that is useful for the real world and the VCDX submission.  

I created a few slides, new design  mindmaps for vROPS and vLI and a quick demo.  

These  are available here for anyone who finds them useful. 

Thanks very much to Simon and the team for having me.  A great venue, nice people  and lots of good chats on the subject.

 Hopefully  I will get the chance to visit again soon.

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.  

Adventures in Infrastructure Design – Regular Webinar

Since passing the VCDX,  I have been helping out a lot with mentoring.

I enjoy creating blog posts, running mocks and completing design reviews. 

It is especially rewarding to see the change in design approach  and improved skillsets as people travel through the VCDX process.

As my time is  a little limited with work, and family.  I will now be running a regular  webex session on all things Infrastructure design incorporating VCDX mentoring.

This session will, at times be primarily aimed at the VCDX journey, with mocks and process discussions.  

However,  I will also be looking to discuss anything related to infrastructure design (Partner solutions,  vendors,  use cases, etc).

The biggest reward from mentoring is the continued learning process I have found myself in.  

To remain useful,  I need to understand the technologies the candidates are working with and how they relate back to  design.

I thought this material may be of interest to other people in the field and start some good discussions along the way. 

To register your interest in the first session on May 9th  please sign up here.

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