A Summary of Architecture Part 1: What is it?

12 min readMay 6, 2022

Overview

This is a 3 part series looking at architecture in all its forms, and asking:

Part 1: What is architecture and what does it involve (this part)
Part 2: Who is doing architecture, and why
Part 3: How do we do architecture, and how does this fit with all the other roles, delivery methods and frameworks

What is architecture?

Definitions abound! But are often more complicated than they are helpful. Usually, there are a few common themes where architecture exists to:

Bring structure, making things easier to understand by showing how larger and more complex things are comprised of smaller and simpler things
Brings the structure to life by showing how things interact, describing X talking to Y and Z, passing ABC information to achieve DEF for the HIJ user
Brings a repeatable method for designing and building things that increases the chances of the customer being happy for a longer time
Balances the focus of delivery teams across functional (what it does) and non-functional aspects (performance, scalability, security, resilience, maintainability, future changeability)

What is in an architecture?

An architecture is a big and complex thing, likely to include:

A lot of text explaining why something is required, how it is to be designed, built and run, how it will work, and how it supports the customers long term goals
Models and diagrams bringing the text to life, describing the structure, composition and interaction of components
Plans, blueprints and specifications for building the systems the architecture describes
Standards, guidelines, principles and constraints describing how the architecture was constructed, and how implementation projects should proceed
An as-is view showing what is there today, a to-be view describing what will eventually be there, and a roadmap describing the steps needed to get from the as-is to the to-be; each of these steps is likely to be realised by a project and is often described as a “transition architecture”
Broad coverage: an architecture isn't just about technology, it should also describe what the end users are actually trying to achieve, and why — independent of any IT systems that might be involved

It takes a lot of effort to create and maintain an architecture and that effort tends to come from expensive people, so it is very important that effort is well spent, and that architectures only go into level of detail required: hence each architecture should include a justification for its existence, outlining what level of detail is required, and how/if the architecture will be maintained.

What kinds are there?

Part of the problem with understanding what an architecture is, is that there are so many kinds of architecture, and each one is different:

An Enterprise Architecture defines a long-term strategy for a company, and a roadmap for implementing it over the next 5–10 years. It’s very broad (covers everything) but not very deep (not much detail), and there is usually only one, covering the whole company (or at least a whole region or division of that company).
A Solutions Architecture defines how each stop on the strategic roadmap is implemented by creating or changing individual systems. It has a shorter term focus (6–18 months), less breadth and more depth than an enterprise architecture, and there will usually be many solutions architectures (i.e. projects) in flight at once. Once the solution is implemented the architecture usually ceases to have relevance, but the product architectures it touched along the way, will be its lasting legacy.
A System or Product Architecture describes how that single system works, and what it talks to. It will have an ongoing lifecycle (i.e., lasts as long as the product exists) and will evolve over time as many different solutions architectures (i.e. projects) request changes to the product. It is likely to have low breadth, but high depth, and there will be many product architectures in a company: as many as there are products. The system architecture is likely to be a wrapper for software, and infrastructure architectures, and may reference a Platform Architecture, if the System is deployed to a platform rather than directly to Infrastructure.
A Software Architecture is a specialised part of a system architecture, that focuses on the application code
An Infrastructure Architecture is a specialised part of a system architecture, that focuses on the infrastructure (servers, storage, networking) — and which depending on deployment choices can become a cloud infrastructure architecture, a hybrid-infrastructure architecture, or any number of on-premises infrastructure architectures
A Platform Architecture is a specialised form of system architecture, that describes how a set of shared services (the platform) are implemented, and how they are consumed by other systems (i.e. those systems using or hosted on the platform). A platform is likely to be a combination of hosting services (i.e. servers, virtual machines, Kubernetes), storage and networking, monitoring, backup & recovery, and deployment.
A Reference Architecture is a generic form of any of the other architectures, acting as an example of what should be covered, how something should work, or providing a taxonomy (a naming convention and classification scheme)
There are many other forms of specialised architecture: Security, Financial, Test, User-Interface, Monitoring, etc.

How do all these architectures fit together?

There should be a single enterprise architecture, that describes the company today (the as-is), a desired end-state (the to-be) and a 5-to-10-year roadmap explaining how to get to that end-state.
Each of the steps on the enterprise roadmap will be realised by a project, and each project will have its own solutions architecture, describing what that project is delivering.
Each project will require new business and IT systems to be created, and existing ones to be changed or disposed of. Each of these systems will have their own product architecture describing how it works and what it talks to.
Each of those products will have their own software architecture.
Depending how its deployed, the product may have its own infrastructure architecture, or it may be deployed onto a shared platform, if it’s the later, that platform will have a platform architecture of its own, with accompanying software and infrastructure architectures.

Avoiding duplication

As there are many kinds of architecture, there is a high risk of duplicating content across multiple architectures, in architectures contradicting each other, in everything getting stale (out of date, outright incorrect) very quickly, and in the architectures bearing no resemblance to what projects are building / operations are running. There are no silver bullets to solve these problems, but some techniques have emerged:

Go into as little depth as possible, while keeping the architectures feasible. More detail = more maintenance overhead and more risk that maintenance/alignment wont happen, so try to ensure the architectures only contain the things they need to. Apply YAGNI principles
Frequent 360-degree communication and collaboration: the enterprise architect must be talking with the solution and product architects, reviewing their architectures and ensuring they are still in alignment. Architects must also be talking to delivery and operations to ensure they understand how well their architectures are panning out in the real world
Retiring (ie archiving / flagging as no longer relevant) architectures as soon as possible. For example, retiring the solutions architecture as soon as it is delivered, leaving the product architectures to be evolved by future solutions.

Waterfall much?

It’s also quite likely some agile folks will see the above as the worst examples of top-down thinking and waterfall planning. But agile and architecture should be complimentary. Enterprise Architectures are there to provide the high-level structure and inform long term business strategy; Solutions Architectures are there to describe how each step in Enterprise Roadmap is to be realised at a medium level of detail, and Software Architectures are there to facilitate agile software development and fill in the low-level details needed to build and run the IT systems introduced in the Solutions Architectue. To get long term success, the enterprise, solutions and software Architcture will need to work with the engineers and everyone should be pulling in the same direction, i.e. the architecture has to be useful to the engineers, not a oft-mocked document sat on a shelf. Hence engineers are critical stakeholders in the construction of the architecture.

The many types of architecture will be covered in more detail later, for now, it is enough to remember every architecture is different but there are some common elements that every architecture must deal with, and top of that list is managing complexity

Managing Complexity:

To keep architectures manageable, it is common to separate them into chunks, which include:

Domains, grouping a set of related concerns, and allowing a consumer of the architecture to focus on once concern at a time, for example: business, information, IT Systems etc.
Layers, or levels of abstraction, allowing consumers to focus on “why”, “what”, “how”, and “with what”
Cross-references, binding and indexing the domains and layers together into a coherent whole — so if someone asks, “why is this thing here?” the logic can be traced back to a good reason
RAIDD (Risks, Issues, Assumptions, Decisions, and Dependencies) help record how we got here, and what we were worried about

Architecture Domains

Architecture Domains include:

Business Architecture — describing what business problems the architecture is trying to solve: who are the users, and what do they want to achieve (regardless of what the IT services get provisioned) — e.g. for Netflix the business architecture is “people anywhere want to consume movies and TV shows”
Information Architecture — describing what information and data is needed, and how/where it is created, modified and deleted — e.g. for Netflix the Information architecture describes the customers, their subscription packages & bills, the shows, and the statistics on who watched what”
IT Systems Architecture — describing what applications must be created to realise the Business Architecture, and how those applications must communicate — e.g. for Netflix this describes the mobile app, the website, the back-end streaming services, the billing engine, the helpdesk.
Technology Architecture — describing what hardware and software is required to run the IT Systems: what servers, storage, networking.
Security Architecture — that describes the confidentiality, availability, and integrity controls, are required — e.g. for Netflix how are user accounts protected from hackers, what DRM is on the movies, and how do we ensure Netflix services are always available for use.
Governance Architecture — describing the operational controls allowing us to be certain the service is working: the monitoring & auditing, the rate-limiting / throttling, and the fraud detection.

Architecture Layers

And each Architecture is going to have several layers — potentially associated with phases the architecture goes through while it is being created

Contextual — explaining the “why” and laying out the ground rules for this architecture: standards, principles, tech-policy, constraints
Conceptual — explaining the “what do we need” to realise the architecture; but not yet attempting to understand how we realise it — the brainstorming phase
Logical — explaining the “how do we realise” the conceptual architecture, grouping all the requirements into a simplified set of logical “chunks” that might eventually become IT systems, or purchased as COTS packages and SaaS services
Physical — explaining the “with what will we achieve this” mapping the logical components into things we will actually build or purchase as COTS packages and SaaS services.

The Integrated Architecture Framework’s view of Domains and Layers

Models

Each of the domains, and the conceptual, logical and physical layers will be comprised of architecture models, and explanatory text like the decision log.

The models can include:

Lists of things: like business services, applications, and servers, including descriptions of those things (why they exist, what they do, who uses them) and architecturally significant functional and non-functional requirements (clients must provide an OAUTH2 key, backups must be taken every 4 hours, service must respond in under 3 seconds, and support 99.99% uptime)
The composition of things: e.g. that “The Ordering System” is comprised of services handling “create order”, “approve order”, “send order”, “validate order has been delivered”, “send order to billing system”
The interactions between things: e.g. that the Ordering System passes Order Information to the Billing System, which then passes Account Updates to the Finance System
Service levels for interactions e.g. the Ordering System can pass the Billing System up to 10 transactions per-second, each of which can be 5kb in size, and each request must contain a valid OAUTH2 authentication token

Each architecture role will have a preferred way of creating architecture diagrams. For example, an enterprise or solutions architect may prefer to use the OpenGroup’s TOGAF method for creating models, and their Archimate diagramming language, whereas as Software Architect may prefer UML or Simon Brown’s C4 method.

In many ways the actual method being used to develop the architecture, and the diagramming styles don’t matter, so long as all consumers understand the method and can work with the diagrams.

Cross References

There are many cross references within an architecture — these hold the individual architecture together, and include elements like:

Business to Information: what information is created or processed by each part of the business?
Business to IT Systems: which parts of the business process does each IT system support?
IT System to Technology: what infrastructure do the IT Systems need to be deployed onto?
Physical to Logical: how do these sets of concerns actually get realised?
Contextual to Conceptual: why do these concerns matter / what part of the strategy are they here to deliver?

These cross references can navigate the architecture, answering questions like “who cares if the server 123 goes down?” Cross referencing from server 123 (Technology Domain) to email system (IT System Domain), then from email system to the billing process that uses it (Business Domain) to the realisation that if server 123 goes down, we can no longer bill clients — therefore server 123 needs to be highly available and monitored properly.

Example of cross references done as diagrams

There are also cross-references between architectures — which are vital for ensuring a system architecture correctly realises the vision of a solutions architecture, and that the solutions architecture is aligned with the enterprise strategy:

Solution to System: this solution architecture changes those 3 product architectures
Enterprise to Solution: this step in the enterprise architecture roadmap is realised by that solutions architecture
System to Platform: this system is deployed on that platform

Therefore, the navigations can also map a Platform Architecture onto several System Architectures, then go from those System Architectures to the steps on the Enterprise Roadmap they realise, to understand how a single Platform supports the Enterprise Architecture, and how that Platform will evolve as multiple Solutions change it.

RAID Logs

These are about project and stakeholder management — a vital part of the architecture role. They help record the things we are worried about, and the actions we are taking to make those things less worrying. They probably form the majority of our day-to-day actions.

Risks — bad things that might happen, that we need to monitor, make less likely, and add mitigation so if they do happen, it doesn’t hurt as much
Issues — bad things that have happened, that we now need to make easier to live with
Assumptions — things we have guessed at, so that we can carry on and make progress, but that we need to keep an eye on, and influence so they are more likely to go the way we hope, or that if they don’t, it won’t hurt so much
Decisions — the things we chose to do, and wrote down to share with others, so everyone knows how and why we ended up where we did
Dependencies — the external things we need to go our way, that we are tracking and working to make sure they go the way want or preparing in case they don’t so it doesn’t hurt so bad.

They might sound like a project manager job — but it is essential the architect is on top of this stuff, and is actively prioritising the work to close down every open risk/issue/assumption/decision and dependency

Wrap-up

This post asked what an architecture is, and introduced the common domains (business, information, IT systems and technology), the layers (contextual, conceptual, logical, physical) and the kinds of cross references we do between layers, domains and architectures.

The post introduced some of the kinds (enterprise, solutions, system) of architecture, and in part 2 we will look at each of those in more detail. Part 3 will then ask how we do architecture, and part 5 covers how does this fit with all the other roles, delivery methods and frameworks

Lastly, it answered the question “why do I want one”: to increase the likelihood the end customer will continue to be happy.

Context