An architectural view of contrivances and their life in the wild

Click here to listen to the interview on UR Business Network

In this episode, Gary and Nathan talk with Dr. Gareth Digby, Systems Architect, Augustine Consulting Inc. about the manifestations of systems architecture and development of the attendant sensibilities as an engineer. Gareth has consulting experience in acquisition, development, and forensic analysis of forensic involving electrical, electronic and computing systems. He also has leadership experience in systems architecture, software and systems security, and corporate development. He is a Visiting Lecturer in the Department of Computer Science at the University of Oxford.

Gareth described how his university education in power engineering helped him develop a holistic view of systems in their operating environment, including the range of considerations from production to consumption (e.g., interrelationships between “supply” and “load”).  While consulting in the railway sector in the United Kingdom (UK) early in his career, he found that formal training and experience with systems-level thinking was relatively rare and that engineers often were brought in from the Defense sector for this kind of expertise. While systems-level thinking has become much more pervasive, the Defense sector still is among the leaders in utilizing such talent. Partly for this reason, Gareth has spent much of his career in the Defense sector in the UK and US.

One of the most distinctive characteristics of systems-level thinking is considering a system in its context. While product design engineers are more likely to look inward from the boundaries of a product, systems engineers tend to look outward beyond the boundaries of a product. The former focuses on the components and construction of the defining characteristics of a product and its function. The latter focuses on interfaces with other products and the operating environment including the human user.

Gareth talked with us about the manifestations of systems-level thinking in his early career experience with transport economics. He talked about the collaboration between engineers and transport planners in the inter-temporal decision-making that typically must consider time scales on the order of decades. Engineers who are involved in the development of such large-scale long-term solutions must translate the initial objectives of planners into requirements that are sufficiently specific to build solutions, assess limits of operation, and estimate costs. Planners then can make adjustments based on budgets and their own assessments of demand elasticity. Although these factors are outside the mandate and area of expertise of the engineers, they are not simple externalities or immutable boundary conditions. They can be influenced by design decisions that are made collaboratively on the basis of engineering considerations and factors considered by transport planners.

This high-level example provided context for our discussion of the ways in which systems thinking is not limited to technology issues. In particular, the interfaces between a system and its surroundings have important implications for the spectrum of associated producers and consumers, that is, for people. Interpersonal acumen is required of the systems engineers who must be intermediaries between a diversity of people throughout the value chain. They must translate between different ways of thinking as well as between different terminology. This diversity requires an intellectual agility of the systems architects who must put all the pieces together in ways that often are surprising to individual stakeholders and influencers.

Gareth explained some of the nuanced distinctions between systems engineering and systems architecture. The former has come to focus more on process including the development and promulgation of international standards for requirements elicitation, acquisition, development and lifecycle management. The systems architect has a greater degree of freedom to envision a holistic solution and determine the overall design. Gareth shared an analogy to a director in a film. A systems architect must do many of the same things as a leader and organizer with an impact that is similarly if not singularly significant to the outcome.

List of episodes and concepts for Science in the Wild

Join the conversation on Twitter

Connect with Gary Riccio and Nathan Roman on LinkedIn

Key Terms and Concepts

• Systems analysis
• Boundary conditions
• Systems architecture
• Systems enineering
• Requirements elicitation
• System interfaces
• Engineering life cycle
• Systems acquisition and development
• Externalities
• Inter-temporal decision-making