Systems within systems: The research computing environment

From The Business of Energy in U.S. Academic Research Computing
Jump to: navigation, search

Systems Overview

Higher education consists of a large number of systems within systems, with uncertain boundaries between them and their environments. In this section, we will introduce some concepts for systems thinking as they may be applied to higher education. This will be an important building block for the rest of the monograph, because a key characteristic of research computing in higher education is that no component operates in a vacuum. We need to look to how systems interact, in order to understand and impact their outcomes.

Systems thinking, including study of complex systems and systems theory, has a long history. A watershed in widespread adoption of systems thinking was Rachel Carson's (1962) Silent Spring. By the following decade, Donella Meadows et al's Limits to Growth applied systems thinking in a rigorous and scientific manner (including computer modeling) to human population growth and its impact on ecological and physical systems. From this standpoint, the history of systems thinking is coincident with the emergence of ecological awareness, as the human ability to influence the environment has become more widely recognized.

Not long after systems thinking began to dominate environmentalism, it came to the fore as an approach to understanding businesses and other organizations. By the time Peter Senge's The Fifth Discipline was published in 1990, recognition had emerged that organizations are complex living systems. In addition to seeing organizations as dynamical systems in a state of continuous adaptation and improvement, Senge described organizations as being able to learn, and thus to have an emergent and separate existence from their component parts.

Systems Characteristics for Research Computing

These are some of the characteristics of systems thinking as they may be applied to academic research computing organizations:

  • Synergistic: The system is greater than the sum of its parts. A supercomputer is a pertinent technical example, in which hundreds of separate systems and subsystems are organized together to accomplish desired goals.
  • Not necessarily logical or goal-oriented: While some systems have clear purposes, most complex systems cannot be so easily defined. In research computing environments, there are numerous changing and sometimes conflicting goals. By taking a systems view, we hope to understand how systems can better achieve desired goals.
  • Uncertain boundaries: There are a multiplicity of ties between systems (organizational, personnel, fiscal, statutory, and others); boundaries around systems are likely to be permeable or uncertain.
  • Many different types of relationships: The organizational chart or budget gives one view of how system components relate to one another, and yet might not tell the whole story. Patterns of information flow and power might have different shapes from those on the organizational chart, and may be subtle or even invisible.

It is incumbent on personnel in research computing environments to consider the system they are part of. Focus on individual components is necessary, but not sufficient, to understand the system and achieve organizational goals. For example, a finely tuned and fully functional computer cannot operate as a node in a supercomputer until the relationships of the node to the larger system are defined and implemented. Human systems in organizations may be even more complex than supercomputers to understand.

Systems in Research Computing Environments

A systems description for any non-trivial environment may be best treated as a tool for discussion and analysis, not as complete truth. In this sense, a systems description is a model. As anyone who uses supercomputers to run computational models will tell you, all models are inaccurate - and yet, they may be useful. For research computing, we can model a number of systems and their environments. Even when such models are useful, we can recognize they are incomplete and possibly even misleading.

For example, here is a simple diagram of how computing technology might exist in a university: System1.png

This image tells us that computing technology is only one type of technology within the organization. Other technologies (such as electron microscopes and genetic sequencers) are out of scope. The image also tells us that research computing, instructional computing and enterprise computing are the three separate types of computing technologies at the University.

When considered as labels describing an organizational chart, this image might be completely accurate. It's typical for a university to have different departments or other units for different types of technologies. It is also typical for administrative computing activities (such as the bursar, registrar, and enterprise calendaring) to be administered separately from classroom technologies or supercomputers.

But does this tell an accurate story of how the systems of this organization are related? Probably not. There are dozens of additional relationships among the different components that might play a role. Some of these might include:

  • Personnel: People might span the organizational boundaries.
  • Technologies: Technologies might be used by multiple systems. For example, an enterprise backup system might be used by the entire university.
  • Budget: Funding might not match the organizational structure. Perhaps one computer-equipped classroom is funded and operated by the research computing group, while another is under an academic department.
  • Users and uses: Does "Visualization" consist of specialized equipment, software and the people to run it? Or, is it an activity for visual communication that is engaged in by a variety of users (including enterprise, instructional and research users)?
  • Constituents: What employees, users, administrators and other stakeholders are part of this system?

These missing features highlight the challenges of selecting which components to include in a systems analysis, and which types of relationships to focus on.

Systems Components for Research Computing

  • Technologies and networks: What systems, subsystems, and relations among them exist in a research computing center or unit? Granularity can become a major challenge, since technology systems tend to be made of many subsystems. Choosing whether to label a "Supercomputer" as a system component, or to expand the different nodes and components (disk drive, Ethernet network, InfiniBand network, accelerator device...) depends on the purpose of the systems analysis.
  • Institutional structure: Sometimes there is a Supercomputing Center. Other times, research computing functions are part of a larger enterprise function (Information Technology Services or similar). Or, a department or other unit might provide research computing.
  • Unit structure: Within the research computing organization or group, what are roles or relationships? This analysis might start with the unit organizational chart, and then expand to illuminate the different functions (such as user support or training) and ties to other systems (such as jointly appointed faculty members).
  • Multi-institutional structure: A campus might be part of a University system or consortium. Research computing activities might span multiple institutions, or might have limited roles for other consortium members. Sometimes, different functions will have different levels of cooperation. For example, wide area networking is often a shared statewide function.
  • Affiliations via industry or other groups: The [CASC] organization is an example of a group that serves to bring together research computing units. Industry groups can span academic and commercial interests, such as the [Cray User Group].
  • Federal agencies and regulatory environments: Mission and status of federal funding agencies has shaped research computing in the US, particularly the National Science Foundation, Dept. of Energy, and National Institutes of Health. Regulations, notably HIPAA and FERPA, can impact policy and operations within research computing centers.

In this section of the monograph, we have introduced concepts of systems and systems thinking for research computing. It is not necessary, for our purposes, to dive more deeply into systems theory or the mechanisms that influence systems behavior. What is necessary for understanding research computing is to understand the many relationships among different systems. Vitality and longevity for research computing activities will require maintaining an effective balance among these many systems.