Architecture Levels and Decision Scope

Suppose a retailer’s order team proposes publishing every order change as an event so that the analytics team can stop copying the orders database each night. Within a week the proposal collects questions from very different people. The enterprise architecture group asks whether the company has an approved event streaming technology. A solution architect asks whether events are the right way to deliver this capability at all, given that finance also needs the same data. The engineers who would build it ask how many partitions the topic needs and which cluster it will live on. The operations lead asks who will be woken up when the cluster runs out of disk. The retailer is invented for illustration, but each question is legitimate, and each belongs to a different level of architecture.

Problems start when those levels are blurred. A review board ends up debating partition counts, or a single team quietly makes a choice that binds the whole company. This article sorts out the vocabulary: what separates the scope of an architecture decision from its domain, what the common architecture roles are responsible for, why the logical design, the physical deployment, and the operating responsibility of a system need separate treatment, and how decisions at one level constrain the levels below.

Scope and domain are different axes

Labels like enterprise architecture, data architecture, and solution architecture look like entries in one list, but they combine two separate dimensions. Scope is how much of the organization a decision covers. Domain is what kind of thing the decision is about.

The U.S. Federal Enterprise Architecture Framework, version 2, published by the Office of Management and Budget in 2013, makes both dimensions explicit. It describes enterprise architecture as support for planning and decision-making through abstracted views of an organization at different levels of scope and detail. Its domains are strategy, business, data, applications, infrastructure, and security. Separately, it lists levels of scope that run from international and national programs down through a sector, an agency, a segment of that agency, a single system, and a single application. The framework was written for government, but the idea transfers: a data decision can be made for one application or for the whole company, and a company-wide decision can be about data, security, or infrastructure.

For this discussion, three nested scopes provide a working vocabulary, with solution architecture describing work organized around a particular need. Organizations may use these labels differently.

Level of scope	What it covers	Typical decisions	When to revisit
Enterprise	The whole organization	Principles, company-wide standards, the target shape of shared capabilities such as identity and data platforms, which technologies are approved	When the business strategy changes, when a shared capability is replaced or retired, when a vendor or regulatory position shifts, or when exceptions to a standard outnumber compliance
Segment or portfolio	A business area, product line, or shared platform	How systems in that area fit together, which capabilities are shared within it, sequencing of investments	When the area’s goals or funding change, when a shared capability inside it changes, or when an acquisition or reorganization changes what belongs to the area
System	One system and its components	Internal structure, technology within the approved set, deployment, and operational design	When its requirements or load change materially, when an operational limit is discovered, or when a decision above it removes or adds an option

Scope is a poor predictor of how often a decision changes. A system’s core structure can stand for a decade while a company-wide standard is replaced in a quarter because a vendor changed its licensing. What is reliable is the list of events that should trigger a fresh look.

Solution describes the design that addresses a particular business need or capability. Here it is not a fixed tier between segment and system: a solution may fit within one system or cross several. This is a working distinction, not a claim that every architecture framework uses the term identically. The order events proposal crosses the order system, the analytics platform, and possibly the finance integration, so it needs a view of their combined behavior.

What ends at delivery is the initiative, not the solution. Once the capability is handed over, the systems keep the relationships the solution created: the event schema is still a contract between two teams, the integration still has to survive both systems’ release cycles, and a change on either side can break the capability without breaking either system on its own. Somebody therefore has to keep holding the cross-system view after the project closes. Who that is varies, and naming it is the point: a standing owner for the capability, the segment architecture for that area, or a written agreement between the system owners. Without that responsibility, changes can escape coordination; for example, a schema change may break consumers the producer did not know about.

Domains then describe the subject of a decision at any level. Business architecture covers capabilities, processes, and organization. Data architecture covers what data exists, what it means, where it is authoritative, and how it moves. Application architecture covers systems and their interactions. Technology or infrastructure architecture covers platforms, networks, and runtime environments. Security is often treated as its own domain because every other domain has to satisfy it. A statement such as “customer data has one authoritative source” is an enterprise-level data decision. “This service stores order history in its own database” is a system-level data decision.

What the common architecture roles are for

Job titles for architects vary a great deal between organizations, and the same title can mean quite different work. It is more reliable to describe each role by the scope it works at and the question it is expected to answer. The descriptions below reflect common usage rather than a standard definition.

Role	Usual scope	Main question	Typical outputs
Enterprise architect	Enterprise, sometimes segment	Does the organization’s set of capabilities and technology support its strategy, and where should it head?	Principles, standards, target architecture, capability maps, investment roadmaps
Domain architect (data, application, technology, security)	Enterprise or segment, within one domain	Is this domain coherent across the organization?	Domain standards, reference architectures, data models, platform designs
Solution architect	One capability, within one system or across several	What combination of changes delivers this capability within the constraints?	Solution design, integration design, options and trade-offs, decision records
Systems architect	One system, including hardware, software, and their interaction	How should this system be structured to meet its requirements?	System decomposition, interfaces, allocation of functions to components and infrastructure
Technical architect	Ambiguous; often one system’s technology, sometimes the technology domain	Which technologies and designs will this system use, and how?	Technology choices, detailed designs, deployment designs

Two roles need a caution. Systems architecture is a term from systems engineering, where a system is often treated as more than software and can include hardware and the procedures around it, so a systems architect may decide how functions are split between physical equipment and code. In software-only organizations the term often just means the architecture of one software system. Technical architecture is used loosely enough that it is worth asking what a person with that title actually decides before relying on the label.

Martin Fowler’s guide to software architecture offers a useful way to think about all of these roles. He recounts Ralph Johnson’s view that there is no objective line between fundamental and detailed design, summed up as “Architecture is about the important stuff. Whatever that is.” Fowler adds that which decisions are important depends on the scale of the context. At the level of one application, the development team shares a fairly unified purpose. At the level of the enterprise, many groups with different purposes have to coexist. Each architecture role, then, is responsible for identifying what is important at its own scale, not for every decision beneath it.

Logical structure, physical deployment, and operating responsibility

Within any single system or solution, three descriptions are often folded into one diagram even though they answer different questions.

• Logical structure describes what the parts are, what each one is responsible for, and how they depend on one another, without saying where they run.
• Physical deployment describes where instances of those parts run: which environments, regions, clusters, managed services, and network boundaries.
• Operating responsibility describes who runs each part, who changes it, who is alerted when it fails, and who decides what correct behavior is.

The first two have a long history. Philippe Kruchten’s 1995 “4+1” view model separated a logical view, organized around the functions a system provides, from a physical view that maps software onto processing nodes and is shaped mainly by non-functional requirements such as availability, reliability, performance, and scalability. He also described a process view for concurrency and distribution and a development view for how code is organized, all tied together by scenarios. Kruchten expected one logical design to have several physical configurations, for example separate ones for testing and for each customer site.

The C4 model, a separate and much later notation, draws the same boundary. Its container diagrams show the applications and data stores that make up a system, while its deployment diagrams show how instances of those containers are placed onto infrastructure in a particular environment, naming infrastructure architects and operations staff as part of the audience. The two models are organized differently: 4+1 divides the description into views for different stakeholders’ concerns, tied together by scenarios, while C4 divides it by level of detail, from system context down to code. Both still treat what the parts are and where they run as descriptions that should be produced separately.

Operating responsibility is rarely drawn as a view of its own, but it diverges from the other two just as often. Consider the order events proposal once it is built.

View	What it says about order events
Logical	The order service publishes order change events to a topic. An analytics ingestion job consumes them and writes to an order history table. The event schema is a contract between the two.
Physical	The topic lives on a managed streaming cluster in the company’s primary cloud region, reachable only through a private network endpoint. The ingestion job runs on the data platform’s shared compute in the same region.
Operating responsibility	The platform team runs the streaming cluster. The order team owns the producer and the event schema. The analytics team owns the ingestion job and the table. Changes to the schema require both teams to agree.

Keeping the views apart shows where problems hide. A logical design can be sound while its deployment breaks a data residency rule because the cluster sits in the wrong region. Moving from a self-hosted cluster to a managed service changes the physical view and the operating responsibility, and it can leave the logical view untouched, as long as the components keep the same responsibilities and the same interfaces. That condition is worth checking rather than assuming. If the managed service does not support a feature the design relied on, and the team adds an adapter or a compensating component to work around it, the logical structure has changed too, and calling the move a pure deployment change will hide that. Where the condition does hold, a diagram that merges all three views makes the migration look larger than it is, while also hiding the fact that ownership of cluster operations is changing hands. A similar separation, between the parts that configure a system and the parts that do its work, is the distinction between a control plane and a data plane.

How decisions at one level constrain the next

Higher levels should not make lower-level decisions, but they do set limits on them. Four instruments carry those limits, and they differ in how much freedom they leave.

Instrument	What it is	Example	Freedom left to lower levels
Principle	A statement of intent that guides choices without naming them	Customer data has one authoritative source	High: teams choose how to comply
Standard	A specific required or approved choice	Event streaming uses the company’s managed streaming service	Low within its subject, none on that point
Reference architecture	A proven pattern that teams are expected to start from	A template for event-driven integration, including schema management and a dead-letter path	Medium: deviations are allowed but should be explained
Exception	An approved, recorded departure from a standard, with an owner and a review date	One team uses a different broker for an acquired product until it is migrated	Case by case

Constraints should also be traceable in the other direction. The federal framework calls this line of sight: work at lower levels of detail should have a visible path to the outcomes of the organization. In practice this means a system design can point to the requirements and constraints it satisfies, a solution can point to the business capability it delivers, and a standard can point to the principle or risk that justifies it. The idea of traceability is the same one, applied to requirements and design choices.

Deciding which level should make a particular decision is where most friction comes from. Three questions give a practical answer.

• Who else is affected? If the choice changes what other teams must do, such as an identity model or a shared data format, it belongs at the level that includes those teams.
• How hard is it to reverse? A library choice inside one service can be undone by that team. A contract with a vendor, a data residency arrangement, or an event schema with many consumers cannot, so those decisions deserve a higher level of review.
• Whose risk and budget does it spend? A decision that commits company money or accepts company-wide risk needs someone with authority over that money or risk, whatever the technical scope.

Decisions that are local, easy to reverse, and within a team’s own budget and risk authority should stay with the team. Pulling them upward produces review boards that become bottlenecks and designs made by people far from the details. The opposite failure is just as common and more expensive to fix. A team adopts a new database engine or a new identity provider for one system, other teams start depending on it, and the organization discovers years later that it made an enterprise decision without anyone deciding it. Recording significant choices in an architecture decision record, with the level at which the decision was made, makes both failures easier to spot.

When nobody has the title, and when everybody wants the meeting

Everything above describes where decisions belong. It does not say how one actually gets made, and that gap is where the levels break down in practice. Two opposite failures are common. In one, every significant choice waits for a review board that meets fortnightly, so teams either stall or route around it. In the other, there is no architecture function at all, and the levels exist only in retrospect, when someone notices that a system-level choice has become a company-wide dependency.

The roles in the table earlier are questions, not job titles. A company with no one called an architect still has to answer them. Someone decides which technologies are approved, someone judges whether an initiative fits with the systems around it, and someone structures each system. In smaller organizations those answers usually come from a principal engineer, a head of engineering, and the teams themselves. The risk is not that the titles are missing but that nobody notices which question is going unanswered.

Andrew Harmel-Law’s 2021 description of an advice process offers one way to run this without a board. Its rule is that anyone may make an architectural decision. Its qualifier is that before deciding, the decider must consult two groups: the people meaningfully affected, and the people with expertise in the area. The decider does not need agreement and does not have to follow the advice. They do have to seek it, listen, and record it, with the advisors named, in the decision record itself. Organizations using the process keep a consultation checklist that maps subjects to the people who must be asked, for example the security lead for anything touching information security, or legal and the data team for anything touching personal data.

Harmel-Law pairs this with an architecture advisory forum: a weekly hour with team delegates and subject-matter experts, open to anyone, where proposed decisions are discussed as decision records. The distinction that makes it work is that attendees give advice and the decision stays with whoever raised it. A forum that approves or rejects is a review board with a friendlier name, and it recreates the queue.

This process is not free. It moves effort from approving to consulting and recording, and it depends on people actually writing down decisions and the advice they received. A team that adopts the process without carrying out the consultation and recording gets only decisions made faster, so building that habit is part of the adoption cost. It also assumes the deciders can recognize when a choice has reached beyond their level, which is what the three questions above are for.

It is important not to read the advice process as a replacement for authority. Harmel-Law’s rule removes the requirement to obtain agreement; it does not transfer anyone’s budget or risk mandate. Those are separate things, and conflating them produces the situation where a team consults widely, records the advice properly, and signs a contract nobody was entitled to sign. The two fit together through delegation.

Situation	How the decision is made
Within the team’s delegated authority: its own budget, its own risk, reversible by the team	The team seeks advice from the affected and the expert, records it, and decides. No approval step.
Beyond the delegation: spends money the team does not hold, accepts risk on the company’s behalf, or commits the organization contractually	The advice process still applies to the technical choice, and the person who holds that budget or risk mandate approves the commitment. Complying with an existing standard does not remove that requirement.
Changes the rules others work under: setting a principle, changing a standard, granting an exception	Approved at the level the rule applies to, because the decision binds teams that are not in the room.

Stated as one sentence: inside its delegated scope a team consults and then decides, and outside that scope the approval belongs to whoever carries the consequence. What makes this workable is that the delegation is written down. Where teams do not know the size of contract, the category of data, or the class of risk they may commit to on their own, every decision is potentially the one that needed a signature, and the organization drifts back toward asking permission for everything.

Whatever the mechanism, an exception deserves particular care, because it is the one instrument meant to be temporary. An exception without a named owner and a review date is not necessarily undocumented, but it is unmanaged: nothing brings it back for a decision, so a temporary departure becomes permanent without anyone choosing to make it permanent. The standard it departs from then means less than the register suggests.

References

• U.S. Office of Management and Budget, Federal Enterprise Architecture Framework Version 2 (2013, PDF)
• Philippe Kruchten, The 4+1 View Model of Architecture (IEEE Software 12(6), 1995)
• Simon Brown, The C4 Model: Deployment Diagram
• Martin Fowler, Software Architecture Guide (martinfowler.com, 2019)
• Andrew Harmel-Law, Scaling the Practice of Architecture, Conversationally (martinfowler.com, 2021)