Application architecture is a term often used in development. Comprehensive, multifaceted and, at first glance, difficult. Let’s try to look at it from a non-developer’s point of view and answer frequently asked questions.
It is not unusual to believe that software architecture is a set of technical solutions for the organization of a software product. Very often, when the team talks about architecture, you hear the words: monolithic, microservices, choice of framework. But these are only technical terms, not architecture as a whole.
In fact, the availability of the entire set of technical solutions is a direct consequence of Business Architecture and Information Architecture. Business Architecture answers the questions “what will we get in the result?” and “what problems ought to be solved?” while the product is being developed. In other words, we outline the range of tasks the future system will solve. The result of Information Architecture is a description of the domains of the system’s essences, and their interaction based on the concept described above.
The formation of architectural solutions starts with the collection of requirements and description of business essences. In the process, qualitatively collected requirements and described essences, along with their interaction with each other, are the basis for optimal technical decisions. Another benefit of Business Architecture and Information Architecture is that you always have handy arguments to resolve controversial “why was this not taken into account earlier, when forming the application architecture” situations with the client.
Software architecture is conventionally divided into the following levels: high та low.
High level architecture describes the system, methods of interaction, deployment of components. Such decisions are made at the start of the project and situationally, with the evolution of the project. Low level is the same code design, or how well the programmer writes the code. There is an objective minimum code quality assessment — the SOLID principle.
The need to control low level architecture is obvious — minimization of refactoring and stabilization of development speed. Controlling all this with the help of code review and code analyzers. It is especially important to follow low level architecture at the start of the project and in the active development phase. This will lay a good foundation for scaling the development in the future.
A painful question is often raised during the product life cycle: “How to distinguish the need for change from the technical perfectionism of developers?”
The first indication of the need to work on architecture is a slowing down of the development, while the team composition is unchanging. Yes, maybe the programmers are tired, but if this is not the case, this is the first sign to pay attention to the quality of architectural solutions.
The second indicator is characteristic of legacy projects. It comes down to the increase of the pace of development by increasing the number of team members. In practice, the pace of development remains the same or even decreases. This causes a lot of misunderstanding on the part of the customer. In fact, the reason is obvious — the time has come to invest efforts and resources in redesigning the system.
If you have been influenced by the wishes of the team to change the architecture, then you have the question “how to do it?”. You need to start with the analysis of code quality — that is, with low level architecture, because this measure is not as expensive as changing high-level solutions. To begin with, add into your team’s DoD (definition of done) the practice of code review and the use of code analyzers. Then, create a refactoring plan with the team to gradually improve the architecture.
Doesn’t help? Then it’s necessary to proceed to expensive changes of high-level solutions. Here, it is necessary to involve a solution architect to develop concepts, plans, terms and arguments, and approve all this with the management. And then we are gradually starting the migration of high-level solutions. For example, with monolithic on SOA. At the same time, it should be remembered: from the point of view of product evolution, changing architectural solutions are normal processes that should be understood and argued for their necessity to the client and management. Because time goes by, product goals change, so it is logical that the tools to achieve them will also be different.
We will talk in more detail about application architecture and other technical skills for PM and BA at our Technical skills for Project Managers and Business Analysts course.
Subscribe to our newsletter and never miss our news