DEV Community: rasrules

A useful architecture representation method

rasrules — Mon, 07 Jun 2021 23:29:53 +0000

"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.

A system that has a good architecture

rasrules — Mon, 31 May 2021 04:54:46 +0000

"Architecture is about the important stuff. Whatever that is." - Ralph Johnson

Abstract

The purpose of this essay work is to provide insights for the reader to identify A system that has a good architecture.
With the general objective: Propose a base criteria to software architecture's attributes which are the foundation we should follow.
By detailing an existing software architecture, which meets the requirements for the project under scope, it becomes simple for us to understand the planning that occurred for the project to be highly adaptable and easy to change over time.
Then also explaining the benefits, trade-offs made and finally providing recommendations for further improvements for the existing software design.

Context

The project's scope is providing a solution for physicians, clinics, hospitals to handle the appointments of their patients which will improve the services provided by the software's customers and also the final users will enjoy many helpful features, such as notifications, which enhance their quality of life.
Patients will access the solution, either by a website or mobile application, in order to find a physician according to their needs. They need to be able to filter them, by different criteria, locate the facilities where the doctors can be found during the day.

The most important feature for the solution is being able to create the appointments, also receiving notifications and reminders. The physician should also be notified and receive reminders of the appointments' status.
The solution is expected to be accessible from anywhere in the world which will later be implemented in more countries after the project grows.

Body

As the diagram shows the current architecture of the system is entirely decoupled, completely different from the original solution the project had before.
The solution relies on Heroku as its PaaS that enables developers to build, run, and operate applications entirely in the cloud and also handles the infrastructure operations for us. Within that platform we are able to scale the up and down manually or automatically the system needs.
The system uses AWS S3 with a CDN in front in order to serve the images, files, documents as close as possible to the user of the app.
Also Infobip is the platform that the project uses to send sms notifications to all the users of the application.
As for the data store solution the system relies on Mysql database running on Linode servers.

Interoperability

As the code base is deployed to Heroku, we have no restriction or configuration required in order to communicate with external solutions, apis, etc. It is clear on the architecture's diagram that the system interacts with Aws S3/CDN and the Infobip Api.

Portability

Again as the code base runs on Heroku the software system is constantly being transferred from one environment to another as stated above about the infrastructure operations.

Availability

Heroku works on top of Aws as its IaaS, it is like a higher lever layer service. As Aws it is the largest or one of the largest Cloud providers the backend will almost always be accessible for the web and mobile clients. Now regarding the data store solution at the moment there is no high availability strategy in case of a failure to recover data.

Test-ability

There are two environments for the software system in order to test/approve/reject new features. The code is deployed to the staging environment where the features are tested by the project owner and then once approved they go to production manually.
At this point there is no proper CI/CD culture but the process just described above.

Maintainability

Maintenance is necessary to preserve the value of the software over time. Maintainable code benefits whoever needs to maintain it, even if its the original developer. Code quality is fundamental for the software to be robust, avoid technical debt scenarios and be able to accurately estimate the time required to implement new features.
The software architecture design must ensure that it can meet the quality objectives, which in the case of the current software system are not met. this is probably one of the most important attribute for all of the software system's to meet.
The existing software solution requires a lot of work to meet this quality attribute.

Conclusion

Although there are a lot of benefits with the current software architecture for the developers, testers, etc and also for the end users of the app because the high level elements of the software system are easy to replace or move somewhere else. The fact that quality attributes are not met is crucial for the project's success. Some techniques to increase maintainability include:

Reducing size
Increasing cohesion
Reducing coupling

There is also an urge to separate the frontend from the backend, as the code uses the Django framework, this could help scaling the project later.
Now regarding the data store the system requires a high availability strategy to avoid losing data.
In order to save money and also to apply devops culture, it would be useful moving away from Heroku to Aws and take the advantage of Aws resources for a complete CI/CD process.