Objective 1.3 – Determine Risks, Constraints, and Assumptions
· Identify appropriate best practices related to a proposed design.
* Associate a role to the information that needs to be collected.
· Differentiate between the general concepts of a risk, a requirement, a constraint, and an assumption.
Skills and Abilities
· Given a business ask or request, determine whether it is a risk, a requirement, a constraint, or an assumption.
· Given an organization, evaluate and respond to common inherent risks, constraints, and/or assumptions.
Scope – Identify the project scope in detail
· Properly identifying the scope prevents unintended project expansion.
· Example: The virtualization project includes only the London datacenter’s test and development servers. At this time, it does not include any production servers or remote offices.
Goals – Identify and list the overall project goals that the organization wants to achieve
· The project goals should be derived from the business goals of the organization.
· Each project goal should be specific, measurable, and actionable.
· Example: The organization wants to achieve a 25 percent reduction in operational costs by the end of the year
Requirements – Identify and list the key business and technical requirements that must be achieved in the project
• Example: The organization must comply with Sarbanes-Oxley (SOX) regulations.
• Example: The underlying infrastructure for any service defined as strategic must support a minimum of four 9s of uptime (99.99 percent).
Assumptions – Identify and list the design assumptions
• Assumptions are design components that are assumed to be valid without proof.
• Example: The datacenter uses shared (core) networking hardware across production and nonproduction infrastructures.
• Example: The organization has sufficient network bandwidth between sites to facilitate replication.
• Example: Security policies dictate server hardware separation between DMZ servers and internal servers.
Constraints – Identify and list the design constraints
• Constraints limit the design choices.
• Example: Due to a preexisting vendor relationship, host hardware has already been selected. The hardware is …
A constraint could be a business process, a business policy, or a technical limitation. Clearly list the constraints so that they can be reviewed for accuracy and
referred to during the design project.
If a particularly goal, requirement, or constraint cannot be met or creates a risk, discuss the issue with the key stakeholders and SMEs. Discuss it as early as possible in the design project so that the best possible compromise can be reached early in the design process.
Discussing issues and risks early in the design project also reduces the number of surprises in the end design. Surprises in the end design increase the risk of not reaching an agreement to move forward with implementation.
Risks – Identify any risks that might prevent achieving the project goals
• Example: The organization's main datacenter contains only a single core router, which is a single point of failure.
• Example: The lack of executive sponsorship places at risk the goal of virtualizing 75 percent of the datacenter by the end of 2010
The conceptual design focuses on achieving the organization’s business goals and requirements.
• Determine the entities that are affected by the project:
- Lines of business, users, applications, processes, management methods, physical machines, and so on
• Determine how the goals, requirements, and constraints map to each entity.
• Design the infrastructure that will be necessary to achieve each entity’s goals and requirements, while staying within the constraints.
- For example, where will you need availability, scalability, performance, security, manageability, and so on, while staying within cost and other constraints?
Gathering information about your organization’s situation is part of the design methodology presented in this course. Choosing, and then interviewing, key technical personnel and project stakeholders to determine your organization’s situation is just as important as gathering workloadsizing information. The organization’s situation will affect your design.
Use interviews early in the design process to uncover things that affect the end design, such as project goals, budget constraints, hardware policy choices, and department boundaries. Sometimes, organizational boundaries and politics affect the achievable consolidation ratio. Key stakeholder and SME interviews help to uncover this information.
For example, one organization’s primary goal might be to reduce its datacenter footprint and the associated costs, while another organization’s goal might be to virtualize to meet the business continuity and disaster recovery (BC/DR) initiatives of its business.
The first organization might be seeking to achieve 10:1, 20:1, or higher consolidation ratios. The second organization, on the other hand, might be entirely satisfied with a 5:1 consolidation ratio, so long as the virtual infrastructure meets its disaster recovery requirements.
Organizational and political factors often affect the design, yet they are not strictly technical. Sometimes, resistance to virtualization exists due to the preconceptions and fears of decision makers. A feeling of control often accompanies owning physical hardware. The loss of physical hardware might result in a sense of loss of control. Decision makers might also have concerns about performance issues as well as concerns about the return on investment and total cost of ownership associated with virtualization. Resolving the doubts and fears of the decision makers is necessary to move quickly through the design process.