Most architecture reviews begin with a diagram. Boxes represent services. Arrows represent data flows. Technologies are named, cloud providers are identified, and eventually someone asks whether Kafka should replace Pub/Sub or whether Kubernetes would be a better fit than Cloud Run. These discussions are often technically interesting. They are also frequently incomplete.
After more than a eight years designing data platforms, one lesson has become increasingly clear: the quality of an architecture is rarely determined by the technologies it contains. It is determined by whether its engineering decisions make sense given the problem it was built to solve.
That observation inspired the architecture review framework we use at Data S2. Its objective is not to judge architectures as good or bad. Instead, it provides a structured way to understand why certain decisions were made, which constraints shaped them, and what lessons they offer for future systems.
The framework deliberately begins with the business problem. This may seem obvious, yet many architecture discussions skip directly to infrastructure. Experienced engineers know that the same technology can be either an excellent or a poor choice depending entirely on the business objective. A fraud detection platform, a recommendation engine, and a financial reporting system may all use similar technologies while requiring fundamentally different architectural decisions. Without understanding the problem first, evaluating the architecture becomes little more than comparing products.
The second step examines architectural constraints. Every real system operates under limits. Some must respond within milliseconds. Others prioritize consistency over availability. Some operate under strict regulatory requirements. Others optimize almost exclusively for cost.
Constraints are not obstacles to architecture. They are the reason architecture exists. Two systems solving similar business problems may look completely different because their operational constraints differ. Understanding those constraints often explains engineering decisions that initially appear surprising.
Once the problem and constraints are understood, meaningful discussion about engineering trade-offs becomes possible. Every architecture accepts compromises. Choosing managed services may reduce operational burden while limiting flexibility. A streaming architecture may reduce decision latency while increasing operational complexity. Event sourcing may improve auditability while making debugging more difficult. Trade-offs are not architectural flaws. They are evidence that engineers prioritized one objective over another. Good architecture reviews make those priorities visible instead of pretending perfect solutions exist.
This perspective naturally leads to identifying what works well.
Engineering reviews often spend disproportionate time searching for weaknesses. That approach overlooks an important opportunity. Well-designed systems deserve careful study because they reveal reasoning that can be applied elsewhere.
Perhaps the engineering team minimized blast radius through service isolation. Perhaps they simplified deployment through managed infrastructure. Perhaps they intentionally accepted eventual consistency because the business process tolerated it. Understanding successful decisions is often more valuable than cataloging mistakes.
Critical evaluation remains important, but it should be grounded in objectives rather than personal preference. For this reason, every review asks a slightly different question. Instead of asking, “What is wrong with this architecture?” It asks, “If my primary objective were different, what would I redesign?”
This subtle shift changes the conversation. Replacing one database with another becomes less interesting than discussing why the original decision optimized for scalability instead of operational simplicity. Architecture criticism becomes an exercise in reasoning rather than opinion.
Another distinctive aspect of the framework is the use of Minimum Context Signals (MCS) as an analytical lens. Importantly, MCS is not treated as the subject of the review. Instead, it serves as one additional perspective for evaluating engineering decisions.
Every architecture processes information. The interesting question is whether every piece of information actually contributes to the decision being made.
Many systems accumulate dependencies simply because data is available. Additional enrichment pipelines, more feature stores, larger event payloads, increasingly complex orchestration — all appear individually reasonable. Collectively, they may increase latency, operational cost, and failure probability while contributing very little additional decision quality.
Viewing an architecture through the lens of Minimum Context Signals encourages a different question.
Which contextual signals are genuinely required before the system can make a reliable decision?
Sometimes the answer is surprisingly small. This perspective often reveals opportunities to simplify systems without reducing capability.
Finally, every review concludes with practical lessons. An architecture review should not end with admiration for a well-designed system. Nor should it end with criticism of imperfect decisions.
It should leave engineers with ideas they can apply tomorrow. Perhaps that means separating online and offline workloads. Perhaps it means reducing architectural coupling. Perhaps it means questioning whether a new dependency truly improves decision quality.
The objective is transfer of reasoning rather than transfer of technology. This philosophy reflects a broader belief about engineering.
Architectures are snapshots of decisions made under uncertainty. They represent constraints, assumptions, priorities, available technologies, organizational culture, and business realities at a specific moment in time. Evaluating them without understanding those forces risks producing elegant but ultimately superficial analysis.
By following a consistent review structure — from business problem through engineering trade-offs to operational lessons — we hope to move architectural discussions beyond diagrams and technology comparisons.
Our goal is not to identify the “best” architecture. It is to understand why intelligent engineers made the decisions they did, what those decisions teach us, and how that reasoning can improve the systems we design next.
After all, the most valuable architecture review is not the one that tells us whether a system is good or bad. It is the one that changes the way we think before we draw the next architecture diagram.
References
[1] Bass, L., Clements, P., & Kazman, R. Software Architecture in Practice. Addison-Wesley, 2021.
[2] Richards, M., & Ford, N. Fundamentals of Software Architecture. O’Reilly Media, 2020.
[3] Newman, S. Building Microservices. O’Reilly Media, 2021.
[4] Simon, H. A. The Sciences of the Artificial. MIT Press, 1996.