Systems Architecture

How Systems Architecture Works

A system rarely consists of a single, independent component. Software requires data, services communicate through interfaces, devices are connected through networks, and technical processes can depend on people or organizational processes.
Systems Architecture does not consider these components in isolation, but rather their structure and interaction.

This can include, for example:

• essential components of a system
• tasks and responsibilities of these components
• relationships and dependencies
• interfaces
• data and communication paths
• technical and organizational constraints
• fundamental architectural decisions

Which aspects are represented depends on what the architecture is needed for.
Different properties may be relevant for a security assessment than for a migration. Different relationships may be important for operation than for the further development of an application.
A system can therefore be described through multiple architectural views.

Architecture and Architecture Model

A Systems Architecture is not the system itself. It describes fundamental structures, relationships, and principles of a system. Architecture models and other representations make selected properties of this architecture visible for a particular purpose. An architecture diagram can, for example, show which applications communicate with one another. Another representation can describe data flows, while another can show the distribution of components across technical infrastructure. None of these representations has to be complete on its own. What matters is that the representation used makes the structures and relationships relevant to the particular question sufficiently visible.

Why Systems Architecture Has Practical Effects

• Dependencies become visible: Changes to one component can be considered in relation to other parts of the system.
• Interfaces become understandable: It becomes clearer where systems communicate with one another and depend on one another.
• Changes can be assessed more effectively: Possible effects can be examined before implementation.
• Migrations become easier to plan: Old and new components, as well as transitions between them, can be considered together.
• Decisions remain traceable: Fundamental architectural decisions and their constraints can be documented.
• Different perspectives become possible: The same system can be considered from different views depending on the question.

Architecture Does Not Always Come First

For a new system, an architecture can be deliberately designed before essential parts are implemented.
For existing systems, the situation is often different.
A system may have grown over years. Components were added, providers changed, interfaces created, temporary solutions kept in permanent operation, and processes adapted to technical circumstances.
In such cases, an actual architecture already exists—regardless of whether it was ever fully planned or documented.
Before this architecture can be changed meaningfully, it is therefore often necessary first to examine how the existing system is actually structured.
Systems Analysis and Systems Architecture interact here: The analysis helps identify structures and relationships. From this, an architecture model of the existing system can emerge, which can then serve as a basis for further decisions.

Typical Example

A company wants to replace an old server service with a new application.
At first glance, the task seems simple: old service off, new service on.
However, examination shows that several applications retrieve data from the old service, a nightly export is processed by another process, and an internal tool accesses its database directly.
A description of the Systems Architecture makes these relationships visible.
This turns the supposedly isolated server migration into a change affecting several interconnected parts of the system.
The architecture does not automatically determine which solution should be chosen. But it provides a basis for assessing possible solutions and their effects.

Distinction

Systems Architecture and Systems Analysis are closely related, but they are not the same.
Systems Analysis examines properties, relationships, and possible alternatives of a system. Systems Architecture describes its fundamental structures, elements, and relationships.
An existing architecture can be the subject of a Systems Analysis. Conversely, an architecture model can emerge from an analysis.
Solution Architecture focuses more strongly on a concrete technical solution for a particular problem or set of requirements. It can encompass multiple systems, products, and integrations and therefore does not have to be identical to the architecture of a single system.
Systems Architecture is also not equivalent to complete technical documentation. It deliberately abstracts from details that are not relevant to the particular architectural view.

Further Reading

Related Concepts

→ Systems Analysis
→ Solution Architecture
→ System Integration
→ Interface
→ Legacy System
→ Resilience