The notion of the application as the best way to package software capabilities is losing relevance. Digital business cuts across application functions, inside and outside the organization. Modern value streams require breaking up application capabilities and dynamically reassembling the digital assets like Sir Mixalot.
Remember the Album?
Before music streaming, the album was the dominant packaging of songs. And for the record, I’m a fan of that most awkward of formats: vinyl (see what I did there?) In the best case, the album represents the artist’s vision and larger statement, and you want to experience it from start to finish. In other cases, they just crammed together a dozen tracks, but you’re only interested in a few of them. Regardless, you might only want to listen to some tracks. In your car, on your phone, streaming on a pod. Easy to do with digital playlists, not so much with physical media.
Similar to albums, applications are still the dominant packaging of software capabilities. But that format doesn’t lend itself to customers interacting with just the parts they need in a digital experience. We want to break them up.
Applications as Containers
Applications support internal business processes. Reservations. Loyalty. Financials. You’d take a group of related functions within the organization, buy an application to support them with software capabilities, or develop your own integrated solution. This works for internal users who work within the context of a given business process, but it doesn’t work well for customers. Customers couldn’t care less about internal functions. They care about a smooth implementation of their digital journey with you. Or they go elsewhere.
Let’s say you run a hospitality business. As a B2B customer, I want to research and book some conference rooms with catering, followed by happy hour at a restaurant that you partner with. The value stream spans discovery to booking. You want this to be a smooth digital experience for the customer. They should be woefully ignorant about your stapled together reservations, loyalty, and financial systems. They should be unaware of your integration with food service and entertainment partners.
The customer journey may look something like this:
Our customer needs to interact with parts of applications that provide customer-facing capabilities, like searching for venues and checking the availability of rooms. Other parts are supporting internal business processes for internal users. However, the parts are all woven together within these applications. They were designed to support business verticals, not value streams.
Different Drivers
Agility is key to the digital experience. Expectations change rapidly. The interface may be a mobile device today, voice-controlled Alexa tomorrow, and an AI chatbot the day after. Applications that support core business processes have an entirely different set of drivers. It’s all about efficiency, compliance, and predictability. Hardly the stuff of consumer excitement, but just as critical to the business as the value streams.
Breaking it up
So let’s just rip these applications apart right? Embed the customer bits with the digital experience and leave the process parts with the back-end. It sounds good when you say it fast, but the components are surprisingly sticky. They aren’t going anywhere anytime soon.
The answer lies in adopting an API-centric model. We want to wrap the components we need to support customer journeys with a well-defined API layer. Using design thinking practices, we can create usable and stable APIs, that evolve with the pace of the application. Those APIs may not exactly reflect what we need to support the digital experience, nor be as agile. They may also use different protocols. And that’s okay. That’s where the secret sauce of API mediation and API gateways comes in.
What if we wrap our APIs in another layer and them expose these as yet another composable layer to the digital experience?
Have you ever noticed the resemblance between software architects and fashion designers? We love layering. And that’s about as far as it goes. But I digress.
The gateway creates runtime governance and consistency between fragmented service landscapes and implementations, including third parties. Mediation creates the connective tissue between agility and stability. It wires application interfaces together, orchestrates between them, and supports versioning. Unlike the enterprise service bus of the past, these are lightweight implementations that are meant to simplify API control and speed up delivery.
Meet-In-The-Middle
There are many ways to go about creating such an architecture. I like the “meet-in-the-middle” approach. This assumes that 1) there is an existing application ecosystem that supports the business processes and 2) we can’t just rip and replace this. This seems like a pragmatic view for 90% of use cases.
As always, we’d want to start with a minimal viable product (MVP) that focuses on the should haves:
- Define the customer journeys expressed in the digital experience. Use personas and scenarios focused on the value stream. Don’t forget to include the business.
- Design the outer APIs that will be consumed by the digital experience. Use a design thinking approach to drive an outside-in perspective. The overriding goal is ease of use for developers. Plan to make them discoverable. Develop an API lifecycle to govern them.
- Map the outer APIs to back-end application functionality. In some cases, there already is some means of integration, but in many cases it is insufficient. Remember that API mediation should not be about designing contortions, but about delivering speed and flexibility.
- Design a set of inner APIs that expose the core needs of the outer APIs. There’s a balance here: we don’t want to bake in too much transformation, but we also don’t want to make the APIs difficult to use. Even though these are not outer APIs, they should reflect the needs, rather than an inside-out view only. These APIs are likely to be around for a long time.
- Finally: design the mediation layer. This is where the two sides meet in the middle. Because it is also where breaking up meets reassembling, it is a double-click on <insert magic here>. We want to abstract complexities, transform protocols and formats, bake in security, monitoring, traffic management, and potentially payment. There are lots of tools on the market to implement API mediation; the last thing you want to do is roll your own.
Takeaway
Although applications aren’t a useful container to support digital business, they are still the most common construct. Sure, we’d love to replace them with something more flexible, say a microservice architecture, but here we are. Our best bet for breaking up applications and reassembling the digital assets for the digital experience is to embrace an API-centric model.
API mediation helps to bridge between a rapidly changing digital experience to execute value streams, and a stable back-end to support business processes. The meet-in-the-middle approach is a pragmatic way to get there.
Let’s not kick Humpty Dumpty too soon.
Ernst Rampen ©2018
