TheSaffaGeek

My ramblings about all things technical

VCAP6-CMA Design Objective 1.3 – Differentiate Requirements, Risks, Constraints and Assumptions

Leave a comment

Due to my decision to aim for my VCDX6-CMA this year and thereby to get it in in time for the only VCDX-CMA defence of the year (so far) I have signed up for the VCAP6-CMA Design beta exam. I’ve been working on a very large-scale vRA 6.2 project for the past 14 months and so I hope this experience of designing and building it as well as my preparations via these objectives breakdown (plus my study resources) and using some of my VCDX5-DCV knowledge will help me. So I thought I would slowly post up each objective for my own benefit but also hopefully help other people looking to pass the VCAP6-CMA Design exam (beta or GA).I will be consolidating all the objectives on my blog page here

Knowledge

Differentiate between the concepts of risks, requirements, constraints, and assumptions.

  • Firstly I’ll take it you know the definitions of Risks, Constraints, Assumptions and Requirements. If not I would recommend looking them up and there is great overview in the VMware recommended study resource around CAD’s.
  • We covered what requirements are, how you would collect them and how they needed to be concise and be mapped to the infrastructure qualities of AMPRS in objective 1.2. During the workshops and interviews you have done with the customer you will also have picked up that a number of their requirements will have been around using certain technologies or certain methods for the project.
  • A constraint is where the customer has asked you to use a certain vendors storage for example or that you have to use their existing network infrastructure. These are almost always non-functional requirements and your biggest challenge around this is understanding how the technology they have asked for you to use will impact the solution in a holistic manner. There are always constraints in a project and it is your job as the architect to record these and understand them and then determine if these are not going to meet what the customer requires from the solution (using a 1GbE network can be a severe one on a vRA design) , is a risk to the project (the existing storage you have to use for the project is end of life in 18 months’ time and the migration to new storage is currently undefined from the vendor for example) or it actually meets the requirements of the solution and is just a constraint.
  • Risks as I mentioned above are a fair portion from the constraints but also external risks such as the project is being done the arab emirates and there are seasonal sandstorms that affect the communications to the data centre or it can be down to personnel where the people from the customer due to maintain the project once you leave have never touched VMware technology before. I like to have a risk register where I record all of these, rate them on their severity (Low,Medium,High and Critical) and also the risk mitigation or if there is no mitigation then that the project sponsor or someone high up has accepted this risk. So to use my example of customers IT team having no VMware knowledge or experience they could mitigate the risk by sending people on the required training and that there is dedicated time allocated to them outside BAU work to work with the consultants building the solution to gain knowledge and experience as well as knowledge transfer workshops at the end of the project.
  • Assumptions are where you can’t get a definitive answer on something that the project relies on and so you have to assume that it will be in place for the success of the project. Assumptions in real life designs should be as minimal as possible as it is your job as the architect to try get clarification on any assumptions but sometimes you have to have assumptions for example that the storage solution purchased from vendor XYZ will be built and configured in a resilient manner to a production level standard seeing as you aren’t the one doing this portion of the design.

Analyze impact of VMware best practices to identified risks, constraints, and assumptions.

  • “Best practices” are a double edged sword but for the exam these are the gospel and knowing the VMware way of designing it is a must (which is what it was like in the VCAP4-DCD and VCAP5-DCD I sat) . This is fairly straight forward if you understand my points in the section above. VMware best practices are covered largely in the vRealize Automation Reference Architecture document and the vCloud Architecture Toolkit (vCAT) documents.

Given a statement, determine whether it is a risk, requirement, constraint, or an assumption.

  • Very much the same as above in that if you understand what assumptions, risks and constraints are then you can amp them no problem. I think they only let you choose one quality per statement so my personal rule of thumb was that if it was between a risk and a constraints I chose it as a risk. Referring back to what I said earlier where not all constraints are risks is where you can have this difference in the exam.

VMware Recommended Tools

The VMware recommended study tools for this objective are:

If you disagree with anything I’ve said above then please let me know and if I agree (I’m always open to learning) then I will update the posting. Now onto objective 1.4.

Gregg

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s