Following the first discussed problem in chapter 4.2, separation of project responsibilities into teams requires an organized communication. That includes both the transition of project know-how inside the team and alignments on the horizontal level between the teams. Closely related to the topic of communication is also project documentation. During
the analysis of work of Drury-Grogan et al. in the chapter 2.1.4, both communication and documentation were mentioned as one of the topics that hindered quality decision making.
On our examples, we will therefore try to emphasize the differences in these two topics, as well as to propose solutions how it should be done properly.
One of the most common issues regarding communication that was mentioned in many interviews (RQ2 and chapter 3.4.2) is the difference in dealing with changes in interfaces.
In monoliths, when an interface is changed within a single project and there is some nonconformity, the compiler immediately informs the developer. Yet, in a microservice system when one service has its interface changed and its consumers do not reflect it, we may not find this issue until the runtime. And the exception may still be then identified in the form of a conversion exception that might not reveal the problem immediately. For this reason, orderly communication rules between the teams of microservices must be established.
When it comes to a difference in know-how between architectures, an interesting point in an interview answer was that in monoliths, the complexity of large monolithic projects makes it longer for newcomers to start efficiently working on the application. Whereas a newcomer assigned to a microservice team usually learns the functionality of that service much quickly and can start working on it sooner. The downside is that it might take longer for him to sufficiently understand the overall picture of the projects, since there are other parts with which he is not working. The documentation differences are then very closely linked to the previous know-how problem. Documentation should stand as a reliant support tool and should help mitigate the drawbacks of each architectural approach.
4.6.1 Issues in monolith
A common answer in the interviews (RQ2 and chapter 3.4.2) was that while microservices need to keep communication between subprojects that compose the services and their respective teams, the main issue in monoliths is the overlapping of work within a development team. Meaning that two developers working on different tasks that overlap in one or more classes, do not break the functionality of each other. That does not have to necessarily include modifying the same files; one developer may just change a piece of code some other programmer relies upon, hence likely altering the results.
Agile approaches deal with this problem differently. Scrum, for example, advises to use daily meetings, where team members work firstly of the problems they encountered, but they also inform other team members of what they are currently working on. This serves as a transparent prevention of such changes within the team. In cases where multiple teams are working on the same monolith, such daily meetings for all coworkers together might be likely unbearable due to the overhead. For that reason, many agile teams organize weekly meetings for developers, meetings for analysts, meetings for team leaders etc., where representants of each team would inform the other teams about what topics they were working, thus performing inter-team alignment (Spanner, 2021).
Proper documentation could reduce the time spent on implementing new featured due to the project complexity. This includes both documentation about specification and responsibilities of each module or component, but also well written and maintained code documentation (for example Javadoc). In the developed monolithic example, besides having properly commented methods in every class, each interface separating layers – façade and service – should have well written assigned responsibilities. This would ensure that developers find faster areas they are looking for as well as those component responsibilities are not broken by logic that does not belong to them.
4.6.2 Issues with microservices
Intrateam overlapping of work in microservices tend to be smaller, as the teams are generally smaller than in monoliths. On the other hand, the inter-team alignments are often much greater challenge, for example due to the mentioned interface changes. As an example, let us imagine that in the sample microservice shop there comes a requirement to modify the fields of product by adding several new. Since the Product object is used by almost all the services, such a requirement must be sufficiently aligned with all the representatives of each service. They will then prepare the change plan within their respective sub-projects. If there would be miscommunication and let us say that the Checkout Service will try to attempt retrieve products from the Product Service but their Product classes would not match, the call would end up with an exception. Although the Product Service would perform its job without any issue, the Checkout Service would not be able to deserialize the incoming data.
One finding in the work of Drury-Grogan et al. (chapter 2.1.4) mentions that it is unfortunately a common practice that changes regarding new or existing features are often mentioned only in emails concerning the participating parties. This then leads to a possible loss of this information and to a chance of other involved parties missing this information.
Well written documentation would help with this issue as well. Firstly, each microservice should have clearly defined its scope and responsibilities for easier implementation of features where they belong to. Secondly, all interfaces should be documented and continuously updated in some shared location. If one service would then change this interface documentation as part of a feature change, all the other teams would be notified by email or some other mean. In the case of the developed microservice e-shop, such documented objects would include the Product, Customer, and Order payloads. Let us assume that the newly developed service for product recommendation would require a change of the Product payload by adding one new field. It would be the Product service feature team to make this change and they would then accordingly update the shared interface documentation that should be for example on a SharePoint server with automatic email notification setup. All the other feature teams would then be automatically notified about this change and the information would not get lost.
4.6.3 Summary
It can be very clearly seen what the differences in communication and documentation are when it comes to using a different architecture on a project. In communication in monoliths, emphasis is made on alignments within a team in order to better define and clarify responsibilities. Documentation then seeks to reduce the project complexity and firmly hold boundaries of module responsibilities.
Whilst for microservices, alignment between teams is a priority as the independence of each service needs to be controlled for the sake of common interfaces. Documentation then helps ensure these alignments if proper standards and processes are set in place. However, communication factors rely heavily on specifications of each individual projects, as there can be multiple teams working on the same monolith or on the same microservice. In those cases, both inter- and intra-team alignments need to take place and teams need to deal with both mentioned issues.