Microservices and APIs are seeing rapid adoption in most enterprises, and are gaining traction as disruptive innovations with human-centric services design at the intersection of business and technology. To realize greater business agility and other benefits Microservices and APIs bring, and in order to seamlessly transform their technology, enterprises must base their transformation on a strong customer journey engineering foundation.
Starting the journey – is Microservices right for your application?
Enterprises often ask, “We have already invested in systems that provide our core capabilities and we just need to expose some capabilities to our end channels. So what is the benefit that we can realize through Microservices adoption?”Adopting a Microservices architecture is a journey that should only be taken on depending on the use case. It is essential to first conduct a Microservices architecture assessment across different dimensions in order to qualify a target application.
Once an application has been slated for Microservices adoption, business and technology leaders must then determine the right number and scale of Microservices. Here are a number of other questions I often come across:
- “How many Microservices should be developed?”
- “Does a higher number indicate more problems?”
- “Are we pushing problems from the developer community to operations team?”
- “Will it be better to keep application development as is?”
- “Which Microservices should be built first?”
The list goes on, and although there are rules of thumb, there are no quantifiable right or wrong answers to these questions.
The identification and discovery challenge
Apart from sizing, identification and discovery is often a challenge across enterprises adopting Microservices. There are several approaches one could take depending on the use case. One option is segregating the capabilities between a service provider and a service consumer view. A second is identifying context boundaries through domain-driven design. The result is a broad number of business capabilities, each of which may require one of three kinds of Microservices:
- Journey Microservices – expose the business capabilities identified by business moments from the related customer journey maps
- Orchestration Microservices – supporting Microservices for journey services
- Pass Thru Microservices – integration services providing the capability to interact between the systems of engagement and systems of record
Below are two representative cases of Business Moments and Journey services of a user leveraging services from Banking (Figure 1) and a Telecom Service Provider (Figure 2), which demonstrate the Customer Journey Engineering (CJE) approach. CJE is used to capture business moments and user personas, and can be applied across industry verticals.