A useful architecture representation method

"An evolutionary architecture supports guided incremental changes across multiple dimensions." - Rebecca Parson, Neal Ford, and Patrick Kua

Abstract

The purpose of this essay work is to provide insights for the reader to identify A useful architecture representation method.
With the general objective: Propose a base criteria for software architecture representation attributes which are the foundation we should look for.
By detailing an specific software architecture representation, C4 Model, which is a good option for most of our software system it becomes simple for us to understand the basic important abstractions such as: form, behavior and operations.
Then also explaining the benefits, trade-offs made and finally providing recommendations for further improvements for the existing software architecture representation.

Context

Software architecture is an abstraction of a software system. The structures of a software system consists of its elements. Software architecture concerns itself with defining and detailing the structures, their elements, and the relationship of those elements with each other.
While the behavior of the elements does not have to be exhaustively documented, care should be taken in understanding how elements have to be designed and written so they can properly interact with each other. This is the moment where a software architecture representation becomes useful, in this case C4 Model, as the method to describe and communicate in different levels of detail the interaction of this elements.

Body

A proper foundation laid down by a software system's architecture yields a number of benefits, which are visible in the C4 Model representation. Let's take a deeper look at those benefits as we follow the model.

Solution to meet requirements

Software strives to meet all functional, non-functional(covered in the next point), technical, and operational requirements. A software architecture defines a solution that will meet those requirements and is the foundation for software, so software systems that lack a solid architecture make it more difficult to meet all the the requirements. Poor architectures will lead to implementations that fail to meat the measurable goals of quality attributes, and they are typically difficult to maintain, deploy and manage.

By taking advantage of the C4 Model levels available there is a good chance to meet functional, technical, and even perhaps operational requirements for the software system. The first one could possibly be visible by using a supplementary diagram, dynamic diagram, but there is a feeling about losing the simplicity included by the Model. Next one is easily verifiable by the last three levels available because with them have enough detail about this type of requirement. Now regarding the operational requirements we are able to cover them with and existing C4 model A.D. template available, however it does feel like a pretty incomplete approach.

Quality attributes

Quality attributes are measurable and testable properties of a system. The way they satisfy the stakeholders of the system are critical, and the design of a software architecture could be made to focus on certain quality attributes at the cost of others. A software architecture, when designed properly, sets out to achieve agreed-upon and validated requirements related to quality attributes.
They are non-functional requirements of a system as opposed to its features, which are functional requirements.

With the C4 Model levels there is no direct way to detail/add this ones, you could probably think about using the diagrams descriptions to do so but it doesn't work at all. Even by using the model's templates available to detail A.D. we cannot find a place or suggestion to state quality attributes.

Easing communication

Software architecture and its documentation allow you to communicate the software and explain it to others. A software architecture is abstract enough that many stakeholders, with little or no guidance, should be able to reason about the software system.

The first level of C4 Model is a great match here because it is quite simple an easy to follow for any audience, technical or non-technical users, and also due to the fact that we are able to view the interaction between the "persons" related to the software system with its elements. Now regarding the technical users, the rest of the C4 Model levels remain easy to understand and help us figure out most of the behavior the software system includes or will implement. Then only one which is a bit hard is the fourth level, probably this one should be only used for the most complex or important elements of the software system because it will be really helpful as an abstraction diagram.

Managing change

Changes to a software system are inevitable. A good software architecture helps with implementing and managing changes. Software architecture allows you to manage and understand what it would take to make a particular change, reduces complexity so that most of the changes that need to be made can be limited to a single element or just a few elements without having to make architectural changes.

The last three C4 Model levels will be quite important for us in order to verify if our solution has a high cohesion, loose coupling, and minimum complexity implementation within its containers, components, and code. This will be have a big impact for the software system whenever a change needs to be addressed.

Conclusion

Although there are a lot of benefits by using the C4 Model in order to describe and communicate software architecture for the different types of audiences. There are still some aspects which are not covered or just incomplete with the this Model, because a software system consists of different dimensions, all of them must be considered to build a system that can evolve.
Technical aspects of the architecture could be easily inferred with this model, also the data store ( and its data) and some parts of its deployment environment. Yet the security, performance and a design decisions remain not properly described by the model.
Another architecture representation method available to cover this missing/incomplete attributes is ARC42. It is strongly suggested to use them both so we fill the gaps and maintain a simple solution to model the software architecture.