Inconvenient Truths About Your DXP

After slightly over two decades of managing content, building sites, and creating digital experiences, I’ve got a book full of anecdotes and the battle scars to show I’ve lived them. And while managing digital experience has matured, some problems have been annoyingly consistent over time. So consistent in fact, that they’ve become my annoying rules of thumb.

These are things nobody wants to say, and we all hope they’re a thing of the past, yet they keep happening again and again like a digital experience Groundhog Day. There are always exceptions to the rules, of course, but it’s hard work to avoid them, and you can’t ignore them. Here are five of them.

I’ve built my own system three times now. The first time I didn’t know any better – and in the late ‘90s, there wasn’t as much choice as there is now. But by the time we were a year and a half in, and I had to demo what we achieved with mostly large parts of (admittedly crucial) back-end services done, it was painfully obvious. “If I input ‘mooh’, it outputs ‘splut’! That means the authorizations and repository are working!” didn’t make for a great pitch. We switched to an out-of-the-box system and customized it instead, which is when I realized this truth. I thought the system wasn’t great, but it sure beat having to build our own.

The two times after that, I thought things would somehow be different. But even with a budget of millions, great architects, fantastic partners, and dozens of developers, the lesson turned out to be the same. Some very large tech companies still didn’t get the memo, and the main thing keeping them from seeing reason is a strong “not invented here” syndrome, possibly with an underestimation of what commercially available systems would do better.

So unless you’re convinced you’re building the new Facebook, don’t build your own CMS.

I’ve written about this in the past, but it’s still something that trips up project managers and budgets. As much as you think that expensive license for your new DXP is costing, it will only be a fraction of the actual cost to implement it – and I really mean just the initial re-platforming. It may not be exactly seven times as much, but if you factor in integrators, internal resources, and so on, it will inevitably come close. In practice, this means two things: raise an eyebrow if a sales person tells you it will be much less than that; and don’t get too stuck on the high cost of the system you’re licensing – it may be the least of your worries.

Every once in a while, some wise guy will tell me, “But we’re using open source, so the license is free! And seven times zero is still zero.” That’s funny over a coffee, but less so if you run out of money halfway through your implementation. Open source can be even more expensive to implement (it often compensates for the fees you’ve saved), and relying on the “free” version of commercial open source is almost always penny wise, pound foolish.

Don’t underestimate the total cost of an implementation by optimistically ignoring the hidden cost, because you will pay for it later.

One of the utopias of managing content is structuring it semantically, as atomically as feasible. It should have good metadata, including descriptors, and it should be completely devoid of formatting or design. The problem is, this is almost antithetic to HTML, which has a long history of mixing content with design; so your content will almost definitely contain a lot of elements that were specific to that iteration of your site, or that version of your CMS. And if your content has bold and italic, links, bullet lists, tables, and images, it’s an unstructured blob made to fit a page. Even the best of efforts at keeping it clean will have some rough edges.

As a result, once you want to redesign your digital presence, it will break in many places. And if you want to do an automated migration from one system to another (or one version to another), you’ll almost inevitably have to do a major cleanup, or constantly tune the scripts.

That’s not even mentioning cleaning up the actual content itself. You’ll need to figure out what content to cull, what to update, and what to add. There are tools to help here, but it’s a major exercise, and I’ve been on one project where it took multiple years (granted, that was close to a million pages). If anyone says, “we’ll do automated migration,” be very skeptical – and don’t expect it to be done overnight.

Don’t ignore how complex a content migration is, even if you’d like to wish it away with automation, and plan accordingly.

The implementation of a DXP is not just some app sitting on your MacBook that automatically updates overnight. It’s usually a highly complicated infrastructure across multiple servers and services. So even in the case of simple systems, you’re likely to run into issues; the more customized your environment, the more of a hail mary the upgrade scripts will be. If you take a long hard look at what might break and identify what definitely will break, you should be concerned, especially if it’s a major version release.

MACH (especially the “API-first” and “headless” parts of it) may save you from the brunt of it but tread carefully. I’ve even run into the problem with a SaaS, headless, content management service. I wasn’t aware of its internal versions, and didn’t have much insight into the release schedule. A major update still broke our apps, because of several minute, but catastrophic changes in the APIs.

Never underestimate how much an upgrade can break, especially if you don’t know exactly what it will change.

I’ve mentioned this in my previous post, “The Future of Your DXP”, but it’s worth repeating. Unless you really do things differently than before, your re-platforming and shiny new DXP will last you about 3 years, give or take. It’s hard to break out of that cycle, and it’s why it’s one of the main topics of the book: how do you go from repeated “revolution”, to a steady “evolution”? If you have the time, I promise it’s worth the read. So go pick up your free copy!

This guest blog post is the fourth 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: