The Engagement Platform
The next generation of great UX will involve unified customer journeys that integrate multiple organisations, systems and services.
The next generation of great UX will involve unified customer journeys that integrate multiple organisations, systems and services.
In our business applications today, we’ve separated user experience from the back-office; so called systems of engagement from systems of record. The architecture takes into account the major differences in requirements for these two classes of applications. But there is a keystone missing in this architecture that is critical to successful digital solutions. This keystone will play a crucial role in delivering the next generation of digital experiences to customers.
The next generation of experiences will unify customer journeys across business boundaries. I call this keystone the Engagement Platform.
Perhaps the best way to explain it is by example.
Consider the process of buying a car – how would you do it? Perhaps you’d visit a number of websites to get the lie of the land before descending on Autotrader to look at what’s out there and affordable in your area.
As you zero-in on your decision about the type of car you want you might research your financing and warranty options. The type of car you buy will affect your road tax so you look into that as well and, when it’s finally time to make a purchase, there’s insurance to consider too.
Each of these considerations affects the other, each is dependent on data from the other and all of them affect and depend upon your personal finances.
Chances are you’ll do most of your research, and possibly your final purchase, online. For each decision you made along the way you’d no doubt encounter an entire ecosystem of apps and sites out there to help you.
The process is fairly efficient and a world away from what it would have looked like 5 years ago. But it could be better.
Because it’s you that has to glue it all together.
What happens online right now for any big ticket purchase such as a house or a car is not a flow from beginning to end but a series of moments where each part of the puzzle is in a separate silo.
The car dealership’s trading website might allow you to make a side-by-side comparison of cars from their forecourt but your insurance comparison can’t consult your shortlist of cars. Typically you find yourself on a separate website in a different journey to get an insurance quote for a single vehicle – not that helpful when what you want to do is compare total cost of all the vehicles in your short-list.
Your bank can’t show you the impact of the car purchase, insurance premium, road tax and fuel you’ll consume during your daily commute on your monthly outgoings. You work that out in a completely separate process on different systems. If you want to take out a car loan, you’re back down another alley like your insurance – often being asked the same questions. A recent path into insurance quote for one vehicle asked for over 50 separate pieces of information. Navigating through an auto finance quote for the same vehicle on the same website, asked for over 25 pieces of information of which 23 were exactly the same as what was entered for the insurance quote. How many times do we need to tell the computer what our birth date was?
It’s you that records the information, remembers what questions you asked and what answers you were given, figures out the impact those answers will have, and it’s you that passes the information back and forth between systems. You are being tasked with manually integrating systems across the business boundary gap. This creates massive friction in the buying process and significantly erodes your user experience.
For all the sophistication in evidence in each silo the crucial enabling technology that ties them together is still pencil and paper. It’s quaint, but not good enough to win customers in the near future.
To create the next generation user experience we have to do better than this – we have to start making information user-centric so that it can flow through complex processes.
That’s the problem that an engagement platform will help to solve. It is the system that marshals information from a variety of sources and presents this information in a unified journey for the customer. It reduces the information gaps that form between separate businesses in the buying chain. It reduces friction in the customer buying process. High-quality user experiences often must cross business boundaries, and the keystone that holds the journey together is the engagement platform.
An engagement platform is becoming more and more critical because of two powerful long term trends that are driving the evolution of the digital experience.
The trends: content and contact distribution
The first trend is the increasing diversity of contact and content distribution channels.
In the first part of this article I showed how transitioning between organisations, systems and products in the virtual world creates gaps in real-world user journeys. As more organisations digitise more products across more channels the situation is likely to get worse, not better. The intermediaries that we depended on in the past, the brokers and sales people who put together “package deals” for us are being replaced with self-service portals that we prefer as digital natives. But we also demand better experiences and a seamless buying process. The only way to improve users’ digital experiences is to focus on the bigger picture and deal with concepts and concerns spanning multiple channels and business boundaries.
Open Application Programming Interfaces (APIs)
In other words, it has become a business imperative to focus on the entire end-to-end journey.
The second trend is something that will help with that task significantly; the continued rise of open standards and open APIs (Application Programming Interfaces).
Open APIs throw the doors open on the data inside applications by providing stable and well documented public interfaces intended for third party software rather than people.
Open APIs are a key underpinning for joined-up user interactions because they turn each organisation from a silo with its own concepts and user interfaces into one of many potential systems of record for platforms that sit above them.
Open APIs are extremely popular with the technology companies like Facebook, Twitter, Google and Amazon because they turn their e-commerce applications into platforms that support entire ecosystems of third party apps and websites.
What financial services should be doing
Banks and financial institutions have not been so quick to adopt open APIs (the open source Open Bank Project not withstanding) but thanks to the the EU’s newly revised Payment Services Directive and its provisions for ’Access to Account’ (XS2A) they have become an inevitability.
To make best use of these emerging trends and to create joined-up user journeys we’re going to need a new generation of highly adaptable software that can consume, aggregate and manage information from these open APIs.
I call it the Engagement Platform and now I’ll tell more about how it’s going to work.
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 3rdparty 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.
Opinion piece: How far can digital go? [PDF] Simon Cadbury looks at the emerging trends in banking technology and how they impact the customer experience.