Cloud native, Kubernetes, Microservices, DevOps, training, Think, Design

Microservices for Managers: Part 1, System Thinking

For consumers, the speed of technological progress is magical, because of what’s suddenly become possible: self-driving cars, same-day delivery, movies and television shows streamed to us anywhere, anytime.

However, for businesses, that same rapid change can be terrifying.

Many companies are in danger of being overtaken by industry “disrupters”. Magic today is expected. Every business is now required to deliver the same type of magic that companies like Airbnb, Uber, Amazon, and Google pioneered and that users have become irreversibly accustomed to.

At the current churn rate, about half of S&P 500 companies will be replaced over the next 10 years, according to a study by the strategy consultants Innosight. Even well-established companies will struggle to keep up with what their customers want, and how fast they expect it.

The Managers' Role

Managers can make a huge difference in the fate of their businesses. The ability to incorporate and use technological advancements is becoming the decisive factor in company success.

Microservices are part of a powerful constellation of tools that allow managers to consistently experiment their way into the future, learning as they go—and without trading speed for stability, or quality for reduced risk. Combined with a culture of continual learning, microservices can lead directly to improved business performance ... and the creation of magic.

In this blog series we will evaluate three principles, borrowed from Gene Kim’s The Phoenix Project: system thinking, amplifying feedback loops, and a culture of continual experimentation and learning. Together, they describe the opportunity for change and strategic execution that comes from the use of microservices. To learn more, see below to request our white paper, “Microservices for Managers”.

First up: system thinking.



Identifying Value Chains

The goal of every business is to deliver value to its customers. Arguably, this is achieved by implementing processes that transform resources—the business’s inputs—into the products or services that customers desire, its outputs.

Inputs, outputs, and processes: the similarity with an information processing system is undeniable. System thinking highlights this similarity and emphasizes the performance of the entire system versus local optimization of individual pieces.

When thinking about a business as a system, processes represent chains of several sequential steps, which consume resources to produce the input for the next steps and, ultimately, deliver the final product or service to the customer as the output. This view introduces the concept of a value chain.

Based on the process view of organisations, the idea of a value chain means seeing a manufacturing (or service) organisation as a system—made up of subsystems, each with inputs, transformation processes, and outputs. How value chain activities are carried out determines a company’s costs and affects profits.

Value chains often require communication across the entire business to be properly identified and measured. They should describe the performance of the entire system, not just those of a department or team.

Identifying value chains should be the first step in implementing your first microservice. Having a clear understanding of the business processes and the way value flows through the system will highlight the areas where improvements are possible. This is where to focus your development efforts.

An entire process, or simply one part of it, can then be implemented using a microservice following the idea of a value chain. In fact, a microservice becomes a small, single-purpose, self-contained component of the system. It maps very well with the subsystems that compose the business.

A typical example of a microservice that follows the value chain is a recommendation service in an e-commerce website. A small team of developers can build a simple service that produces a list of items in the same category to the one currently visualized by the customer. It is a well defined, isolated feature of the entire system and it immediately delivers more choice to the customer. It is evident that such a small addition could have an important positive impact on the e-commerce business performance and customer satisfaction.

Starting Small

Your first microservice should introduce the smallest amount of work that positively affects the performance of your business. It should increase the amount of value delivered by the company, such as by making business processes more efficient or decreasing system downtime.

The main advantage of this iterative approach is risk reduction and resource efficiency. On one hand, developing and deploying your first microservice can be done in parallel while the established system keeps running, reducing the risk of overall disruption. On the other hand, given the small size of a microservice, only a small portion of resources (say, the size of Amazon’s famous “two-pizzas teams”) need to be dedicated to the development of your first microservice.

This approach can work for both greenfield projects and legacy systems. For greenfield projects, it is best to start small and focus on the minimum viable product (that is, a product with just enough features to satisfy early customers, and to provide feedback for future product development). For legacy systems, a typical practice is to employ the strangler pattern: building one or more microservices around a larger legacy system to expose or re-implement a portion of it and add functionality.

Built to Scale Up

A positive side effect of deploying your first microservice is that microservices are able to communicate to each other. This means other processes can start using the service immediately. The improvement that you created for your initial process is now multiplied by all the other processes that will be able to use it.

Following this pattern, microservices can be used to recursively build larger processes. Each sub-system is now smaller and correspondingly easier to reason about. This means it is now easier to onboard new developers; the codebase is well contained, and so easier to understand and maintain.

Moreover, microservices can evolve independently from one another. This allows you to focus your effort upon system areas that change often—and with minimal or no impact to other parts. Microservices allow you to move faster by removing constraints and parallelising lines of work. We emphasise speed of delivery because the value generated by your code is only realized when deployed in production.

Look for the next blog post on amplifying feedback loops, and that principle’s relationship to microservices. And for a deeper dive, request our white paper, “Microservices for Managers.” You can download below.


microservices for managers whitepaper, Riccardo cefala


Leave your Comment