- "Do I Know This Already?" Quiz
- Foundation Topics
- Exam Preparation Tasks
This chapter is from the book
This chapter is from the book
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?
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.