Reference architecture definition, framework landscape, and required detail…

Research Question

What should a practical reference architecture include, which established architecture frameworks define or structure it, and how much detail should be specified across capabilities, components, flow diagrams, and technology choices so that stakeholders can use it consistently?

Findings

Executive Summary

A practical reference architecture should define a reusable architecture description, the work product ISO/IEC/IEEE 42010 uses to express architecture, and organize that description through stakeholder-oriented views and viewpoints as TOGAF describes them, rather than collapsing directly into an implementation blueprint. ISO/IEC/IEEE 42010 and TOGAF together supply the structural side of that answer, architecture description, views, viewpoints, and reference material, while Azure, AWS, and Google Cloud show how those ideas appear in working reference-architecture artifacts such as diagrams, workflows, named components, and review considerations. The most reliable detail ladder is three-tiered: capability or conceptual reference architecture, logical or pattern reference architecture, and implementation or deployment architecture, with each level adding commitments that the level above intentionally leaves open. As a working heuristic, stakeholder requests for a reference architecture often map to one of three needs, common vocabulary, reusable solution pattern, or bounded implementation standard, so clarifying which need is in scope is the key scoping move.

Key Findings

1. A practical reference architecture should be treated as a reusable architecture description, the work product used to express architecture, that is organized through stakeholder-oriented views and viewpoints instead of being reduced to a single diagram or a list of products.
2. ISO/IEC/IEEE 42010 provides the structural grammar for architecture descriptions, while TOGAF adds more operational guidance on selecting viewpoints, reference models, and concrete views, so together they cover both expression and reuse of the architecture artifact in practice.
3. Official cloud reference architectures commonly include a canonical diagram, a flow or workflow description, named components, and explicit quality or control considerations in the same artifact family.
4. The minimum viable detail level for a reference architecture is logical rather than deployment-specific: it should name stable building blocks, their responsibilities, the major interaction paths, and the constraints used to evaluate later implementations.
5. Flow diagrams belong in a reference architecture when they show how requests, data, control actions, and trust boundaries move across components, because those flows determine whether the pattern is secure, operable, and scalable enough to reuse.
6. Exact technology choices should usually remain optional or be expressed as bounded options in a reference architecture, because the official frameworks repeatedly pair reusable guidance with an explicit instruction to tailor the pattern to local environment, risk, and operating needs.
7. Implementation architecture starts when the artifact commits to environment-specific topology, selected services or products, service tiers, operational procedures, resilience settings, and production control mechanisms instead of staying at the reusable-pattern level.
8. A useful detail ladder has three levels, conceptual or capability reference architecture, logical or pattern reference architecture, and implementation or deployment architecture, because official guidance separates reusable structure from environment-specific commitments and production controls.
9. A useful working heuristic is that the phrase "we need a reference architecture" can hide three different requests, common vocabulary, reusable pattern, or implementation baseline, so architects should clarify which deliverable is actually wanted before locking the artifact shape.

Assumptions

• Assumption: The older public Open Group pages on views and viewpoints remain representative of the current TOGAF treatment of stakeholder-oriented views. Justification: The current TOGAF overview still frames the standard around configurable detail and reusable guidance, and the older pages expose the core concepts directly.

Analysis

ISO/IEC/IEEE 42010 answers the structural question but intentionally does not prescribe one architecture artifact shape, which is why a standards-only answer would still leave teams uncertain about deliverable form. TOGAF answers more of the practical enterprise-architecture question by tying stakeholder concerns to views, viewpoints, reference models, and view selection, which is the missing bridge between formal architecture description and usable architecture work products. Azure provides the clearest evidence for the detail ladder because one official example separates architecture, workflow, components, and considerations, then explicitly explains why the basic version is not production-ready and what the next level adds. AWS and Google qualify the opposite failure mode, overcommitting too early, by repeatedly framing reference architectures as guidance to review and tailor, supported by principles such as design for change, modularity, and environment-specific adaptation. A plausible rival remedy is to force every reference architecture to name one preferred technology stack so projects move faster. That can be useful for a platform-standard profile, but it is a different artifact type because it trades reuse breadth for governance speed and vendor commitment.

Risks, Gaps, and Uncertainties

• The most detailed directly accessible TOGAF evidence in this session came from older public Open Group pages plus the current TOGAF overview rather than the latest full standard text.
• The cloud-vendor examples are strong for practical document shape and detail boundaries, but they are still vendor-authored examples and therefore stronger on artifact form than on a universal enterprise taxonomy.
• The conclusion about what stakeholders usually mean by "reference architecture" is a synthesis of framework structure and observed artifact patterns rather than a direct survey result.

Open Questions

• Should this repository formalize a house template that separates conceptual reference architecture, logical pattern architecture, and implementation architecture into explicit sections or file types?
• Which governance domains, identity, data, network, observability, and policy, should always be mandatory viewpoints in enterprise reference architectures, regardless of workload?
• Would a lightweight intake checklist reduce ambiguity by forcing requesters to choose between vocabulary map, reusable pattern, and implementation baseline before architecture work starts?

sources

• [x] The Open Group TOGAF - enterprise architecture framework overview and positioning
• [x] The Open Group Developing Architecture Views - official Open Group explanation of views, viewpoints, concerns, and progressive detail
• [x] The Open Group Consider different architecture reference models, viewpoints, and tools - official Open Group step guidance on selecting reference models and concrete views
• [x] ISO/IEC/IEEE 42010 Systems and software engineering - Architecture description - formal architecture description structure and viewpoint requirements
• [x] Microsoft Azure Architecture Center - catalog of reference architectures, guides, and decision support
• [x] Microsoft Azure Reference Architectures - Azure reference architecture entry point
• [x] Microsoft Azure Basic web app reference architecture - concrete example with architecture, workflow, components, and considerations
• [x] Microsoft Azure Well-Architected Framework - workload design principles and technical design areas
• [x] AWS Architecture Center - AWS architecture guidance entry point
• [x] AWS Well-Architected Framework - architecture evaluation and design best practices
• [x] AWS Key components of an AWS web hosting architecture - concrete component and flow guidance
• [x] AWS Security Reference Architecture introduction - official AWS reference architecture guidance and tailoring boundary
• [x] AWS Modern Data Analytics Reference Architecture on AWS - concrete multi-component reference architecture with numbered flows
• [x] Google Cloud Architecture Center - enterprise architecture guidance entry point
• [x] Google Cloud Well-Architected Framework - pillars, perspectives, documentation, and design-for-change guidance
• [x] Google Cloud Well-Architected Framework Operational excellence pillar - operational design principles and continuous improvement guidance
• [x] Google Cloud Implement zero trust - example of control concerns expressed as layered recommendations
• [x] Google Cloud Promote modular design - modular component and clear-interface guidance
• [x] Mitchell (2026) Technology Capability Models: Survey, Comparison, and Recommendation for Multi-Level IT Capability Mapping - prior completed item on framework combinations and capability abstraction