Architecture at Scale

The definitions discussed connect architecture with a decision's significance, the cost of changing it, and the constraints it places on future development. This distinction separates choices that affect several teams or future product capabilities from local implementation details. Applying the same approval process to both turns architectural work into continuous interference with delivery.

The talk distinguishes software architecture, solution architecture, and enterprise architecture. They address different scopes, contexts, tools, and participants. A single set of diagrams or one job title cannot be expected to cover an application's internal structure, relationships between systems, and the company's broader technology landscape equally well. Clarifying the level of a decision helps identify who needs to participate.

Growth in products and geographically distributed teams makes individual leaders' memories an unreliable coordination mechanism. The talk separates everyday design from architectural decisions while retaining the ability to make decisions close to the teams. Regulating every detail does not scale. Teams instead need to agree which changes require wider discussion and how others can understand the reasons behind them.

RFCs and ADRs are discussed in this context. A proposal provides a place to discuss a consequential change, while a decision record preserves the chosen option and its rationale. This makes context available to other teams and future contributors. Documentation does not replace discussion: without a clear purpose and a connection to actual work, a formal record merely adds another layer of paperwork.

At the enterprise level, the talk discusses the Zachman approach and the risk of excessive bureaucracy. The company described does not address the problem simply by appointing a dedicated enterprise architect. Instead of assuming that one method automatically fits every situation, the talk considers practices for maintaining a shared picture while keeping responsibility for products distributed.

One such tool is a technology radar inspired by ThoughtWorks. It supports discussion about adopting technologies, where they fit, and retiring older choices. Platform capabilities and a move toward PaaS provide another way to embed common practices into daily development. The overall principle is to scale the knowledge, rules, and tools available to teams rather than an architect's personal oversight. The appropriate arrangement still depends on the organization's scale and needs.