Home > Articles > VMware

This chapter is from the book

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?

key_topic.jpg

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.

key_topic.jpg

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:

  1. Vendor selection—In selecting the VMware datacenter hosting provider, we considered the requirements detailed in the information gathering phase.
  2. 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.
  3. Production deployment of application—Based on the lessons learned from the proof of concept, we released a single production application.
  4. 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.

key_topic.jpg

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.

Pearson IT Certification Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Pearson IT Certification and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Pearson IT Certification products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by Adobe Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.pearsonitcertification.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020