Andy Cohen is the founding architect of Sitecore XM Cloud. He is VP/Chief Architect at Altudo, and a CMS Critic contributor.
I wrote my first lines of code in the 1980s. At the time, I was just a curious kid fascinated by the way a few keystrokes could change what appeared on the screen. Watching a cursor move or a pixel shift because of something I typed felt like a kind of magic. Those early experiments sparked a curiosity that never went away.
Eventually, that curiosity turned into a career in software architecture and digital platforms.
Over the past two decades, I have lived through every reinvention of digital experience. I saw the rise of monolithic suites that promised all-in-one solutions. I saw headless emerge as a response to flexibility demands. I watched composable become the term that dominated every RFP and analyst report. And now, I see the industry grappling with the arrival of artificial intelligence and the new expectations it brings.
Each of these cycles began with enthusiasm and ended with new layers of complexity. None of them were failures. They all delivered value and moved the industry forward. But each also left behind lessons that deserve to be carried into the next era.
The question now is not whether composable was right or wrong. The question is what comes next, and how we can make sure it solves real problems without recreating the same patterns of over-complication.
The word “composable” seemed to appear out of nowhere, but in reality, it was introduced and amplified by analyst firms like Gartner and Forrester. Their frameworks shaped the categories that vendors had to compete in, and those categories shaped how customers thought about their options.
I remember how much energy leadership teams put into preparing demos for analyst submissions. I was not directly involved, but it was impossible to miss the pressure. Each submission required proof points that mapped to analyst checklists, and it often felt less like leading a vision and more like checking boxes that someone else had drawn.
This is not a criticism of Sitecore or any other vendor. It was the reality of the industry. Analyst frameworks serve a purpose: they help customers navigate a complex landscape. They provide benchmarks and comparisons that buyers depend on.
But they also create incentives that favor coverage over depth. If the report says you need to have six integrations to qualify as composable, you work to prove those six integrations, even if you would prefer to double down on rethinking a core architecture. Composable was as much a product of these external pressures as it was an internal shift in how platforms were designed.
What still makes me smile (even today) is this: if you ask most marketers or developers to define “headless” or “composable,” they often hesitate. Marketers tend to describe the benefits they have been promised, such as freedom, agility, or choice. Developers are more likely to point to APIs or decoupling. Both perspectives are partly correct, but neither offers a precise definition.
That is the irony of composable’s rise: the buzzword spread faster than a shared understanding of what it actually meant, and the industry chased adoption before it ever agreed on clarity.
That is how composable went from an architectural pattern to an industry mandate. Vendors raced to prove their coverage, customers asked about it because the reports told them to, and soon it became the central conversation. It was marketed as freedom, flexibility, and best-of-breed choice. It created excitement and hope. But it also created a gap between what was pitched – and what was possible.
The divide between IT and Marketing has always existed. For years, platform conversations were usually led either by a CTO or a CMO, rarely both in the same room. Composable did not create this gap, but it sharpened it. The promises of plug-and-play freedom appealed to one audience, while the realities of microservices and integration work spoke to another.
When IT led the process, the questions focused on governance, security, and scalability. A CTO wanted to know how to enforce single sign-on across twenty sites. They wanted to understand whether the platform could manage localization and translation at scale without breaking workflows. They wanted to know how open the APIs were, how easily the system integrated with their existing infrastructure, and whether adopting it would lock them into a corner they could not escape.
When Marketing led the process, the questions were about speed and agility. A CMO wanted to know how quickly a campaign site could launch without waiting for IT. They wanted assurance that authors could edit content without having to log a ticket for a developer. They wanted confidence that they could swap tools in and out as their needs changed, whether for personalization, analytics, or optimization.
Composable appealed to both groups, but for entirely different reasons. Marketers heard plug-and-play freedom. Developers heard microservices and decoupling. In practice, neither group got what they expected, because composable was never backed by a cultural alignment of goals. The result was friction, and in many cases disappointment.
The divide between IT and Marketing maps perfectly to Conway’s Law, organizations design systems that mirror their communication structures. If two departments do not work well together, their technology stack will reflect that divide. Composable did not eliminate this pattern. It made it more visible.
I have seen organizations where IT operated as a shared service. Developers had to submit tickets to a central infrastructure team just to spin up a project. That team was talented, but they were overloaded and far removed from the context of the actual business problem.
As a result, the burden shifted back onto the developers, who were suddenly expected to become “super-developers” who could handle infrastructure, security, and application code. Those people are rare. More often, projects stalled, or they became brittle because a developer was forced into responsibilities outside their expertise.
The alternative was embedding DevOps or infrastructure specialists within each team. This sped things up dramatically, but it also created fragmentation. Each team made its own choices, adopted its own patterns, and optimized for its own success. At the enterprise level, the result was chaos. Teams moved fast, but the organization as a whole lost consistency and scale.
Even within the same company, different groups often used the terms “headless” and “composable” in completely different ways. I have been in meetings where marketers and developers debated whether a platform was truly one or the other, and neither side could land on a crisp definition. Marketers spoke in terms of outcomes. Developers spoke in terms of architectures. The fuzziness in language mirrored the fuzziness in communication. Conway’s Law was not just visible in the codebases. It was present in the vocabulary itself.
Tightly coupled organizations built tightly coupled systems that moved slowly but consistently. Fragmented organizations built fragmented stacks that moved quickly in silos but struggled to scale. Composable laid bare whichever culture was already in place. It never fixed the communication gaps.
For developers on the ground, composable created its own kind of friction. Each new system came with an integration promise. The marketing slides made it look simple: plug in a CMS, connect a DAM, integrate analytics, layer on personalization, and wire in a CRM. In practice, every new tool brought new orchestration requirements. You had to handle retries, errors, and edge cases. You had to monitor flows, test regressions, and maintain fragile connections over time.
iPaaS platforms promised to make this simple. Their demos were compelling, drag-and-drop connectors moving data between systems in minutes. But on the ground, almost every integration required custom code. iPaaS workflows needed to be tested and monitored like any other application. And they added another tool to learn, another dashboard to maintain, and another point of failure to debug.
Very few people can go both wide and deep across all of these systems. Most developers specialize in one or two. As the landscape expanded, the field of view became harder to cover. You might have one developer who knows the CMS inside out, another who knows the DAM, and a third who can wrangle iPaaS. But the person who can stitch all of them together with confidence is rare. And when that person leaves the team, progress often stalls.
This is why composable created so much hidden friction. It was sold to marketers as plug-and-play freedom. To developers, it became integrate-and-pray.
The truth is that technology revolutions are never just technical. They are cultural.
I saw this firsthand during Sitecore’s transition from on-prem to SaaS. That shift required more than new code. It required continuous delivery. It required a culture of shipping constantly, not in large annual releases. It required transparency, with roadmaps and commits visible instead of hidden. And it required a change in how engineering, product, and leadership communicated.
That kind of transformation never happens without change agents. These are the people who carry the future in their heads before it is visible to everyone else, and who are willing to keep pushing even when they meet resistance. They bridge silos, notice misalignments, and translate between groups that do not normally understand each other.
In my experience, they rarely begin with grand speeches or bold declarations. More often, it starts quietly. A change agent is the one who asks the clarifying question in a meeting that nobody else dares to ask. They are the ones sending late-night messages to colleagues to test an idea or to make sure a decision really reflects what the team agreed to. They are the people who catch the small cracks in communication before they widen into gaps that sink a project.
Over time, those small actions build momentum. The same people begin to run workshops, draft presentations, and lead town halls. They are the ones building a new vocabulary for the company and repeating it until others start to use it as well. By the time leadership begins echoing the new philosophy, it often feels inevitable. But it only became inevitable because change agents kept the fire alive long enough for it to spread.
During Sitecore’s shift to SaaS, this looked like engineers pushing for continuous delivery even when the old habits of quarterly releases pulled hard in the other direction. It looked like product managers were aligning roadmap conversations to reinforce the new culture of “ship it” instead of “save it for the big launch.” It looked like middle managers reworking reporting structures to remove bottlenecks, and executives amplifying messages they first heard in backchannel conversations.
Cultural revolutions are not driven by one person at the top or one team at the bottom. They are carried by many people at every level who decide to act differently, and then repeat those actions until they become the norm.
Today, the conversation has shifted again. The new buzzword is “agentic.” AI is being sold as the next easy button. Just let the agent do it.
The pitch feels different this time, because AI really does feel like magic. Watching a system stream text out as if it were a human conversation is not a trick; it is a fundamental change in how we experience software. For decades, technology has forced people to conform to its rules, menus, forms, dashboards, and processes that only made sense to those who lived inside them every day.
AI flips that expectation. It responds in natural language, it adapts to our words, and it feels like it is meeting us on human terms. That alone sets it apart from previous waves of technology.
But there is more here than the surface experience. Underneath, new patterns are emerging that could finally provide the connective tissue the industry has struggled with for years. Standards are being explored to make it easier for systems to exchange context, so one service can hand off to another without brittle integrations.
Orchestration platforms are evolving from static pipelines into adaptive layers that can coordinate tasks across multiple systems. These are not yet mature, but they point toward something that goes beyond what traditional iPaaS or workflow tools could deliver.
That is why the agentic pitch feels different. For the first time, both sides of the equation are moving. The human-facing side feels conversational and natural, and the machine-facing side shows signs of becoming more adaptive and interoperable. If those two trends converge, teams could see a step change in how they build, integrate, and operate digital platforms.
Still, history gives us a reason to be cautious. Big shifts tend to magnify what already exists. They rarely erase it. AI will not suddenly fix dysfunction. It will accelerate whatever is already there. A broken workflow fed into an agent will still deliver broken results, just faster. A poor architectural assumption will not become smarter when wrapped in a conversational interface; it will simply become harder to undo.
AI is best understood as a multiplier. It makes strong foundations stronger, and weak foundations weaker. Organizations that already have clarity, pragmatism, and well-aligned teams will find that AI accelerates their progress. Those that are fragmented, slow, or siloed will find that AI makes their problems show up sooner. That is why the agentic future is not an automatic “easy button.” It is a reflection of culture and design. The winners will be those who recognize this early and prepare accordingly.
Which brings me to what I believe will define the next era of digital experience.
The success of DXP players in rolling out their agentic future will not rest solely on the quality of their APIs or the elegance of their architectures. It will depend on the ability of their customers and partners to implement real change, to succeed at scale, and to communicate that success outward. A DXP that helps make that cultural transformation possible will create value beyond anything in its feature list.
Selling cultural change cannot just be about inspirational marketing. It has to be embedded in the product. The next generation of DXPs will need to make cultural adoption tangible. They can do it in several ways.
How can platforms make transformation part of the product itself?
Finally, package cultural transformation as part of the value proposition. The software license can include the platform and the playbooks, the bootcamps, the benchmarks, and the community. That is what it means to sell cultural change as a product, not just as a service.
A lot of this may sound like lofty language. Defaults, playbooks, bootcamps, cultural metrics, communities. It can read like a management consultancy brochure more than a product roadmap. And to be honest, it is complicated. It stretches beyond what most software companies are set up to deliver.
But software alone rarely succeeds unless people also change how they work. When platforms focus only on moving licenses, customers run into the same adoption struggles, the same failed projects, and the same missed potential. The companies that break through are the ones that aim higher. They do not just sell features. They help customers adopt a new way of working.
This is where the Steve Jobs analogy fits. Jobs did not just sell an iPhone. He sold the idea that you could carry freedom and creativity in your pocket, and that by buying one, you were joining a movement. That was not a feature list. It was a lifestyle.
I am not sure what the exact equivalent is in the DXP space, but it cannot just be uptime, APIs, or another integration tick box. The platforms that win will be the ones that tie their value to something larger, something human. They will show that adopting their platform means joining a movement toward faster collaboration, shared ownership, and cultural agility. That is a lifestyle for the digital enterprise, and the companies that learn how to sell it will define the next era of this industry.
And it cannot just be a rebranding exercise. Saying “we are agentic” will not cut it. Customers have lived through enough acronyms and buzzwords to be skeptical of the next one. If the value does not go deeper than a new term, it will fall into the same cycle of hype and disappointment.
That is why cultural change has to be more than marketing. It has to be built into the way the platform is delivered, the way teams are enabled, and the way success is measured. The equivalent of Steve Jobs selling a lifestyle in the DXP world is not a clever tagline. It is the moment when a customer realizes that adopting a platform has changed how their teams work together, how fast they can adapt, and how confident they feel about their future.
After decades of cycles, I have learned that the vocabulary will always change. Monolith, headless, composable, now AI. Each wave comes with new language, new optimism, and new complexity. Yet the constants remain. Success does not come from the acronym of the moment. It comes from clear ownership, pragmatic design, and a culture aligned with technology.
The companies that move fastest are not always the ones with the best technology. They are the ones where product and engineering are aligned, where marketing and IT learn together, and where culture is treated as part of the product itself. The platforms that succeed are not only those with strong APIs or elegant architectures. They are the ones that help their customers adopt new ways of working and sustain them at scale.
That is why cultural transformation must be built into the product, not added later as a consultancy service or a line item in a pitch deck. Defaults, playbooks, workshops, metrics, and communities are not extras. They are how customers change how they work. Without them, even the most advanced platforms end up underused, misaligned, or abandoned.
And perhaps the most important question of all: why do we keep building in the first place? It cannot only be about efficiency, or cost savings, or quarterly growth. At its best, this work is about something larger. It is about the search for simplicity in a complex world. It is about the hope that technology can help people work together more effectively. It is about creating tools that make life a little easier, and perhaps even more human.
The future of digital experience will not be defined by who invents the cleverest acronym or who adds the most features to a slide. It will be defined by who helps organizations work differently, who unites product and engineering, and who delivers cultural change alongside software.
That is the lifestyle of the digital enterprise. That is the movement worth building.
October 14-15, 2025 – Amsterdam, Netherlands
November 4, 2025 – New York, NY
November 6, 2025 – Los Angeles, CA
Join us at JoyConf 2025, where the future of content meets the people shaping it. Built for developers, marketers, and digital innovators, this free conference goes way beyond product updates or yet another strategy playbook. It’s where you’ll get inspired, get real, and get connected – to ideas, to the community, and to what’s possible when you build joyfully. Whether you're building lightning-fast frontends or launching cross-channel campaigns, this is where content becomes connection and collaboration becomes second nature. Come for the talks. Stay for the community. Leave with joy. Save your spot.
November 3-5, 2025 – Orlando, FL
At Sitecore Symposium, you’ll learn how to meet your customers where they are – across channels, moments, and touchpoints that didn’t exist a year ago. You’ll hear how the boldest brands in the world are transforming content into outcomes and creating experiences that are fast, relevant, and human. Join 1,500 marketers, digital leaders, and technologists in Orlando to see what’s possible when personalization scales, AI accelerates creativity, and trust becomes your competitive edge. This is the Third Wave of the Internet. And this is your moment to lead in it. Get your tickets today.
January 13-14, 2026 – St. Petersburg, FL
Meet industry leaders at our fourth annual CMS Kickoff – the industry's premier global CMS event. Similar to a traditional kickoff, we reflect on recent trends and share stories from the frontlines. Additionally, we will delve into the current happenings and shed light on the future. Prepare for an unparalleled in-person CMS conference experience that will equip you to move things forward. This is an exclusive event – space is limited, so secure your tickets today.