duynguyendang / software-architecture-models

This is an initiative to allow experimentation with various software architecture models in the form of an open-source project.

Software Architecture Models

An open-source initiative to drive experimentation and consensus around software architecture models.

This document is available on this official web-site and the code is maintained here on GitHub.

About this document

This open-source project sets out to create a standard model for software architecture diagrams. Creating agreement and consensus in the industry about diagramming standards for software architecture is challenging for many reasons. Using the approach, techniques and platforms from the open-source community seems obvious.

This initiative is inspired by the works of Simon Brown called The C4-model and is intended to be a natural evolution of the original ideas presented in his work. This initiative should allow different people to express different competing models so that experimentation can thrive and true consensus can emerge in the industry.

The Models

Each model is described on a sub-page. Please select the model of your choice:

• The C4 Model
• The C5 Model

What is a model?

For the scope of this document, let us define a model for software architecture diagramming, in short 'a model', to be a coherent set of concepts and notation in the following sense:

• concepts: a set of unambiguously defined concepts within software architecture
• notation: a standardized notation for how to depict these concepts in diagrams

One challenge of software architecture in general is the difficulty of defining the core concepts concisely and a model should go head-first on this challenge.

Hence, the concepts should be be defined as consicely as possible, yet the definitions should be unambigious and clear by anyone reading them. If they fail being so, the model is not useful.

In addition, the definitions of concepts should explain the relationship between the concepts so they make up a semantic network (also called a knowledge graph).

Once the concepts are established in this way, we have a solid ground for the notation, which must explain how each concept and each relationship between them can be depicted. If the various concepts can be depicted in several different ways, these variations should be explained as well.

A model should be selective in what concepts are included in the model because the purpose is to create an inner core of concepts that are truly unambigous and fully understood by everyone using the model. Naturally, around every model being adopted there will be an informal language used on an every day basis. Allowing such informal language to develop freely is an important objective of a model. You may say that the model should strive to formalize just enough to provide a solid ground of core concepts to allow an informal conversation to grow out of it.

How you can contribute

This work is licenced under the Creative Common Corporation license. Feel free to re-use, remix or simply make a pull-request to suggest changes to some of the listed models, or propose yet another Software Architecture Model if you find the ones provided here insufficient for your needs. At last, you may always fork the repository to create your own version entirely.