This chapter covers:

• Structuring your teams to maximize the benefits of the micro frontends architecture
• Fostering a healthy amount of knowledge-sharing between the teams
• Identifying common crosscutting concerns and highlighting different strategies to address them
• Illustrating the challenges a diverse technology landscape can introduce
• Helping new teams to get up and running quickly

Throughout this book, we’ve focused on the technical aspects of micro frontends. You learned techniques to integrate independent user interfaces that form a greater whole. We talked about strategies to mitigate architecture-inherent issues like performance and providing a seamless user interface. But why are we doing all this?

Yes, there are some technical benefits that come with this architecture. Smaller software projects are simpler to build, test, understand, and rebuild than a monolith. Being able to use different tech stacks in different areas of the product can also be a valuable asset.

However, the most significant benefits our composable frontend architecture unlocks are the organizational ones. It makes it possible to parallelize development. Properties like having real team ownership and local decision making can lead to faster innovations.

You might have noticed that I’ve used the word team a lot in this book--it occurs 1,723 times if I’ve counted correctly. This is not by accident or lack of creativity. It would have been perfectly fine to use words like micro frontend application or software system in most cases to understand the described techniques. But it’s not about the software. It’s about the people designing and building it.

I’ve talked to a lot of smart people who successfully introduced a micro frontends architecture in their company. In all cases, the motivation to go down this road was the organizational and not the technical benefits--setting up individual and robust teams and empowering them to build and improve a specific area of the product.

That’s what we’ll talk about in this chapter. What organizational and cultural changes should you make to leverage the full potential of this model? How can you address cross-cutting concerns without reinventing the wheel in each team? Lastly we’ll look at the topic of technology diversity. How much freedom should a team have to pick their stack? Let’s start with a bit of theory.

13.1 Aligning systems and teams

If you have ever explored the concept of microservices before, you’ve probably come across Conway’s Law. 1 In the 1960s, computer programmer Melvin Conway formulated the hypothesis that the communication structures of an organization are reflected in the technical systems they create.

This means that if you let one team build a product, it will likely produce a more monolithic system. If you give the same task to four teams, they’ll probably come up with a more modular solution.

The importance of keeping the structure of the organization and its technical systems in sync has been well researched 2 and understood in modern software development. Here’s a quote from the book Organizational Patterns of Agile Software Development, published in 2004:

If the parts of an organization (e.g., teams, departments, or subdivisions) do not closely reflect the essential parts of the product [...], then the project will be in trouble... Therefore: Make sure the organization is compatible with the product architecture.

James O. Coplien and Neil Harrison

For a micro frontend architecture, this means that the team boundaries should align with the boundaries of the vertical applications that form the product. Figure 13.1 illustrates this.

Figure 13.1 Team structure and software structure should align. Having one team working on multiple applications, or even worse, multiple teams working on the same application, can create issues. An architecture where one team owns one application will likely be more effective.

13.1.1 Identifying team boundaries

Ok, understood! We should keep team and software structure aligned. But how do we find out what structure is beneficial for the product we want to create? How do we identify sound boundaries? Here are three methods that can help you.

Domain-driven design (DDD)

Domain-driven design is a popular approach for structuring software. It acknowledges the fact that it’s hard to create a consistent model for a project of a specific size. It provides patterns to handle this complexity by creating smaller sub-models that have an explicit relationship with each other.

DDD provides a set of concepts and tools to identify and isolate areas in your project. It introduces the idea of analyzing the language of different experts and departments in a company: ubiquitous language.

By analyzing differences in vocabulary, it’s possible to identify bounded contexts, one of DDD’s core concepts. You can see a bounded context as a group of business processes that are related to each other. A checkout process could be viewed as a bounded context. It consists of different sub-topics like delivery and payment which are closely related to each other. We won’t go into more detail on DDD in this book. Still, there’s a lot of great content 3 you can check out if you want to learn about it. A bounded context is an excellent candidate to become its own micro frontend application and team.

User-centered design

Let’s set aside our IT glasses and put on our product management scarf for a minute. A critical task in product design is to pinpoint user needs. In day-to-day business, it’s easy to get lost in optimizing our current products.

If we want a sustainable relationship with our customers, it’s essential to understand their real motivations. What do they want when they come to us? How can we make their life easier?

Techniques like design thinking 4 or jobs to be done 5 provide solid mental models to reason about a user’s motivation. A famous quote 6 from Theodore Levitt highlights the difference between our current offers and the users' needs:

People don’t want to buy a quarter-inch drill. They want a quarter-inch hole!

Theodore Levitt

Modeling your teams and systems around your customers needs can be a valid choice. It gives the teams a clear goal that’s focused on what matters most: your user.

In the example of Tractor Models, Inc., we’ve structured the teams and systems along the typical buying process of our customers. A customer goes through different phases like “browsing the site for interesting products” (Team Inspire), “considering if a specific product would be a good choice” (Team Decide), and finally “doing everything that’s necessary to acquire the desired product” (Team Checkout). The customer has different needs in these three phases and the individual teams can specialize in addressing them.

You can apply these phases and user needs to other business areas. Let’s look at another business. You have a company that sells Internet of Things devices like smart bulbs and sensors. Here you might have a “Which devices do I need?” phase, followed by a “How do I set it up?” phase. In the third phase, everything is running and the user wants to interact with the devices--checking measurements or switching the light. These three phases are good candidates to structure your software around. They don’t have too much overlap and the user has very different needs in them.

Examining existing page structures

A more hands-on method for identifying boundaries is to look at the page structure of your current project. This method works when you already have a functioning business model. Print out all page types on a piece of paper. Gather a group of experienced colleagues and group the pages by using your intuitions.

In most cases, a page represents a specific use case or task your user needs to do. Looking at pages is not a perfect solution. Some pages might have more than one purpose. Print a copy of your page and use scissors to cut out parts from it. These cutouts are candidates to become fragments. This method is an excellent entry to start more in-depth discussions.

If you’ve established groups, you can try to verify your hypotheses by looking at analytics data you’ve gathered in the past. Do the usage patterns align with your page groups?

Now that we have an idea of how to structure the teams, let’s talk about who should be on the teams.

13.1.2 Team depth

The integration techniques described in this book are all frontend-related. But micro frontends is not an architecture limited to the frontend--on the contrary. It unfolds its full potential when it covers the complete stack. Figure 13.2 shows different depths of integration and their potential benefits.

Figure 13.2 A micro frontend team can be limited to the frontend (left). However, when you add more disciplines like backend and operations to the team (middle), it becomes easier to ship features end-to-end. An ideal team also includes business experts and stakeholders (right). Then it’s able to make all its decisions locally to create customer value.

Let’s look more closely at the three approaches described in the diagram.

Frontend only

In this model, you have a backend, be it monolithic or microservices-style. The vertical micro frontend teams sit on top of this backend. In case of a microservices architecture, each frontend might have its own backend for frontends (BFF) 7 to communicate with the services.

This approach has some real benefits compared to, for example, a monolithic single-page application:

Scaling development--Here the Two-Pizza Team Rule we talked about in chapter 1 comes into play. Assuming you’ve come up with good boundaries, it’s more efficient to have three teams with five developers, each working on a dedicated piece of software, than to have a 15-person team working on a large code base. It’s easier for developers to understand the part of the system they’re responsible for. When you’ve established a micro frontends architecture with three teams, all patterns are in place to create a fourth team that develops an entirely new part of the application. The other three teams can go on with their regular business. Integrating the new micro frontend with the existing application is a small amount of work.

Easier rebuilds--Modernizing an existing micro frontend is a more straightforward task. You don’t have to think about the complete application. You can upgrade and rebuild team-by-team. No all-hands-on-deck, big-bang migrations.

Full-stack team

In this model, we make our micro frontends teams go beyond the frontend-backend line. Each team includes developers from the frontend, backend, operations, or data science. We form a cross-functional team that combines competences from database to user interface. Here are the benefits of the full-stack approach:

• More creativity--Cross-functional teams combine people with different backgrounds who provide different perspectives on a problem. This diversity can lead to better and more creative solutions.8

• Less coordination--The most significant benefit of the end-to-end team model is that it reduces waiting time. All features that can be accomplished inside team boundaries don’t require other teams to become active. This autonomy eliminates the need for organizing meetings with other teams, formalizing requirements, and global ticket prioritization.

Moving to this deeply decoupled model introduces some unique challenges: How do teams share data in the backend when there are no shared services? This is typically solved by accepting data redundancy and asynchronously replicating data from other systems. In chapter 6 we talked about different technical solutions to architect this.

Full autonomy

We can take this one step further by also including domain experts and business people in the team. In most companies, these people typically work in departments like legal, marketing, risk, customer support, logistics, controlling, and so on. These departments specify requirements that the “IT people” must implement. Breaking up this traditional boundary and moving these experts closer to the development teams is not an easy task. It’s a slow transition that must be encouraged by the top of the organization.

Having expertise like marketing, legal, or customer support directly available in a development team can unlock further benefits:

• Fast trial of ideas--Moving from a formal requirements and prioritization process to a basis where you can exchange ideas at eye level can improve your product. Here’s a small-scale example: In our last project, the team developing the checkout system invited people from the call center to its end-of-sprint meeting. A developer presented the new voucher system. A call center employee interrupted and described the fact that older customers are often stressed by the minimum order value--especially if their shopping cart total is only slightly below it. In this meeting, they came up with the idea to make the minimum value constraint more tolerant: communicating a minimum of $20 but enforcing only $18. This trivial software change had a measurable effect on customer satisfaction: fewer support calls and a more generous company image. Ideas and changes like this can make a big difference.

• Adapt to market quickly--The digital services landscape and your user’s expectations can change fast. New forms of payment methods, integrations with social platforms, and communications channels emerge. When all people that are necessary for strategic decisions work on the same team, you can move quicker.

A general rule of thumb is that extending your vertical teams deeper into the organization will likely increase the speed and quality of these teams' work. If you want to get deeper into this topic, the Agile Fluency Model is a good starting point. The model describes four fluency zones an agile team can reach. 9 A team in the first zone (Focusing) leverages basic agile practices like scrum to improve its work. Running a micro frontends architecture with full-stack teams aligns with the second stage: Delivering. The full autonomy approach maps to the third agile fluency stage: Optimizing.

A development team can decide to adopt the micro frontends architecture for technical reasons. But extending this model to the entire development team or even an organization is a significant management task. Let’s briefly talk about the cultural changes that come with it.

13.1.3 Cultural change

The vertical architecture plays well with having a user-focused culture. Every team delivers to the customer directly.

This mentality is often already part of the DNA of startups. That’s why the proposed vertical team structure might feel like a natural way of growing a startup.

Large traditional organizations have a harder time moving to a more vertical architecture. They often think in short-term projects rather than long-term products. Also, the concept of ownership plays a vital role in running this architecture successfully.

You want teams to identify with the product they create and make it more valuable for the user. Teams should be empowered to make decisions, conduct experiments, and learn from failures. Hierarchies and department structures might get in the way. I think having an open culture based on agile values 10 is a prerequisite for getting the most out of a micro frontend-style architecture.

13.2 Sharing knowledge

The cross-functional team structure optimizes communication along with a business domain (vertical). This model is good because it helps to focus on the user, but it also introduces challenges: How do you avoid reinventing the wheel in every team?

Ok, granted--the majority of the work in these teams is not the same. Developers building a fast-loading product list are faced with other challenges than the developers who are architecting a registration form that has to work in all countries around the world.

But there are aspects that all teams share. What are the right strategies to automatically test the software? What’s a good way to handle state inside my application? “I’ve encountered a strange issue. I wonder if anyone else has this problem?”

Let me give you a real-world example of insufficient cross-team communication. In my last project, we’ve been developing an e-commerce shop with five teams staffed from three software companies. Half a year into the project, a co-worker from one of the other companies gave a talk on debugging Node.js performance at a conference in Hamburg. I attended his talk because I was curious. On stage, he referred to a mysterious problem he’d been tracking down for the past few weeks. He was convinced that it had to be something in his team’s application code. The behavior he described was instantly familiar to me because I’d encountered something very similar in our team’s application. After the talk, we spoke and shared our findings. It became apparent that it had to be an issue with the hosting infrastructure our applications ran on.

But the fact that we had to meet at a public conference to figure this out was a little disturbing. We could have saved each other a considerable amount of time and headaches if we had spoken to each other earlier.

13.2.1 Community of practice

In the early '90s, the concept of a community of practice (CoP) 11 was formulated. It describes ways to spread knowledge across teams. A CoP is a group of people that share a craft or profession. In our example, all people doing frontend work could be part of the same CoP. These groups create their communication channel to exchange information on a specific technology, ask for help, or share learnings.

Spotify is famous for its agile and team-focused organization structure. They also organize in end-to-end teams. They’ve institutionalized communities of practice called guilds. 12 There, like-minded people from different parts of the organization can exchange knowledge. Figure 13.3 shows some example guilds that form horizontal channels across our otherwise vertical organization structure.

Figure 13.3 A guild creates a room for people from different teams that share an interest or profession. Their primary goal is to exchange knowledge.

Guilds typically have a dedicated communications channel like a Slack group. All guild members meet regularly. In our projects, short guild meetings happen (bi)weekly via video call to discuss recent issues. From time to time, the guild also organizes longer in-person workshops for diving deeper into a specific topic.

Typical guilds in our projects are frontend, backend, UX/design, analytics, infrastructure, data-science, coaching, security, and macro-architecture.

13.2.2 Learning and enabling

Having a cross-functional team that’s able to handle the complete stack flawlessly sounds terrific on paper. In practice, it is rarely possible to assemble a team that is capable of developing customer features while also mastering all non-functional requirements such as performance, security, or testing. Being faced with these expectations as a team can be intimidating.

In some areas, technical developments like cloud hosting play in our favor. A team can offload tasks like “managing real hardware” to a cloud provider. These services make a You build it; you run it! approach more realistic.

But that’s not possible for all topics. Learning and improving is an integral part of forming a cross-functional team. Having each team identify and formalize its strengths and weaknesses can speed up the learning process.

CoPs can play a central role in education. A developer from Team A who has experience in analytics can teach other guild members and help them to level up their skills. For some topics, it might also be a good option to hire an external mentor to support a guild.

13.2.3 Present your work

Another way to exchange information is by presenting your team’s work. This way, teams have an idea of what the others are working on. This can be in the form of a real on-stage presentation where all teams show what they’ve accomplished and learned in the last month. But it can also be in the form of a small internal blog post.

Since all teams work in different areas, these presentations usually don’t have much immediate value for the others. However, they enable moments like, “Wait, hasn’t Team Inspire also built a feature with Apache Spark? Let’s talk to them first.” Rituals like these can also strengthen group cohesion and avoid an “us vs. them” mentality.

13.3 Cross-cutting concerns

Let’s dig a little deeper into these cross-cutting concerns. Yes, rituals like guilds can help to spread knowledge, but let’s look at some concrete examples of how to address common topics.

13.3.1 Central infrastructure

Some cross-cutting concerns require dedicated infrastructure. Examples of this are your version control system, continuous delivery pipeline, analytics, dashboards, monitoring, error tracking, hosting setup, and shared services like a load balancer. Each team could make these choices on its own. However, these are all general topics most professional software projects need. Having each team figure out a solution might not be the best use of their time.

Establishing a shared set of infrastructure all teams can use is a good idea. There are different ways to organize this.

Software as a Service (SaaS)

For commodity products, it’s often easiest to use an off-the-shelf product like Amazon’s AWS for infrastructure and GitLab for version control and pipelines. Using standardized services does not introduce inter-team coupling. All teams communicate directly with the provider of the service. Make sure that each team has its sub-account or an explicit namespace to avoid conflicts. If a team has a strong need to switch to another provider, there should be no technical hurdles.

Sometimes going for a SaaS solution is not an option. The reasons for this might be the price or lack of functionality. If you need to run an infrastructure component yourself that all teams can use, you have two options: having it owned by one of the product teams or introducing a dedicated infrastructure team.

Owned by one product team

In this model, the product teams take responsibility for the self-hosted central services. Team A might be responsible for setting up, running, and maintaining the shared load balancer. Team B might run a private NPM registry that all teams can use. Having clear responsibility is essential to ensure that these services receive the attention and care they need. By spreading the services among the teams, the burden that each team has to carry is reduced. This model works well if the number of self-hosted services is not too high and the services themselves are easy to maintain.

Warning Share generic infrastructure components only. Avoid sharing business logic this way, because it creates coupling and undermines team autonomy.

Central infrastructure team

If the preceding methods don’t work for you, there’s always the option to create a dedicated infrastructure team that takes responsibility for all shared infrastructure aspects. But this pure infrastructure team does not fit well into our otherwise vertical and customer-centric architecture. It has the potential to become a bottleneck that hinders feature development.

13.3.2 Specialized component team

Sometimes there is neither a managed service nor an open source solution that fulfills our need. This is where the concept of component teams comes in. 13 Spotify calls these teams infrastructure squads. 14

Say different product teams need to talk to a legacy ERP system that does not support modern APIs. Having a dedicated team that develops a service or an abstraction library might save the product teams a lot of time. Another example of a component team is the central design system team we talked about in the previous chapter.

Component teams don’t provide direct value. Their goal is to enable the product teams to move faster. Since the introduction of a component team creates friction and inter-team dependencies, its use should be carefully considered. These two questions can help with deciding if you should use a component team or not:

• Is the service it provides required by many teams?

• Does building the service require specialized technical expertise that is not present in the product teams?

If you can answer one, or better both questions with a clear yes, it might be worth thinking about a component team.

13.3.3 Global agreements and conventions

Not all cross-cutting concerns manifest themselves in a shared service or library. Often an agreement to which all teams adhere is enough. For topics like currency formatting, internationalization, search engine optimization, or language detection, it’s often perfectly fine to have central documentation.

All teams agree upon the described canonical way and implement it in their applications. Yes, this may result in redundant code, but for topics that are not critical or don’t change frequently, it’s often the most effective way.

13.4 Technology diversity

The micro frontends architecture enables each team to pick and change their technology stack. We’ve already discussed the benefits this introduces. But just because you can does not mean you must use a diverse technology stack.

Having to hand-pick a technology stack can also be a burden. Let’s talk about some techniques to make these decisions easier.

13.4.1 Toolbox and defaults

The toolbox idea explicitly limits the technology choices by providing a list of vetted options. It’s a project- or company-wide piece of documentation that may live in the wiki. The content of the toolbox might read like this: Java or Scala are the backend programming languages of choice. PostgreSQL is our go-to for relational databases. You should stick to Webpack for your frontend builds.

The toolbox should be guidance and not a set of laws. If teams have reasons to deviate from the norm, they should have the possibility to do so. For most teams, the toolbox is a source of sensible default options. Need an end-to-end testing framework? Let’s open the toolbox and see what has worked for other teams.

Since technology is evolving, the toolbox has to be a living document that’s updated regularly by adding new technologies that have proven valuable or deprecating existing ones that went out of date.

13.4.2 Frontend blueprint

When a new team starts fresh, it has to do a lot of setup work, creating its basic application, build process, and other tedious tasks that are necessary before it can become productive.

We’ve been using the concept of a shared frontend blueprint to ease this pain. The blueprint is an example project that includes all significant aspects a micro frontend application needs. We can divide these aspects into two groups: technical and project-specific.

Technical aspects

• Directory structure

• Testing (unit, end-to-end)

• Linting and formatting rules

• Code formatting rules

• API communication

• Performance best practices (optimizing assets)

• Build tool configuration

These general topics are necessary to have, but they are not that interesting. Most major JavaScript frameworks have a scaffolding tool that generates an example project for you. But a stock frontend setup will not be sufficient for a team to get going.

Project-specific aspects

Your frontend needs to integrate with the other teams and must adhere to the high-level architecture guidelines. A new frontend must also cover project-specific aspects. That’s why our frontend blueprint also includes

• Composition examples

  • Including another micro frontend

  • Providing an includable micro frontend

• Communication examples

• Team prefixing for CSS and URLs

• Template for documenting your micro frontends

• Integration with the central pattern library

• Setup for the local pattern library

• Wiring for shared services like error tracking or analytics

• CI/CD pipeline

New teams will copy the blueprint over to their project and adjust it to their needs. Building on the existing work reduces setup time noticeably. But for us, the blueprint has another, even more, important role. It’s the reference implementation for the macro architecture decisions.

It includes running examples of integration patterns and communication strategies. This example code helps all developers to understand high-level topics by seeing them in action in a real application.

Make it optional

Teams are not forced to use the blueprint as is, or even at all. They are free to adapt it to their needs. It’s explicitly not a shared production code base. The frontend applications are based on a copy. Making a change to the blueprint will not affect the existing frontends. Developers communicate improvements to the blueprint via the frontend guild. If a specific improvement is valuable for a team, that team can look at the change and apply it manually.

13.4.3 Don’t fear the copy

As you’ve seen with the blueprint, it’s often a good idea to copy and paste from other applications. For everyday tasks, it’s an easy solution that ensures team autonomy down the road. Copying the 15-line currency formatting algorithm from your neighbor team is a good example. This algorithm is not set in stone, but it’s easy to understand and unlikely to change monthly.

We, as developers, have a trained tendency to spot and eliminate duplications. But this elimination is not free--especially when you try to centralize across teams. Maintaining a shared library that six teams depend on is not a trivial job and will come with a lot of discussions, waiting, and headaches.

For bigger use cases, the pain a duplication introduces might be greater. Our poster-child example is the central pattern library. You don’t want to copy and paste it on every change. There might be other pieces of code you want to share, like a library that makes talking to a legacy system easier. Sharing these as a versioned library might be fine, but it should always be a conscious decision and come with the right amount of dedication. In discussions, I found this quote helpful to create the right mindset:

Only do it if you are willing to run it as a successful (internal) open source project.

Don’t underestimate the organizational overhead a shared library introduces.

13.4.4 The value of similarity

In our projects, teams often picked similar programming languages and frameworks to build their applications.

Using the same technologies as your neighbors has advantages. It makes sharing best practices more accessible. Developers that want to switch teams can get up and running quickly. The ability to browse other teams' Git repositories and see how they’ve solved a particular task is also valuable.

Artifacts like the toolbox and the blueprint can help in forming a shared technical direction. Finding the right balance between similarity and freedom is never easy. Technical arguments often drive discussions around this. But taking the business, or even better, the user perspective can help to maintain focus. Will using Haskell instead of Scala improve the product in a noticeable way?

Summary

• Running a successful micro frontends architecture is not a technical decision. The team structure should align with the software systems to be most effective.

• There are different ways to identify team and system boundaries. Domain-driven design provides tools like analyzing expert language to identify groups of functionality. Bounded contexts are good candidates for a micro frontend team.

• Organizing your teams around user needs can be a good model. Techniques like design thinking and jobs-to-be-done can help to isolate these use cases.

• The existing page structure of your site might already be a good indicator of team boundaries. The question “What purpose does this page serve?” can lead you to groups of functionalities.

• Using micro frontends only on the frontend has technical benefits like parallelizing work and easier rebuilds. Rolling it out to the complete development stack or extending it further also to include stakeholders and business experts can unlock further benefits, like faster development and a better customer focus. The vertical team structure aligns well with the upper stages of the Agile Fluency Model.

• The vertical architecture optimizes for delivering features inside a team’s scope. Introducing horizontal groups like communities of practice or guilds helps to spread knowledge.

• It’s often more efficient or necessary to run a shared infrastructure. Leveraging SaaS solutions like AWS can be a good option that doesn’t introduce inter-team coupling. Sometimes the SaaS model doesn’t fit, and you need to self-host. You can distribute the responsibility for the infrastructure components across the product teams. Introducing a dedicated infrastructure team is an alternative, but does not fit well into a vertical architecture.

• Since micro frontends are decoupled, each team can choose its technology stack freely. Methods like a shared toolbox or a central blueprint can help to form a common technology direction that ensures room for innovation and experimentation when needed.

---