Explore the six layers of architecture through a 360-degree lens, bridging executive vision with technical detail to align business and technology for clarity, strategy, and success.
Organisations today are built on software. This is invisible to most employees, leadership, and customers. Good architecture makes it visible; great architecture helps us understand it, enabling us to map out our future with clarity.
Successful companies operate three pages ahead, not three pages behind. Read on to learn how the six layers of great architecture grant 360 vision showing where you are and how to lead towards your company’s goals.
- Introduction
- The Six Levels of Great Architecture
- #1 Executive Layer of Architecture: A High-Level Strategic Overview
- #2 Enterprise Architecture: Mapping the Technology Landscape
- #3 Domain Architecture: Aligning Business and Technology
- #4 Application Architecture: Detailed Design and System Interactions
- #5 System Architecture: Zooming into Core Functionality
- #6 Component Architecture: Building Blocks for Engineering Success
- Further Reading: Exploring the 360-Degree Lens of Architecture and Other Models
- Conclusion
Introduction
In today’s complex organisations, architecture isn’t just about technology—it’s about providing a comprehensive, interconnected view of how technology and business align. The six-layer framework introduced here acts as a 360-degree architecture lens, enabling teams to zoom seamlessly between high-level strategy and detailed implementation.
This holistic 360-degree lens ensures that every stakeholder—from board executives to junior engineers—has the clarity they need to make informed decisions. By bridging these perspectives, the framework not only improves technical accuracy but also fosters stronger collaboration, alignment, and business outcomes.
This lens doesn’t just focus on individual aspects; it ensures every layer of the architecture connects with the others, creating a cohesive view that adapts as your organisation evolves. Each layer builds upon the previous, offering a unified vision that remains actionable at every level.
The Six Levels of Great Architecture
Shining a light through the 360-degree lens on technology underlying the business reveals clarity, context, and actionable insights. This perspective is not the sole responsibility of Architecture teams, though they are accountable for ensuring this clarity is visible and understood from the Executive layer to the newly joined contributor.
Underpinning these levels of great architectural clarity there must be ownership. Roughly, the stack ownership should be shared 50/50 with Engineering, with clarity of ownership at the top and bottom two layers, and a mixed ownership between.
A Note on Roadmaps
Roadmaps are what sit between a current and a future state diagram—and they can exist at any level. From the perspective of a 360-degree lens, these roadmaps serve as pathways that ensure strategic alignment between the present state of your architecture and your envisioned goals.
Roughly, roadmaps should come towards the end of the exercise.
- Map the current state: Diagrams articulating the current state should come first and be accurate.
- Converge on the vision: Investment of time to ensure the company vision & goals in the relevant area are understood.
- Map out the future: High-level future state prepared & circulated with relevant stakeholders.
- Forge a path: Begin roadmapping.
#1 Executive Layer of Architecture: A High-Level Strategic Overview
Owners: Head of Architecture, Principal Architects.
Purpose: To allow the Executive and Senior Management across the Organisation to understand what makes up of the Enterprise Estate, how it all connects and their domains. To facilitate conversations about specific initiatives and how they provide improvements to the business.
Analogy: The 3D model of a building or large site development.
Why Architecture Needs Design and Marketing
This Executive layer, when seen through the 360-degree lens, becomes a vital storytelling tool. By blending technical insight with modern design and marketing principles, architecture teams can craft visuals and narratives that resonate with leadership. The goal at this level is to help people who lack deep context to quickly understand the message. These people are busy and will move on quickly or dismiss a topic that fails to speak their language.
Many teams fail to show up at this level or if they do, haven’t adjusted their approach to meet the communication style and expectations of Executives and Senior Management.
Architecture teams must push themselves to break free of the visual and design standards prevalent within Technology and pull in advisors from Customer and User Experience teams. These documents must not only be correct, they must look good, be simple and consumable by top managers and the Executive.
At this level teams are competing for time with other departments like Marketing, Product, and Sales. As such, this level of Architecture must be written in a way that is easily consumed by the Executives and the Board. It must be consumable and quickly get the point across.
Simple is best. Omission of irrelevant portions is fine so long as the truth is preserved. Stay out of the detail unless necessary. Each diagram must be designed for the purpose and audience it is intended for.
Base Camp and the Mountain
Through the 360-degree lens, this level is where the current Enterprise position meets the company’s vision and mission. It describes both the base camp and the mountain, providing a clear picture of where we are, the outcomes required, and the path to get there.
Current state diagrams are an opportunity for Technology to show the Business where we are. The future state versions are an opportunity for Technology to help the Business understand why, on the way to the destination the Organisation may need to invest in more or different work than is intuitive.
This level is where the team describes the base camp and the mountain, proving both an understanding of where we are, the outcome required and the path to get there.
#2 Enterprise Architecture: Mapping the Technology Landscape
Owners: Head of Architecture, Principal Architects.
Purpose: To provide a clear and accurate technical view of the Enterprise Estate.
Analogy: The blueprint of a building, with references to deeper levels of detail.
The Reference and the Map
This level is often the highest in traditional architecture teams. There can be a tendency to merge this layer with the Executive level described above. This is a mistake: the two have very different purposes and should be treated as distinct levels of architecture.
While the Executive level is often used to provide a high-level overview of the Enterprise, the Enterprise level is where the team provides a clear and accurate technical view of the Enterprise Estate.
The Reference
The current-state diagrams at this layer must deliver an accurate, high-detail view of the organisation’s domains. These diagrams group domain-level blocks, providing essential context for understanding how key applications interact. They are crucial for identifying unnecessary complexity, duplication, and other opportunities for improvement.
Key benefits of this layer include:
- Identifying problem areas: Highlighting problematic vendors, outdated systems, and potential risks.
- Spotting inefficiencies: Exposing duplication of functionality and areas for system/team consolidation.
- Revealing gaps: Identifying missing components, such as the need for a unified billing or sales system.
- Validating alignment: Confirming whether the Technology Estate aligns with both explicit and implicit business domains.
By focusing on these aspects, this layer serves as a foundation for refining the broader architecture. These insights can inspire high-level representations used in Executive-level discussions to emphasise key issues and proposed solutions.
The Map
The future-state diagrams at this level serve as navigational tools. They chart the course for ongoing and upcoming change programs, clearly illustrating the improvements these programs aim to deliver. Through the 360-degree lens, these maps should highlight the transformation from the current to the desired future state, showcasing the alignment with strategic goals.
Key aspects of this mapping process include:
- Flexibility during early stages: Diagrams remain adaptable during discovery and design phases, ensuring accuracy as the future state becomes more defined.
- Actionable insights for stakeholders: Providing clear, digestible visualisations that enable discussions with key sponsors and stakeholders about how investments will yield measurable improvements.
This dynamic interplay between the Reference and the Map solidifies the Enterprise layer’s role as a critical bridge between the strategic and technical aspects of architecture.
#3 Domain Architecture: Aligning Business and Technology
Owners: Solution Architects, Principal Engineers.
Purpose: To ensure domain owner(s) have clarity on their accountabilities from a technology ownership and hand-off perspective. To facilitate better conversations about how the organisation is or is not enabling the right focus and alignment between the business (intended domains) and technology (actual domains).
Analogy: Floorplan or layout of a proposed multi-story building, broken up into ground and lower level commercial, mid-level apartments, and upper-level penthouse hotel suites.
Cooperative Governance and Alignment
All layers require collaboration, but this is the first where ownership is shared between Engineering and Architecture. Through the 360-degree lens, this layer represents the intersection of high-level architecture diagrams and detailed design.
Architecture assures alignment with the broader Enterprise and Executive views, while Engineering ensures coherence with Application and Component layers. This collaboration fosters clarity, accountability, and a unified approach to domain-level challenges.
No leader can lead without knowing who and what they lead or where they are to go: the domain level provides this for both current and future state. It must be built by and understood by both parties:
- Architecture assures it is aligned with the Enterprise and Executive views.
- Engineering assures it is aligned with the Application and Component views.
Domains and Conway
Conway’s Law is particularly relevant here: the structures that Engineering teams create often mirror the structures of the organisations they work within. Accurate domain maps empower leaders to scrutinise these structures, evaluating their validity and exploring pathways for improvement.
Domain-level diagrams provide a framework to address:
- Technical debt: Exposing inefficiencies and outdated structures that need modernisation.
- Organisational debt: Highlighting misalignments between technical and business domains.
- Transformation opportunities: Articulating the pathway to a more effective future state, underpinned by aligned domains and improved functionality.
This layer’s insights allow organisations to identify and mitigate risks, streamline operations, and establish a robust foundation for sustainable growth. Building competence here will support success in layers up and down the stack. Great collaboration between Architecture and Engineering teams provide evidence for correctness of designs at the Enterprise and Executive level.
This is where organisations can unlock the ability to “see around corners”, as the Architecture and Engineering teams combine their skillsets and vision.
#4 Application Architecture: Detailed Design and System Interactions
Owners: Solution Architects, Principal Engineers.
Purpose: To provide a detailed diagrammatic explanation of an individual application, showcasing key systems, their interactions, and their connections to upstream and downstream applications and domains.
Analogy: A detailed design of a single floor in a multi-story building, illustrating connections to other floors, potential bridges to neighbouring buildings, and room layouts as block-level representations.
LEGO Sets and Their Instructions
This layer of architecture should be treated like LEGO sets, particularly in large organisations. Here, the Application diagrams function as the instruction booklets. These diagrams should provide enough detail to enable the seamless assembly or modification of components and highlight any dependencies on external systems.
Using the LEGO modular buildings analogy, the goal for any target state modifications and roadmaps should be to ensure each application delivers essential functionality while remaining independent enough to avoid over-reliance on peer applications.
When tight dependencies exist, the level above: Domain-level diagrams should flag these as constraints, turning them into opportunities for improvement.
Cooperative Governance
The Application layer reinforces the critical partnership between Engineering and Architecture. Key responsibilities include:
- Architecture’s Role: Ensuring applications align with higher-level Enterprise and Domain views while delivering intended outcomes.
- Engineering’s Role: Guaranteeing that applications are built to specification and functioning as designed. Engineering teams should actively participate in redesigns and replacement planning to ensure long-term viability.
By fostering this collaborative governance model, organisations can optimise their application architecture to better meet both technical and business objectives.
As described in the Domain section, these two layers are an opportunity for Architecture and Engineering to integrate the organisation’s vision and lead together.
#5 System Architecture: Zooming into Core Functionality
Owners: Lead Engineers, Senior Engineers.
Purpose: To provide a zoomed-in view of a single system within an application, focusing on specific functions such as checking account names via third-party services or processing transactions.
Analogy: A detailed outline of a single room, showing desk arrangements, seating, adjoining facilities, entrances and exits, and the tools required to fulfill its purpose.
Zoom in, Enhance
If the Application layer represents a LEGO instruction booklet, the System layer is akin to a single page from that booklet. It offers focused, high-detail insights into specific system and are typically documented in a Detailed Design Document (DDD).
A typical documentation repository for an application may include:
- A high-level Application view.
- Links to relevant Domain-level diagrams.
- A collection of DDDs, each describing logically grouped functionalities.
This layer is instrumental in supporting squads as they design, build, and maintain functionality within existing applications.
As Built and Assured
At the System layer, the emphasis is on precision and assurance. It offers:
- Detailed Functionality Maps: Including API call structures, system dependencies, and integration points.
- Support Documentation: Covering troubleshooting guides, disaster recovery protocols, and operational procedures.
- Compliance Assurance: Particularly critical in regulated industries, where this layer demonstrates adherence to governance and regulatory requirements.
For stakeholders, the System layer ensures that teams are delivering what they’ve promised while maintaining alignment with broader enterprise goals. It also provides the foundation for rigorous review and approval processes, ensuring consistency, quality, and compliance across the estate.
By zooming into individual systems, this layer empowers engineers to build robust solutions while maintaining alignment with organisational objectives.
#6 Component Architecture: Building Blocks for Engineering Success
Owners: Lead Engineers, Senior Engineers.
Purpose: To provide clarity to the engineering team responsible for building each individual component of a system. The lowest level formal design should go down to the specific components and serve as the starting point to understand how something was built.
Analogy: A detailed view of a single item within a room, for example, a chair or a computer.
The Nuts and Bolts
This layer provides the essential detail required to ensure that engineers know what to build, and that the right components are being built. It is also used to verify and trace the “as-built” state, especially during audits.
The Component-level diagram is often part of a DDD and focuses on the individual pieces that make up a system, such as an API call handler, a button, or a form. This layer is pivotal when the system requires complex, reusable components that must function across various contexts.
Although uncommon, the Component-level view is distinct from the System level and holds significant value.
This layer is particularly useful for detailing complex functionality or reusable components that form the foundation of broader system behaviour. For simpler systems, it may not be necessary, but for organisations relying on modular and reusable components, the Component layer ensures everything is designed to specification and is easy to trace and maintain.
For DDDs that require integrating new components from an Enterprise component library, this documentation becomes crucial to ensure clarity and consistency.
Further Reading: Exploring the 360-Degree Lens of Architecture and Other Models
Integrated Architecture Framework (IAF)
The layers and approach described in this post can complement many existing models. Dive into how the 360-degree lens enhances the Integrated Architecture Framework (IAF) by reading: A 360-Degree Lens on IAF: Integrating the 6 Layers of Architecture.
TOGAF
To explore a comparison between the 360-Degree Model and the TOGAF framework, which is widely used for enterprise architecture, check out Choosing the Right Architecture Framework: A 360-Degree Approach vs. TOGAF. This article discusses at a high level the methods and approaches of TOGAF and how it contrasts with more flexible, lighter approaches like the 360-degree lens.
Conclusion
The six levels of architecture presented here form a comprehensive but light framework that bridges the gap between executive vision and technical implementation. Each layer serves a distinct purpose, whether providing executive clarity or enabling detailed component-level understanding. When viewed through a 360-degree lens, this layered approach ensures that architecture fulfils its core value: illuminating current states and charting the path forward.
By maintaining clear distinctions between these levels while ensuring they work in harmony, organisations can better align their technology landscape with strategic business objectives. This framework not only provides the necessary tools for effective communication across all levels of the organisation but also ensures that architectural decisions remain grounded in both business value and technical reality.
The success of modern organisations increasingly depends on their ability to navigate complex technical landscapes. Through these six layers of architectural knowledge and vision, businesses create a shared understanding that empowers better decision-making, fosters more effective communication, and drives successful outcomes.
