Introduction

Over the years, software architecture models and frameworks have come a long way, evolving to address the challenges and complexities in the world of software development. Starting from the early days of the Zachman Framework, moving on to the more comprehensive TOGAF, then to the 4+1 architectural view model, and finally, to the more recent C4 model, the progress has been significant.

Each of these models have provided architects and developers with new ways to approach software design and address the ever-changing demands of the industry.

However, something is still not exactly right, and we have set out to fix this problem.

As much as these frameworks have evolved, their real-world application in complex digital transformations has been a challenging endeavor. Advanced frameworks like TOGAF and Zachman, while offering a comprehensive and structured approach to software architecture, can be difficult to implement effectively in practical situations.

The sheer complexity of these frameworks can sometimes make it hard for architects and developers to derive tangible value from them, especially when dealing with large-scale, intricate digital transformation projects.

In this article, we will explore the evolution of software architecture models, their strengths and limitations, and how newer models like C4 aim to strike a balance between complexity and practicality to make a real difference in the world of software architecture.

We are taken it one step further by arguing that we should experiment and collaborate around the creation of new and more suitable software architecture models via an open-source project. We link to one such project that for now presents C4 and a revised model called C5:

https://www.softwarearchitecturemodels.com/

This document is derived from the following open-source project.

https://github.com/Sprinting-Software/software-architecture-models

A Short History of Enterprise and Software Architecture Frameworks

Let us have a condensed overview of the history of some selected enterprise and/or software architecture frameworks.

Zachman Framework:

• Introduced by John A. Zachman in the 1980s as an approach to enterprise architecture.
• Provides an ontology, that is, a classification system that can be used to organise software architecture artefacts (documents)
• Based on a 6×6 matrix, where each cell represents an intersection between a perspective (who, what, when, where, why, how) and an audience perspective (planner, owner, designer, builder, implementer, user).
• Considered one of the earliest and most influential frameworks in the field of enterprise architecture.
• Mainly focused on the holistic representation of an organisation’s architecture rather than being specifically tailored to software systems.
• We link to the official source on the Zachman Framework.

TOGAF (The Open Group Architecture Framework):

• Developed in the 1990s by The Open Group, an international consortium of organisations.
• A comprehensive, industry-standard framework for enterprise architecture that guides organisations through the entire process of creating, maintaining, and managing their architecture.
• Contains a detailed methodology called the Architecture Development Method (ADM) that provides a step-by-step approach for designing and implementing an enterprise architecture.
• Offers a wide range of tools, techniques, conceptual models and reference models to support architects and developers.
• While extremely thorough, it can be complex and time-consuming to implement, especially for smaller organisations or projects.

4+1 Architectural Model:

• Consists of five standard diagrams (also called views) called Logical, Development, Process and Physical View plus Scenarios.
• The Logical View represents the main functional elements, their relationships, and interactions in terms of object-oriented abstractions.
• The Process View focuses on the system’s concurrency and synchronisation aspects, while the physical view deals with the system’s deployment and distribution aspects.
• The Development View illustrates the software’s organisation in terms of modules and components, while the Scenario View (also known as the use case view) captures end-user functionality and interactions.
• The key concepts of this model include Component, Connectors, Module, Sub-System, Layer, Process, Message, Event and more.
• We link to the original article for reference.

C4 Model:

• The C4 model starts from four key concepts: Software System, Container, Component and Code. These four concepts form a hierarchical set of abstractions that are suited to describe the static structure of a software system.
• The C4 model favours simplicity over sophistication, making it easy to understand and reason about software architecture.
• Although the C4-model is notation-agnostic, in most circumstances C4-diagrams are easily recognisable due to simplicity of the model and the clear example diagrams presented on the c4-website

Let us conclude this overview by having a concise comparison, highlighting what makes each of the models distinctly different from the other models:

• Zachman Framework provides a generic and abstract ontology (classification system) for enterprise architecture artefacts.
• TOGAF is an extensive and complete Enterprise Architecture framework providing both an elaborate conceptual model around enterprise architecture, a structure for architectural artefacts, a methodology for architects, tools, guidelines and techniques.
• The 4+1 Model provides a standard for five specific architecture diagrams based on a particular set of concepts, notation and diagramming conventions.
• The C4 Model provides a concise terminology around four key concepts used to describe the static structure of a software system, together with a flexible notation guide and a handful of architecture diagram examples to guide software architecture.

To boil it down even more, we can say:

• Zachman Framework provides a generic and abstract structure for Enterprise Architecture artefacts (documents)
• TOGAF provides an all-inclusive framework for Enterprise Architecture
• The 4+1 Model provides a standard for 5 software architecture diagrams
• The C4 Model provides four key concepts together with some conventions of how to describe the static structure of a software system.

Enterprise Architecture vs Software Architecture

In the previous section, we went over four of the most influential models/frameworks on enterprise and software architecture. However, we have not really been clear on what is the difference between enterprise and software architecture. Let us clear that out now.

Enterprise architecture and software architecture are related disciplines that focus on the design, organisation, and management of systems. However, they differ in scope, objectives, and the types of problems they address.

Enterprise Architecture is characterised as follows:

• Scope: EA covers the entire enterprise, including its strategic and tactical objectives, business processes, organisational structure, governance, information systems, data, applications, system landscape, technology, and infrastructure. It it typically split up into four so-called architectural domains: business, data, application and technology architecture.
• Objectives: EA aims to align the organisation’s IT resources and capabilities with its business goals, ensuring efficiency, scalability, and adaptability. It is supposed to help in managing complexity, reducing risks, and facilitating decision-making across the organisation.

Software Architecture is characterised as follows:

• Scope: Software architecture should cover the design and implementation of software systems, including their components, modules, interfaces, interactions, and behaviour. It includes various views or perspectives, such as the logical architecture, physical architecture, deployment architecture, and operational architecture. It also addresses various concerns, such as functional requirements, quality attributes, constraints, and trade-offs.
• Objectives: Software architecture aims to satisfy the functional and non-functional requirements of the system, such as performance, scalability, security, maintainability, and usability. It helps in managing complexity, minimizing risks, and ensuring quality and reliability of the system.

Frameworks vs Models

Another thing that wasn’t clearly defined is the distinction between a Model and a Framework. Both are used in the field of enterprise architecture and software architecture to guide the design, development, and management of systems. However, they differ in their scope, purpose, and level of abstraction.

In brief, we can say that a framework is larger than a model. We could also say that a framework is a model + methodology.

Being a bit more accurate, we can say that an architecture framework provides a standardised structure, methodology and set of tools for developing and managing architectures. It typically includes a set of principles, concepts, and practices that guide the creation of architectural artifacts, such as models, diagrams, and specifications.

On the other hand, an architecture model can have two contradicting meanings, and the reader should be aware of the distinction.

1. A model can refer to a concrete set of views (or diagrams) describing a concrete enterprise or system landscape. Such a model could include a context view, data model view, a component view, an integration view and a deployment view.
2. A model can refer to a model for a model, also called a metamodel. When we refer to the C4 Model, it is really a metamodel, not a model.

For the scope of this article, whenever we use the word “model”, we really mean “metamodel” as in bullet 2, in the same sense as C4 is commonly referred to as a model, although it really is a metamodel. If we really want to refer to a model in the sense of bullet 1, we will call it a model instance.

With this understanding, it should now be clear that:

• Zachman is an enterprise architecture model
• TOGAF is an enterprise architecture framework
• 4+1 is a software architecture framework
• C4 is a software architecture model

We can summarise these ideas in the following way:

In addition, we can illustrate the building blocks of an Enterprise Architecture Framework as follow.

Open-sourcing software architecture models

Software architecture models are essential to the software industry for several reasons. First, they provide a shared language for developers, architects and business stakeholders to reason about AS-IS and TO-BE system landscapes in complex enterprises.

Second, they enable software architects to clearly communicate their vision and decisions to stakeholders, such as developers, managers, and customers. Finally, they help in managing complexity by breaking down the system landscape into smaller, more manageable components which allows for planning and execution of digital transformation programs.

In spite of the importance of software architecture models, they are notoriously hard to get right. On most enterprises I have been, there has been a mixture of overly complex utilisation of TOGAF by one group of people combined with informal utilisation of C4 among other groups of people.

This is a problem because TOGAF actually has a complete overlap with C4, and this overlap is inconsistent. If you study the Architectural domains of TOGAF, you will find that the Application domain serves a similar purpose as C4 but it uses entirely different concepts such as Information System Service, Logical Application Component and Physical Application Component.

I have yet to meet an architect who can reliably map between a C4 diagram and a TOGAF diagram from the Application domain. It simply doesn’t add up and leads to nothing but confusion and lack of clarity.

For these reasons, it is my belief that we as an industry need to experiment and collaborate to converge toward a future consensus around architecture models. I believe we should focus on the model, not the framework, in other words, we should focus on the inner core which is the architecture models consisting of concepts and diagram standards.

We could increase the focus more by focusing on a single architectural domain such as software architecture. This is illustrated in blue below.

It is my hope that we via consensus-building and standardisation can help in establishing best practices and guidelines to create better architecture models, promoting quality, consistency, and interoperability across different systems. Open-source tools and platforms seem perfect for the creation of such industry standards as they provide a collaborative and transparent environment for creating and sharing architecture models.

Even though GitHub was originally intended for open-sourcing of code, it can just as well be used for open-sourcing of ideas and standards. This approach may allow architects and developers to experiment and explore new architecture standards.

We have started this initiative on GitHub here:

https://github.com/Sprinting-Software/software-architecture-models

It is created as a GitHub book and the project is nicely rendered here:

http://www.softwarearchitecturemodels.com/

Feel free to contribute. You can choose to fork the project or make a PR to propose changes to the existing models listed on the page, or to present your own favorite.