Building a sustainable competitive advantage with the right digital architecture

Companies should build their digital infrastructure through a use-case approach. Microservices that solve specific problems lay the foundation for long-lasting growth.

It could be the mantra of our time: go digital, or suffer a slow death. And it’s not enough to just do the things that everyone else is doing; companies are expected to find unique selling points, make everything scalable, and change all the time. In a world of legacy systems and organisational inertia, going digital can be a difficult journey. Fortunately, every step can be made to count.

By this I mean that becoming a master of the digital game is something best done in increments. Every move along the path can and should bring value that accumulates in a sustainable competitive advantage.

The problem of changing an existing business

Typically, the evolution of an enterprise leads to duplicated and fragmented data across multiple systems. It is hardly a surprise then that data quality is often poor too. These systems also tend to have various integration points and dependencies that make changing them an expensive and cumbersome undertaking.

But complete process and system renewals seldom make sense. Rare is the context where a monolithic system solves things once and for all.

So how do you change everything without creating a cascade of process failures? How do you justify investments in mega projects that have a risk of dragging on for years and years?

The answer is: you don’t.

You need to start small, while thinking big.

Start by prioritising your use cases

Customer and end-user centric development can be viewed through a use case methodology that helps you to prioritise between projects. Different organisations have different ways of doing this, so there is little point in diving into the details of business-case formulation. It is enough to say that there are ways to assign business value to alternatives.

Let’s run through an example journey on this. We’ll start with a case involving Customer Information, which is especially important when creating a new Customer. The business case behind this kind of selection might be related to improvements in the quality of Customer Information, for example.

In a microservices-driven architecture, a service dealing with all the queries and modifications related to customer info is created first. It can start as a simple function with a dedicated database behind it. The database can only be modified by this microservice, which is operated through an interface. For those with the proper credentials, this interaction offers access to customer identifiers and data related to any other service too. New prospect creation is still handled in the CRM system, but the CRM system asks the microservice to create a new entry and then uses the information that the service returns.

By extension, whenever a change in customer information takes place, it must be made available to the CRM system via an interface that the service provides. As this service is implemented, all the systems in the landscape that are involved in new customer creation must be enhanced to utilise it. Depending on the landscape, it might not be feasible to immediately upgrade all the customer information systems so they can utilise the new microservice. That’s why the change is limited first to the systems that are involved in creating the new customer entry. As a side effect of this change, the customer creation process also becomes harmonised across the landscape.

Next steps in the microservices journey

In our example, the first microservice lays the foundation for further cases. Next, we might consider creating a microservice that handles inputting new orders. Order intake capability is an essential part of any business. Depending on the scale and the nature of business in question, it might involve several channels, customers, countries or products. If this is the case, then simply divide and conquer them through business case analysis and prioritisation. In some cases, a new microservice will need to be created, and in other cases an existing one can perhaps be modified to meet the need. After implementation, all new orders within the scope must be routed via the new service.

At this point the microservices approach reveals a benefit beyond process consolidation: the New Order Entry must utilise the already available Customer Information service. This way the data integrity and quality in new orders is guaranteed to be in line with the customer information.

When it comes to order input, new customers get created and existing ones get treated through a harmonised interface that carries responsibility for Customer Information. The arrangement does not guarantee data quality, but it clearly defines the responsibility of the service and where to address quality issues.

After we’ve started with Customer Information and Order Input, we might look into Order Management. Tracking orders and changing them deserves a microservice of its own. Again, completeness of first iteration and a possible implementation order need to be considered.

The interplay of Customer Information, New Order Input, and Order Management processes provides numerous benefits. We could continue describing additional services, but in order to understand the rationale behind the approach, we have a sufficient set of them to take our thinking further.

The power of multiple services

When the services work together they present requests to each other. When the New Order Input service operates, it will ensure using or creating a proper customer ID from the Customer Information service.

The Customer Information service might also make a request to update expired contact information, for instance, while dealing with the request and checking the data. The other microservices must support this functionality through their interfaces so that the request gets handled properly.

After the introduction of the initial microservices, not all the tools and processes use them. Since they are essentially orchestrator services, there is no need to consider converting open orders. As incremental implementation proceeds, the same systems that handle the transactions still run them — they just do their interfacing a bit differently.

When it comes to considering the order in which to implement the services, in general it is better to look at breadth first. Instead of developing a microservice to cover the whole range of responsibilities, focus on completing a set of microservices representing the end-to-end journey that provides a complete transaction and experience to the customer. This way the architecture approach can be proven. After an end-to-end reference has been made available, additional use cases can be considered that bring more processes and systems into play.

When the fundamental microservices are in place, additional services can be built on top of them. Audience creation based on Customer Info and Transaction History is very useful — especially if it can be enhanced with data from digital marketing and website browsing. Is there an interest in experimenting with AI? It can be approached so that it interfaces with the microservices and provides insight through its own interfaces.

Handling GDPR-related requests becomes a breeze too. Let’s take a look at the case of a customer asking to erase all data. The Customer microservice that receives the request through a user interface simply checks the other microservices for legal grounds that prevent the deletion of all data. After the facts are available, the necessary steps can be taken. Finally, the service can inform the customer that the request has been fulfilled, or list the reasons that prevent it from being completed. Since all the data entry and manipulation is orchestrated by the microservice layers, we can be sure that all the relevant viewpoints have been examined and finally acted upon. If you add an expiration date to all data entries, then you automatically have a way to implement privacy by design.

Microservices also help in separating the systems of record from systems that engage with users. The events that trigger the services to act can be almost anything. The end-user experience can be enriched by any available data or analytics source without interfering with the foundational layer or creating a load with more official responsibilities.

In this model, there will always be microservices that do not implement business logic rules. On the other hand, it is very easy to create services on top of them that do implement these rules.

Running an environment built on microservices

After the completion of the first entire journey, the existing microservices can be further enhanced. Again, the priorities must be assessed through business case analysis. Additional source systems or new functionality can be added in increments as specified by the needs of the use case. By now, solid architecture principles have been established. For example, guaranteed interfaces do not mean that things cannot change. Inevitable changes must be handled with API versioning, cross-service regression testing, and an applied version of Change Advisory Board.

Since the data is always in a service specific database, it is never accessed or modified through anything else but the service managing it. Systems that utilise the microservices in a proper way always go through these services when they need something outside their own data.

Since integrations are now towards the microservices, changing a system becomes easy. In addition to migration of system specific data, only integration with microservices is needed. Rigid point-to-point integrations diminish as time goes by. The architecture becomes more and more modular when the implementation proceeds. The flexibility of an IT and process landscape is on a completely different level now. New, market-facing services can be introduced in a rapid fashion without compromising the integrity of data. Since they can utilise the available set of services, there is no need to build everything from scratch. Even the existing services can be enhanced in case there is a need to provide new functionality to a wider set of services.

The problem with a microservices driven architecture is not technical. In the end it requires a change in mindset and culture. Instead of organisational silos, people must start focusing on solutions and fulfilling use cases. A lot of the known discipline is still needed during the journey towards an organisation with a sustainable digital edge. It just can’t be achieved through old ways of working alone.

Learn more about how to strive at the turning point of digital sales by reading The Digital Sales Transformation Handbook. In the book we discuss how digital sales transformation will affect companies on organisational and structural level, what it means for customer experience, how ways-of-working and culture needs to adapt, and what future technologies need to be considered, amongst other key themes.

Download The Digital Sales Transformation Handbook

Originally published at https://www.columbiaroad.com.