VCAP6-DCV Design Objective 1.1 on the #vBrownbag

The other week I saw the call to all VCDX volunteers for the vBrownbag series around the new VCAP6-DCV Design exam, so with exam closet to my heart I have volunteered for a few sections.  The first section I really wanted to cover was the Objective 1.1 as this was one of the sections that I really struggled with when I wrote the DCD 5.1/5.5 exam, however the due date didn’t leave me much time to prep a presentation deck.  So over the weekend I gave it the good old college try but was only able to get half way through the presentation due to the length of the chapter.  With that in mind I messaged Gregg letting him know I wouldn’t be fully ready by Tuesday and he gladly stepped up to the plate.  So me and Gregg ended up doubling up on this Objective and I think it really turned out well.  Gregg did a fantastic job and really hit home on the objectives from a design perspective, real world perspective and exam perspective, while I hyper focused on what the exam will focus on in the objective.  I think the mix between the two really filled in any missing holes and turned out really well.  You can see Gregg’s blog post below:

VCAP6-DCV Design Objective 1.1 on the #vBrownbag

With that said I wanted to give a quick break down of what was discussed along with a link to the video / slidedeck.  I’m going to try and finish out the slide deck and will update it when possible.

Objective 1.1

Associate a stakeholder with the information that needs to be collected
Roles you would need to talk to collect data that would shape your Requirements, Constraints, Assumptions, and Risks

• IT Director
• Network Engineer
• Storage Engineer
• Compute / Virtual Infrastructure Engineer
• CEO
• CFO
• CTO
• Manager
  • Applications Manager
  • Sales Manager
  • Office Manager
  • Infrastructure Manager
  • Network Manager
  • Storage Manager
  • Backup Manager
• Engineer
• End-User

Exam Use:  This section will be used or built on with further chapters.  This chapter is laying the ground work for interviewing the people required to pull out the requirements, constraints, assumptions, and risks to help develop a conceptual design.  In later chapters this will be built on and you will need to also pull out AMPRS (Availability, Manageability, Performance, Reoverability, and Security from these stake holders)

Utilize inventory and assessment data from a current environment to define a baseline state
What does the customer have, how do you find it?

How do we find this info and create a baseline:

• State Analysis
• Current Inventory
• Review documentation
• interview Stakeholders in the project

Tools used to accomplish this:

• VMware Capacity Planner
• Microsoft Map Tool
• Perfmon
• Powershell
• WMI

Exam Use: This section can be used in either a drag-n-drop scenario or a design scenario.  In most cases the exam will give you some form of State Analysis and given you requirements to design something new around that analysis.  An example of this can come in many forms, they could give you the analysis and put a requirement that the customer would like to re-use some of the hardware, or give you the analysis and have to do some kind of sizing assessment / calculations to fulfill the design requirements.

Analyze customer interview data to explicitly define customer objectives for a conceptual design
After the interviews with the steakholders define the Requirements, Constraints, Assumptions, and Risks to obtain the objectives to help construct a conceptual design.

• Goals
• Scope
• Requirements
  • Functional Requirements (Section 2.1)
  • Non-Functional Requirements (Section 2.1)
• Constraint
• Assumptions
• Risks

Exam use:  Like mentioned before in the earlier section you will most likely be given information from stake holders and you will be required to map those too requirements, constraints, assumptions, and risks.

Determine customer priorities for defined objectives
You will be taking the customers Goals, Scope, Requirments, Constraints, Assumptions, Risks, and defining their priorities / objectives.  This will define milestones which can be used to measure the success of the project and mitigate scope creep or help further solidify the scope of the project.

• Key Success Factors (KSO)
• Key Performance Indicators (KPI)

Exam use:  This will just merge in with the previous exam use examples.  When given information from the stake holders you will need to be able to extract the requirements, constraints, assumptions, risks, AMRPS, and Key Success Factors or objectives.

Ensure that Availability, Manageability, Performance, Recoverability and Security (AMPRS) considerations are applied during the requirements gathering process
This is best broken down with examples which I’m going to try and get out, however you will be required to be able to take stake holder information and break it down into AMPRS.  You will also need to be able match these up with your Requirements, Constraints, Assumptions and Risks.  Gregg has a good slide on this in his presentation.  An quick example below:

(R01) – Availability – Exchange/SQL System (Tier 1 Applications) availability is 99.5% of Year

(R03) – Availability – Tier 2/3 Applications availability is 99% of Year.

(R06) – Recoverability – Exchange/SQL (Tier 1 Applications) RPO is 6 Hours and RTO is 18 Hours

(R07) – Recoverability – Tier 2/3 Applications RPO is 12 Hours and RTO is 36 Hours.

(R08) – Performance – Support current mailboxes of 4500 users on Exchange VMs

(R09) – Performance – Exchange VMs should support 150 mail per user per day with avg. size of 1 MB/message

(R12) – Manageability – Reduce deployment time of any further required servers

(R13) – Manageability – Management and security concerns, Management Duties separation is required

(R14) – Security – For security concerns, DMZ is required to contain Web Servers Farm.

Exam Use:  You will need to be able to match stake holder information to AMPRS and or match your Requirements, Constraints, Assumptions, and Risks to them.  This is critically important when moving onto your VCDX design.

Given results of the requirements gathering process, identify requirements for a conceptual design
This section is merging all the previous tasks/sections together to form a conceptual design.  The key piece here is understanding what a conceptual design is and pulling out the requirements needed to create the conceptual design.  Later sections will get more into the conceptual, logical and physical design aspects, but a quick way to think of a conceptual design is a visual conceptual overview of the project.  This typically doesn’t need to be overly technical and really just outlines how your design will fulfill the requirements and other information you have gathered in the previous steps / sections.

Exam us:  This section will most likely be covered with the design questions.  The design questions give you a piece of information collected from a customer and than you have to build a design to fulfill the requirements.  This really pulls on all the information gathering skills talked previously in this chapter but most importantly pulling out the key Requirements, and Constraints for the design while managing your assumptions as the question will sometimes be ambiguous in some places.

 

Categorize requirements by infrastructure qualities to prepare for logical design requirements.
This section is asking you to layout your requirements by infrastructure to prepare for a logical design.  This is really laying the ground work for the skills that will be required in preparing your VCDX document, however this is a great design exercise that will allow you to manage your design decisions to your logical design per infrastructure qualities based off your (you guessed it)  Requirements, Constraints, Assumptions, Risks, and AMPRS.

• Networking
• Storage
• Recovery
• Compute
• VM
• Security

Exam Use:  Do to the way the Drag-n-Drop and Design tools work you probably won’t get hit directly on this, however they could ask something of you in a drag-n-drop or design question to line up your design decisions based on a logical design given on the infrastructure groups listed above.  This will however be another critical part of your VCDX design if you decide to go after your VCDX.

vBrownbag Video:

 

Slide deck: