This is a question I asked my self many time throughout our preparation to the defense and we had several iterations of it before we got to the final version, how do I incorporate the business requirements into the presentation (By saying Business requirements I mean constraints and risks as well).
Ggenerally speaking the main presentation should be no more then 15 minutes, this is not enough to cover everything in your solution design ofcourse, not even close, that’s fine since the presentation is meant to give you and the panel points for discussion from which you can break out to your backup slides (we had 80 backup slides!). There a several good posts about creating your presentation which i used:
- Rene Van Den Bedem awesome VCDX blog - http://vcdx133.com/2014/04/24/vcdx-the-presentation/
- Derek Seaman post about the presentation has many good tips including a great example of how to create a good references to backup slides – http://www.derekseaman.com/2014/02/vcp5-vmware-vcdx-125-180-days-pt-2.html
- Josh Odgers – another great blog that I read in and out several times – http://www.joshodgers.com/
There are others as well but these are the ones i used the most.
But what about them busienss requirements? in my view they are the most important thing in your presentation and defense, this is how it is written in the VCDX blueprint and handbook:
The design you submit must be for an infrastructure…
where business requirements drive design and implementation decisions
suited for mission-critical applications
in a managed environment.
The “Business requirements” is not the first point here for nothing, A VCDX must show not only his or hers mastery of vSphere design, but most importantly that he/she is able to translate business requirements to the design in the best way, many times contradicting best practices, customer’s practices and the customer’s perception of the solution.
So, if this is so darn important then incorporating them in the presentation correctly will allow you to show how your design aligns to them and be able to reference them easily and clearly.
There are two ways to do this and i have seen candidates do both:
- At the beginning of the presentation have 1 or 2 slides that cover the most important requirements and constraints, this way you can explain to the panel the requirements, how you got them and how they drove the solution presented.
2. Weaved throughout the presentation it self, at the beginning of each section outline the requirements and constraints that drove the decisions outlined in the slide
a few things to remember:
- The panelists have read your design in and out, they know what’s in it so explaining the drivers for each decision and how they are aligned with the business requirements is the key to success in my view.
- Most of the technical information is in the backup slides, it is impossible to force all the technical details in the main presentation , but it is more then possible to have the business requirements and constraints in.
- You probably remember all of the requirements you put in but having them with a reference number like R01, C03 etc helps the panel look for them in your design if they need to or even eliminates the need for them to do that because you have it up on the screen, This allows them to focus on the questions and you to score more.
- If you have too many requirements and constraints don’t put all of them in the main deck. Have the most important ones in and have a backup slide with all the rest just as a reference if needed.
We chose to weave in the requirements and constraints throughout the presentation in each slide since it fit the layout of our deck, we aligned the presentation with the blueprint 1:1 and that made sense to us, your presentation might be different and each with his own approach.
The most important thing i can tell you is, being able to show how you aligned the solution with the customer’s business requirements is the most important thing for an architect, even more then knowing every knob in the software you are implementing.
Good luck!
Niran
links to other VCDX articles in my blog:
To VCDX with a fictitious design – Part 1 - Our VCDX Journey
To VCDX with a fictitious design – Part 2 – some lessons learned
Handling sub-optimal design decisions before the VCDX defense
How to create top notch VCDX application documents
