Architecture Repository/Process/What is system architecture?

‎

Wikimedia Architecture Repository
Home | Artifacts | Process | Patterns

What is system architecture?

Last updated: 2024-03-13 by Kghbln
Author: Dana Bredemeyer
Status: v1 published January 2023

This page provides an introduction to the concepts and practice of system architecture.

Defining systems

Before we discuss system architecture, we need to define systems.

A system is a collection of parts that compose a whole, such that the whole performs a function or pursues a purpose that no part, or collection of parts, does.

Every part affects the system. No part, or collection of parts, has an independent effect on the system. Said otherwise, the way every part, or collection of parts, affects the system, is itself affected by the rest of the system. The behaviors and properties of a system are not the sum of the parts; they are not the sum of the behaviors and properties of the parts; they are the product of the interactions of the parts.

System architecture is a design activity that attempts to produce system behaviors and properties. It focuses on how the parts of the system interact with each other so as to define the overall system and its interactions with its environment. Since the role of architecture is to design the system so that desired outcomes are realized, and outcomes are the product of the interactions of the parts, the architecture of a system includes the definition of its parts and their interactions, specifically:

• the boundaries of the parts,
• the responsibilities of the parts,
• the interfaces to those responsibilities, and
• rules and patterns of the interactions of the parts.

Any change to a part which affects the system as a whole, or said otherwise, any change to a part that has effects outside the part’s boundary, is a change to the system’s architecture.

The role of system architecture

Architecture’s objective is a system design that leads to maximum realized value. To support that objective, the architecture process seeks to identify and understand all elements that can influence realized value, including strategy, all internal and external stakeholders and their desired behaviors and properties, organizational history, culture, attitudes, politics, and any other influence that can enhance or diminish ultimate realized value. At narrower scopes, the influences tend to be more technical; at broader scopes, they become more socio-technical.

For system architecture to do its job, it needs a complete picture of the desired system and of the forces impacting our ability and likelihood of getting from intent to delivery.

Architecture Process in a Nutshell

Vision

A picture of our desired future. "Imagine a world in which every single human being can freely share in the sum of all knowledge."

Stakeholders

For every stakeholder (some are individuals; some are groups) we need a model or profile that expresses our understanding of them, what they are trying to accomplish and what help they want from us.

Strategy

This is our organization-wide strategy, how we will invest our resources, and why we think those actions will move us toward our vision. In this simplified diagram, strategy includes our understanding of the world and how it’s evolving, other players and how we engage with them.

Capabilities, properties, behaviors

This bridge is necessary to clarify, re-express, make specific and actionable the content from strategy and stakeholders so that it can be integrated into the whole-system description and guide decisions in the rest of the process. Much of this is derived from the stakeholder profiles.

Whole-system product description

This is a complete description of:

• The built system as experienced by its users (external stakeholders), and
• the development process (as it relates to the architecture) and architectural structures (platforms, architectural mechanisms, … as experienced by WMF developers and technical managers (internal stakeholders).

This description integrates and prioritizes all the inputs from upstream (strategy and stakeholder concerns) and downstream (development concerns, legacy system and architecture).

Without this description, we cannot reason effectively about the whole desired system. Specifically we are unable to:

• See how parts of the desired system interact with each other.
• Reason about the impact, to the whole system, of proposed changes.
• Make system architecture decisions based on a whole-system description

The system architecture

This is a minimally-constraining set of design decisions considered necessary to ensure the realization of desired outcomes. Without the whole-system description, and a system architecture designed to realize the system, the whole system has no design. It is simply the accumulated consequences from the designs of the parts.

Boundaries of system architecture

Just what gets decided in an architecture? What should, and should not, must, and must not, be decided, for architecture to do its job. Where does architecting stop and design begin? Being careful about scope helps us answer these questions.

Architecture Umbrella Diagram

When we call something a system, we draw a (partially arbitrary) boundary around a bit of the world, and decide that what’s inside the boundary is the system we’re talking about.

A system’s architecture doesn’t make decisions about things outside its boundary.

But how much does architecture decide about what is inside the boundary? Downstream designers and developers are often worried that the architecture is going to decide everything, or at least everything interesting. Minimalism counsels us to make these subsystems as ‘big’ as possible, encapsulating as much of the complexity of the overall system as possible inside the subsystem boundary.

A good architecture is a set of design decisions that ensures, or at least enables, the realization of system-level desired outcomes, while maximizing downstream degrees of freedom.

Learn more

To learn more about system architecture, see the list of recommended resources.

References

Bass, Len; Clements, Paul; Kazman, Rick. (2021). Software Architecture in Practice. Addison-Wesley Professional. ISBN 9780136885979

Rechtin, Eberhardt (1991). Systems Architecting: Creating & Building Complex Systems. Prentice-Hall Inc. ISBN 0-13-880345-5.