IT Infrastructure Projects: A Framework for Analysis

Jerry Grochow, Senior Advisor to NET+, Internet2; and Consultant, IT strategy in higher education

This article represents a condensed version of the July 2014 ECAR Research Bulletin by the same name. —Editor

Just as maintaining a healthy infrastructure of water delivery and roads is essential to the functioning of cities and towns, maintaining a healthy infrastructure of information technology is essential to the functioning of universities. Deterioration in IT infrastructure can lead to deterioration in research, teaching, and administration. While this is self-evident to IT professionals, it may not be as obvious to senior administrators who more commonly deal with other types of university infrastructure. Given the importance of information technology to all functions of the university, IT professionals must be strong advocates for appropriate life-cycle processes for IT infrastructure.

One responsibility of IT leaders is to provide executive staff with appropriate background, analysis, and recommendations about IT infrastructure, focusing on the impact that inappropriately maintained or out-of-date IT infrastructure may have on the academic, research, and administrative functions of the institution. This article develops a framework to assess the need for IT infrastructure projects; analyze the issues and risks in implementing and maintaining IT infrastructure; and engage other university officials in better understanding the impact of IT infrastructure projects.

Outline of the Approach

The basic approach (see figure 1) is to show how to value a project by looking at the capabilities to be implemented or updated, the benefits to different parts of the university community, the risks entailed in undertaking the project (or not undertaking it), and the costs (including ongoing maintenance and operational costs) — all based on a fundamental understanding of the different types of infrastructure projects and their purposes.

For existing infrastructure, begin by making a determination of its status (or "health") before determining what type of project is necessary. The type of project — initial implementation (for new infrastructure), maintenance, reimplementation, or technology migration — dictates the factors to be considered in the analysis. After capabilities are studied, the bulk of the analytical effort is spent in assessing benefits, risks, and costs. Finally, a Value Scorecard brings together the analysis and compares the project under consideration with alternatives, including maintaining the status quo.

Definitions

The term infrastructure (or "below the structure") is widely used for public works such as water and electric delivery systems, roads, and bridges and, even more generally, to refer to any systems that support society or an organization. IT infrastructure is the stuff on which we build and operate IT applications. Note that while people are specifically excluded from this definition, the costs of people to implement and maintain infrastructure are included in analyzing IT infrastructure projects.

Two related terms deserve mention. Critical infrastructure refers to those infrastructure assets critical to the functioning of society. While this traditionally has referred to infrastructure dealing with necessities such as the water supply, electricity, transportation, and food supply, the federal government now includes information technology in critical infrastructure, both in terms of the organizations that supply IT and the organizations that use IT.¹

Cyberinfrastructure has at least two popular definitions. First used in the academic community in an NSF-sponsored report over a decade ago, the term highlights the importance of information technology to the future research environment. The report defined cyberinfrastructure as a "layer of enabling hardware, algorithms, software, communications, institutions, and personnel" between hardware and the applications.² In the more recent National Infrastructure Protection Plan, cyberinfrastructure is defined for a more general audience: "Cyber infrastructure includes electronic information and communication systems, and the information contained in these systems."³ Note that the first definition includes institutions and people, while the second includes data and information.

Analyzing Types of Infrastructure Projects

Infrastructure projects are not just about developing new infrastructure. They are also about maintaining current infrastructure, deciding when to replace infrastructure, and even about moving to the cloud. For example, when wireless networks were starting to be installed almost a decade ago, this was seen as totally new infrastructure, and it was not clear whether they would replace or augment wired networks. Universities that installed wireless networks then had to maintain them, fixing anything that broke and upgrading network wiring and routers that connected those access points. These maintenance projects were sometimes very large infrastructure projects in themselves. This life cycle of build-maintain-upgrade-replace-reimplement results in the different types of infrastructure projects. The factors to be analyzed for each type of project are similar, but different types of projects require different levels of justification, with each type addressing capabilities, benefits, risks, and costs in its own way (see table 1).

Table 1. Analysis factors for different types of infrastructure projects

	Project Type
	Initial Implementation	Maintenance and Upgrade	Reimplementation	Technology Migration
Capabilities	Basic capabilities	Additional capabilities	New design	Old capabilities vs. new capabilities
Benefits	To different constituencies	Use of anecdotes	Reliability and performance improvements	Capability, reliability, and performance improvements
Risks	New technology acceptance	Impact of upcoming technology shift	Impact on related infrastructure and systems	New technology acceptance
Costs	Maintaining prior infrastructure	Cost changes with maintenance frequency Maintenance costs vs. replacement costs	Impact on related infrastructure and systems	Phased cost model Migration costs

Initial Implementation Projects

When approaching completely new infrastructure, most IT organizations focus on the capabilities the project will bring to campus. In the wireless network example, the core capability was to provide Internet access throughout the campus without having to connect to a wall outlet. This capability provides different benefits to different constituencies: students can use their laptops anywhere; staff can access systems and the Internet as they hold meetings across campus; researchers can work wherever they gather; office layouts do not have to be driven by where network outlets are available; and so forth.

In addition to those immediate benefits, IT staff often raised the possibility of an additional benefit: that wireless networks would reduce or even eliminate the need for most wired networks, thus lowering the cost of that infrastructure. Because wires had to reach all those wireless access points, however, the wired network would still need to go everywhere wireless went (although not necessarily to each desktop). Moreover, dozens of new wireless devices would keep demanding more and more bandwidth, and the wired network would need to keep up. Another factor to consider was the relative newness of wireless technology, and the likely need to replace the entire infrastructure in 3–4 years.

This is common in IT — install a new infrastructure and end up maintaining the old one for a long time, or install a new technology and discover that a new version supersedes it in short order. So while you can expect various benefits from new infrastructure, there is always a risk that those benefits will not be realized. A thorough risk analysis will look at the impact of expected benefits not being realized, as well as other potential risks, including cost overruns and impact on other systems or departments. Meeting with staff from multiple departments is one way to help avoid surprises and demonstrate to decision makers that risks have been studied broadly.

With a completely new infrastructure, benefits and risks will have to be described without much data to draw upon. This means the analysis will be highly qualitative and anecdotal, although some factors might be quantifiable.⁴ Subjective assessments may come from anecdotes or interviews or surveys, or experiences at other campuses. For example, in a 2012 ECAR study on research computing, participants agreed (anecdotally) that "having research computing resources makes an institution more competitive in recruiting and retaining faculty with research computing needs."⁵

In addition to capabilities, benefits, and risks, the other important part of the analysis is the cost model. This will include the costs for the initial project, as well as expected operational costs for several years (typically 3–5) and any major expected upgrades or replacements if they occur within that time. Costs should be determined for planning, design, and implementation. If it is possible to put a time frame on when the technology will become obsolete (or at least obsolescent), then costs can also be estimated for replacement or major upgrade and can be included in the overall cost model as well.

Ongoing maintenance costs should be considered, including hardware, software, other equipment, construction, and personnel. Personnel costs (both contractors and employees) are often a significant figure and should include full- and part-time people involved in the project, both from IT and any other departments involved, such as the construction department.

Maintenance and Upgrade Projects

Analysis of maintenance projects includes the same basic factors as new infrastructure projects: capabilities, benefits, risks, and costs. Maintenance projects run the gamut of simple software upgrades to complex efforts that might involve retesting entire networks, systems, or databases. One of the facts of life is that there is never enough money to maintain or upgrade all infrastructure to the highest and most productive level, requiring organizations to establish priorities. This, in turn, requires understanding the benefits of maintaining and the risks of not maintaining IT infrastructure. For example, the failure to maintain networks means that fewer people will have high-speed access to online research facilities and that, as a result, fewer multi-institutional research projects will take place. In one instance, a physics professor asked the CIO at his institution for a written commitment that the university would increase bandwidth to keep pace with other institutions in the physics research community because he wanted to submit that document with a grant application! Without this commitment, he felt that he was unlikely to win the grant.

Before going forward with a particular maintenance project, an institution must consider several key questions:

• How often should the maintenance be performed?
• When should replacement be considered instead of maintenance?
• Is there a new or emerging technology on the horizon that might change the approach to maintenance?

The answers to these questions can help an organization decide what and how much maintenance is appropriate, which provides the basis for a cost model for infrastructure maintenance.

Reimplementation Projects

There comes a time in the life cycle of any software, hardware, or network system when it is appropriate to start over. Technology refresh cycles in the IT infrastructure realm can be as short as 2–3 years or as long as 5–7 years.⁶ Moreover, whereas some network routers, for example, have a useful life in the upper end of that range, newer equipment may have 10 to 100 times the capability for the same or lower price. When maintenance costs start to equal replacement cost, and the capability/cost ratio declines significantly, it is time to reimplement, taking into account the ongoing maintenance costs of new infrastructure, which may be higher or lower than current maintenance costs. However, replacement is rarely as simple as a "forklift upgrade." The related impact on facilities, networks, and other systems has to be taken into account. If current computer hardware requires power of 5kW per rack but new hardware requires 10 or 20kW, the cost of upgrading electrical and cooling equipment can equal or exceed the cost of replacing the computer hardware. Replacing software infrastructure such as the database system could impact hundreds of applications, perhaps requiring replacing these systems as well. The implications of reimplementing infrastructure can be far reaching, and all those reaches must be part of the analysis.

Technology Migration Projects

Sometimes a reimplementation project is based on technology so dramatically different that the infrastructure project is essentially a new implementation — except that the old infrastructure has to be migrated to the new. When universities started to shift from "plain old telephone service" (POTS) to IP-based telephony or from on-premises servers to cloud-based servers, the migration of services from one infrastructure to another was a major factor in the reimplementation. In this type of situation, the cost analysis has to show the overlap of both services, as well as costs attributable to the migration effort (see figure 2).

Assessing Existing Infrastructure via a Health Check

One of the questions in justifying infrastructure maintenance or replacements is, Why do this now? While a leaking roof is a sure sign of the need for building maintenance (although not necessarily for roof replacement), the need for maintenance on other types of infrastructure may not be so obvious. The building trades and other engineering professions have established many types of metrics and standards to guide such decisions. IT hasn't achieved that level of standardization, but we can develop an approach to assessing infrastructure systems by measuring their usefulness, reliability, and technological obsolescence.

Ratings can be established in various ways, ranging from subjective opinions of people knowledgeable about the system to detailed technical analyses performed by outside consultants. Once individual measures have been assessed, the infrastructure system or component can be given an overall rating or "health check score" depending on the decisions to be made:

• Maintenance level of effort: an indication of the level of effort (low, medium, high) needed to bring the infrastructure up to some established level of performance
• Maintenance time frame: when significant maintenance will likely be necessary
• Useful life time frame: when the infrastructure is likely to fall below the acceptable threshold for usefulness, reliability, or technological obsolescence

In preparing for an annual budget review, one university IT department performed a health check on its infrastructure systems, using subjective ratings from multiple staff members. After collecting data on four criteria (meeting known needs, outage frequency, how up-to-date the technology was, and cost to maintain it), the department applied its knowledge of the technology environment and expectations of user needs to rate each infrastructure component on whether it would require significant maintenance or upgrade over specified time frames: 1–2 years, 3–5 years, or greater than 5 years (see table 2). According to the university's CIO, "This made a powerful presentation going into the governance committees, particularly when we could show some systems past end of life or using completely outdated technology." The health check was updated for subsequent annual budget reviews.

Table 2. Example health check rating of infrastructure systems

Infrastructure System	Meets Need (Usability)	Outage Frequency (Reliability)	Up-to-Date Architecture (Tech Obsolescence)	Cost to Maintain	Health Check Rating
Service management system	1	3	2	2	2.0
Enterprise storage	2	2	3	3	2.5
Web server	3	3	3	1	2.5
Wireless network	4	3	2	3	3.0
Database	3	3	3	5	3.5
Identity and access management	4	4	4	4	4.0
Wired network	4	5	4	4	4.3
Printing management system	5	5	4	4	4.5
Emergency response system	5	5	5	4	4.8

Scale
1.0–3.5	Needs attention in the next 1–3 years
3.5–4.49	Needs attention in the next 3.5–5 years
4.5–5.0+	Needs attention after 5 years

Justifying Infrastructure Projects

Justifying an infrastructure project means presenting the value proposition. Although cost reduction is often the justification for infrastructure investments, other goals are also involved, such as improved capability or risk reduction. Infrastructure projects will compete with all the other demands on the IT budget, however, and sometimes suffer in comparisons because benefits and risks are thought to be difficult to explain or quantify. A value analysis can be helpful in this regard and need not be costly or difficult to develop.

Return on Investment, as a Scorecard

Consider the value proposition for adding a redundant switch in your campus network. Having this redundancy will reduce the likelihood of an outage, but by how much, and how likely is an outage without the redundant switch? What is the cost of an outage? In other words, how do you calculate the value of this infrastructure project? In practice, many risks and benefits can only be translated into financial terms by making gross assumptions on financial value that would be nearly impossible to verify. That said, in some situations a financial return-on-investment (ROI) analysis is useful, and those instances shouldn't be ignored. For example, maintenance or reimplementation projects are often cost-savings projects, in which case ROI may be the only justification needed. ROI might only rarely be a key decision metric, but when it is, it is an important part of the analyst's toolkit.

So how do you create the value proposition for infrastructure where a single financial ROI is not readily calculable? Create an ROI scorecard using all that you know about the project. Some benefits and costs can be presented in quantifiable terms and some not, but all should enter into the decision-making process. Describe who benefits — specific groups of faculty, students, or staff. ROI is all the different types of returns — positive and negative, financial and nonfinancial — that accrue from implementing a project. If ROI is presented as a scorecard rather than a single number, then all types of benefits and costs can be presented.

Finally, it is important to know your audience. Who are the decision makers who will evaluate your analysis? What measures will resonate with them? If it is faculty, then the most important aspects might be how the infrastructure will aid their ability to do research, obtain research grants, or better teach students. If your audience is the CFO, then an argument with at least some discussion of financial return will be useful.

Justification via Comparison

An infrastructure project under review must be compared to other projects. Alternatives likely also exist, such as procuring equipment from different vendors or moving to the cloud. The option of doing nothing also has benefits, risks, and costs and should be evaluated with other alternatives. This evaluation should compare all the factors discussed, from general capabilities to benefits to risks and costs. Table 3, while not exhaustive, lists many of the criteria that can be used in such a comparison.

Table 3. Analysis and comparison matrix template

Framework	Criteria	Alternative 1	Alternative 2	Status Quo
General	Primary purpose of the infrastructure
	Type of infrastructure
	Specific capabilities
Value/Benefits	Primary beneficiaries; how they benefit
	Ancillary beneficiaries; how they benefit
	Reduction of complexity or dependencies
	Impact on research
	Impact on teaching and learning
	Impact on administration
Risk Analysis	Benefits not achieved
	Reputation risk
	Compliance (legal) risk
	Schedule slippage (time risk)
	Cost overruns
	Unintended consequences
	Increased complexity or dependencies
Cost Analysis	One-time costs of planning and implementation: external, including external personnel (range of cost)
	One-time costs of planning and implementation: internal, including internal personnel, amortization, nonbudgeted costs (range of cost)
	Cost of conversion/overlap: external (range of cost)
	Cost of conversion/overlap: internal (range of cost)
	Annual (ongoing) costs: external, including external personnel (range of cost)
	Annual (ongoing) costs: internal, including internal personnel, amortization, nonbudgeted costs (range of cost)
	User costs (range of cost)
	User savings (range of cost)

Conclusion

IT leaders often opine that it is difficult to make a case for spending money on infrastructure systems, certainly much more difficult than making a case for spending money on application systems. The value proposition for infrastructure spending is undoubtedly complex, involving both financial and nonfinancial factors. This framework helps analyze and present that value proposition, thus helping IT practitioners justify the need for individual infrastructure projects. It provides background to enhance understanding of the various types of infrastructure projects, present capabilities, analyze benefits and risks, develop a cost model, and, by comparing alternatives, develop the value proposition for presentation to decision makers. With this presentation, decision makers will be in a better position to appreciate the value of IT infrastructure and approve necessary projects.

1. Department of Homeland Security, National Infrastructure Protection Plan: Partnering to Enhance Protection and Resiliency, 2009.
2. NSF, Revolutionizing Science and Engineering Through Cyberinfrastructure: Report of the National Science Foundation Blue-Ribbon Advisory Panel on Cyberinfrastructure [http://www.nsf.gov/cise/sci/reports/atkins.pdf], 2003.
3. DHS, National Infrastructure Protection Plan.
4. There are many examples of project teams spending much time developing quantifiable measures for just about everything, even when that analysis is of dubious quality or does not have any actionable value. Sometimes, qualitative analysis provides more than enough information to allow actions to be taken. For example, rather than trying to calculate "lost productivity" of a network outage to help justify some number of duplicate routers, it might be equally useful to note that having your university on the front page of a local or national newspaper for having a prolonged network outage is a reputational risk the president and trustees might not want to take very often. Different options for mitigating this risk can then be compared by analyzing costs and other factors.
5. Jacqueline Bichsel, Research Computing: The Enabling Role of Information Technology, research report (Louisville, CO: ECAR, 2012).
6. Replacement cycles for application systems are often longer, sometimes much longer. It is not unusual to hear of accounting systems still in use after 20 years or more.