Y-Statement – Capturing (wh)y behind Architectural Decisions
Introduction
Architecture Decision Records (ADRs) answer “why” questions about design and architectural options. One of the key elements is being able to clearly articulate why any architectural direction was chosen. There are many industry approaches for capturing the rationale and reasoning behind choosing one option over another. Among those, the Y‑statement has proven to be a simple yet effective way to capture key decision rationale.
Why Y-statement
Modern architecture teams use several templates for documenting architectural decisions. While they all aim to capture what was decided and why, they differ in complexity, attributes, and intended usage. The table below provides a concise comparison of the seven widely used practitioner templates summarized in academic literature.
Olaf Zimmermann‘s research and paper on this is inspirational. Below is my understanding of his WICSA 2015 paper; it does make sense to choose Y‑statement for most cases when you want to keep it simple and move fast without compromising on context, objectives, decision rationale, and consequences considered.
| Template | Complexity | Key Strengths | Key Limitations | Typical Usage |
|---|---|---|---|---|
| IEEE 42010 Template | Medium | Strong structure, includes rationale, traceability, and scoping guidance | More formal; heavier than lightweight ADR styles | Enterprise architecture, governance-heavy environments |
| IBM UMF | High | Most comprehensive; includes implications, assumptions, categorisation | Heavyweight, not publicly documented in full | Large organisations with formal design processes |
| Tyree/Akerman | High | Detailed: status, drivers, related decisions; widely adopted | High documentation effort | Traditional architecture reviews; complex systems |
| Bredemeyer Key Decisions | Medium | Clear focus on business & technical drivers; practical | Lacks alternatives/options structure | Early-stage strategy & foundational decisions |
| Nygard ADRs | Low | Lightweight; simple headers; easy to adopt | Minimal attributes; limited traceability | Agile teams, developer-centric decision logging |
| arc42 Decision Section | Low | Integrated into broader architecture documentation; concise | “Why” often less explicit; questions format may vary | Teams already using arc42 template |
| Y‑Statements | Ultra‑light | One-sentence clarity; captures context, drivers, decision, trade-offs | Too terse for complex decisions; limited metadata | Fast-moving teams; complement to ADRs |
What is “Y-Statement”
The purpose of a Y‑statement is to summarise the decision context, the objective, and the chosen option. It also highlights what will be achieved with the decision and whether there are any potential downsides.
Here is the structure:
In the context of << Functional Requirement, Architecture Component>>
facing objectives <<Non-functional requirements/concerns>>
we made decision to/for <<Option 1/ chosen option>>
and passed-over / neglected << option 2, 3…>>
to achieve << intended result/outcome/result>>
accepting downside << consequence, trade-offs >>
Example:
Below is a real‑world example of a Y‑statement that should be included in an “Architecture Decision Record“
In the context of implementing an enterprise metamodel repository for architecture assets (capabilities, applications, data entities, integrations, controls, and lineage),facing the need to model highly connected knowledge, support deep impact analysis across domains, and evolve schemas without disrupting consumers, we decided for a graph datastore using Amazon Neptune (RDF/Property Graph) within the AWS ecosystem and neglected a relational (Amazon RDS/PostgreSQL) or key‑value/document approach (Amazon DynamoDB) and search‑optimised stores (Amazon OpenSearch)to achieve expressive relationship traversal (multi‑hop queries), flexible schema evolution, standards‑based query (SPARQL/Gremlin), and native support for lineage/traceability, accepting the need to invest in graph modeling discipline, specialised query skills, data governance for ontologies/vocabularies, and the operational overhead of capacity planning, backups, and security hardening of a managed graph cluster.
Conclusion
The Y-statement is intentionally lightweight, and that’s exactly why it works. It forces clarity, intent, and articulation of not just what you’re doing, but why it matters and what you’re willing to trade off to get there.
When you embed Y-statements into your ADRs, you elevate your architecture practice: decisions become auditable, defensible, and easier for others to understand long after the context fades. Good architecture isn’t just about making decisions—it’s about making the rationale behind them obvious.