Why microservices - part 3: two thirds of the success triangle - process and organization

success triangle  

---

This is part 3 in a series of blog posts about why and when to use the microservice architecture. Other posts in the series are:

• Part 1, the need to deliver software rapidly, frequently, and reliably
• Part 2 - the need for sustainable development
• Part 4 - the final third of the success triangle - architecture
• Part 5 - the monolithic architecture

In this post, I describe the software development success triangle.

About the success triangle

In order to deliver software rapidly, frequently, reliably, and sustainably you need what I call the success triangle:

In other words, you need a combination of three things:

• Development process - DevOps
• Organizational structure - a network of loosely coupled, cross functional teams
• Architecture - sometimes a monolith and sometimes the microservice architecture

Let’s look at each of the three elements of the success triangle starting with process.

The success triangle: Process = DevOps

The process part of the success triangle is DevOps. As the must read book DevOps Handbook describes, DevOps is a set of principles and practices where developers, testers, and operations collaborate and communicate to deliver software rapidly, frequently, and reliably.

The philosophy underlying DevOps consists of the three ways:

1. The rapid flow of small changes from developers to production and end users
2. The rapid flow of feedback from production and end users to developers. This includes both telemetry, such as metrics, from the production environment, and feedback from users.
3. Continual learning and experimentation in order to improve how software is delivered and the software’s resilience.

A key part of DevOps is continuous delivery, which is ‘… is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way…’. Two of the key foundations of continuous delivery are continuous integration and automated testing. Software is built, tested and deployed by an automated deployment pipeline that is triggered by each commit.

Another key part of DevOps, which is inspired by Lean, is hypothesis driven development and A/B testing. Research shows that as many as two thirds of ideas have zero or negative value. Teams should, therefore, make product management decisions based on feedback from real customers rather than, for example, the HiPPO (highest paid person’s opinion). One reason IT performance correlates with business performance is because the lower your lead time and the higher your deployment frequency the faster you can experiment to find those features that increase revenue.

The success triangle: Organization = small, cross functional teams

Let’s now talk about the organization aspect of the success triangle. As the must read book Team Topologies describes, a high performance IT organization is a loosely coupled network of small, autonomous and empowered teams. Each team is relatively small, ideally five to nine people. That number is chosen because the research shows that small teams promote trust, which is essential for high productivity. Also, each team is long-lived because it takes time for a team to become highly effective.

Also, teams should be cross-functional (also a DevOps principle) because that eliminates time-consuming handoffs, which would otherwise occur between different cross-functional groups. For example, in a silo’d organization, developers hand code over to QA, who would then hand the code over to operations. In contrast, in a modern organization, each team should all of the skills to take a requirement and turn it in to deployed code. In some organizations, such as Amazon, each team also contains business people and effectively functions as a mini-startup.

Also, each team should own a suitably sized software component. That’s important for two reasons. First, code ownership promotes long-term sustainable software development. If the team owns the code, they’re strongly incented to keep it clean. What’s more, the components should be suitably sized. You should never overload a team with a code base that is far too large for them to manage.

What about architecture?

It’s essential to organize an IT organization as a loosely coupled network of small, autonomous and empowered DevOps teams. But, in order to be successful you also need the final third of the success triangle: architecture.

What’s next

The next post describes the architectural characteristics required to develop software rapidly, frequently, reliably, and sustainably.