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:


  1. Journey Microservices – expose the business capabilities identified by business moments from the related customer journey maps
  2. Orchestration Microservices – supporting Microservices for journey services
  3. 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.


Figure 1. Banking User Persona


Figure 2. Telecom User Persona


Architecture – turning your ideas into designs

Once the Microservices have been identified and defined, the next step is to create a detailed design. Figure 3 shows a Microservices and API-first reference architecture with a service consumer and service provider view with API led connectivity. The reference architecture uses an API Management layer to handle security, compliance, filtering, traffic control, monitoring and communication between microservices through API’s. Microservices development driven by CJE, is used to handle sizing, granularity and componentization while the PaaS/CaaS provider handles Devops, infra provisioning, scaling and centralized search, logging, analytics and monitoring, which can be enabled through the adoption of an open source/custom tech product stack (e.g. Eureka/Elastic Search/Kibana).


Figure 3. Microservices and API-first reference architecture


Customer Journey Engineering – taking a closer look Domain driven design must be thought through extensively, as it reflects the core capabilities required by the application/product. When applied to domain driven design, CJE will result in the following four key outcomes:


  1. Enabling collaboration between business and technology: technologists and domain experts come together to identify and define the journey maps for business moments of value to the customer, and develop the Journey Microservices and APIs.
  2. Addressing some of the key Microservices adoption challenges related to sizing and scope.
  3. Defining the boundary for the identified domain and context mapping patterns applicable (e.g. anti-corruption, aggregator, entities, value objects) which define the interaction and relationships between Microservices.
  4. Helping to better address the critical integration challenges of Microservices with the front end, which include integrating with many devices (i.e. browsers, mobile and smartphones) and ensuring a seamless, consistent user experience across multiple channels. Adopting a CJE approach will enable the developers to focus on the user experience for the identified business moments and journey maps, and design the Microservices tech stack and integration approach.


These key outcomes will lead to the development of products that customers will love – and journey services would be a key differentiator when it comes to product/service offerings. They should be a top-priority agenda topic for C-level discussion to articulate the potential value to be gained from Microservices adoption.  The far-reaching benefits of customer centricity


CJE empowers enterprises undergoing digital transformation to reap the true benefits of “being digital” – applying Agile principles, improved decision-making, new ways of working, and leveraging disruptive insights and data (business moments and journey maps provide valuable insights for designing and developing value-added services).


Build a strong Microservices foundation platform with the customer at the forefront of solutions/product development, and the result will be greater business agility, a superior product, improved customer engagement, increased revenue, and extended reach and market share.

Ravi Prasad

Ravi Prasad

Chief Technologist & Practice Head of Digital Engineering


As Chief Technologist and Practice Head of our Digital Engineering Practice, Ravi drives our clients’ large-scale Digital Transformation engagements, adoption of API-first & Microservices architecture, and move to enterprise-level APIM platform. With over two decades of experience in technology strategy, incubation of technology practices, cloud, product consulting, and presales, he brings his expertise in numerous ever-evolving digital solutions to help companies innovate and thrive.

What you’ve read here? Tip of the iceberg. Are you ready to be part of the excitement?