Re-architecting a monolithic application to microservices is hard. What is even harder is all the complexity you have to manage. You will likely break things that you didn’t know were breakable. During the monolith-to-microservices journey, you will uncover that things are so interconnected it can feel like you are playing Jenga but with digital pieces. Except that, unlike a physical Jenga tower, you can’t walk around it, touch it, test it , or wiggle it before you make your next move. All you know is that if you swap one piece out, you may get lucky that the change didn’t break something else. But the reality is that there is a high probability you will hear from the marketing or legal or a business department that you broke something they needed. So how do you go about solving that challenge? The solution is to have clarity and insight into all the pieces or set of capabilities in a microservices architecture.

In this article, I am going to show one technique called a Service Blueprint that I like to use to solve the above challenge. A Service Blueprint is a technique and artifact that allows you to model the front stage and backstage pieces of how a Service is produced or provided. It also can produce alignment between the customer facing part of your organization and the technology department that enables that Service. I especially like the technique because in deeply siloed organizations, it allows you to bring different parties together to look at how things are produced to create value for the customer.

What do I mean by Service?

When I say Service, I am speaking about a Service like Uber or Insurance. If you consider the complexity of how many different pieces fit together to deliver a Service, it can be overwhelming. By using a Service Blueprint you can start to visualize the constraints and complexity that surface as you start your work. Before diving into a project, I recommend taking inventory of the various components involved. With the components mapped out, model the relationships between the various entities. I find this helpful because it allows me to understand the interwoven dependencies as well as the landscape for which I am working.

Here is an example of what I mean when we model a process or system that we want to redesign. The following images are evolutionary breakdowns of the process from a monolith to a microservice and then a proposed change to the microservice.

Below is the current state of the application as a monolithic application (for demonstration purposes.)


Ride Sharing Mobile Application as a monolith


Ride Sharing Mobile Application – Broken into Microservices

The thought process behind using this template is that as you are designing and modeling a service you can identify both the current and future state of the application. This can serve both as a conversation and a map that speaks both languages: business and technical. Bringing both parties together saves time and money. You can then “double click” on each respective boxes and identify where the opportunities for changes are, and which services should go into which box. The key aspect of this activity is to achieve alignment and clarity.


Ride Sharing Mobile Application – Broken into Microservices: Proposed Changes

For example, we can start to mark out and identify which boxes are candidates for changes and what components, services, and/or processes are tied to each other in order to safely decouple them or change them if necessary. For example, I have highlighted a potential change I would like to make and I can visualize the front stage and back stage dependencies and have alignment on how that change will take place and its impact.

Why is this important?

  • It allows your Agile team to understand how the pieces of a capability or service fit together and how granular services fit into the larger picture.
  • Gives your developers a sense of the bigger picture and what it means to end users
  • Assists in identifying individual components as well as critical pieces that are required to continue functioning through the redesign and implementation.
  • Helps your Product Owners and their stakeholders visualize how the pieces fit together and how the work will align going forward. Being able to visualize the changes ensures changes with confidence and anchors the work to the customer.

Things to remember

Although the Service Blueprint is a great technique and artifact to produce, it is one of many artifacts that should be there in a redesign of your monolithic application. Service Blueprinting as a technique, in our experience, has been the most effective at breaking down silos within organizations and provide the clarity and alignment to drive digital transformations. When Silos are broken people start to talk, ideas are generated, and most importantly great customer value is produced. In conclusion, as you break things down into smaller pieces it is key to remember they produced value when they were together and this technique will help in ensuring the value remains throughout your efforts.