R.I.P. DXP, Long Live the Web The WebOps Manifesto This March, a conversation started with the observation that [the original leaders of the DXP category (Sitecore, Acquia, Optimizely) are in distress](https://www.linkedin.com/feed/update/urn:li:activity:7306029845686173696/).
Category creator Adobe stands strong, but all others in that cohort have declining adoption. At the same time an already broad category expanded further with the entrance of rising [MACH alliance](https://machalliance.org/) stars Contentful, Contentstack, Builder.io, and Uniform.
The DXP category is going through a churn cycle. Moreover, its utility to the market in current configuration is questionable.
While it contains many great companies, the category doesn’t provide a well lit path for prospective customers. The first generation of monoliths are on their way out, and the composable approach isn’t yet coherent; there are gaps in best practices, and misalignment between DXP and MACH that may lead decision-makers astray.
Most importantly, the DXP point of view has a blind spot when it comes to the role of open source projects and ecosystems, which are integral to any buyer’s success in this space. In a world where there’s little margin for error in making big technology bets, we propose another way.
This alternative is grounded in the work of practitioners and focused on where the rubber meets the road, where the experience meets the customer. #### This is WebOps {#h.23urb8anrzsy} The vast majority of digital experiences are web experiences, even those that occur offline. Websites are vital, but the notion of “the website” as a static or singular asset is antiquated.
The web is a medium. The web is a channel. The web is where content and data meet, and the results can be magic. Those who can wield it are out-competing those who cannot.
But the web is also legacy. Within every organization there’s an aging incumbent, old ways of doing things, dysfunctional team dynamics that date back to an era when “the website” was a battleground for organizational politics as much as anything else.
We call for renewal. Long live the web.
The web should be a company’s most valuable digital asset. It is their primary and often only _owned_ means of reaching new and existing customers. It is the place where they can be sovereign.
Where prior approaches have missed the mark, WebOps is a realignment that allows for autonomy, velocity, and ultimately results. This can be achieved without sacrificing non-negotiable concerns around stability, security, or compliance.
Whether it’s a single team rising to become an agile business driver, or an organization realizing this transformation at scale and finding freedom within a framework, nobody who makes this change goes back to their old ways of working. This new partnership between development, marketing, and IT works, and the professional movement is growing every day. Join us. ## “Pssst… I See Dead ~~People~~ Platforms” {#h.pu62v8ixlw3t} First generation DXP implementations are being replaced as their contracts come up for renewal. Acquia, Optimizely, and Sitecore all show signs of decline. Here are BuiltWith statistics on [Sitecore](https://trends.builtwith.com/cms/Sitecore-CMS) and [Optimizely](https://trends.builtwith.com/cms/Optimizely-CMS):
| | | | --- | --- | | ![](https://cdn.prod.pcc.pantheon.io/PaD6uJMiCzq3KEskTrjK/K5RujMWeVGMHfDt49gG0) | ![](https://cdn.prod.pcc.pantheon.io/PaD6uJMiCzq3KEskTrjK/G1mbdKZuGUh4XWLFBzkT) |
Backers of these companies will offer excuses. In the case of Sitecore, they’ll say this is because of the “[self disruption](https://www.mi-3.com.au/14-05-2024/sitecore-likely-pushed-customers-hard-shift-cloud-and-composability-says-new-ceo-dampens)” from introducing Sitecore Engagement Cloud. But that launched in 2023, well after their growth sailed, and it has [fewer than 50 tracked instances](https://trends.builtwith.com/analytics/Sitecore-Engagement-Cloud) so far.
In the case of Optimizely, their PR game is strong and many cite their impressive revenue numbers. However, a closer look at the timeline reveals that the chest-beating is propped up by [inorganically acquired growth](https://www.optimizely.com/company/press/optimizely-acquires-netspring/). The core product is not what’s driving it.
For whatever reason Acquia’s cloud platform isn’t tracked by Builtwith, so we have to look to other sources. [The HTTP Archive](https://httparchive.org/) offers a vast dataset of public web crawls, and is [accessible via Google BigQuery](https://har.fyi/guides/getting-started/), allowing anyone to delve into 100s of terabytes of data from over 16 million sites going back several years. It can fingerprint their product suite:

![](https://cdn.prod.pcc.pantheon.io/PaD6uJMiCzq3KEskTrjK/3V1LwLMdPHbeTwVFNcsy "Chart") It’s a similar pattern to their peers over recent years.
A hypothesis: these companies show a similar pattern because they followed a similar playbook. They [acquired technologies and bolted them on](https://www.cmswire.com/web-cms/acquia-launches-dxp-wordpress-55-underway-and-more-open-source-cms-news/) to an existing CMS offering in an attempt to copy Adobe and meet analyst criteria for the newly created category.
It doesn’t appear to be working out well. The results of botched integrations are not pretty. Technical debt, often accompanied by actual debt, leading to layoffs and disorganized, demoralized teams. This isn’t unique to DXPs — buy and bolt always has its risks — but it seems to have put these companies in a bad spot.
![](https://cdn.prod.pcc.pantheon.io/PaD6uJMiCzq3KEskTrjK/7bUCqmAYLU7qucg56STl)
Another excuse these companies offer for the declining visibility of their products is that the web experience is now handled elsewhere due to a headless or decoupled architecture. That’s undoubtedly a factor, but I’m skeptical that it’s hiding robust growth behind the scenes.
And hey, are DXPs not meant to deliver digital experiences? Seems like a bit of a _categorical_ problem. We’ll get to that in a minute. But first a word about the web. ## Digital Experiences are Web Experiences {#h.jtpczicqw4d1} The Web is the dominant medium for digital experience. Most user interfaces are now built to run in browsers. Software is eating the world and the teeth are made of HTML, CSS, and Javascript,
Figma has made design professionals native web creators. Google Docs/365/Notion and others are where content is actually crafted. B2B SaaS is predominantly web driven, down to things like the software powering dental practices, law firms, and car dealerships. What used to run on a Microsoft local LAN setup is now in the cloud, and people interact with it via a browser.
Desktop apps like Slack, Zoom, and others are thinly-wrapped web experiences. Loads of mobile apps are the same. There are exceptions where unique device capabilities warrant a native application (e.g. VR), but even demanding workloads like video editing are being driven through web apps these days; Adobe had to buy frame.io because it was eating Premiere’s lunch.
Flash is dead, but the open web has caught up and surpassed its capabilities. We are in a new era now. It’s a shame that crypto scams tainted “Web 3.0” as a label, because that’s what it feels like.
The Web is an inherently open source medium. Working on digital experiences requires teams to leverage open source tech where the rubber meets the road. The question is *how does that happen?*
There’s an incredible amount of pain and suffering where teams struggle with that question. Legacy processes for web production based on print processes don’t work. The standard delivery model for enterprise software similarly sets teams up for failure.
If you were doing a DXP build in the 2010s you’d spec out the software (and license fees), the hardware (which you might well be responsible for maintaining), and probably a hefty implementation fee from a Systems Integrator. All of this would lead up to the big-bang (re)launch we all know and loathe.
When your approach to deploying an application is to build it in the back room then throw it over the wall for IT to host somewhere, you’re foreclosing the evolutionary and expressive capabilities of open source by restricting yourself to maintenance and security updates. “Launch it and live with it” is a recipe for failure.
Sure you can post new content if your implementation wasn’t botched, though that might still require a specialist team that understands how to operate a user-unfriendly CMS. But you’re effectively locked into whatever experience you launched with.
This isn’t in line with what the market wants, as evidenced by declining adoption numbers from the founding leaders of the DXP Magic Quadrant.
Most orgs don’t and frankly _can't_ do DevOps for the web (a core tenant of WebOps) and that’s a huge problem. This is why MACH was initially skeptical of open source — their reason d’etra was getting away not only from the monolithic DXPs, but also from the slow death of IT lockdown. A laudable cause, but one with its own set of challenges, as we’ll see. ## Headless & JAMStack & Composable & Kludgesauce. {#h.v91amcnn7rp9} There’s a new generation of rising web talent creating amazing UX with the web as their medium; they’re the ones pushing the envelope of application development within the browser. They are a key element of making the magic happen.
You want some of that, and for front-line marketing staff to be able to “compose” at the experience layer, so you let your DXP vendor talk you into going headless. Perhaps the salespeople from Contentful sold you on their whole new way of thinking. However it started, the journey has begun.
It’s exciting! This is why front-end platforms like Vercel are doing so well; they provide a modern delivery lifecycle for the experience. WebOps for the front-end is quite widespread, and unleashing creativity at this layer is leading to a ton of great innovation.
However, this is uncharted territory for a lot of teams. Sure the site looks great, but the disconnect between content and experience frequently stymies the less technical staff in marketing.
Even in the simplest setup, you’re telling me I have to create a GitHub account and make a pull request on a Markdown file to fix a typo? Did you just tell me to go fuck myself?
What happens then is the magicians get pulled back into production roles. Grindy, boring, high pressure production work. Nobody is happy.
Alternatively, your developers start extending the headless setup so that it can actually do everything the rest of the team needs, which is at least more interesting at first, but after a while it dawns on them… did I just write my own CMS? Again???
Most organizations are not prepared for the “science project” nature of this approach, and while it’s a breath of fresh air compared to the monolithic DXP it still creates bottlenecks and puts resources in the wrong place. It has resulted in a lot of idiosyncratic implementations that are one staff departure away from being totally unmaintainable. The directional trend here is correct, but buyers are drowning in decision fatigue and complexity, and many are feeling remorse. We have to do better. ## What the Analysts Miss {#h.mitxh9hz8lxz} The initial responses from analysts to the conversation that sparked this manifesto were understandably [a little defensive](https://www.linkedin.com/posts/irinaguseva_part-of-my-job-as-an-analyst-is-education-activity-7307204930577080320-vMB1/?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAAHYv4B-347oY6gm0hpZyNQFcb5fE0MW9A). Stating that the original DXP vendors are facing decline because they “followed an analyst playbook” could be taken to suggest a level of intent or agency that certainly wasn’t present.
Analysts don’t make stuff up, but they do extrapolate; at least a bit. That’s kind of the job. Listening to clients and aggregating their concerns is important, but it can also easily miss the bigger picture. Compiling what people are asking for is different from discovering what they truly need.
Without delving deeper into what’s going on with practitioners, the business itself, and examining the customer experience closely it’s hard to get to the _why._ It leads to incremental feature add-ons, and may over-weight the needs of procurement or other internal process (or politics) vs top-line objectives.
Just look at the criteria for the DXP category. It’s both super extensive and also somehow vague as hell. “Cloud?” C’mon, man. That's literally [a (hilarious) bit from The Onion circa 2012](https://theonion.com/hp-offers-that-cloud-thing-everyone-is-talking-about-1819595260/).
The paradigm of “buy and blend” is much closer to today’s market reality than “build vs buy,” but there’s still a missing piece. Where and how does this blending actually take place? A Cloud Application Platform? If you need to buy a DXP _and_ a tool from a completely different category to get an experience live, something’s off.
In this economy, reinventing the wheel and doing manual digital plumbing is unaffordable. Open source frameworks can solve that, but the vendor-centric approach dictated by the analyst business model leaves them at a loss to give guidance here.
Open source ecosystems are human, not corporate. They support massive economies, but do so via a blend of directed business investment, professional camaraderie, coopetition, personal passion, and hobbyist tinkering. Success in anything digital requires software from these communities, and the fact that analysts haven’t really analyzed them means there’s a blind spot in their perspective. ## The WebOps Way {#h.uvm9a3iyhu3t} WebOps starts with the practitioners of this craft and seeks to elevate their roles. In doing so, adherents transform the way they work and make themselves capable of what was previously impossible. It unlocks the magic.
What does that mean? Content teams publishing in real time, campaigners self-serving on optimizing rich pages and points of conversion, and technical and design resources improving the components those teams use, sprint over sprint, quarter over quarter, with no end in sight.
With WebOps, you break from the past of big-bang delivery, and get into the business of consistent ongoing improvement. It doesn’t mean you’re unable to make big changes, or take on ambitious goals, but it means you’re not halting all other action while a more complex project comes to fruition. You don’t need the re-launch motion to innovate.
This is how you get durable gains in efficiency. It’s also how you can create breakthroughs that deliver business upside. Fully leveraging open source gives teams a new gear, making them 2x or even 4x more productive.
The key is bringing proven best practices from DevOps to web teams. This requires capabilities currently split across the DXP and Cloud Application Platforms categories. Most IT organizations struggle to deliver this internally, and most vendors do not provide a solution given it's a blend of categories.
Teams need the ability to stand up the core web experience and quickly integrate or “compose” whatever data components are needed. They need a vertically integrated experience delivery stack so nothing stands in their way of shipping content, design, or functional integration. And they need a real application lifecycle to manage the ongoing evolution of this project.
Teams with these powers can move fast _without_ breaking things.
Your web experience tooling — be that a CMS, a front-end, or both — isn’t something you buy from a vendor or implement once. It’s something you evolve and drive forward continuously. That’s how you gain mastery over the medium: by keeping teams productive and armed with the tooling they need to win the day.
Teams that work this way become Agile Business Drivers. They don’t just hit delivery milestones for outputs; they can own goals, and work towards business outcomes. They are flexible, fast, and focused on results.
Zooming out, organizations with many stakeholders and teams doing this at scale achieve Freedom within a Framework. Unlike the one-size-fits-all approach, which never reaches required levels of adoption to deliver on its promise, WebOps can drive consistency, efficiency, and governance across the enterprise, without holding anyone back from their goals.
Central service groups can empower individual business units to customize locally within the framework, while also innovating and maintaining standards at a global level. This strikes a new balance that maximizes velocity within the organization, minimizes people “going rogue,” and ensures that security, stability, and compliance are maintained long-term at an affordable cost. #### Pantheon’s Part {#h.tn1ocu8yjp1o} Changing the way teams work on the web can be challenging. Legacy technology, organizational baggage, and gaps in processes can all create headwinds. The fact that the use-case is mission critical means it can’t be halted to do upgrades or modernization, complicates efforts to improve.
But progress is possible. Leaders that reject the status-quo are outpacing those that acquiesce to it, or throw up their hands in frustration. The professional movement of WebOps is growing every day.
Pantheon’s is here to help as many teams as possible realize the full potential of the web. We do so by helping developers make the most of open source frameworks, and bring their work closer to the web-native tools of their colleagues in content, campaigns, and design.
There are many ways we can carry the conversation forward. First and foremost, by conversing. We’d love to hear your feedback on this.
If you are a practitioner we invite you to check out our free study guide, and [learn the principles and benefits of WebOps](https://docs.pantheon.io/certification/study-guide/webops).
If you are a leader, we have a wealth of resources and case studies to help you understand and [build the case for change](https://pantheon.io/about/webops) within your organization. We’re also happy to partner with you in that effort.
If you are a service provider who delivers web experiences to or for clients, the above resources are great, and we also have a rich partner program [you may want to explore](https://pantheon.io/partners).
If you build web products, and want to explore how elevating your operations can unlock new levels of efficiency and help you grow your business, [we have a special ISV program just for you](https://pantheon.io/partners/pantheon-isv-partners).
Together we are building a better web, and better professional practices for everyone who does this work. We make the internet, and together we thrive.

About This Site