What a systems architect does¶

A systems architect designs complex IT systems and takes responsibility for the coherence of those designs as they move through implementation, operation, and change. The work spans hardware, software, and network concerns, and it requires sustained engagement with the people and processes that the systems exist to support.

The conventional description of the role focuses on outputs: requirements analysis, architecture documentation, technology selection, standards development, stakeholder communication. These are all real and all necessary. They are also the visible surface of a role whose less visible work is equally consequential.

The rational layer¶

At the rational layer, the architect’s work is analytical and synthetic. Requirements come from multiple sources with different levels of clarity, different levels of authority, and sometimes mutually incompatible demands. The architect analyses what the system needs to do, identifies the constraints it operates within, and designs a structure that satisfies the requirements within those constraints.

This is genuinely difficult work. It requires technical depth across the domains involved, the ability to reason about systems as wholes rather than components, and the discipline to document decisions in ways that remain comprehensible to people who were not in the room when they were made.

The PSL framing identifies this as one of three layers, not the whole of the work. An architect who operates primarily at the rational layer will produce technically sophisticated documentation that underestimates the conditions required for the design to be implemented and operated.

The emotional layer¶

Architecture work touches people’s investments. Engineers have expertise in the technologies a new architecture proposes to replace. Managers have made commitments based on previous architectural directions. Teams have developed practices around existing systems that a new design will disrupt.

None of this is irrational. The emotional responses to architectural change reflect real considerations about competence, identity, and continuity. An architect who treats these responses as obstacles to be overcome, rather than as information about the implementation landscape, will encounter resistance that grows rather than diminishes. The same design, arrived at in a way that acknowledged those concerns rather than bypassing them, often produces entirely different outcomes.

The emotional layer also applies to the architect’s own relationship with their work. Architects who have invested significantly in a design are not well positioned to evaluate criticism of it objectively. The survival stances Satir described are as available to architects as to anyone else: the computing retreat into technical justification when a decision is challenged, the blaming response when implementation diverges from the design, the placating agreement that masks continued reservations.

The political layer¶

Architectural decisions are decisions about authority: about what is standard, what is permitted, what requires exception approval, and who has the standing to make those calls. An architecture that is technically correct but politically unsanctioned will not be followed. An architect who does not have the authority, or the relationship with the authority, to require that their designs are implemented will produce designs that are treated as recommendations.

This is not a complaint about organisational politics. It is an observation that architecture is an inherently political role in the sense that it makes binding decisions about shared resources, shared standards, and shared constraints. The political layer is where those bindings are established and maintained.

Understanding the political layer does not require the architect to become primarily a political operator. It requires them to understand whose endorsement is needed for a design decision to be treated as a decision rather than a suggestion, and to invest in obtaining that endorsement as part of the design process rather than after it.

What this means in practice¶

A systems architect is effective when they attend to all three layers, not just the rational one. The technical work is the entry requirement. The ability to work the emotional and political layers is what determines whether the technical work produces the outcomes it was designed to produce.

This is consistent with what the Wikipedia descriptions of systems architecture and systems architect make visible: the role requires working with “various stakeholders to implement solutions that align with business needs.” Working with stakeholders is not merely communicating technical decisions to them. It is understanding their concerns, earning their trust, and creating the conditions in which their cooperation can be relied upon.