Architecture Levels and Terminology

As with many other areas of software development, the same terminology is often used in different ways and the same term can mean different things to different people.

System vs Application

In the interest of cataloguing architecture concerns, resources and patterns, this is the classification I use:

• System — a collection of multiple applications, services and infrastructure components that provide an enterprise capability.

• Application — a bounded set of components or services that provides a distinct software unit focused on a cohesive set of business functions or tasks.

In this context, an application is often owned and developed by a single team and is often deployed as a unit, though it might be split into multiple technical components that are deployed separately to meet technical and non-functional requirements. A system as a whole is often developed by multiple teams, with each team responsible for different business capabilities that together serve the enterprise, or a part of it.

System Architecture vs Application Architecture

• System Architecture — the structure of a specific technical system: its hardware, software, networking, and how components interact to meet functional and non-functional requirements (scalability, reliability, security). Broader than one application — it can span multiple applications, services, and infrastructure that together form a system.

• Application Architecture — the internal design of a single application: its layers, modules, patterns (e.g. MVC, layered, hexagonal), and how its components interact with each other and with external systems.

What about Solution Architecture?

The terms Solution Architecture and Solution Architect are often used in the industry, probably more so than “System Architect”. The terms are also loosely defined. As I use it, Solution Architecture is more of a role or activity than a static structure. It’s the discipline of designing a solution to a specific business problem, spanning whatever is needed to deliver it: the applications, integrations, infrastructure, data flows, and sometimes process or organisational elements. It’s typically project-scoped and time-bound — you’re solving this problem, for this initiative, and the architecture is judged by how well it satisfies that specific set of requirements (functional, non-functional, cost, timeline).

A Solution Architect’s output is often a system architecture (plus the surrounding decisions — technology choices, migration approach, cost trade-offs, risk).

In short:

• Solution Architecture is the process, the role and the decision-making.
• System Architecture is the resulting technical structure or blueprint.

For classifying architecture styles, principles and patterns, I find the split between system and application architecture more useful. A system or application outlives any particular project, and the split reflects the different concerns at each level.

Other Architecture Classifications

The above definition of System Architecture and Application Architecture, and the split between the two, has an engineering or technical focus. There are other classifications of architecture. For example, TOGAF defines four architecture domains: Business Architecture, Data Architecture, Application Architecture and Technology Architecture (BDAT). In this classification, Application Architecture provides a blueprint for the individual applications to be deployed, their interactions, and their relationships to core business processes. This is more business- or portfolio-oriented (enterprise planning).

My own focus is at the technical level: system and application architecture. The enterprise view still matters to that work. Understanding the business is part of Context Is King, and enterprise architecture gives teams a shared direction, provided its standards and processes stay proportionate (see Don’t Be Too Rigid).

Data Architecture

Traditional data architecture (the definition of canonical or enterprise data models, for example standardising the definition of Customer across an enterprise or organisation) is something I see much less of than I used to. I’ve worked with clients who put a lot of effort into it, but microservice architectures and techniques such as Domain-Driven Design have promoted the concept of “bounded contexts”, with applications and services owning their own data, moving away from shared data services. This is particularly true in transactional systems. Data analytics is different: in data lakes and data warehouses, a shared, well-defined data model still has a place.