Architecture is multi-dimensional

architecting   architecture documentation   architecture  

---

---

Architecture means different things to different people. One reason it’s an overloaded term is because architecture is multi-dimensional. In this article, I briefly explore the different dimensions of architecture. But let’s first look at the classic definition of architecture.

The classic definition of architecture

My favorite definition of architecture comes from Len Bass and colleagues at the Software Engineering Institute, who played a key role in establishing software architecture as a discipline. They define software architecture as follows:

The software architecture of a computing system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.

This is obviously an abstract definition. But its essence is that an application’s architecture is its decomposition into parts (the elements) and the relationships (the relations) between those parts.

As I describe in my book, the exact meaning of element and relationships depends on your perspective or view. Different stakeholders are interested in different dimensions. For example, a developer is typically concerned with elements, such as classes, packages, and modules, and the relationships between them, such as inheritance, associations and dependencies. In contrast, a network engineer typically focusses on elements, such as machines, and relationships, such as networks.

The classic 4+1 view model of architecture

The classic 4+1 view model of architecture describes software architecture using 5 views. The first four views are:

• logical - the object model consisting of classes and their relationships
• development - the application’s code compiled/packaged into modules (e.g. JAR files) and components (e.g. executable JARs or WAR files)
• process - the application’s components as a set of running processes and the communication between them
• physical/deployment - the physical/virtual machines and the processes that run on them

The fifth view (+1) are the scenarios that animate each of the four views and describe the architecture’s dynamic behavior.

Views != diagrams

It’s important to keep in mind that architecture views are not simply diagrams. While the primary way to document an architecture view is a diagram (e.g. using UML), the view itself is a set of elements and relationships. For example, the logical view is the object model, not a UML class diagram. The class diagram is merely one possible way to visualize the object model. Among other things, the view is also described using text.

The +1 is not an afterthought

It’s also to remember that the scenarios that document the dynamic behavior of the architecture are not an afterthought. They are an integral part of thee architecture description. Without the scenarios, you merely have a lifeless collection of boxes and lines.

My preferred architectural views

Over the years, my preferred way of describing architecture has evolved away from the classic 4+1 view model. For example, in my Using scenarios to reinvigorate your microservice architecture presentation, I described four dimensions: implementation, logical, deployment, and deployment pipeline.

These days I tend to think of architecture as having the following dimensions:

• Domain (was logical) - the organization of programming language elements - classes, packages, etc - into subdomains/bounded contexts
• Component (was implementation) - the organization of the subdomains/bounded contexts into executable/deployment units, e.g. monolith vs. microservices
• Deployment - the deployment technologies, such as Kubernetes
• Pipeline - how changes flow from developers to production

In addition, there are the scenarios that animate each of these views.

Domain-driven design (DDD) is focussed on the logical dimension. However, since it involves build-vs-buy decisions, it also touches on the other dimensions. For example, the purchased software that implements a supporting or generic subdomain could very well be a separate application, e.g. SaaS.

The success triangle is mostly focussed on the component architecture - monolithic architecture vs. microservice architecture - and the deployment pipeline architecture since these are the dimensions - along with a well-designed (e.g. loose (design-time) coupled) domain architecture - that affect the ability to deliver software rapidly, frequently, reliably and sustainably.

Need help with accelerating software delivery?

I’m available to help your organization improve agility and competitiveness through better software architecture: training workshops, architecture reviews, etc.

Learn more about how I can help