Author: Clayton Locke
Financial Services companies need to escape from their service siloes to give customers the joined-up experience they crave.
The engagement platform supports the next generation of digital financial services solutions. Its job is to create seamless, unified customer experiences that integrate multiple products across company boundaries.
Broken user experiences
In my previous article about the engagement platform, I explained the problem that users face when taking on complex journeys, such as buying a new car.
The goal for the end user is simple – to drive away with a new car – but to get there they’ll need to get to grips with deciding their budget, finding a car, financing it, purchasing insurance and paying their road tax.
From a user’s perspective those tasks are all parts of a single thing: getting a new car. But to the organisations in the supply chain that sell automobiles or finance or insurance, they’re all quite separate.
That separation leaves customers navigating a lumpy and uneven path to their end goal. They hop from website to website, app to app, supplier to supplier, running the same searches and re-entering the same data over and over. A quick look round an online car retailer shows how disconnected this journey is at the moment and also highlights the current opportunity for an engagement platform.
Today, customers are left to figure out what it all means and how all these disparate tasks with separate organisations interact and impact their final goal.
Solving that problem requires a user experience that matches the way the user thinks, that puts their goal front and centre and arranges the supply chain accordingly. Companies that solve this problem and provide a better user experience that spans company boundaries will out-compete their rivals. Delivering a user experience that enables customer journeys end-to-end and across company boundaries requires a software architecture built around an engagement platform.
Traditional website architectures are generally variations on the same theme: a front-end integrated with a monolithic, back-office database that’s owned and operated by the same organisation developing the front-end.
To deliver the seamless experience users need, the solution has to talk to multiple data sources, each of which may be operated by different organisations. The solution has to be able to integrate new data sources simply and easily.
The proven design most capable of delivering such a solution is a microservice architecture.
In a microservice architecture, product features expose their data and functionality through language-agnostic service interfaces.
Each product feature is small, somewhat independent, fine-grained, designed to perform a single function and independently deployable.
Underpinning these product features is a platform that provides a set of common services available to all features. The platform provides everything the features need in order to become a unit in a bigger user experience – including orchestrating when each feature is presented to the user, directory services, messaging, encryption and authentication.
This all helps to lower the overall cost of new features, accelerates the time to market of new features, reduces defect rates and improves the quality delivered to the end user. It allows features developed by one company to be used by a different company. Crucially it allows data to flow across company boundaries almost as simply as electricity flows into a lamp from a plug in the wall.
And, as Amazon has discovered, those attributes also allow the architecture to scale:
“For us, service orientation means … the only access [to data is] through a published service interface. Over time, this grew into hundreds of services and a number of application servers that aggregate information from the services. … (When) you hit the Amazon.com gateway page, the application calls more than 100 services to collect data and construct the page for you.”
– Werner Vogels, Amazon CTO
Deployment as publishing
“[In a monolithic architecture] a change to any single component results in having to redeploy the entire application. But if that application is decomposed into multiple services, you can expect many single service changes to only require that service to be redeployed.”
– Martin Fowler, author
Traditional websites and architectures tend to have a clear dividing line between the elements that are published (the content) and elements that are deployed (the code). The content is typically a mix of text and images and the code is the framework that controls how the website works and how the content is published.
Publishing can be done by people without development skills and happens at the publisher’s discretion. The effects of mistakes made in publishing are limited to the elements being published rather than the system as a whole.
Systems deployment is typically performed by specialist technicians, is done to to a schedule and may even require down time. The effects of mistakes made in deployment are not confined to the element being deployed and may break the entire system.
This distinction between publishing and deployment is useful but it’s a compromise – the cost of making the system hard to break is that adding functionality is also hard.
Because a microservice architecture consists of discreet features that can be deployed independently it significantly lowers the risk of a code change breaking the entire system. If those features are created using modern software development techniques, such as continuous build and integration (where code is automatically compiled and tested as soon as it’s ready) then features can be considered ready for deployment within hours of the code being written.
With a microservice architecture, an entire tier of the system – the product features – can now be published rather than deployed.
The low risks involved in publishing new features to a microservice architecture mean that deployment does not have to be managed or coordinated centrally, it can be put in the hands of service providers.
Let’s return to the example we started with, buying a car, to see how it would all work.
At the heart of the system is an organisation operating an engagement platform that acts as a single destination for handling the entire process of buying a car – from researching and comparing cars to paying road tax and choosing insurance.
Although that organisation provides some core features, perhaps services for listing and comparing cars, a cart and a checkout, the majority of functionality and data is provided by an ecosystem of 3rd party service providers.
The network of 3rd party service providers isn’t coordinated, instead it’s ad-hoc and self-organising. New providers can sign up and publish features based on their own priorities and development schedules.
The code written by providers is subject to restrictions familiar to app developers wanting to get their software on to Google Play or the Apple App Store; it has to run according to the platform’s rules and it’s only available to users after it’s passed an automatic vetting process.
Car traders could subscribe to the platform to add their stocks of used cars, insurance companies would sign up to keep the platform up to date with their products. Other organisations embed comparison engines for insurance and finance products whilst payment providers plug in to the checkout and offer a variety of ways to pay.
Each new provider acts independently but adds value to the user experience to the benefit of the other 3rd party providers taking part, the operator and, most of all, the platform’s users.
The engagement platform ties everything together, across company boundaries. It works much the same way Amazon has shown the world supply chains should work. The opportunity is to find financial services supply chains that are not integrated across company boundaries, build an engagement platform, and then use the platform to grow a business with the many customers who will value the easier journey to their goal.
Download our free white paper by Simon Cadbury: How can financial services innovate digitally within the constraints of their legacy infrastructure? (PDF)