Software architecture

The analysis of functional and non-functional requirements is often the first step to effectively tackle the creation of appropriate solution architecture. When starting a new project, we place great emphasis on working closely with stakeholders, especially the product owner and business analysts, to identify as many requirements as possible. This allows us to design the best possible initial version of the solution architecture (enterprise architecture, software architecture, module architecture, etc.). However, our experience shows that during the life of a project, requirements change or new requirements are identified. The evolution of the solution architecture should follow these changes. We are convinced, and always try to convince our customers, that a software architect should be involved throughout the project and adapt and improve the architecture in line with the development. This is one of the key factors to successfully create complex systems.

One of the tasks closely related to architecture is the choice of the appropriate technology stack. 3B IT Consulting approaches this task very individually taking into account many aspects, including functional and non-functional requirements, team experience in specific technologies, consistency of the technology stack with the client’s IT ecosystem, market availability of specialists in the technologies in question, and costs. Of course, the technology stack proposal is discussed with stakeholders before a final decision is made.

The software architecture must be stored in some form. 3B IT Consulting advocates a pragmatic and lightweight approach to this subject. We believe that the purpose of software architecture is a high-level description of the system’s operation, its structure and its dependencies to other systems. Written language is a very good tool here, especially if complemented by diagrams in formalised languages such as UML or BPMN. We also often resort to informal diagrams, which, described by a legend, are understandable in the given context for all involved stakeholders. We prefer lightweight ways of describing the system – such as the C4 architecture model. In long-term projects, it is also important to document the decision-making process in order to understand it – for this purpose, we often suggest the creation of so-called ADLs (architecture decision logs). Not only does it create documentation, but it also helps new team members (developers, architects) to effectively familiarise themselves with the project.

Quality assurance of the system under development can be considered on many levels. In some projects, the essence of quality is the speed of the application, in others the ease of use of the user interface, and in yet others the ease of understanding the code and its extensibility. These are just examples of factors to consider when defining a strategy for code quality assurance. 3B IT Consulting takes an individual approach to each project and, in collaboration with the stakeholders, discovers the areas that are critical to the project. Then we introduce and configure tools that automate the checking of the defined metrics continuously during development and generate alerts when the set metrics are not met. Static code analysis is the technique commonly used by us (we recommend using it both in frontend and backend development) whereas Sonarqube is the platform we use by default.

The creation of a software architecture is the basis for starting an implementation that reflects the architectural design in the source code. In some projects, architects do not implement source code at all and in others they act as developers to some extent of their working time. 3B IT Consulting believes that, wherever possible, the architect should work close to the source code and actively participate in programming. This way, firstly, he/she gets the direct feedback on whether the architecture design can be seamlessly transformed into the implementation and quickly reacts in case of problems (architecture should evolve together with the code and with the changing requirements). Secondly, the architect is typically an experienced team member who can method and train other team members – both by conducting pair-programming, doing code reviews but also by explaining the background of architectural decisions. We believe it’s beneficial in the long term for all parties: the architect, the developers and the project itself.