The Future of Your DXP

How does your digital experience infrastructure keep up with constant change? Let’s take a step back from the technology and look at the bigger picture, so your DXP can live long and prosper.

Over the course of the decades I spent working on digital projects, I’ve come up with several rules of thumb. Some of them are mere observations; some are good advice; some are inconvenient truths. Probably most annoying of these is this: “The lifespan of your DX implementation is about three years.”

This is not what anyone wants to hear when they’re investing heavily in a complete re-platforming, spending a lot of time and effort into finally, once and for all, getting it right this time. Re-platforming is costly, as well as resource and time-intensive, definitely not something you’d want to do every three years. So how do you break out of that cycle?

I could write a book about the reasons (and I just might), but let’s tackle some of the bigger ones.

First of all, before you say, “it wasn’t, in our case!” I concede it’s not always exactly three years to the dot. I’ve seen it happen after six months (when it became obvious the new platform was untenably expensive to run) and as much as twelve years (when the inertia of the organization was finally overcome to make the change). But generally, after about three years, the idea sets in that things need to be done differently.

There are many reasons for this; I summarize it as “Revolution versus Evolution.” Sometimes, you can’t avoid re-platforming your entire digital experience, but you really want to be evolving it continuously instead. Re-platforming is disruptive, and not in a good way.

Therefore, if you’re experienced and have gone through several rounds of re-platforming, flexibility will be high up on your wish list. You know digital experience is a moving target, so you’ll want to have the ability to evolve the platform as requirements shift.

One common solution to this is “future-proofing”. But since none of us have a fully-functional crystal ball, there really is no such thing. Future-proofing is an exercise in boiling the ocean, adding in everything you might one day need. The looming danger is this becomes scope creep on steroids and drags out your re-platforming for years.

What we actually need to do is to build for change and embrace the unknown. But that’s easier said than done.

If you talk to an architect about future-proofing or building for change, the conversation is likely to go in either of these directions:

When I think of a monolith, it looks like the one in 2001: A Space Odyssey. A black oblong, impossible to see inside, so dark, no light seems to reflect from it— the ultimate black box. If you’re trying to analyze one in order to replace it with a more modern architecture, you should look up the scene from the movie where the monolith on the moon is being investigated – it will be eerily familiar.

By contrast, it’s important to keep in mind that a modern digital experience infrastructure is never just one system. Even my personal blog, running the bare-bones minimum to operate it, uses about a dozen different services. If you’re using a DXP that claims to cover all areas, that’s a monolith, but one where you’ll want to extend it functionally. A DXP infrastructure is never one monolith. It’s Stonehenge. But if you’re focusing on one rock only, you’d never get the bigger picture.

Most organizations can’t afford to build their entire DX stack from the ground up. The answer to the “build versus buy” question is “both”. It’s about buying intelligently and then building the integrations. Unfortunately, this comes at a cost since you don’t get to dictate how the services you buy are actually built. In many cases, it won’t even be about how to deploy all the services – many of them will, in fact, be black boxes that you don’t even run on your own infrastructure.

So when I say “services” in this context, I’m not talking about microservices. I don’t even mean macroservices (also known as “the revenge of the monolith”). This isn’t really about a service mesh, messaging queues, or API gateways. That’s not to say that these things don’t matter – they very much do, especially when you’re building extensive integrations.

However, some of the most fundamental issues in your DX infrastructure will be with what I tend to call “functional services”. You’ll often see multiple functional services overlap and compete for the same space. For example, will you manage user identities in your DXP, DMP, CRM, or use IAM? (Probably, in some shape or form, all of them.) Do you manage images in a MAM, DAM, PIM, or CMS? (It often depends on what kind of business you’re in.) And so on.

The only way to keep track of these is at a functional level. I’ve often drawn up “functional areas” diagrams to make the conflicts between functional services more tangible. You’ll have to clear a few hurdles first – tech people will think of it as “pseudo-architecture”, yet many people on the business side will think it’s too technical. But it allows the conversation to address a core topic; what functionality goes where? From which system will we control this information flow?

If you share a good understanding of functional areas in DX, you can have much more fruitful conversations about your roadmap. Which functional services do we need to replace in the next 6-12 months to overhaul an important functional area in the DX infrastructure? Which ones do we need to add? Who will be your DXP partners essentially? It makes it possible to plan and execute major infrastructural change without going through a painful “Revolution” of a complete re-platforming. Instead, you can have a steady Evolution where you swap functional services in and out or integrate new back-office and front-end services.

Watch out for Babylonian confusion while doing so. In classic clashes between business and tech, the business can be talking about “microservices”, but will usually mean “functional services”. To tech, those “functional services” could be composed of many microservices (or macroservices, or monoliths).

One architectural decision that’s usually left to software architecture is, where it will all come together. You can’t leave the integration bit to the front ends. In most modern setups, they’ll be decoupled from the back-end systems (headless). The web is just another app, next to iOS, Android, and other devices you want to serve. Those apps will then make hundreds of API calls to build the screens:

Modern phones are not the limited devices they once were, and my current phone has a faster processor than the laptop I had five years ago. But the latency and overhead on many disparate systems calls will still kill the experience.

A common solution to this is to build your own middle layer or use one of the stacks to integrate or unify the APIs. Another is to do something similar on the front-end. This is where you have to become a software company. Build and maintain a very critical piece of infrastructure, one that can make or break your apps. As I mentioned before – yes, deployment and software architecture matter.

But the potentially bigger problem is how to manage it functionally. You can solve the technical challenge, but how do you then operate it? The nightmare of content and marketing ops is having to go into all the different backends to set up a campaign, track, and monitor it. And it’s usually impossible to still see or comprehend the effect of changes in one system, the interaction with something out of another, and the end result for any particular user.

My name is Adriaan. I’m Dutch, but I live in Dubai and Spain, and I like penguins and Porsches. What’s your slider going to promote to me?

So, where possible, you’ll have to pick one back-end interface to coordinate the backends. Use it as a pivot to manage the digital experience, and integrate the other sources you need so that editors can edit and review content in context. It won’t solve the technical problem – you’ll still need to unify your communication with the frontends, and you’ll still have to overload those apps with client-side SDKs. But at least the teams will know where to push the buttons and what they’re pushing out.

How you integrate will have a big influence on how you operate; don’t let this be a tech decision, alone.

Finally, to reiterate, functional architecture needs a lot more attention, but it doesn’t mean you should ignore software architecture. You will need a strong software architecture and practices to maintain and evolve integrations. But be very clear about the difference between that functional architecture and the actual software architecture. What I like about the term “digital experience” is it puts the goal (the digital experience) before the tools. If that’s the goal you’re after, then “building for change” should start by categorizing functional areas.

I’ve mentioned Stonehenge twice now, and the important question remains, it’s an impressive feat, but what’s its actual purpose? And you should probably think that through if you want your DX to last as long, as well.

This guest blog post is the second of a series of five articles, written for Magnolia by Adriaan Bloem.

Oh, and a sweet surprise for you: Adriaan is not only writing blog articles for you, he also wrote a book: