Information systems are complex. How can we deal with it?
Each of us was in a situation when we started a completely new #project or (a slightly worse situation) - we were forced to work on the legacy system. Both scenarios require us to #visualize our system's future #structure somehow or discover how the current system works. However, the most important thing is that such a diagram should be the basis for communication between various stakeholders of our project - #programmers, product owners, customers, etc.
Each of us has our way of building these kinds of #diagrams. However, are they understandable to everyone in our #team? Can we understand our diagram in a week, month, or year? We will look at a few examples.
Approach 1 – brainstorming
In other words, we take a board and start drawing. The result of such brainstorming is usually a diagram, which we digitize at the end of the day - taking pictures with the phone so that our office cleaning staff don't remove our "project" at night. Below we see a photo of a diagram from our office - about a year ago.
As an element of brainstorming - the above diagram was certainly understandable at its inception. However, do we remember now what it was all about? Does anyone remember precisely why there are quotation marks? The diagram is not legible. It cannot be used both as documentation or communication between team members or contact with the client. Each developer/architect will use their notation (which we may not understand in the future). So let's try to recall a slightly more structured system of architecture documentation.
Approach 2 – UML
Figure 1- https://en.wikipedia.org/wiki/Class_diagram
Probably each of us encountered the UML language on our way. Some struggled with it during our studies, and others learned its elements while working. The UML language consists of several different types of diagrams related to the structure of the system being built and its behavior. The UML standard itself is pervasive. It includes many rules, shapes, etc. For this reason, it is an excellent tool for an analyst but not necessarily a good tool for communication between team members or contact with the client.
Currently, few programmers and even architects know all the details of the UML standard. There is a reason for this. Maintaining documentation created with the help of UML is expensive. Adjusting the diagram to the current system structure can be difficult, and as a result, the state of the documentation has little to do with the current system over time.
In addition, the complexity of this type of diagram does not make it a good tool for communication between team members. The created model requires technical knowledge to understand it. However, there are some elements of UML diagrams that have caught on very well:
Use case diagrams
Class diagrams used to visualize specific design pattern
Class diagrams used to model business domain
Sequence/state diagrams
UML also defines the so-called "Component diagrams" and "deployment diagrams", which are interesting for us from the architectural point of view.
Figure 2 - https://cdn-images.visual-paradigm.com/guide/uml/what-is-component-diagram/02-component-diagram-overview.png
Component diagrams include system elements with a slightly higher level of abstraction than classes in the context of object-oriented languages - depending on the technology, we can talk about assemblies or packages. This level allows us to illustrate, for example, the architecture of our code within the application.
Figure 3 - https://modernanalyst.com/Portals/0/Public%20Uploads/customer_client_form.png
The deployment diagram also includes hardware elements - servers, indicating communication between them.
Without going into details, we can note that:
They are pretty "ugly" - very subjective, of course, but you have to admit that the form of the diagrams takes us a bit back to the 90s.
They are not simple. The notation and rules behind these diagrams are not obvious. It may not be easy to create or interpret such a diagram without prior preparation. In other words, these diagrams cannot serve as a universal element of communication and information about the system architecture.
Some elements remain unclear even here - e.g., arrows between BankingClient and BankingServer. Is the communication synchronous or asynchronous?
Certainly, UML diagrams are helpful and have their place in the software development process. However, we would like to find a slightly simpler system suitable for both brainstorming sessions and subsequent documentation and communication in the team.
C4 model
Simon Brown proposed the C4 model. It is an additional tool that allows you to visualize our architecture in an accessible way.
The C4 model is based on four levels of abstraction. We can imagine them as a map that we zoom in more and more. In the beginning, we see a map with a dot representing the entire city. Then we go down to the level of individual streets. We look at the architecture of our systems similarly. Finally, we go from the general level to the details.
The individual levels of the C4 model (starting with the most general):
C1 – context diagram
Figure 4 - https://c4model.com/
This level represents a bird's eye view of our entire system. We mainly see our system (defined as a single element, regardless of how many applications it includes), actors, and external systems with which we communicate. In this case, we focus on the environment of our system. We do not go into the technical aspects of the system. Our system may internally consist of many more minor elements deployed separately.
The elements we see here are:
actors
software system
external systems
C2 - containers
Figure 5 - https://c4model.com/
The C2 view allows us to focus on the internal elements of our system. Note: the word container has nothing to do with Docker here (although of course, our system may use it).
The container can be a server application, web application, database, etc.
An important rule: in general, a container is an application that represents a separate deployment unit. We disregard here whether, for example, both applications are running on one physical server.
Additionally, the diagram shows the lines that define the communication between the containers.
Each item must be clearly described. This may seem redundant, but remember that people of different technical levels of advancement may later use our model. We also want the created model to be clear in a month or a year.
Let's take a look at the arrows representing communication between containers. It is worth noting that communication between modules is often two-way. Even so, in our diagram, most of the arrows have an arrowhead on one side. Remember that we want to mark on the diagram elements which initiate communication. Typically, the communication between the two containers is not fully symmetric. Some element here is usually more active or passive.At this level, we have:
actors
external systems
containers (you can say that we have broken the software system into several containers)
C3 - components
Figure 6 - https://c4model.com/
The component diagram lets us peek "inside" the containers and see their internal structure. The equivalent of this diagram could be a "Component diagram" from UML. It is up to us what elements to put on the diagram. The important thing is that we don't have to place all the details in one model - in this case, the controllers. We put the key elements on the diagram from the architectural point of view. It does not mean that, e.g., the system described above does not contain other controllers within the API project.
Elements on the diagram:
actors
external systems
containers
components (we break down a given container into components to present their internal structure)
C4 – code level
At this point, we got down to the code level. Simon Brown recommends skipping this level altogether. Why? Because at this stage, we are at the level of individual classes. We can, of course, build a class diagram and use other elements, e.g., UML. Unfortunately, this type of documentation is of little use because it quickly becomes out of date. Usually, keeping such documentation fully compliant with the code is highly time-consuming and does not pay off.
Summary - More about the C4 model
As you can see, the C4 model is not complicated. The elements described can be found in other models such as UML. Its advantage is the simplicity and intuitive way of building our model from general to more detailed views. This analogy is usually intuitive to any team member.
The C4 itself is nothing new, but it's still common to meet a team that hasn't heard of it. So I hope you found this short helpful material.
A great introduction to the C4 model is the presentation of its creator - Simon Brown, which can be found on Youtube. https://www.youtube.com/watch?v=x2-rSnhpw0g https://c4model.com/
Which approach do you think is better? For which projects? Feel free to write us a comment and tell us why!
I invite you to read more in next articles!
Comentarios