Summary = it’s doable but a long hard road.

Note: as with all my session notes this is a mix of what’s on the screen, what the presenters are saying, and my own thoughts. If something doesn’t sound like what the presenters would say, assume it’s just my opinion. 😉 Or ask in the comments if not sure…

Everything covered today relates to VCDX4 & VCDX5.

People on panel = Mostafa, Chris Colotti, and more that I didn’t catch.

More after the jump…

• Selection of a Design
  • The design you must submit for an infrastructure…
    • where business requirements drive design and implementation decisions
    • suited for mission-critical applications
    • in a managed environment
  • The design you submit may be partially fictitious
    • You must defend fictitious components as if they were real.
  • If your design is based on an actual project, you must have played an architect role in that project.
    • But not necessarily the sole architect.
  • vSphere must be the primary design component.
  • Side comments/questions.
    • to your benefit to submit a comprehensive design
    • focus/embellish on areas that are your strengths
    • you have 75 minutes….so put out a design that can fill up the time well
    • if you don’t present designs, practice presentation beforehand
    • anything you submit may come into question (i.e. if have View pieces in the design) — focus is on vSphere pieces but will hit on other pieces
    • if you submit a View desktop design, don’t focus totally on View
    • make sure that infrastructure has relevant resources to match the design in a real world, practical way (not just theoretically enough resources)
    • need to understand all components of design (hardware, infrastructure) even if you didn’t design those pieces originally
    • if submit a design with extra components, be careful that you don’t miss including the core design areas (that do affect your score the most)
    • don’t have to include specific products (example = vShield) but have to cover the general area (security)
      • Example: you wouldn’t get marked down for not including vShield but would get marked down if didn’t consider security at all.
    • If have older design and submitting it, consider how you would design it today when considering which products to add fictitiously.
• VCDX Process
  • Showing flowchart of how the process works.
  • Need to cite everyone who participated in the design (in case they want to submit the same design later on a separate application).
  • Can use solution toolkits but best to modify so it doesn’t feel canned and better understand everything you’re including (whether from the kit or your own changes).
  • The kits are not VCDX quality submissions – there are things missing in them and VMware knows what those are….you had better know that too.
  • This is not a technical defense process – we assume you’ve got the technical pieces by having passed the VCP5 and VCAP-DCA.
  • What makes VCDX unique – both very deep technical and very deep business mapping.
• VCDX Applications – Components
  • Completed Application Form
  • Signed Attestation and Statement of Conduct
  • Mandatory Documentation
    1. Architectural Design
    2. Installation Guide
    3. Implementation Plan – consideration for training, timeline and/or process for deployment
    4. Testing Plan – system-level testing, unit-level testing, do vSwitch setup make sense from an HA perspective?
    5. Standard Operating Procedures
  • Registration Fee
  • Ensure your submission is free of technical inconsistencies.
  • Side Comments
    • Andrew – Everyone does a lot with the Architectural Design…there’s a lot of space to show VCDX value in the Implementation Plan design.
      • Would love to see more creativity in the bottom 4 bullets below.
    • Remember that your design is your first impression to the panelists — better design in whatever way makes your defense easier.
    • All pieces above in one big doc? Doesn’t have to be….make it easy to follow. Some mention of splitting it into separate docs.
• VCDX Interview Day
  • Approved applicants are invited to interview.
    • Interview is on-site meeting with panel of VCDX certified architects.
  • Interview process consists of 3 parts:
    • VCDX Defense – 75 minutes
      • Deliver short presentation (15 minutes) that introduces your design. Call out highlights, unique good stuff, etc.
      • Answer questions from panelists about the design you submitted.
      • Provide further insight into your design decisions and rationales.
    • Design Scenario – 30 minutes
      • Demonstrate that you can begin to work through design issues in a methodical and logical manner.
    • Troubleshooting Scenario – 15 minutes
      • Demonstrate that you can begin to work through design or operational problems in a methodical and logical manner.
• VCDX Defense – Format
  • Panel
    • 3 Panelists – VCDX Certified, interact with candidate, record scores.
    • 1 Facilitator – ensures rules and timelines are adhered to.
    • Observers – VCDX certified, learning how to conduct defense, no interaction with candidate, assist in adjudication process.
  • Environment
    • Room with whiteboard, 1-2 projects, and presentation laptop
      • Personal laptops or PDAs not permitted in room
      • Bags stored in secured area.
  • Timer (only pauses between sections)
• VCDX Defense – What we’re looking for
  • From Conceptual Requirements to Logical Model
  • Differentiate between logical architecture and physical architecture (calls out specific vendors, brands, etc.)
  • Better to start with requirements, move to logical architecture, move to physical architecture/vendors/brands.
  • Map the above into one or more infrastructure design qualities…
    • Availability
    • Manageability
    • Performance
    • Recoverability
    • Security
  • Build relationship models among design entities to create solutions based on those mappings.
  • Side Comments
    • Constraints – make sure to call out constraints and how/where they affect things in the logical design.
    • Simplest way to know difference between logical and physical is that logical does allow you to swap vendors under the covers.
    • Logical design = capture business requirements of the customer, what’s important to the customer
• From Logical Design to Physical Design
  • Propose detailed specifications for the technology stack, showing the components’ mapping to the entities in the logical design.
    • Fault Tolerance stuff.
  • Virtual Machines – Including backup/recovery.
  • Compute Resources – Including hosts and clusters
  • Storage Resources
  • Network
  • VI Management
• Candidate Characteristics – show mastery of….
  • Do Design Work
  • Know how to implement and guide on that.
  • Identify and mitigate risks inherent in the design.
  • Complete, clear and organized technical communication.
• Tips
  • Before your defense session…
    • Make personal commitment to budget time for preparation.
    • Plan an working a minimum of 30-40 hours to complete the application and supporting docs (not including the design itself)
    • Consider forming study partnerships or groups.
    • Know your design thoroughly!
      • Review your design beforehand so it’s fresh on your mind.
  • During defense….
    • Use time wisely.
    • Allow for time in all design areas.
  • Talk and think out loud – panelists can’t hear what you’re thinking.
  • Use diagrams frequently.
• Design Scenario – Format
  • Design exercise role play
    • Given a situation/scenario that requires you to begin to architect a design.
    • During the scenario, the panelists are your peers.
      • Focus is on the journey to the solution, not finished design.
      • Think out-loud. Talk through the process to let the panelists see you work the problem.
      • Ask questions to gather additional information for consideration.
      • Go through the steps to demonstrate your strategy and thought process.
      • Try to follow a thread to build your deisng on.
      • Use diagrams.
      • You might not finish in the time and that’s fine.
  • Duration – 30 minutes total.
• More Tips
  • Sketch your ideas – walk through topology for the design on the whiteboard.
  • Think – Do I have all the information needed? What are the requirements, constraints, assumptions, and risks? Am I meeting all the business requirements?
  • Do – Ask questions! What is your strategy? What information do you need? What clarification? Is risk mitigation required due to some of the business requirements?
  • Don’t – Be silent as you work the design.
• Design Scenario – Sample
  • Poke at constraints, do they really need to be there?
  • What servers are dev vs. prod vs. QA? What SLA’s on the workloads?
  • What were the compelling events that caused you to start this project much less run Capacity Planner in the environment?
• Troubleshooting Scenario
  • Don’t necessarily try to figure out how to fix the problem (maybe) but definitely who should fix the problem.
  • Ask about what changed recently.
  • What is the PSP selection policy? Active/passive array? LUN trespass? Boot from SAN?
  • Start out with questions but try to have some kind of recommendation by the end.
    • Something on the whiteboard – diagram, thoughts, recommendations.
  • Don’t get stopped by short answers – I asked AV question and shouldn’t have taken the short answer.
• Other Q&A
  • Design Length – have had short and long pass. Explore constraints and what might need to change.
    • Really about having traceability through the whole design.
    • Need more details in the design than being short.
    • Don’t need as much time describing features and technology – “how DRS works”.
  • Include scripts –
  • Minimum size – doesn’t need to be multi-site but that helps. Make sure to use features on the blueprint.
    • 50 VM’s could work as long as you cover everything in the blueprint.
    • Most designs have reviewed have hundred’s of VMs and 8 or more ESX servers.