Oct 6 2022 12 min read
Oct 6 2022 12 min read
There are multiple articles on the internet that touch the definitions of CMS and DXP and attempt to draw a line between them. And of course the line can vary from one definition to another.
In this blogpost, I would like to look into how the web has changed from web 1.0 to what it is right now and how these changes and business needs have impacted the evolution of content management systems.
The first website in history was published on August the 6th, 1991 by Tim Berners Lee. While working at CERN, Berners Lee was frustrated with the fact that there is so much knowledge spread with the thousands of researchers employed at CERN and yet… it is near impossible to access and use it. In his own words:
“I found myself answering the same questions asked frequently of me by different people. It would be so much easier if everyone could just read my database.”
It took some serious work and negotiations from the London-born physicist to convince his boss to allow him to work on the project then called “Information Management” (later changed to WorldWideWeb). The website below is the key milestone of that project:
The first webpage (source)
This simple compilation of links and text started everything. Fast forward about 5 - 6 years and the WWW grew to over 200.000 websites. Nothing compared to near 2 billion we have in 20221. But what was noticed then, is that producing new content with HTML authoring tools will simply not scale up to the needs. Wise observation for the time, considering that the websites of tech giants like Microsoft or IBM still looked something like this:
Microsoft “write us” page in late 1996 (source)
IBM homepage in October 1996 (source)
All this was still in the mid of web 1.0 era, Internet Explorer had just learned to support CSS and shortly after Document Object Model was born. Pages like above shaped the early requirements of the CMS:
Having one, central repository where content authors would collaborate efficiently;
Easing the process of content creation by removing pure HTML creation. More consistency between pages needed;
Rudimentary set of permissions for content authors, so that it is clear who can work on which parts of the website;
Some basic security over our content and the information we want and potentially do not want to publish.
That was really it. And early content management systems allowed for exactly that. Server side scripting transformed simple templates filled in by authors to HTML. One database stored all the content and managed permissions. Only one distribution channel - the desktop, only static pages served, and finally, only one way communication: from the content authors to the web. Things were simple.
Fast forward to the Web 2.0 era. This is when users started generating content. Pages were no longer static, e-commerce had arrived and soon social media started becoming very relevant. The web users now communicate with the businesses in digital. And they expect to be heard. Around that time (2008 - 2010) your CMS should:
Support WYSIWYG content authoring;
Support complex, publishing workflows;
Allow for bi-directional communication with your users;
Store and serve various media types, including rich media.
Things became much trickier - your CMS then had to support some complex processes and integrate with a lot of different applications (think about all the Wordpress app-like plugins). And this is something it was not designed to do initially.
One more jump in time and we are in 2015 - 2017. 2017 was the first year when mobile traffic overtook the desktop. And it has remained so until now. The WWW users now expect a consistent experience between desktop and mobile. There are 1 billion websites in the world. Your CMS has become more of a platform that:
Supports all devices;
Gathers data and customer intelligence;
Is context aware and serves personalized content;
Supports multiple infrastructure and deployment models;
Integrates seamlessly with 3rd party software.
Even though monolithic CMS are still standing strong, it is becoming apparent that at some point, the amount of data, touchpoints and users will become a challenge. Scaling monoliths will be complicated or costly but most likely both. And this is actually how we enter the DXP.
I do not like definitions, so I will not quote Gartner Glossary here. Allow me to list the challenges I think a DXP should address:
The ability to deliver contextualized experiences to digital channels (web, mobile, apps, social media, email, IoT devices…) and scale up quickly and at low cost.
Consistency between all channels and devices for a full, end to end customer journey. There is nothing more annoying than an empty basket on your mobile app when you've just completed it on a website.
One to one personalization. 75% of consumers are likely to buy from companies that are able to suggest a product based on their previous interest, buys and journeys2.
The ability to extend your customer’s profile by easily connecting other systems - CRM, CDP and similar.
Using any tools you like. Due to the architecture of a DXP, you should not be subject to vendor - locking. Instead you are able to build the best digital marketing suite out of the tools and systems you feel are best.
You could argue that some of the same issues we were trying to solve as early as in 2016. And I would agree. There is a major factor to consider here though, which is the volume. There is a fantastic book by Vaclav Smil called Numbers don’t lie (I’d recommend you give the entire book a read) and one of the chapters touches on the volume of data we produce. Some facts:
In 2018 in the United States, the internet users have downloaded 97000 hours of movies and series from Netflix every minute. They watched 4.5 million Youtube movies and generally transferred a total of 3.1 petabytes of data (that is 3.1 x 1015 bytes). Again that is every minute.
In 2016, the pace in which we produced data was estimated to be 16 zettabytes a year, which is 16 * 1021 bytes. To put that into perspective: you would have to download the 4k Braveheart movie about 400.000.000.000 times to generate the same volume.
It is estimated that by 2025 this number will be ten times higher - 160 zettabytes a year (which is 160 * 1021 bytes).
Somewhere in all of this, is your digital estate and your CMS.
So what is a DXP? In essence, a DXP is a technological suite, at heart of which could be the CMS. The suite should be powered by an architecture with loosely - coupled elements that allows you to easily plug in tools (personalization engines, marketing automation, CRM etc.) that improve your user and customer experience. Most importantly however, that architecture should be able to serve all your visitors, channels and data volume now, tomorrow and three years from now, when it becomes even more challenging (as indicated by Professor Smil in his book).
Is DXP a revolution then? In my opinion no, it is the next step, just like Web 2.0 CMS was the next step from Web 1.0 CMS. Does it require a shift in technical design from what it initially was? Yes, definitely.
Yes, you should. Here is why:
65% of North American consumers say they trust a business less when they experience a problem using a website or mobile app 5
55% of customers prefer digital channels over traditional channels 5
32% consumers say they will walk away from a brand they love after just one bad experience 6
If a company has a digital presence and wants to keep up with user’s growing expectations - a DXP should be on their radar.
The goal of this post is to give the reader an overview of how the needs of the businesses in WWW have shaped content management systems. We went from its early days to explaining the explosion of data and delivery channels and what challenges they have brought.
In the next blogpost, I would like to introduce how our product - WebSight is designed to fit the demanding digital environment today. We will take a closer, more technical look into the features and architecture that is able to power the next generation of Customer Experience.