Data Center Owners and Designers, Part 1: What Owners are Demanding of Design Engineers

The owner's responsibility is to establish the requirements and make the decisions necessary to implement them. Developing solutions and providing hard data to support the decision making is what the design engineer is hired to do.

By Julian Kudritzki and John H. Seader, Uptime Institute, New York December 16, 2009

This is the first in a two-part series to provide proven methods for improving the working relationship between the owner and the design engineering team during a data center construction project. When this relationship is problematic, initial repercussions are in the traditional project elements of cost and schedule. Inevitably, the impact is in data center performance (i.e., it doesn’t work), which results in career penalties and squandered investment of millions of company dollars.

The first part in the series will focus on the owner’s responsibilities that can most significantly facilitate the design engineer’s tasks. This article will include guidance to avoid the common occurrence of owner’s responsibilities shifting to the design team.


The process of justifying a new data center is an intensive, months-long exercise completed by the owner team before engaging a design engineer. Data center project justification requires special allocation of funds and staffing resources. “Getting a budget for the budget” is critical to fully assembling the drivers, factors, and business requirements compelling a data center build.

If framed in terms of business case, capital investment is driven by business requirements rather than cost/budget or pride of ownership. Owners are most successful if they successfully impress upon upper management the value of uptime. This is best phrased in the cost of downtime (dollars and otherwise): effect on quarterly earnings, disruption of smooth business function including lost productivity, adverse market perception, diminished stock value, and punitive action by regulatory or oversight bodies. If the business doesn’t justify Tier IV level of investment in terms of the actual (dollars) and incalculable consequences of downtime, it is likely that business doesn’t require such a robust, complex, and costly solution. See the sidebar, “The Uptime Institute Tiers for Data Center Design.”

A demand model and growth forecast are essential to defining the need for a new data center in terms of the organization’s strategic objectives. The demand model will emphasize the criticality of the computing function and current site constraints through a close accounting of the current IT equipment, power and cooling demand, and space use. The growth forecast will project the load (power, cooling, computer room space) into the future. Owners should account for increases in demand (merger, acquisitions, consolidation) and capacity recovery (cloud computing, virtualization, mining of dead servers). Gathering data for these project justification endeavors requires significant time and resources throughout the organization. These data must be accurate and well-sourced and the assumptions defensible in order to fully demonstrate that the current assets will not serve the business needs beyond a reasonably predictable timeframe. Ideally, the event horizon is sufficiently far out to allow for the time for approval, design, and construction. If the site is nearing capacity thresholds, and has limited or no provisions for new IT equipment, the owner is already well behind in the process.

Shortcuts in the project justification effort endanger the project, which can ultimately suffocate the business as the data center assets are unable to continue to deliver. Once upper management senses that the project is not on stable justification, it is difficult to limit its erosion. The owner team must beware of extras that cannot be explained in terms of business strategy, e.g., multiple utility feeds, 2(N+1) UPS, multiple types of fire suppression, or excessive capacity not justified by sound business needs.

Ceding elements can invite rote behavior, such as blind pursuit of the 10% cost reduction that is the ubiquitous measure of project management. Cost cutting can be just as difficult to slow as runaway spending. Features that the business does not require may come at the cost of the functionality the business does require. It is difficult to regain momentum for a data center project once it is delayed or denied, and the resumption typically is harried.

Project justification is an artful balance of education and refutation. Owners must fully understand all terms that will establish the project goals. They should prepare materials that pre-empt faulty assumptions and disabuse stakeholders of misconceptions.

• Tiers can be inflated by pride of ownership. Tier signifies an infrastructure configuration, rather than a “job well done.” Best-in-class, world-class, or gold-plated do not easily correlate to Tier because Tier is a business-case-driven and performance-based system. Distinguish between Tier (actual functionality of equipment) and how the data center looks. Corporate image expressed in flourishes, finishes, foyer design, and extensive upkeep can support branding identity, but does not result in increased availability of the critical environment. The “whiz-bang” of a gleaming computer room carefully arranged in the cold aisle/hot aisle can be visually comforting to upper management and data center clients. Yet, Tier cannot be determined through the visual aspects of the equipment because many Tier requirements are met out of plain sight in the form of pipes, pumps, and parts.

• There is nothing inherently “wrong” with a Tier II facility if it meets the owner’s business needs. For some, Tier I and II have become fearful terms, indicating a substandard level of service or investment management. This is true only if there is a disparity between Tier of the facility and what is required and budgeted.

• Tier topology addresses maintenance opportunities; operational sustainability addresses the other significant risks to operations.

  • O&M best practices may be implemented in facilities of any Tier. O&M includes staffing levels, security, and processes and procedures. A number of Site Uptime Network members have outperformed Tier III expectations of availability in Tier II facilities through observant, careful, site management techniques. The culture of high availability and pride of ownership improves performance of facilities of all Tiers.

  • It is possible to implement Tier IV topology in a multi-tenant, downtown high-rise or by a major river or airport. Site location and building characteristics are critical decisions that will ineluctably influence the lifecycle operation of the facility, but Tier cannot eliminate these types of risks. Similarly, if the organization grows through acquisitions or has a variable IT load due to industry volatility (e.g., energy, petrochemical), Tier alone will not guarantee the flexibility to contract and expand to meet the business’ needs. It is very difficult to launch an expansion project that was not anticipated without affecting uptime and/or incurring extreme costs. Design provisions for the facility to evolve to meet known or foreseeable business needs are critical to avoid obsolescence or waste—and are not ensured by Tier alone.

If project justification materials perpetuate myths and misuse terms, the results could be rework and a significant delay in justification. The primary consequence of inadequate justification is that upper management will not understand the imminent demand for the project. In the interim between the next presentation, which is typically a year, the existing assets could be further stretched and fail.


Poor requirements planning is one of the major contributing factors to data center projects that fail to reach their objectives or exceed budget and/or schedule. The project justification process described above will provide the framework for the requirements planning phase. Nevertheless, the type of detail appropriate to a C-suite presentation is insufficient basis to guide the design solution. The former is the business needs and value of the investment; the latter is strictly performance requirements and building characteristics.

It is critical that the project requirements are vetted, validated, and documented in technical language appropriate to the design engineer. The owner may choose to engage a third party, including a design firm, to provide relevant technical expertise during this phase. However, in order to impress upon the team the firm’s importance, it should be distinct from any other tasks—especially generation of design solutions. The Uptime Institute delivers consulting services culminating in a Performance Requirements and Design Assumptions (PRDA) to fill this need. The PRDA is a unique deliverable, developed in close collaboration with the owner team stakeholders, and organized by site selection, architectural, mechanical, electrical, and ancillary subsystems. Within each of the five sections, specific Tier requirements and operational sustainability requirements are detailed for numerous subsystems. The purpose of this document is to provide the design engineer with the specific information necessary to initiate a responsive design.

Stakeholders throughout the organization should be involved during the requirements planning sessions. These typically include IT, facilities, insurance, security, and risk mitigation. All of these organizations need not be present for all sessions, but it is critical that each has the opportunity to contribute its concerns and relevant expertise and that they are fully documented. And, just as important, all stakeholders should sign off on the final document. A formal sign-off procedure is recommended because during the course of the project all decisions will be challenged.

The requirements document should fully and consistently document the Tier and capacity requirements at completion of construction and ultimate build-out. The requirements document should also address the five operational sustainability factors. It should capture the valuable lessons that have been learned from the challenges or features of the current site operation. The document also should incorporate the data center staff’s operational experience. Features such as ample storage room and a room outside the data center to unpack and burn-in equipment are frequently overlooked. Site staff will have either appreciated it or felt its lack.


Respondents are typically able to provide great detail if supplied with great detail. A thorough, explicit RFP will allow respondents to include project experience that directly speaks to their capability to perform the job. It also allows the owner team to accurately gauge respondents’ experience in projects of similar investment magnitude and performance expectations. The team should provide an excerpt of the requirements document to enhance the submission packages and interviews, and clearly state in the RFP the relevant standards and certifications (Tier, operational sustainability, commissioning requirements, LEED, ISO, etc.). This will establish the third-party review expectations and indicators of project success from the outset.


If the owner has secured a budget appropriate to the project objectives and published a requirements document, the development of the design is smooth and timely, and the solution responsive and innovative.

In the absence of a detailed requirements document, the design engineer is encumbered with the research, preparation, and decisions that belong to the owner. This can result in an ad hoc or boilerplate requirements document establishing the basis of design. Boilerplate requirements documents lead to tired solutions best suited for the design engineer’s last project. This dis-empowers the owner as driver and determinant of this project’s success.

The lack of an owner’s requirements document forces migration of decision-maker tasks and responsibilities to the design engineer. Furthermore, it compels the design engineer to perform a facilitator role, which he may not be qualified, incented, or enthused to perform. The design engineer’s opportunity to improve the project outcome through innovative solutions and incorporation of emerging technologies is squandered developing requirements and making decisions that are the owners’ responsibility.

Table 1: Tier requirements summary

Tier I Tier II Tier III Tier IV
Source: Data Center Site Infrastructure Tier Standard: Topology, by Uptime Institute Professional Services, 2009.
Active capacity N N+1 N+1 Ncomponents to support After any failure the IT load
Distribution paths 1 1 1 Active and 2 Simultaneously 1 alternate active
Concurrently maintainable No No Yes Yes
Fault tolerance No No No Yes
Compartmentalization No No No Yes
Continuous cooling Load density dependent Load density dependent Load density dependent Class A


Author Information
Kudritzki is vice president of Uptime Institute. He has managed the expansion of Tier Program into South America, Europe, Middle East, and Africa. He continues to ensure the integrity of the Tier Program Certifications worldwide, and has assisted in the development of numerous Uptime Institute white papers and educational programs, including the Accredited Tier Designer curriculum.

The content of this article is informed by the collective resources of Uptime Institute Professional Services: field experience as Owner’s Representative and Tier Certification Authority on high-availability projects worldwide; consultants’ personal data center development and operations experience; real-time, real-life reporting of Site Uptime Network members; analysis of the Uptime Institute’s Abnormal Incident Report database; and the professional engineers attending the Accredited Tier Designer curriculum.

The Uptime Institute Tiers for Data Center Design

The Tier classifications were created to consistently describe the site-level infrastructure required to sustain data center operations, not the characteristics of individual systems or subsystems. Data centers are dependent upon the successful and integrated operation of at least 16 separate site infrastructure subsystems. Every subsystem and system must be consistently deployed with the same site uptime objective to satisfy the distinctive Tier requirements. The most critical decision-making perspective owners and designers must consider, when making inevitable tradeoffs, is what effect the decision has on the lifecycle integrated operation of the IT environment in the computer room. The Tiers are summarized in Table 1.

Simply put, the Tier topology rating for an entire site is constrained by the rating of the weakest subsystem that will impact site operation. For example, a site with a robust Tier IV UPS configuration combined with a Tier II chilled water system yields a Tier II site rating.

For more information, download Data Center Site Infrastructure Tier Standard: Topology at .