A Summary of Architecture Part 2: Who is doing it?

13 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
Part 2: Who is doing architecture, and why (this part)
Part 3: How do we do architecture, and how does this fit with all the other roles, delivery methods and frameworks

Recap

Part 1 asked “what is architecture, why do we do it and what does it involve”. It then described the constituent parts (models, domains, layers, cross-references and RAIDDs) and introduced several kinds of architecture, each with a different purpose, scope and level of detail.

This part of the series is going to look at each of these types of architecture in more detail, describe why these architectures exist and who uses them.

Enterprise Architecture

Comes from the idea that success requires everyone in the company to understand the mission: who the customer is, how we help them, why they would pick us, how we are different from all the other companies, and critically: ensuring everyone in the company is pulling in the same direction. It is a top-down approach, meaning Enterprise Architects (actually management consultants), should be few in number, and operating at the top of a company — at heads-of-division or board level. They are there to translate the company’s aspirational mission statement into a long-term strategy, ensure that strategy gets implemented through a series of projects, and ensure everyone in the company is bought into that strategy and those projects.

They will be dealing with a 5 to 10 year planning horizons, making very long-term decisions, or “the big bets” on which the company builds its future. They will spend a lot of time talking about contextual architecture (strategy, roadmaps, principles, constraints, tech-policy) — the major concerns that guide everything a company does. They will also be very interested in the business architecture (i.e. “what the company does for its clients”), but relatively little time talking about technology architecture (i.e. what IT systems the company has). They definitely shouldn’t be down in the weeds of provisioning AWS infrastructure but could be guiding the decisions of whether the company uses AWS, Azure or GCP, and whether they will build cloud-native or cloud-hosted solutions.

What might Contextual Architecture involve? Let’s look at couple of companies selling mobile phones.

Apple focus on a very small range of luxury products, they emphasis user-experience and quality of service, and charge an exceptional margin. Hence, everything they do, every product the sell, every advert they release, every interaction with their customers is designed “quality product”. The trade-offs are that they don’t sell to everyone, only to people who subscribe to their brand of “quality product”, and they have to be obsessive over every aspect of their product: the best screens, the best CPUs, the best software — i.e. they must control their supply chains ensuring every supplier subscribes to the same quality ethos.
Samsung focus on selling something to everyone, they emphasise choice: doesn’t matter if you want a budget phone, midrange, top-end, or the latest 17-camera folding phone, they will have a product for you. Hence their Business Architecture is built around catering for everyone, with the trade-offs are that they have many more products to design/support, so they can’t provide Apple-level service on every product, and over time the products that don’t become successful will quickly become end of life (leading to complaints) or increasingly expensive to support.

Contextual Architecture isn’t about saying whether Apple or Samsung phones are better. It’s about knowing what the company is selling, to whom, and why, so that all of its products and processes, and all of its IT systems and applications can be optimised around that purpose. It’s about Apple knowing they aren’t competing with Samsung’s budget phones, and Samsung not competing with Apple’s length of product support.

The WHO and the WHY are critical in for all architecture. Failed companies often forget the WHY when they create their business or technology architectures. For example, Blockbuster thought they existed to rent video tapes, so didn’t try to complete with Netflix in streaming movies. Kodak thought they existed to sell camera film, so didn’t try to create digital camera. These companies focused on WHAT they did, not WHY they did it. Enterprise Architecture should have reminded them that they existed to help people watch movies and to create memories and would have helped their businesses adapt to the changing ways their customers sought to watch movies and create memories.

Solution Architecture

If Enterprise Architecture is about corporate strategy and 5 to 10-year journeys, a Solutions Architecture is about taking one of the steps on that journey. A single solutions architecture is likely to touch several systems, and each of those systems will have their own software and infrastructure architectures.

As an example, a retail company might be selling products through a chain of shops but have identified, in its enterprise architecture, a need to compete with online retailers. A solution might be developed over several phases to establish that online presence as follows:

MVP: an Alpha-website enabling a small group of pre-selected customers to order a limited range of products and collect/pay at their nearest retail store
Private Beta: expanding the product catalogue, and allowing chosen users to create accounts, introduce a product reviews system, and allow home deliveries
Public Beta: Allow any user to create an account, significantly expand product catalogue, strengthen security controls, introduce promotions and marketing campaigns
Full Service: Quality of service improvements

Each of those solution phases, will require changes to existing systems and the introduction of new systems (i.e. updates/creation of those systems product-architectures)

Hence there is likely to be one solutions architecture that describes 4 phases, with each phase describing a high level a set of changes to system architectures. Then a set of system architectures that describe how each of those systems change at a high level of detail. In that sense, the solution architecture is providing a set of requirements for each of those ongoing product architectures, and those product architecture are what actually get realised by the engineers.

Solution architecture phase plan, showing what product architectures each phase impacts

Alongside the solution architectures creating the online services, there are likely to be many other solutions in flight: expanding into a new geography, introducing a new product or service, migrating from an on-prem data centre to a cloud service, patching and upgrading applications, etc. and each of those solutions may also touch some of the same systems. So, it is important the system architectures can absorb changes from multiple solutions at once.

A table of contents for a typical solution is likely to include:

What business problem does this solution solve, and for whom?
How this solution supports the strategic vision?
What systems does this solution depend upon?
How does the solution’s data/users flow between those systems?
What changes are required to those systems? Both functional (what must they allow users to do) and non-functional (volume of users, concurrent requests per-second, response times, authentication, availability, backup & recovery)
How will the solution be implemented (what phases, what releases?)

System (Product) Architecture

A systems architecture describes how that single system works, who uses it / what business problem it solves, what it talks to, what data it creates, updates and deletes, what infrastructure it runs on, and what service levels it provides.

It is the highly detailed set of plans needed to build the system; but isn’t necessarily going to go down to the lowest levels of details in all areas (separate software and infrastructure architectures are more likely to do that).

Unlike a solutions architecture, a systems architecture is going to be a very long-lived artefact surviving for the life of the system it describes and being changed by many different solutions. It might even be incorporating changes for several different solutions in a single release of the system.

A table of contents for a typical solution is likely to include:

What business problem does this system solve, and for whom?
What other systems does this one interact with: what is it dependent on / what is dependent on it?
How this system supports the strategic vision, and complies with tech-policy?
How do any IT applications work, how are they realised, what components, COTS products and libraries are involved (perhaps going down to software design, perhaps referencing a separate software architecture)
What infrastructure or platform services are consumed? What servers, storage, networking (perhaps referencing a separate infrastructure architecture)

Specific sections will cover the system’s functional requirements: such as: what does it do, how do data/users move within the system, and what is passed to/from other systems.

Other sections will cover the non-functional requirements:

How is security handled: what authentication & authorisation, what encryption, what access roles, what auditing and non-repudiation, what firewalls and NACLs?
How is monitoring and alerting handled, what log files are created & under what circumstances, how are incidents to be identified and fixed?
How do users interact with the system (if via user interfaces, what accessibility needs must be met, such as screen-reader compliance)
What performance and scalability is needed: volume of users, concurrent requests per-second, response times, message sizes, throttling, does load vary throughout the day?
What availability is required (e.g. 09:00–17:00 Monday to Friday excluding public holidays, or 24x7x365 at 99.999%), and what failover, backup & recovery
How will the system be implemented? What phases and releases will be needed? How is the system upgraded?
What will the operations team need to do, and how will they do it: e.g. how do they troubleshoot the system, how do they patch/upgrade it?
What housekeeping is in place (e.g. archiving log files, purging old data, restarting failed instances)
Compliance requirements, such as how ISO27001 is evidenced,

And finally, other sections might cover delivery concerns: risks, issues and assumptions to be managed via project delivery and tested by the QA team. Dependencies on other teams, and implementation constraints.

Software Architecture

The software architecture is a specialised form of systems architecture, that focuses on the application code making up that system, and represents a common break point between the architectures using the enterprise style (i.e. Enterprise, Solutions and Systems architectures typically use TOGAF, IAF or Zachman) and those using specialist styles and constructs such as UML for software, or IDF for infrastructure.

The software architecture focusses on the code: how is it structured? What are the specific API constructs? What programming languages and frameworks are used? What versions of what libraries are used? How is the code compiled and how are CI/CD pipelines used to package, test and deploy the code? Hence, the breadth is relatively low: just the components within the architecture; but depth is much greater, with detailed designs often created within the software architecture — although not always by the software architect as detailed design should be owned and carried out by the entire engineering team, not just someone with an architect badge.

There will be some cross over (or at least reference to) the system architecture, describing the business problem this system solves, for whom; dependencies to/from other systems, alignment with the strategic vision, and compliance with tech-policy. However, the focus is at a much lower level of detail, suitable for the software engineers to implement, and the Quality Assurance to assemble tests.

The table of contents for the software architecture document is likely to be pretty similar to the systems architecture, but the focus is different. Everything is about the structure and functionality of the application code. Therefore the modelling will also be different, UML is more likely to be used (other styles also available), class diagrams and sequence diagrams show how the code is structured and how it interacts.

Infrastructure Architecture

The infrastructure architecture (like the software architecture) is a specialised form of systems architecture, that focuses on the compute (servers, storage, networking) required to host the application code. It’s also another a common break point between the architectures using the enterprise style (i.e. Archimate modelling) and specialist styles (i.e. AWS specific symbols and diagrams)

There will be some cross over (or at least reference to) the system architecture, describing the business problem this system solves, for whom; dependencies to/from other systems, alignment with the strategic vision, and compliance with tech-policy. However, the focus is at a lower level of detail with less breadth, suitable for the infrastructure engineers to implement, and the Quality Assurance to assemble tests.

There are a few different styles of infrastructure architecture:

The legacy style of on-premises services built around mainframes (e.g. VME), midrange (e.g. AS/400, Power8), and proprietary compute (e.g. Solaris, AIX)
The more recent on-premises styles using commodity compute (e.g. x86 blade servers) and virtualisation (e.g. VMWare) — potentially air-gapped from the cloud for security and compliance reasons
The cloud hosted solutions, replicating the traditional style on AWS, Azure, GCP and OCI
The cloud provider native solutions, replacing self-built infrastructure stacks (e.g. Oracle Databases, IBM MQs) with cloud SaaS/PaaS solutions (e.g. AuroraDB, SQS)
The cloud provider agnostic solutions, swapping the SaaS/PaaS solutions for super portable and provider agnostic solutions like Kubernetes

Each style of infrastructure architecture will require a different set of specialist skills to realise.

On-premises solutions require datacentre planning, taking into account physical space, power and cooling capacity, and the long lead times needed to order and rack/stack physical servers.
VM based solutions require significant effort to be expended creating and supporting “standard stacks” containing the appropriate configuration of operating system, application servers, system management and monitoring agents, and the necessary configuration, patching and deployment processes.
Cloud based solutions typically require more thought on how to secure the system from internet-based attacks, understanding how the services each cloud provider offers differ, and the capabilities needed to configure, scale, and automate their provisioning.
Platform based solutions are possible in the cloud and on-premises. In this scenario the code isn’t deployed directly to infrastructure, but to a shared hosting platform, such as VMWare or Kubernetes, and this shared platform provides a wide range of hosting services: storage, compute, scalability, monitoring, auto-recovery, release/deployment, and often many more.
More complex and hybrid solutions where a single system is deployed across multiple cloud providers, or multiple styles of architecture (e.g on-premises AND cloud)

Other than that, the table of contents for the infrastructure architecture document is likely to be pretty similar to the systems architecture, but the focus is different: everything is about the “tin” necessary to host the application code and respond to changes in user volumes.

There will also need to be significant consideration given to failure scenarios: when the infra fails, really bad things happen: how can the application be expected to carry on when the network goes down, or the database becomes corrupt? This often requires deployment of high-availability solutions such as additional servers, or even disaster recovery sites offering a complete clone of the infrastructure in alternative facilities that can automatically take over (probably) in the event the primary site suffers an outage. These scenarios are often very difficult to properly test, and such tests can often only reliably be carried out in the production environment — which does not often go down well with the end user.

Infrastructure Architecture concepts like High-Availability Clusters and Disaster Recovery highlight the need for collaboration between architects. Both software and infrastructure architectures must support the disaster recovery approach. The solutions architect must ensure the availability of one system is supported by the availability of its dependent systems. The choice of software components, infrastructure and cloud services must be supported by the technology policy/strategy maintained by the enterprise architects.

Platform Architecture

A platform architecture is a special kind of system architectures, where the user-group isn’t the end user interacting with the application, but one or more application development teams, who will be using the platform to host their applications.

The platform will be built around technologies like VMWare, or a Kubernetes distribution (OpenShift, EKS, Mirantis, etc) and will provide basic infrastructure services like compute, storage and networking. But its benefits come from value-add services the application team can simply consumer (rather than building themselves) such as:

Operations services like: Monitoring, tracing & alerting, and dashboarding of system performance / capacity / uptime / usage, service patching / updating
Deployment services like code releases, testing and roll-back
Infrastructure services like automated and on-demand backup & recovery, automated scale in/out, self-heal, and storage replication and analysis (e.g. searching for PII and key-leaks)
Application services like message queues, publish/subscribe notifications, analytics, task scheduling (e.g. house-keeping activities like purging data and archiving log files)
Developer services like code repositories, task management, wikis, CI/CD
Security services like authentication, authorisation, encryption at rest and in-transit, key management, role-based access control, user-audit

Platform services are often generic, meaning they can be consumed simultaneously by many different application teams. The main use of platforms is to prevent the application developers from having to worry about “the tin”, meaning they can focus all their energy on serving their end-users.

Reference Architectures

Are a generic form of any of the other architectures, acting as an example of what should be covered, showing how something should work, and often providing reference models, such as a taxonomy (naming convention and classification scheme)

TOGAF’s Technical Reference Model — a taxonomy of application and infrastructure services

There are many others. The OpenGroup promote the snappily titled Integrated Information Infrastructure Reference Model, and the AWS Well Architected Framework could be considered a collection of reference architectures for building effective architectures in the cloud.

Other

There are many other forms of specialised architecture: Network, Security, Financial, Test, User-Interface, Monitoring, etc. I haven't covered these here — it’s long enough already!

Summary

This post provided more detail on what each type of architecture is trying to achieve. In summary

An Enterprise Architecture defines a long-term strategy for a company, and a roadmap for implementing it over the next 5–10 years.
A Solutions Architecture defines how each stop on the strategic roadmap is implemented by creating or changing individual systems.
A System or Product Architecture describes how that single system works, and what it talks to.
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).
A Platform Architecture is a specialised form of system architecture, that describes how a set of shared services (the platform) are implemented.
A Reference Architecture is a generic form of any of the other architectures, acting as an example of what should be covered.

How the different kinds of architecture fit together

Context