Objective 1.3 – Determine Risks, Constraints, and
Assumptions
Knowledge
·
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.
Tools
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?
Document the conceptual design with diagrams,
tables, and text.
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.
