VCAP5-DCD Official Cert Guide: Introduction to Technical Design

Date: Aug 20, 2013

To help you prepare for the VCAP5-DCD exam, this section explains what a technical design is and why it is important to the end solution, what happens at each stage of the technical design process, and what should be produced as part of a technical design. These topics cover Section 1, “Create a vSphere conceptual design” from the VCAP5-DCD 5 blueprint.

Technical design requires completely different skills from the troubleshooting and maintenance tasks commonly carried out by experienced IT professionals. The role of a technical designer or architect involves communication skills, technical knowledge, and a certain amount of artistic flare. This chapter will take you through the terminology and process of technical design. The concepts discussed here can be applied to any project, not just a VMware-related solution. By understanding and working with a design process, an engineer can integrate with other business and technical professionals and provide valued input to a business project.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter or simply jump to the “Exam Preparation Tasks” section for review. If you are in doubt, read the entire chapter. Table 1-1 outlines the major headings in this chapter and the corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know Already?’ Quizzes and ‘Q&A’ Chapter Review Questions.”

Table 1-1. “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

Foundations Topics Section	Questions Covered in This Section
What Is a Technical Design?	1, 7, 9, 12
The Technical Design Process	2–4, 6, 10
Project Deliverables	5, 8, 11, 13

Which of the following is a design methodology?
1. A set of best practices for the technology
2. An iterative process used to produce a technical solution
3. A project proposal that shows the advantages of new technology or the latest upgrade
Which of the following is a project risk?
1. The technology is over three years old.
2. The technology is cutting edge.
3. Both a and b.
Who sets the vision?
1. The board and business professionals
2. IT staff
3. A proposed vendor
Who generally sets the scope?
1. Business staff
2. IT staff and business staff working together
3. The proposed vendor
Which of the following is true of a project requirement?
1. It must be satisfied.
2. It is for advice and observation only.
3. Both a and b
You are working on a project team tasked to migrate a platform between two datacenters. Which of the following describes a design methodology?
1. A set of best practices for the technology
2. An iterative process used to produce a technical solution
3. A project proposal that shows the advantages of new technology or latest upgrade
Which of the following describes a best practice?
1. Dictated by the vendor as the way to do something
2. Continuously evolving
3. Static
If changed, which of the following may affect the logical design?
1. The server vendor
2. The type of replication from synchronous to asynchronous
3. The IP addresses of the servers
A project vision may be a long-term goal, and it may be achieved after several iterations of a project life cycle.
1. True
2. False
Which of the following is a constraint on design?
1. The VDI platform is dependent on a stable network, which is not managed by the internal network team.
2. The VDI project has a small budget.
3. During a migration project, the destination datacenter has not been completely finished. It is currently three months behind schedule.
The number of disks used in a storage array is detailed in the physical design.
1. True
2. False
You are the technical lead in a vSphere 4 to vSphere 5 project. The platform is currently using a supported NFS storage device. There are no plans to upgrade or change this device within two years. Which of the following is correct?
1. This is a risk to the project.
2. This is a design constraint.
3. This is a design assumption.
Best practices can be used as guidance in a design, assuming that the requirements are satisfied.
1. True
2. False

Foundation Topics

What Is a Technical Design?

A technical design is a way of communicating an end product or solution. By creating a technical design, a group of people can work together to create a final solution.

A design methodology is a multiphase process used to direct a technical design process. A design process is:

Iterative
Involves other people
Helpful and necessary to the success of a project

Where Do We Start? What Are We Doing?

These questions are asked not only in the classroom but also during real projects. Skilled engineers are accustomed to some form of guidance, such as a vendor best practice or a design document from an experienced consultant or architect. How are technical designs constructed? How does an engineer bridge the gap between engineer and architect/designer?

What Makes a Good Designer?

I have asked this question in a number of training courses. The following are some examples of responses:

Expertise—in-depth technical knowledge
Experience—someone who has implemented the technology previously
Good communication—a technical expert who can talk to nontechnical people

From my own commercial experience, I know that a good designer is someone who can:

Accept advice from other members of the team and other stakeholders
Be flexible to change and understand that the end result is the required aim
Acquire new skills rapidly

Most importantly, however, a good designer questions everything!

For example, say that a technical designer working on an application migration project interviews a senior user who spends 40 hours per week operating a data processing application. The user has data delivered to him weekly as a zip file. He unzips the file, counts the number of uncompressed files, and takes a copy for an archive and uploads it into the system. He stores the zip file in one folder (original) and keeps a copy of the unzipped files in another (imported data).

The designer establishes that this method is viewed as the accepted process—the company best practice, which has been developed over time by an experienced member of staff.

A technical designer would probe this process from various angles, asking questions such as: When is the data required? Can the zip file be stored and unzipped when required? Is it possible to work backward from the result of the data processing?” The zip file is a smaller copy of the processed data after all, and even a designer with no experience with the software at the user level could save the company time and money by taking a step back and questioning the process—even if it is an accepted one.

A Familiar Scenario...?

Suppose that a company’s CTO calls his team into a meeting. The CTO looks enthusiastic and says, “I’ve just had a meeting with the board. Our competitors are gaining on us. We need to deploy our services more rapidly, without lowering the quality our customers expect. The web applications are needed now rather than next quarter.”

The CTO continues, “I need the platform guys to continue to support the production system but work smarter, so you can spend more time with the development team and investigating new technology. Developers, I am depending on you to produce our new software on time. Automate it all. You are the top team! If you make this work, there will be no more late nights in the office! And one more thing: Nobody mention a budget!”

The CTO leaves the room, the dust settles, and the project team looks at each other. Now what?

The Technical Design Process

Try typing “design methodology” into a web search engine. You will be presented with numerous versions and definitions. Some of these definitions are standard, but some are company specific. VMware, for example, has developed its own methodology, called VIM, for Virtual Infrastructure Methodology.

Each methodology has various pros and cons, but all have similar phases:

Information gathering—This is where a problem, vision, or goal is described; requirements are detailed; users are interviewed; and factors affecting the project, such as risks, constraints, compliancy, and cost are highlighted. Analysis of the current state of play is carried out.
Solution development—This phase uses the information gathered from the previous phase to produce a detailed solution.
Implementation and delivery—This stage utilizes the detailed plans from the solution development phase, and the solution is produced.
Review and manage—During this frequently forgotten part of the technical design process, the project and solution are discussed to ensure quality and continuous improvement. Issues such as ongoing maintenance and operational management can be addressed here.

The basic components of a good design are:

Vision
Scope
Requirements
Constraints
Assumptions
Risks

Vision

The vision component represents the actual idea—the light bulb over the cartoon character—and is the whole reason for a project. The vision must, therefore, be kept at the forefront throughout the project.

The vision may be ambitious, such as “Automate everything.”

The project team might never actually achieve the original vision; costs, risks, and constraints could prevent it. The vision is the end goal; however, without a vision, a project may evolve into something else entirely.

The vision is normally set or controlled at the upper management level, and it is, consequently, a business-driven attribute rather than one driven by technology.

Scope

The scope is a quantitative statement of what is included in a project, or, more pertinently, what is not included in a project.

While virtualization consolidation projects may have several phases, instead of trying to virtualize every machine in the company in one go, the scope would specify quick wins or good, critical, or high-priority candidates, allowing for progress on the project while establishing implementation methods.

The project requester normally creates the project scope, but he or she further develops it by working with other members of the project team, such as IT management.

Requirements

A requirement is an attribute that must be achieved; for example, the solution must comply with the company’s security policy, the current security policy specifies that any web-facing application servers must be separate from internal application servers.

Requirements affect design choice substantially.

Constraints

A constraint is an attribute that may limit a design choice, and it could be technical or business driven. For example, in a datacenter migration project, the storage vendor has already been decided due to existing company vendor relationships. This choice means that data de-duplication technology cannot be used, as it is not available from the preferred vendor. A greater amount of network bandwidth would be required to synchronize data between the two sites.

Consider the applications running on the new virtual platform; a requirement states that these applications must remain supported by the application vendor. If the vendor does not support applications running in VMware platforms, the application may have to remain running on physical machines.

Assumptions

An assumption is something that has been decided to be true for the project design but that has not been tested nor verified.

Say that a company requires a new remote working solution. It creates a project and assembles a team. The current solution, a VPN, is provided by an outsourcing company. This service was already in place before a firm-wide agreement of telecommuting was in place. The contracts in place prevent renegotiation of service until next year. There is, however, no reason to expect an issue as the availability and performance of the VPN have been acceptable. Therefore, a suitable assumption could be “Sufficient network bandwidth to support 500 concurrent VDI users is available via the existing VPN solution.” It could be difficult to accurately predict the amount of network bandwidth required and the work patterns of the proposed service once in use.

Risks

A risk is an attribute that could prevent the completion of a project or change the project design considerably.

Risks can be pretty easy to spot. For example, say that in a datacenter migration project, one datacenter is being demolished, and another one is being constructed. The company has to move in any case, and it is starting the application migration project before the destination datacenter is available. If the availability of the second site is delayed, the project will be affected substantially. This is a risk.

A less obvious risk would be using cutting-edge technology. Has this been done by someone else, on this scale? If not, it may not be the best solution.

Project Deliverables

Depending on the size and type of project or the organization where the project is being carried out, the items that are delivered from the project process will vary. They could include the following:

A high-level design document (HLD)
A quick one-pager
A proof-of-concept solution
An implementation or configuration document
A test or verification document
Support documentation

At a minimum, it is useful to always have a short HLD that explains the approach. In addition, a quick one-pager or a data flow diagram is an invaluable reference during project meetings and defenses. A good example of such a diagram is an exit plan affixed near the elevator in case of fire or other emergency.

Talking through a design with a CTO is a completely different task than talking through a system with another designer or a technical resource. The technical details of the design have to be pitched correctly; you must present useful information with sufficient detail to ensure comfort in the project or confidence in the design.

If a suitable level of communication is not achieved and maintained, there is a danger of confusion, scope creep, and an unsuccessful project.

Building a Realistic and Executable Plan of Approach

Following the information gathering phase, you can devise a realistic time frame and approach for the project. A key question to address is whether the project will be delivered in one big bang or in smaller, more manageable phases.

For example, in a recent vCloud project, I was required to deploy a secure and scalable hybrid cloud platform to release various e-discovery applications. It was possible, of course, to plan to make all applications available to users simultaneously, releasing nothing until all the project requirements were met. This approach requires a huge investment in terms of technical hours, and if the finished application does not meet user expectations, you have to start over.

A less risky approach is to separate the requirements into phases, with each phase working toward the vision. In the vCloud project I worked on, we used the following phases:

Vendor selection—In selecting the VMware datacenter hosting provider, we considered the requirements detailed in the information gathering phase.
Proof of concept application—We produced a proof of concept based on the solution design. The application the users were most familiar with was selected as the first candidate, and it was used to establish the process for verification and validation of the design.
Production deployment of application—Based on the lessons learned from the proof of concept, we released a single production application.
Integration and management—We implemented the support and operational management requirements.

Once phase 3 was complete, additional applications were deployed, using the processes developed from the first live deployment. Gradually we released all applications and created a full production platform with associated management and integration tools.

This phased release approach gave comfort to the business sponsor, who was able to witness regular application releases on a tight schedule. This staggered approach provided the opportunity for continuous platform improvements from one release to the next.

General Guidelines for a Good Technical Design

Although every project is different and depends on several factors, a good technical design should:

Be simple and easy to reproduce
Be scalable
Be cost efficient
Be fault tolerant
Have a total cost of ownership that the business can achieve
Be supportable

One useful addition to every technical design is a section that justifies the design choices and references the original requirements, constraints, risks, and so on. This extra information demonstrates to the business project sponsor that all the requirements have been seriously considered, and it also assists the designer in validating his or her thought process at the next project iteration.

Learning from Experience

How do you know if a project has been successful?

Early in my career as a Windows engineer, I worked on many Microsoft Exchange projects. Microsoft Exchange can be deployed in various ways, and it does have some great functionality. For instance, I remember well the excitement surrounding the release of Outlook Anywhere, and the massive impact it had. Users were suddenly able to double-click on an icon and check email without a VPN! The underlying system, however, was not completely fault tolerant, and the single points of failure were unlikely to satisfy uptime requirements if they failed.

This is an example of a project evolving from “Building a highly available messaging solution for the company based on a standard supportable platform” to “Enabling users to access email from any location without the use of a VPN.”

As you work on a project, ensure that at every stage of the project, the vision and requirements remain in clear view. It is easy to lose sight of the vision or goal and fall prey to scope creep. Both the vision and requirements should be clearly defined and not open to interpretation.

Measuring Project Success

“That will do.” This everyday saying makes many people shudder; however, it can be very true with technical design.

A company needs a sensible design to be delivered on time and within budget, and it needs the design to meet requirements while observing risks and assumptions and operating around constraints.

“True perfection has to be imperfect; I know that sounds foolish, but it’s true.”
—Noel Gallagher

Your project may be far from perfect, but if it meets its vision while respecting all requirements, then it can be regarded as a success. Any imperfections can be fixed either as a business-as-usual exercise or during a period of stabilization.

Exam Preparation Tasks

Review All Key Topics

Review the most important topics in the chapter, noted with the key topics icon in the outer margin of the page. Table 1-2 lists these key topics and the page number on which each is found.

Table 1-2. Key Topics

Key Topic Element	Description	Page
Paragraph	The Technical Design Process	7
Paragraph	Building a Realistic and Executable Plan of Approach	11
List	General Guidelines for a Good Technical Design	12

Design Scenarios

Create your own standard templates for a high-level design process:

Write down the components of a design process as headings in a document.
Think of a project you have worked on as an engineer. Fill in each component area with bullet points to consider. This is the start of your HLD.
Start to flesh out the HLD. Add more detail, such as what your company’s security policy specifies with regard to encryption, uptime, and so on.
Use the HLD to create a one-page summary of the project. Construct a diagram of the solution. (Logical and physical designs are discussed in Chapter 4, “Developing a Design on Paper and Delivering It Physically”)
The skills needed for these tasks are assumed in the VCAP5-DCD exam.

Definitions of Key Terms

Define the following key terms from this chapter and check your answers in the glossary.

Vision, Requirement, Constraint, Risk, Assumption

Read the Technical Material with a Designer’s Hat On

No specifically defined or examined design process exists for the VCAP5-DCD; you must adapt a suitable one with which to work throughout your exam preparation.
Study the recommended reading on the VCAP5-DCD blueprint, ensuring that you work to the latest exam version; slight changes in documentation or content often appear without warning.
Although the VCAP5-DCD exam is a highly technical one, try to look past the technical facts and consider the impact of the settings or functionalities. For example, do not simply memorize the requirements for vMotion but consider the effect of guest virtual machines not meeting those vMotion requirements. Will the cluster become imbalanced? What is the importance of initial guest placement? What affect will DRS have?
Know the VMware design terminology. Technical knowledge is great, but this exam also requires you to understand business requirements. If you don’t have experience with design work, remember to ask questions such as, “Is this the best way? Is it still simple? Is it required? Does its meet the requirements?”

Review Questions

The answers to these review questions are in Appendix A.

You are working on a hybrid cloud project, where production applications (yet to be fully developed) are to be deployed. Which of the following is a project requirement?
1. The production data must be in the UK at all times.
2. The hosting partner provides sufficient resources, without overcommitting, to support application load.
3. The hosting provider meets uptime expectations.
4. The development team provides the software on time.
In the project life cycle, who defines the vision?
1. The IT architect
2. The software vendor
3. The business
Which of the following describes an item that is taken to be true at the design phase but has not been tested prior to execution?
1. Requirement
2. Constraint
3. Assumption
4. Risk
You are a virtualization consultant working on a disaster recovery project. You have proposed a solution that uses SAN technology to replicate production virtual machine files. This meets a cold standby requirement. During a design workshop meeting several points are raised. Which of the following could be a design constraint?
1. The hardware currently being used in the datacenter is no longer supported.
2. The company is undecided about the choice of centralized storage to be used in the enterprise.
3. The company is at the end of year one of a three-year contract for the point-to-point link between site A and site B. This link is currently 10MB.
You are a technical consultant designing a solution for a web retail company. The project vision is to deploy a hybrid cloud, where the internal team develops the website on internal infrastructure and migrates production-ready applications to a hosting provider. The project is expected to ease deployment and require less infrastructure capital expenditure without lowering application quality. Which of the following is a risk associated with the project?
1. The solution must adhere to ISO27001.
2. Change control of the hosting vCloud platform is not under full control of the internal business.
3. The hosting provider outsources the platform support to the platform vendor.
4. The applications to be deployed are not fully developed, although a beta exists.
A project vision in some cases may not be achieved due to constraints, risks, and other project factors. However, a vision is required to guide the project throughout the life cycle.
1. True
2. False
When should a software vendor’s best practice be adhered to? (Choose all that apply.)
1. Whenever possible, respecting other project requirements
2. At all times because the vendor wrote and designed the software
3. When there are no other requirements, as a guide to configuration
The following diagrams may be included in project documentation. Which of them shows a system’s components and how they could affect each other?
1. Logical
2. Entity relationship diagram
3. Physical diagram