Benefits from a Business Perspective

The previously discussed organizational benefits also lead to business advantages; the projects are less risky, and coordination between teams needs to be less intense so the teams can work more efficiently.

Parallel Work on Stories

The distribution into microservices enables work on different stories to occur in parallel (see Figure 4.3). Each team works on a story that only affects their own microservice. Consequently, the teams can work independently, and the system as a whole can be simultaneously expanded in different places. This eventually scales the agile process. However, scaling does not take place at the level of the development processes, but is facilitated by the architecture and the independence of the teams. Changes and deployments of individual microservices are possible without complex coordination. Therefore, teams can work independently. When a team is slower or encounters obstacles, this does not negatively influence the other teams. Therefore, the risk associated with the project is further reduced.

Example of Legacy Integration

Figure 4.3 Example of Legacy Integration

An unambiguous domain-based design and the assignment of one developer team per microservice can scale the development or project organization with the number of teams.

It is possible that certain changes will impact several microservices and therefore several teams. For example, only certain customers are allowed to order certain types of product—for instance, because of age restrictions. In case of the architecture depicted in Figure 4.3, changes to all microservices would be necessary to implement this feature. The Customer microservice would have to store the data about whether a customer is of legal age. Product search should hide or label the products prohibited for underage customers. Finally, the order process has to prevent the ordering of prohibited products by underage customers. These changes have to be coordinated. Coordination is especially important when one microservice calls another. In that situation, the microservice being called has to be changed first so that the caller can use the new features.

This problem can certainly be solved, although one could argue that the outlined architecture is not optimal. If the architecture is geared to the business processes, the changes could be limited to just the order process. Eventually, only the ordering is to be prohibited, not searching. The information about whether a certain client is allowed to order or not should also be within the responsibility of the order process. Which architecture, and consequently which team distribution, is the right one depends on the requirements, microservices, and teams in question.

If the architecture has been selected appropriately, microservices can support agility well. This is certainly a good reason, from a business perspective, to use a microservice-based architecture.

< Prev   CONTENTS   Source   Next >