Chapter 12. Organizational Effects of a Microservices-Based Architecture

It is an essential feature of the microservice-based approach that one team is responsible for each microservice. Therefore, when working with microservices, it is necessary to look not only at the architecture but also at the organization of teams and the responsibilities for the individual microservices. This chapter discusses the organizational effects of microservices.

In section 12.1 organizational advantages of microservices are described. Section 12.2 shows that collective code ownership presents an alternative to devising teams according to Conway’s Law, which states that an organization can only generate architectures that mirror its communication structures. The independence of the teams is an important consequence of microservices. Section 12.3 defines micro and macro architecture and shows how these approaches offer a high degree of autonomy to the teams and let them make independent decisions. Closely connected is the question about the role of the technical leadership (section 12.4). DevOps is an organizational approach that combines development (Dev) and operations (Ops) (section 12.5). DevOps has synergies with microservices. Since microservices focus on independent development from a domain perspective, they also influence product owners and business stakeholders—for example, the departments of the business that uses the software. Section 12.7 discusses how these groups can handle micro-services. Reusable code can only be achieved in microservice systems via organizational measures as illustrated in section 12.8. Finally, section 12.9 follows up on the question whether an introduction of microservices is possible without changing the organization.

1. http://www.scrumguides.org/scrum-guide.html#team

Besides, modern enterprises stress self-organization and teams that are themselves active directly at the market. Microservices support this approach because each service is in the responsibility of an individual team consistent with Conway’s Law (Section 3.2). Therefore, microservices fit well to self-organization. Each team can implement new features independently of other teams and can evaluate the success on the market by themselves.

On the other hand, there is a conflict between independence and standardization: when the teams are supposed to work on their own, they have to be independent. Standardization restricts independence. This concerns, for instance, the decision about which technologies should be used. If the project is standardized in regard to a certain technology stack, the teams cannot decide independently anymore which technology they want to use. In addition, independence conflicts with the wish to avoid redundancy: if the system is supposed to be free of redundancy, there has to be coordination between the teams in order to identify the redundancies and to eliminate them. This, in turn, limits the independence of the teams.

• Decoupling via independent releases: each team takes care of one or multiple microservices. The team can bring them into production independently of the other teams and the other microservices.

• Technological decoupling: the technical decisions made by a certain team concern, first of all, their microservices and none of the other microservices.

• Domain-based decoupling: the distribution of the domain in separate components enables each team to implement their own requirements.

For deployment monoliths, in contrast, the technical coordination and deployment concerns the entire monolith (see Figure 12.1). This necessitates such a close coordination between the developers that in the end all developers working on the monolith have to act like one team.

A prerequisite for the independence of the microservice teams is that the architecture really offers the necessary independence of the microservices. This requires, first of all, good domain architecture. This architecture also enables independent requirement streams for each team.

There are the following teams in the example from Figure 12.2:

• The team “user registration” takes care of how users can register in the e-commerce shop. A possible business objective is to achieve a high number of registrations. New features aim at optimizing this number. The components of the team are the processes that are necessary for the registration and the UI elements. The team can change and optimize them at will.

• The team “order process” addresses how the shopping cart turns into an order. Here, a possible objective is that as many shopping carts as possible turn into orders. The entire process is implemented by this team.

• The team “product search” improves the search for products. The success of this team depends on how many search processes lead to items being put into a shopping cart.

Of course, there can be additional teams with other goals. Overall this approach distributes the task of developing an e-commerce shop onto multiple teams, which all have their own objectives. The teams can largely independently pursue their objectives because the architecture of the system is distributed into microservices that each team can develop independently—without much need for coordination.

In addition, small projects have many more advantages:

• Estimations are more accurate since estimates concerning smaller efforts are easier to make.

• Small projects are easier to plan.

• The risk decreases because of the more accurate estimates and because of the better forecast reliability.

• If there still is a problem, its effects are smaller because the project is smaller.

In addition, microservices offer much more flexibility. This makes decisions faster and easier because the risk is smaller, and changes can be implemented more rapidly. This ideally supports agile software development that relies on such flexibility.

• The teams have to remain stable in the long run. Especially when the microservices use different technologies, the ramp-up time for an individual micro-service is very long. Developers cannot easily switch between teams. Especially in teams containing external consultants, long-term stability is often hard to ensure. Already the usual fluctuation of personnel can turn into a challenge when working with microservices. In the worst case, if there is nobody left to maintain a specific microservice, it is still possible to rewrite the respective microservice. Microservices are easy to replace due to their limited size. Of course, this still entails some expenditure.

• Only the team understands the component. When team members quit, knowledge about one or multiple microservices can get lost. In that case the micro-service cannot be modified anymore. Such islands of knowledge need to be avoided. In such a case it will not be an option to replace the microservice since an exact knowledge of the domain is necessary for this.

• Changes are difficult whenever they require the coordinated work of multiple teams. When a team can implement all changes for a feature in its own microservices, architecture and scaling of development will work very well. However, when the feature concerns another microservice also and therefore another team, the other team needs to implement the changes to the respective microservice. This requires not only communication, but the necessary changes also have to be prioritized versus the other requirements of the team. If the teams work in sprints, a team can deliver the required changes without prematurely terminating the current sprint earliest in the following sprint—this causes a marked delay. In case of a sprint length of two weeks the delay can amount to two weeks—if the team prioritizes the change high enough so that it is taken care of in the next sprint. Otherwise the ensuing delay can be even longer.

Collective code ownership can relate to a team and its microservices. Since the teams are relatively free in their organization, such an approach is possible without much coordination.

• Changes to a microservice of another team can be faster and more easily implemented. When a modification is necessary, the change does not to be introduced by another team. Instead the team requiring the change can implement it by itself. It is not necessary anymore to prioritize the change in regard to other changes to the component.

• Teams can be put together more flexibly. The developers are familiar with a larger part of the code—at least superficially due to changes that they have introduced in the code. This makes it easier to replace team members or even an entire team—or to enlarge a team. The developers do not have to ramp up from the very basics. A stable team is still the best option—however, often this cannot be achieved.

• The distribution in microservices is easy to change. Because of the broader knowledge of the developers it is easier to move responsibility for a microservice to a different team. This can be sensible when microservices have a lot of dependencies on each other but are in the responsibility of different teams that then have to closely and laboriously coordinate. If the responsibility for the microservices is changed so that the same team is responsible for both of the closely coupled microservices, coordination is easier than in the case where two teams were working on these microservices. Within one team the team members often sit in the same office. Therefore, they can easily and directly communicate with each other.

• Collective code ownerships are in contrast to technology freedom: when each team uses other technologies, it is difficult for developers outside of a team to change the respective microservices. They might not even know the technology used in the microservice.

• The teams can lose their focus. The developers acquire a larger overview of the full system. However, it might be better when the developers concentrate on their own microservices instead.

• The architecture is not as solid anymore. By knowing the code of other components developers can exploit the internals and, therefore, rapidly create dependencies that had not been intended in the architecture. Finally, the distribution of the teams according to Conway’s Law is supposed to support the architecture by turning interfaces between domain components into interfaces between teams. However, the interfaces between the teams lose importance when everybody can change the code of every other team.

Since there is still the need for communication between teams, Conway’s Law is not violated by this approach. It is just a different way of playing the game. In case of a bad split among teams in a microservice-based architecture all options are associated with tremendous disadvantages. To correct the distribution is difficult as larger changes across microservices are laborious, as discussed in section 7.4. Due to the unsuitable distribution, the teams are forced to communicate a lot with each other. Therefore, productivity is lost. Also, there is no option to leave the distribution as it is. Collective code ownership can be used to limit the need for communication. The teams directly implement requirements in the code of other teams. This causes less need for communication and better productivity. To do so the technology freedom should be restricted. The changes to the microservices still have to be coordinated—at least reviews are definitely necessary. However, if the architecture had been set up appropriately from the start, this measure would not be necessary as a workaround at all.

The basis for this is the microservices architecture. It provides a large degree of technical freedom. While normally due to technical reasons, uniform technologies are mandatory, microservices do not have these restrictions. However, there can be other reasons for uniformity. The question is which decision is made by whom. There are two layers of decision making:

• Macro architecture comprises the decisions that concern the overall system. These are at least the decisions presented in Chapter 7, “Architecture of Microservice-Based Systems,” regarding the domain architecture and basic technologies, which have to be used by all microservices, as well as communication protocols (Chapter 8, “Integration and Communication”). The properties and technologies of individual microservices can also be preset (Chapter 9, “Architecture of Individual Microservices”). However, this does not have to be the case. Decisions about the internals of the individual microservices do not have to be made in the macro architecture.

• The micro architecture deals with decisions each team can make by itself. These should address topics that concern only the microservices developed by the respective team. Among these topics can be all aspects presented in Chapter 9 as long as they have not already been defined as part of the macro architecture.

The macro architecture cannot be defined once and for all but has to undergo continuous development. New features can require a different domain architecture or new technologies. Optimizing the macro architecture is a permanent process.

The macro architecture can be defined by a team that is composed from members of each individual team. This approach seems to be obvious at first glance: It enables all teams to voice their perspectives. Nobody dictates certain approaches. The teams are not left out of the decision process. There are many microservice projects that very successfully employ this approach.

However, this approach has also disadvantages:

• For decisions at the macro architecture level, an overview of the overall system and an interest to develop the system in its entirety are necessary. Members of the individual teams often have a strong focus on their own microservices. That is, of course, very sensible since the development of these microservices is their primary task. However, this can make it hard for them to make overarching decisions since those require a different perspective.

• The group can be too large. Effective teams normally have five to ten members at maximum. If there are many teams and each is supposed to participate with at least one member, the macro architecture team will get too large and thus cannot work effectively anymore. Large teams are hardly able to define and maintain the macro architecture.

The alternative is to have a single architect or an architecture team that is exclusively responsible for shaping the macro architecture. For larger projects this task is so demanding that an entire architecture team certainly is needed to work on it. This architecture team takes the perspective of the overall project. However, there is a danger that the architecture team distances itself too much from the real work of the other teams and consequently makes ivory-tower decisions or solves problems the teams do not actually have. Therefore, the architecture team should mainly moderate the process of decision making and make sure that the viewpoints of the different teams are all considered. It should not set a certain direction all by itself. In the end the different microservices teams will have to live with the consequences of the architecture team’s decisions.

The NUMMI car factory² in the United States, for instance, was a very unproductive factory that was known for drug abuse and sabotage. By the company focusing more on teamwork and trust, the same workers could be turned into a very productive workforce. When teams are able to make more decisions on their own and have more freedom of choice, the work climate as well as productivity will profoundly benefit.

2. http://en.wikipedia.org/wiki/NUMMI#Background

Besides, by delegating decisions to teams, less time is spent on coordination so that the teams can work more productively. To avoid the need for communication by delegating more decisions to the teams and therefore to micro architecture is an essential point for architecture scaling.

However, when the teams are very restricted in their choices, one of the main advantages of microservices is not realized. Microservices increase the technical complexity of the system. This only makes sense if the advantages of microservices are really exploited. Consequently, when the decision for microservices has been made, there should also be a decision for having as much micro architecture and as little macro architecture as possible.

The decision for more or less macro architecture can be made for each area differently.

• Uniform security (section 7.14), service discovery (section 7.11), and communication protocols (Chapter 8) are necessary to enable microservices to communicate with each other. Therefore, decisions in these areas clearly belong to macro architecture. Among these are also the decisions for the use and details of downwards compatible interfaces that are required for the independent deployment of microservices.

• Configuration and coordination (Section 7.10) do not necessarily have to be determined globally for the complete project. When each microservice is operated by its respective team, the team can also handle the configuration and use its own tool of choice for it. However, a uniform tool for all microservices has clear advantages. Besides, there is hardly any sensible reason why each team should use a different mechanism.

• The use of resilience (section 9.5) or load balancing (section 7.12) can be defined in the macro architecture. The macro architecture can either define a certain standard technology or just enforce that these points have to be addressed during the implementation of the microservices. This can, for instance, be ensured by tests (section 10.8). The tests can check whether a microservice is still available after a dependent microservice failed. In addition, they can check whether the load is distributed to multiple microservices. The decision for the use of resilience or load balancing can theoretically be left to the teams. When they are responsible for the availability and the performance of their service, they have to have the freedom to use their choice of technologies for it. When their microservices are sufficiently available without resilience and load balancing, their strategy is acceptable. However, in the real world such scenarios are hard to imagine.

• In regard to platform and programming language the decision can be made at the level of macro or micro architecture. The decision might not only influence the teams but also operations, since operations needs to understand the technologies and to be able to deal with failures. It is not necessarily required to prescribe a programming language. Alternatively, the technology can be restricted, for example, to the JVM (Java Virtual Machine) that supports a number of programming languages. In regard to the platform a potential compromise is that a certain database is provided by operations, but the teams can also use and operate different ones. Whether the macro architecture defines platform and programming language depends also on whether developers need to be able to change between teams. A shared platform facilitates transferring the responsibility for a microservice from one team to another team.

Figure 12.3 shows which decisions are part of the macro architecture—they are on the right side. The micro architecture parts are on the left side. The areas in the middle can be either part of the macro or micro architecture. Each project can handle them differently.

How to test the respective microservices should be up to the individual teams as they have the responsibility for the quality of the microservices.

In many areas decisions can be made either at the level of macro or at the level of micro architecture. It is a central objective of microservice-based architectures to give the individual teams as much independence as possible. Therefore, as many decisions as possible should be made on the level of micro architecture and therefore by the individual teams. However, in regard to operations the question arises whether the teams really profit from the freedom to use their own distinct tools. It seems more likely that the technology zoo just gets bigger without real advantages. In this area there is a connection to DevOps (section 12.5). Depending on the degree of cooperation between developers and operations there can be different degrees of freedom. In case of a clear division between development and operations, operations will define many standards in macro architecture. In the end operations will have to take care of the microservices in production. When all microservices employ a uniform technology, this task is easier.

When defining programming language and platform, one should likewise weigh the advantages of specialized technology stacks versus the disadvantages of having heterogeneous technologies in the overall system. Depending on the circumstances the decision to prescribe a technology stack might be as sensible as the decision to leave the technology choice to the individual teams. A uniform technology stack can facilitate operations and make it easier for developers to change between microservices and teams. Specialized technology stacks make it easier to handle special challenges and motivate employees who thus have the possibility to use cutting-edge technologies.

Whether a microservice really conforms to the macro architecture can be evaluated by a test (see section 10.8). This test can be an artifact that is likewise part of the macro architecture. The group responsible for the macro architecture can use this artifact to unambiguously define the macro architecture. This enables you to check whether all microservices are in line with macro architecture.

For example, a database can be prescribed. In that case the team can delegate the responsibility for the database to the technical leadership team. If the database decision were part of the micro architecture, the database would be run by the team since it made the decision for the technology. No other team would need to deal with potential consequences of this decision (see section 7.9). Whoever makes the decision also has the responsibility. The technical leadership team certainly can make such decisions, but by doing so it takes away responsibility from the microservices teams and therefore independence.

A larger degree of freedom entails more responsibility. The teams have to be able to deal with this and also have to want this freedom. Unfortunately, this is not always the case. This can either argue for more macro architecture or for organizational improvements that in the end lead to more self-organization and thus less macro architecture. It is one of the objectives of the technical leadership team to enable less macro architecture and to lead the way to more self-organization.

3. http://www.infoq.com/news/2012/02/programmer-anarchy

4. https://www.youtube.com/watch?v=uk-CF7klLdA

• The teams cannot only take care of the development but also of the operations of the microservices. This requires that the teams have knowledge in the areas of operations and development.

• Orienting the teams in line with features and microservices represents a sensible organizational alternative to the division into operations and development.

• Communication between operations and development gets easier when members of both areas work together in one team. Communication within a team is easier than between teams. This is in line with the aim of microservices to reduce the need for coordination and communication.

DevOps and microservices fit very well together. In fact, the aim that teams deploy microservices up to production and keep taking care of them in production can only be achieved with DevOps teams. This is the only way to ensure that teams have the necessary knowledge about both areas.

• Via the macro versus micro architecture division, operations can define standards. Then technical elements like logging, monitoring, or deployment belong to the macro architecture. When these standards are conformed to, operations can take over the software and make it part of the standard operations processes.

• In addition, platform and programming language can be defined as much as needed for operations. When staff from operations only feels comfortable running Java applications on a Tomcat, this can be prescribed as the platform in the macro architecture. The same holds true for infrastructure elements like databases or messaging systems.

• Moreover, there can be organizational requirements. For example, operations can ask that members of the microservices teams are available at certain times so that problems arising in production can be referred to the teams. To put it concretely, whoever wants to deploy on his/her own has to provide a phone number and will be called at night in case of problems. If the call is not answered, the manager for that developer can be called next. This increases the likelihood that developers actually answer such calls.

In such a context the teams cannot be responsible anymore for bringing all microservices up to production. Access and responsibility rest with operations. There has to be a point in the continuous delivery pipeline where the microservices are passed on to operations and then are rolled out in production. At this point the microservice passes into the responsibility of operations that has to coordinate with the respective team about their microservices. A typical point for the transfer to operations is immediately after the test phases, prior to possible explorative tests. Operations is at least responsible for the last phase, that is, the rollout in production. Operations can turn into a bottleneck if a high number of modified microservices have to be brought into production.

Overall, DevOps and microservices have synergies; however, it is not necessarily required to also introduce DevOps when deciding for microservices.

The “microservices” topic has meanwhile reached numerous IT departments and is discussed there. Interestingly, initiatives for introducing microservices are often started by middle management. However, frequently too little thought is spent on the effect a microservice architecture has on the (IT) organization of enterprises. Because of this I would like to tell of a number of “surprises” that I experienced during the introduction of such an architecture approach.

5. http://www.slideshare.net/randybias/architectures-for-open-and-scalable-clouds

Thus the point is to avoid the personification of servers—for example, by giving them names (like Leviathan, Pollux, Berlin, or Lorsch). If you assign such “pet” names to servers, there will be a tendency to care for them like pets and thus provide individual updates, scripts, adjustments, or other specific modifications. However, it is well known that this has negative consequences for the reproducibility of installations and server state. Especially considering auto-scaling and failover features as they are required for microservice-based architectures, this is a deal breaker.

One of my projects addressed this problem in a very interesting manner. The server and virtual machines still had names. However, the administration of these systems was completely automated via Puppet. Puppet downloaded the respective scripts from an SVN repository. In this repository individual scripts for each server were stored. This scenario could be called “Puppets for automated pet care.” The advantage is that crashed servers can quickly be replaced by exact copies.

However, requirements for scalability are not taken into consideration at all, since there can always only be one instance of a “pet server” named Leviathan. An alternative is to switch to parameterized scripts and to use templates like “production VM for app XYZ.” At the same time this also enables more flexible deployment scenarios like Blue/Deployments. In that case it is not relevant anymore whether the VM app-xyz-prod08.zone1.company.com or app-xyz-prod045.zone1.company.com gets the job done. The only relevant point is that eight instances of this service are constantly available, and at times of high load additional instances can be started. How these instances are named does not matter.

“You shouldn’t care about that!”

“That is none of your business; it’s our area!”

Unfortunately, I frequently hear sentences like these in so-called cross-functional teams. These are teams composed of architects, developers, testers, and administrators. Especially if the members previously worked in other, purely functional teams within the same company, old trench wars and prejudices are carried along into the new team—often subconsciously. Therefore, it is important to be aware of the social aspects right from the start and to counter these proactively. For example, in my experience letting newly set-up teams work in the same office for the first two to four weeks has very positive effects. This enables the new teammates to get to know each other’s human side and to directly experience the colleague’s body language, character, and humor. This will markedly facilitate communication during the later course of the project, and misunderstandings can be avoided.

In addition, team-building measures during the first weeks that require that the team members rely on each other can help to break the ice, to get an idea of the strengths and weaknesses of the individual members, and to build up and strengthen trust within the team. If these points are neglected, there will be noticeable adverse consequences throughout the run time of the project. People who do not like each other or do not trust each other will not rely on each other, even if only subconsciously. And this means that they will not be able to work 100 percent as a team.

Such a change of perspective can also be advantageous in IT. A developer could, for instance, get a new perspective with regard to the use cases or test cases. This might motivate them to enforce a modularization in the development, which is easier to test. Or they might consider early in development which criteria will be needed later on to better monitor the software in production or to more easily find errors. A deeper insight into the internal processes of the application can help an administrator to develop a better understanding for implementing a more specific and more efficient monitoring. Each perspective that deviates from one’s own perspective can raise questions that previously were not considered in this section of the application life cycle. These questions will help the team to evolve as a whole and deliver better software.

For this reason, it is important to take these systems into consideration when planning a microservices-based architecture, especially in regards to IT costs. Can the existing hardware infrastructure really be restructured for the microservices or is there a legacy system that relies exactly on this infrastructure? These are often questions that get caught on the infrastructure or operations team—if there is such an organizational unit in the company. Otherwise it might happen that these questions first arise when a deployment to the system test or production environment is supposed to be done. To recognize these questions early on, I recommend dealing with the deployment pipeline as early as possible in the reorganization project. The deployment pipeline should already be in place before the first business functionality is implemented by the teams. A simple “Hello World” program will often be sufficient, which then is brought towards production by the combined forces of the entire team. While doing so, the team will almost always encounter open questions, which in the worst case will have effects on the design of the systems. However, as not much is implemented at this stage early on during the project, such changes are still comparably cost-efficient to implement.

When the microservices have a good domain architecture, they can be independently developed. Ultimately, each domain should be implemented in one or many microservices, and the domain should only be of interest to one department. The architecture has to take the organization of the departments into consideration when distributing the domains into microservices. This ensures that each department has its own microservices that are not shared with other domains or departments.

Unfortunately, the architecture often is not perfect. Besides, microservices have interfaces—an indication that functionalities might span multiple micro-services. When multiple functionalities concern one microservice and therefore multiple departments want to influence the development of a microservice, the product owner has to ensure a prioritization that is coordinated with the different departments. This can be a challenge because departments can have different priorities. In that case the product owner has to coordinate between the concerned departments.

Let us assume that there is a department that takes care of sales campaigns in an e-commerce shop. It starts a campaign where orders containing a certain item get a rebate on the delivery cost. The required modification concerns the order team: tt has to find out whether an order contains such an item. This information has to be transmitted to the delivery microservice, which has to calculate the costs for the delivery. Accordingly, the product owners of these two teams have to prioritize these changes in regards to the changes desired by the departments in charge of delivery and orders. Unfortunately, many of these sales campaigns combine different functionalities so that such a prioritization is often required. The departments for orders and deliveries have their own microservices, while the department in charge of sales campaigns does not have its own microservices. Instead it has to introduce its features into the other microservices.

However, when the client library also contains domain objects, problems can occur. When a microservice wants to change the domain model, the team has to coordinate this change with the other users of the client library and therefore cannot develop independently anymore. The boundaries between a simplified use of the interface, which can be sensible, and a shared implementation of logic or other deployment dependencies, which can be problematic, is not clear cut. One option is to entirely forbid shared code.

• Open source projects in general are of high quality. Developers working in different companies use the code and therefore spot errors. Often they even remove the errors so that the quality permanently increases. To publish source code and therefore provide insight into internals is often already motivation enough to increase the quality.

• The documentation enables you to immediately start to use the code without a need to directly communicate with the developers. Without good documentation open source projects hardly find enough users or additional developers since getting started would be too hard.

• There is a coordinated development with a bug tracker and a process for accepting code changes introduced by external developers. Therefore, errors and their fixes can be tracked. In addition, it is clear how changes from the outside can be incorporated into the code basis.

• Moreover, in case of a new version of the open source library it is not necessary for all users to use the new version. The dependencies in regard to the library are not so pronounced that a deployment dependency ensues.

• Finally, there are clear rules how one’s own supplements can be incorporated into the open source library.

In the end the difference between a shared library and an open source project is mainly a higher quality in regard to different aspects. Besides, there is also an organizational aspect: there is a team that takes care of the open source project. It directs the project and keeps developing it. This team does not necessarily make all changes, but it coordinates them. Ideally, the team has members from different organizations and projects so that the open source project is developed under different viewpoints and in the context of different use cases.

• The organization around reusable libraries is structured like in an open source project. There are employees responsible for the continued code development, the consolidation of requirements and for incorporating the changes of other employees. The team members ideally come from different microservice teams.

• The reusable code turns into a real open source project. Developers outside of the organization can use and extend the project.

Both decisions can result into a significant investment since markedly more effort has to go into quality and documentation, etc. Besides, the employees working on the project have to get enough freedom to do so in their teams. The teams can control the prioritization in the open source project by only making their members available for certain tasks. Due to the large investment and potential problems with prioritization the decision to establish an open source project should be well considered. The idea itself is not new—experiences⁶ in this area have already been collected for quite some time.

6. http://dirkriehle.com/2015/05/20/inner-source-in-platform-based-product-engineering/

If the investment is very high, it means that the code is hardly reusable for the moment, and using the code in its current state causes quite some effort. Probably the code is not only hard to reuse, but hard to use at all. The question is why team members would accept such a bad code quality. Investing into code quality in order to make the code reusable can pay off already by reusing it just once.

At first glance it does not appear very sensible to make code available to external developers. This requires that code quality and documentation are of high enough quality for external developers to be able to use the code without direct contact to the developers of the open source project. Only the external developers seem to profit from this approach as they get good code for free.

However, a real open source project has a number of advantages:

• External developers find weak spots by using the code. Besides, they will use the code in different projects so that it gets more generalized. This will improve quality as well as documentation.

• Maybe external developers contribute to the further development of the code. However, this is the exception rather than the norm. But having external feedback via bug reports and requests for new features can already represent a significant advantage.

• Running open source projects is great marketing for technical competence. This can be useful for attracting employees as well as customers. Important is the extent of the project. If it is only a simple supplement of an existing open source project, the investment can be manageable. An entirely new open source framework is a very different topic.

Blueprints such as documentation for certain approaches, represent elements that are fairly easy to reuse. This can be elements of macro architecture, like a document detailing the correct approach for logging. Likewise, there can be templates that contain all necessary components of a microservice including a code skeleton, a build script and a continuous delivery pipeline. Such artifacts can rapidly be written and are immediately useful.

Ideally the teams should be put together in a way that enables them to work separately on different domain aspects. If this is not possible or requires too much coordination between the teams, collective code ownership can be an alternative (section 12.2). In that case each developer can change all of the code. Still, one team has the responsibility for each microservice. Changes to this microservice have to be coordinated with the responsible team.

Section 12.3 described that microservices have a macro architecture that comprises decisions that concern all microservices. In addition, there is the micro architecture, which can be different for each microservice. In the areas of technology, operations, domain architecture, and testing there are decisions that can either be attributed to micro or macro architecture. Each project has the choice to delegate them to teams (micro architecture) or to centrally define them (macro architecture). Delegating into teams is in line with the objective to achieve a large degree of independence and is therefore often the better option. A separate architecture team can define the macro architecture; alternatively, the responsible team is assembled from members of the different microservice teams.

Responsibility for the macro architecture is closely linked to a concept for technical leadership (section 12.4). Less macro architecture means more responsibility for the microservice teams and less responsibility for the central architecture team.

Though microservices profit from merging operations and development to DevOps (section 12.5), it is not strictly required to introduce DevOps to do micro-services. If DevOps is not possible or desired, operations can define guidelines in the context of macro architecture to unify certain aspects in order to ensure a smooth operation of the microservice-based system.

Microservices should always implement their own separate requirements. Therefore, it is best when each microservice can be assigned to a certain department on the business side (section 12.7). If this is not possible, the product owners have to coordinate the requirements coming from different departments in such a way that each microservice has clearly prioritized requirements. When collective code ownership is used, a product owner and his/her team can also change microservices of other teams, which can limit the communication overhead. Instead of coordinating priorities, a team will introduce the changes that are necessary for a new feature by itself—even if they concern different microservices. The team responsible for the modified microservice can review the introduced changes and adjust them if necessary.

Code can be reused in a microservices project if the code is treated like an open source project (section 12.8). An internal project can be handled like an internal open source project—or can in fact be turned into a public open source project. The effort for a real open source project is high, which has to be considered. Therefore, it can be more efficient not to reuse code. Besides, the developers of the open source project have to prioritize domain requirements versus changes to the open source project, which can be a difficult decision at times.

Section 12.9 discussed that an introduction of microservices without changes to the organizational structure at the development level does not work in real life. When there are no domain-focused teams that can develop certain domain aspects independently of other teams, it is practically impossible to develop multiple features in parallel and thus to bring more features to the market within the same time. However, this is just what microservices were meant to achieve. Sustainable development, an easy introduction of continuous delivery, independent scaling of individual micro-services, or a simple handling of legacy systems are still possible. Operations and an architecture team can define the macro architecture so that changes to the organizational structure in this area are not strictly required. Ideally, the requirements of the departments are always reflected by one microservice. If that is not possible, the product owners have to coordinate and prioritize the required changes.

• Viewing the organization as part of the architecture is an essential innovation of microservices.

• A combination of DevOps and microservices is advantageous but not obligatory.