Chapter 6. The Design Scenario
“Design is a plan for arranging elements in such a way as best to accomplish a particular purpose.”
—Charles Eames
Showcase Your Skills
What do the best architects do when faced with a design problem? How do they adapt accordingly, when provided with new information? What type of qualities do they exhibit throughout the entire process?
The second phase of the VCDX Defense is the Design Scenario, which provides an opportunity for candidates to demonstrate their ability to gather requirements and apply them to a design. The candidate is presented with a set of design parameters and must use them to formulate a design. Here you are largely demonstrating that you know how to ask the questions to elicit the right requirements from the customer, even when the customer has not thought of all requirements.
Think of this exercise as a brief conversation with a customer, where you tease out requirements and supply design options. We do not expect you to complete the entire design; this is unfathomable for even the most experienced architects. You are expected to drive the conversation through all the relevant areas, per the goals of the scenario. This scenario is different than the Design Defense, where you primarily respond reactively to inquiries from the panelists about your design. As with all other phases of the VCDX defense, time management is critical to ensure that you cover the articulated design goals.
When you re-enter the room after the break, you will see two slides projected that provide contextual information for the Design Scenario, as shown in Figure 6.1. The moderator explains the rules and reads the design scenario aloud. Listen intently to the key points. The moment you begin asking questions, the clock starts.
Figure 6.1. Scenario projection.
Consider these key points for the Design Scenario:
• You have 30 minutes for the VCDX-DV role-play and 45 minutes for the VCDX-Cloud and VCDX-DT role-play.
• One to two contextual slides are provided.
• The candidate is the architect.
• The panelists are the customer.
Each scenario is unique, but all of them share common themes. They serve as a starting point for you to demonstrate your experience and skill set. No candidate approaches the scenario in exactly the same manner; everyone has a unique perspective on design. This small window allows the panelists to get an understanding of your thought process and design approach.
Viewing the panelists as customers sometimes throws candidates for a loop. This situation is exacerbated if the panelists happen to be comprised of well-known industry personalities. It is best to put aside your knowledge of these individuals and treat the scenario as a role-play. Do not assume that your panel knows everything, even if your panel consists of well-known storage or networking experts.
Don’t be afraid to ask questions during the design and troubleshooting exercises—the panel members are there to help you. —Duncan Epping, VCDX007
The goal is to demonstrate your consultative skills to the panel. This includes articulating key points, asking relevant questions, and, most important, listening and applying responses from the panel. Use the whiteboard to form your thoughts and approach. You must address several key design objectives. As with real-world situations, not all information is shared, and information provided might be unclear, confusing, or incorrect. As the architect, you must guide the customer to the desired target state.
Do not get caught up on any minor details that can lead you down an unproductive rat hole. Successful candidates have a constant presence of mind and know where they are during each step of the design process. Scrambling at the end to cover additional areas commonly occurs, but it is seldom beneficial.
Occasionally, the conversation might shift toward a spirited technological debate. It is easy to fall into this trap, but simply state your reasoning and move on instead of expending valuable time.
Panelist’s Perspective
Before the VCDX defenses, panelists review freshly created design scenarios that are specific to the defense. Some scenarios require each panelist to play a specific role; others allow for more improvisation. Ultimately, you have the responsibility of directing the conversation.
Panelists are responsible for providing the appropriate information when prompted, while evaluating your abilities. Experience is the key here. Panelists can clearly tell when someone performs this job function frequently, compared to someone who might have the technical fortitude but lacks customer-facing experience. If you are in the latter group, it’s still possible to achieve success—through extensive practice. When practicing, think about how to convey your knowledge and skill set to the panelists. Having that extra bit of knowledge or insight always helps.
The panelists are keenly interested in the design methods and perspective of the candidates. Reviewing and evaluating many different designs often yields new concepts, allowing the panelists to continuously refine architectural methods for virtualization and cloud computing.
If you feel some stress or angst, this is perfectly normal. Although the panelists try their best to create a natural environment, acclimating to the situation takes time. The panel’s goal is not to pose intentionally challenging questions, but to probe for information to create an assessment. They have all been through the same experience and understand if you flub a line or two. Focus on the task at hand, and the time will be over before you know it.
Design Scenario Examples
This section contains several example design scenarios that you can use for study sessions and mock defenses. Guidance is provided to spark ideas, but it is important to develop your own unique perspectives and approaches. Be creative and think about all possible solutions.
When you first see the two slides projected on the wall, you might feel that you have a lot of information to take in. Keep in mind that not all information presented could be relevant. It is your responsibility to isolate and extract key elements of the scenario. No single correct answer exists, and scenarios often change based on responses from the panelists. Stay calm, process one thing at a time, and focus on the immediate objective.
When the moderator reads the presented material, quickly internalize the key objectives and devise a plan of attack. You might find it useful to classify and prioritize key design inputs using the whiteboard to illustrate your thought process.
Design Scenario 1
Figure 6.2 shows the first slide of Design Scenario 1. Take a moment to read the provided content and think about the types of questions to ask.
Figure 6.2. Design Scenario 1, Slide 1.
Figure 6.3 shows the second slide, which provides additional contextual information, such as server count, configurations, and I/O characteristics.
Figure 6.3. Design Scenario 1, Slide 2.
Candidates often fall into the trap of diving into the technical details immediately. Take a moment to look at the broader picture.
• What are the business goals for the project?
• How would you define your success criteria?
• What are the target application use cases?
Slide 1 consists largely of technical requirements, and Slide 2 contains information on the physical server specifications. Don’t get too consumed with the amount of information provided on the physical specifications—extract what is necessary for your design. Use the provided capacity planner information to calculate the estimated number of target hosts. Although information about the application I/O characteristics is present, probing further into the types of applications could bring up additional information on SLAs or policies that can affect the design.
Requirements
Although this scenario explicitly declares the requirements, read between the lines to uncover additional hidden requirements. Questions to the panel can also result in newer requirements that conflict with the originally stated goal. Listen carefully and call out any discrepancies, just as you would if you were working with an actual customer. Some candidates take this a step further and begin prioritizing the various requirements.
The following requirements identified in the slides drive the discussion and design development.
R1: Reduce total cost of ownership
R2: Simplify management of environment
R3: Reuse hardware where possible
R4: Configure storage for optimal performance
R5: Explain the process of consolidation and containment
R6: Design for two-host failure, factoring in workload balancing
R7: Use best practices to create a design
Constraints
As with requirements, you have to tease out any constraints that impact your design. The slides give very little information on the data center equipment and topology of existing systems. Look for the gaps and decide what additional information you need to gain from the panelists. Be mindful of the clock, and ration your time accordingly based on the key design requirements.
The following are identified constraints:
C1: NetApp SAN
C2: New hardware (HP blades)
C3: Existing hardware for reuse
Design Whiteboarding
If you are not comfortable diagramming and explaining concepts using the whiteboard, start practicing now. Visuals are an efficient way of conveying a message in a time-constrained exercise. Consider these suggestions to leverage the whiteboard in this exercise.
1. Initial planning
• Methodology (topics to cover)
• Requirements
• Constraints
• Information gathered from panelists
• Scratchpad for calculations
2. Design
• Computing
• Networking
• Storage
• Dependencies
Design Methods
The most successful candidates have a standardized approach to framing questions and developing designs. When new information is presented, re-evaluate the existing design and make changes accordingly. Pay acute attention to the various perspectives, and have a keen awareness of design implications. The minutes tend to fly by quickly (ask anyone who has defended), especially if you do not manage your time properly. Have a strategy before you walk into the room.
Example Approach
1. Understand business goals and use cases.
2. Identify requirements and constraints.
3. Prioritize requirements.
For example:
• Design for two-host failure, factoring workload balancing.
• Select appropriate RAID levels.
• Explain the process of consolidation and containment.
• Reuse hardware where possible.
4. Ask questions to clarify gaps.
5. Diagram proposed solutions (covering applicable areas, such as computing, storage, and networking).
6. Validate and adapt the proposed solution.
Design Scenario 2
Figures 6.4 and 6.5 show the slides for Design Scenario 2. Again, take a moment to read the provided content and think about the approach you will take toward creating a design.
Figure 6.4. Design Scenario 2, Slide 1.
Figure 6.5 provides additional details on server count and storage requirements.
Figure 6.5. Design Scenario 2, Slide 2.
Let’s follow the sample method outlined in the previous scenario:
1. Understand the business goals and use cases.
“What problem are we are trying to solve?”
Although the scenario appears to be a server consolidation project with considerations for disaster recovery, asking about business requirements and use cases might elicit information that impacts the design.
2. Identify requirements and constraints.
Requirements:
• R1: Support virtualization of 200 physical machines.
• R2: Support future expansion to additional sites.
• R3: Reuse hardware where possible.
• R4: Design for redundancy and flexibility to enable future growth.
• R5: Explain the process of consolidation and containment.
Constraints:
• C1: Mixed environment of Intel and AMD processors
• C2: New hardware (2 CPU 6-core Intel servers, 32 GB RAM)
• C3: Existing hardware (1 Intel and 3 AMD servers)
3. Prioritize requirements
“If there are multiple problems, which one is the most important? How do they relate to or impact our goals?”
While analyzing requirements, note that R2 and R4 are similar, and R1, R3, and R5 are closely linked. This comes from just a cursory glance at the provided content. Additional requirements might emerge when interacting with the panelists. As such, restate the requirements as follows:
• Support virtualization of 200 physical machines, reusing hardware where possible.
• Design for redundancy and flexibility for future expansion to additional sites.
• Explain the process of consolidation and containment.
Now that you have restated and prioritized the requirements, you can begin the process of drawing out additional supporting information to formulate an initial design.
4. Ask questions to clarify gaps.
Not all the information is provided; the slides are merely a starting point. As with any customer engagements, methodically draw out the core requirements of the design. Examples:
• Are there any performance SLAs that must be maintained?
• What level of availability is required?
• What are the key workloads that will be converted?
• What is the existing networking and storage infrastructure?
• How will environments in multiple sites be managed?
5. Diagram proposed solutions (covering applicable areas such as computing, storage, and networking).
Split the whiteboard into sections, and begin diagramming proposed solutions for the scenario. Be sure to reference logical design characteristics, such as availability, manageability, performance, and security.
Computing:
• Cluster design
• Cluster features
Storage:
• Host-to-storage connectivity
• Storage features
Network:
• Virtual network design
• Physical network (if applicable)
6. Validate and adapt the proposed solution.
You are expected to take the lead as an architect and recommend a solution, but take time to validate key decision points with the panelists. Candidates have been known to get caught up in the moment and diagram an intricate design that doesn’t solve the core business issues.
Key point: Occasionally take a step back to ensure that what you are proposing matches the target end state.
Design Scenario 3
Let’s switch things up and look at how to design for a cloud-based scenario. Introducing cloud broadens the scope of the project, so prioritizing requirements is essential. Figures 6.6 and 6.7 provide contextual information.
Figure 6.6. Cloud Design Scenario, Slide 1.
Figure 6.7. Cloud Design Scenario - slide 2
Cloud requires additional components on top of virtualization to automate and orchestrate business processes. Although managing the amount of complexity introduced into the environment to achieve cloud capabilities is a persistent design goal, the method devised in the previous scenarios is still applicable.
1. Understand the business goals and use cases.
The primary business goal is to gain a foothold in the cloud computing marketplace through the creation of cloud services. The service provider wants to update its brand as a next-generation cloud computing service provider.
Initially, there are two offerings, a container-based offering and a pay-as-you-go offering. Each offering comes in a variety of sizes, as specified in the service definition.
2. Identify requirements and constraints.
Ask specific questions about the project requirements and constraints, to gather more information for your design. This scenario differs slightly from the previous two, in that the slides do not state the explicit requirements. Consider these examples of requirements that can emerge by asking questions on the necessary cloud capabilities.
• Requirements:
• R1: The system can scale to 5,000 virtual machines (scalability).
• R2: An API exposed for end users (integration).
• R3: Metering is required for accurate billing (chargeback).
• R4: End users can self-provision applications from a catalog (self-service).
• R5: The solution must provide 99.9% availability (availability).
• R6: Tenant data and applications must be isolated (multitenancy).
• R7: The system must address the virtual machine lifecycle (service lifecycle).
• R8: Efficiency of hardware must be addressed, to improve profit margins (resource pooling).
• Constraints:
• C1: Existing hardware must be used for the first phase.
• C2: A limited number of VLANs is available.
• C3: The budget must include resources for training administrators.
• C4: Legacy management and billing systems must be used.
• C5: 10 TB of storage is available.
3. Prioritize requirements.
In this case, the requirements are fairly distinct. Work with the customer to prioritize the requirements and understand the mapping to technology. The final result might look something like this:
• R1: Provide 99.9% availability.
• R2: Isolate tenant data and applications.
• R3: Expose an API for end users.
• R4: Ensure that the system can scale to 5,000 virtual machines.
• R5: Ensure efficiency of hardware, to improve profit margins.
• R6: Address the virtual machine lifecycle.
• R7: Use metering, for accurate billing.
• R8: Enable end users to self-provision applications from a catalog.
4. Ask questions to clarify gaps.
Further questioning is needed to understand how to design various components of the cloud.
Examples:
• Please elaborate on the security and compliance requirements. Which compliance regulations need to be supported?
• Based on the service definition, what types of Service Level Agreements (SLAs) will be maintained with the tenants?
• What types of catalog items are required? Base operating systems? Complete applications?
• Is it acceptable to provide isolation through the use of overlay network technology? Can the network infrastructure support this today?
• What are the eventual goals for the cloud-management system and multiple data center locations?
You might eventually get into details such as Virtual eXtensible LAN (VXLAN), storage profiles, virtual data center, single sign-on (SSO), and API extensions. If these topics exist in the design, display your understanding of them as they relate to core design choices. For example, VXLAN provides Layer 2 over Layer 3 capabilities, but it necessitates configuring multicast and increasing the maximum transmission unit (MTU) for endpoints participating in the VXLAN transport VLAN.
The Art of Explanations
Be able to articulate the rationale behind any statement that you make. Sometimes panelists appear to act like inquisitive two-year-olds to validate true depth of understanding. The key is to provide very succinct explanations that clearly articulate the reasoning behind a certain design decision. If you do not know the answer to “Why?” research the topic until you can back up the statement with confidence. Think about what you are trying to convey to the panelists, and what the clearest explanation you can use would be.
Statement: “Start out with allocation pool virtual data centers and pay-as-you-go. “
Why?
Answer: “Based on your cost constraints and service offering models, this gives you the capability to control overcommitment and provides flexibility for end users.”
How?
Answer: “Allocation pool virtual data centers provide the capability to set guarantees or reservations on the container, and pay-as-you-go allows deployment of resources up until a specified limit.”
An easy way to avoid this line of questioning is to preemptively provide succinct explanations for design choices.
5. Diagram proposed solutions (covering applicable areas: computing, storage, networking, and so on)
Split the whiteboard into sections, and begin diagramming proposed solutions for the scenario. Be sure to reference logical design characteristics such as availability, manageability, performance, and security.
Figures 6.8 through 6.10 show examples of design artifacts.
Figure 6.8. Cloud pod design, a cluster diagram showing separation of management and cloud resource group functions.
Figure 6.9. Network design, illustrating the virtual switch to physical networking component mapping and how traffic types are isolated.
Figure 6.10. UCS connectivity. Host-to-storage layout for the blade server system.
6. Validate and adapt the proposed solution.
Because of the complexity of cloud solutions, remaining organized and methodical throughout the process is vital. The number of components involved increases the importance of traceability. As the architect, you must be relentless in managing the requirements and mapping them to design decisions. In addition, time management is more challenging, especially when trying to determine how deep to go in each area.
Design Scenario 4
Figure 6.11 is a desktop-based scenario. The approach used should not be radically different, although the desktop focus has specific implications on design areas such as performance and security.
Figure 6.11. Desktop Scenario, Slide 1.
Figure 6.12 provides specific desktop statistics from an earlier analysis.
Figure 6.12. Desktop Scenario, Slide 2.
Use the process outlined in the previous examples to work through this desktop design scenario. We leave the details as an exercise for the reader.
Review
The Design Scenario is a role-play of an architect meeting with a customer. The VCDX-DV is 30 minutes; the VCDX-Cloud and VCDX-DT are 45 minutes in length. Two contextual slides are presented as a starting set of design parameters. You are the architect, and the panelists represent the customer.
During the defense, you must think aloud, interact with the panelists, and use the whiteboard to demonstrate your design approach. Consider the five phases for developing an architecture specific to a customer. Categorizing and prioritizing design inputs at the onset helps narrow the focus and clarify additional required information.
Use an approach that demonstrates the methodology you use. We provided the following as one possible approach as a checklist. Modify and adapt this accordingly.
[•] Understand the business goals and use cases.
[•] Identify requirements and constraints.
[•] Prioritize requirements.
[•] Ask questions to clarify gaps.
[•] Diagram proposed solutions.
[•] Validate and adapt proposed solutions.
Successful candidates demonstrate several common traits. First, they put in the effort to think through the questions that a panel was likely to pose and how to respond. Second, they studied the rubric to identify deficient areas and spend time strengthening those areas. Third, they practiced placing themselves in a defense-type situation that prepared them for the actual experience. Seek out opportunities to conduct design-type workshops to condition your mind for the actual experience.
Consider these closing tips:
• Think aloud: Contrary to popular belief, panelists cannot read your mind. A pause here and there is fine to gather your thoughts, but an extended pause makes us wonder whether you are thinking about dinner plans. Not articulating your thought process means fewer data points from the panel. When you encounter an unknown, think aloud.
• Focus on panelist interaction: Drive the conversation using a logical approach. Asking precise questions saves time by reducing the need for follow-up questions. Never assume that the panelists understand the underlying intent of the question. Be aware of all interactions with the panel, and ensure that the solution aligns with the business problems.
• Practice: Knowing something and being able to articulate it are two separate things. Deliberate practice and high-quality feedback help increase the signal-to-noise ratio.
• Relax: If you start to feel nervous, take a deep breath. Panelists will not ask you to do quantum mechanics or perform complex integrals.
Candidates often comment on how quickly time seems to elapse, especially if you get into a good flow. It bears repeating: Be organized and manage your time well. Think of the exercise as a dialogue among architects, and the experience might actually be enjoyable.