In this blog, I will discuss with two simple tools and a story why integrations are so critical for service digitalization and why those need to be carefully considered when digitalizing existing services or implementing a new service with a digital element.
Tools: Service journey and layered architecture
The tools used in the story are service journey/path and layered architecture.
The horizontal axis of the description below is a service journey/path. This blog describes an example story's collaboration points between a customer and a service. On the vertical axis, layered architecture provides an abstract idea of the elements needed for delivering the service or part of the service to the customer. Here the layered architecture consists of customer, service, process, data, application, and technology. Those are bound together as follows: Customer uses a service -> Service is delivered by processes -> Processes consume and generate data -> Data is processed in applications operating on technology. See the illustration below.
These two concepts together can be used as a basis for a service blueprint, which is an essential tool in service design. However, we do not go there to keep this blog as short and simple as possible.
The simple story
In the story, we use a webstore as an example service. That is familiar to us, and we generally know how this service works. In our service journey, a first touch point is to "Sign in" or "Log in" to a webstore. The webstore may use an authentication service provided by 3rd party, say Google or Facebook. Naturally, this needs to be seamlessly integrated into the webstore User Experience.
Let's go further down in the architecture layers
There is a specific process a customer needs to go through to get authenticated, and there is a process the applications need to perform to get authentication executed. The webstore and 3rd party service providers exchange data required for the authentication based on the authentication protocol used. We are talking about SaaS from a technology layer perspective in both parties' cases.
Once the customer has logged in, they start to browse the products and add products to purchase to a shopping chart. This is the service provided to a customer at the second touch point in the service/customer journey. A customer follows the determined process for browsing and selecting the products. Product data is used to present the products to a customer. Warehouse status data is used to show products available, and order data is generated as the customer adds products to a shopping chart. Product data may be processed in Product Information Management system (PIM) and order data in Order Management System, to mention two example systems. Both of these may be located in a webstore provider's on-premises technology.
We can use the same logic to describe the service journey's third touch point (Payment) and the fourth (Delivery). There most likely is a 3rd party payment service provider that a webstore is using, and most likely, there is a set of logistics service providers that a webstore uses and that provides customers with multiple delivery options.
Change is inevitable, and resistance is futile
In our story, the first change hits the third touch point in a service journey - Payment.
A webstore owner wants to introduce a new 3rd party payment service to a webstore. The service design change is done, and the webstore UI is modified to include new payment services. Well, that is not quite enough to get it working. The new payment service may require additional customer information not collected by a webstore. To get needed data collected and stored, a webstore owner needs to implement that into a webstore. A new process is designed to collect this information, maintain it securely, and finally, remove it from systems when a customer wants to delete the account. The new information contains some data elements, which need to be designed as a data model. With that design, the master storage system for the data needs to be decided, and the system needs to be changed accordingly. An application level integration between webstore applications and 3rd party payment system needs to be designed and implemented.
This considerably minor change in the service setup "stirs up" almost the whole matrix we have built for our case in the image above.
Let's introduce yet another change to our setup here from the layers below and towards the service layer. In this, the order management system is changed to a new one. The new order management system is far better than the old one but has a different working logic. It consumes and provides data in a totally different structure and format than the old one. The new logic may even impact how the customer handles the shopping cart while using the web store. This introduced change on the lower levels of the layered architecture stack affects even how service is provided to the customer and the stack of the next steps of the service journey steps. The change impact needs to be evaluated throughout the layered architecture levels.
Integrations - the cornerstone
In summary, integrations are critical when creating a high-level customer experience in digital service. I want to emphasize that integrations on all levels of the layered architecture are crucial, not only on the service level or at the process level. Any gap in the integration and data silo in the model will cause problems from a service quality and customer experience point of view. As digital service is fueled by data and data is processed in applications, the application level integration can be seen as the cornerstone for all digital services. It is like the fuel pump pumping the data within the rest of the model.
