Exploring Composable CMS & Adobe Experience Manager Evolution

Brad:
Hey everybody, welcome back to another exciting episode of the Scaling Enterprise WordPress and Open Source Software podcast. I’m one piece of the puzzle of your hosting crew here, Brad Williams. Excited to dive in—another fun episode. As always, I’m joined by Tom Wilmot. What’s going on, Tom?

Tom W:
Great to be here. Excited to be back with Tom Cranstoun, who you can see is already here. And so I think without further ado, we can probably dive right in. Karim, I’ll hand over to you.

Karim:
Absolutely. Hello, audience. Karim Marucchi here again as the third host, and today I’m excited to have a conversation with Tom Cranstoun. Tom and I met last year at Janus Boye’s conference around CMS experts, and we’ve had a lively, spirited conversation since. Tom has been working for almost 15 years with AEM—Adobe Experience Manager—and we’ve had some really interesting conversations. He has a lot of experience in it. So really, Tom, welcome. I’d really like to welcome you to the opposite side. We, in the WordPress world and the open source world, think of AEM as the competition. So welcome. Thank you for taking some of our questions, and tell us a little bit more about your experience and how our misconceptions about AEM are hurting us in figuring out how to help the enterprise.

Tom C:
Okay, yeah, thanks. As you said, 15 years with AEM—worked with all of the major websites: Nissan, Twitter (now X), Ford, Jaguar Land Rover, McLaren Sports Cars, Hyundai, Genesis, EE (a telecom provider in the UK). So I’ve worked with all the big players, and I’ve worked on the largest AEM websites on the planet. The website for Nissan-Renault covered 300 markets in 25 languages, all done on two AEM systems. The key misconception is that it’s miscategorized as a proprietary system. AEM is not proprietary—it is built on open-source foundations. Even more importantly, the open-source foundations were created by the original developers of what is now known as AEM. I’ll cover that in a little more detail later. It is really one of the most successful marriages of open source and enterprise capability, and it is now moving fully toward a composable architecture. As I said, I’ve been working with it for 15 years. I’ve always used it as a composable architecture. I’ve never used it as a monolithic, out-of-the-box, one-stop solution. So, forever, it’s been composable, and it’s getting more composable as the years go on.

Karim:
So can you tell us a little bit more about these open-source origins? We are intrigued.

Tom W:
That’s very interesting. Yeah, I’d love to know a bit more about that.

Tom C:
Yeah, well, that began with a product called CQ. You may have heard the expression CQ5, and if you’re looking for AEM-related content, you’ll always come across CQ5. CQ5 was the last iteration of Communiqué, a product of Day Software. Day Software invented Communiqué, which eventually morphed into Adobe Experience Manager. The Chief Scientist, Principal Scientist at Day Software was a guy called Roy Fielding. Roy Fielding should be well known to everybody who uses the internet. He was chairman of Apache, he created the URL structure, and his university thesis was on REST—Representational State Transfer for the web. He is the chief architect of what has become Adobe Experience Manager. And way back in 2010, he published slides—I’ll share them with you later, Karim—about how to build on open source and really create a marketable, wonderful product.

Karim:
We will post them on the site.

Tom C:
Okay, thank you. Yeah, as part of Apache Software and Day Corporation, he was chairman of Apache. Day Corporation created Apache Jackrabbit, which is a Java Content Repository database for the Java community. They also created Apache Felix and OSGI plugin modules, which is the plugin system that AEM uses—much like WordPress has plugins, AEM has plugins for OSGI and Apache Sling. These were all developed by Day Corporation, contributed to the open-source world, and then built upon to become Communiqué.

Karim:
Right. So can I ask you a quick question? What happened in 2002? Why did they decide to move away from open source?

Tom C:
No, they’ve never fully moved away from open source. They are still the maintainers. Adobe is still the maintainer of these projects, and the staff they acquired from Day Corporation moved into Adobe with them. Roy Fielding remains a principal scientist at Adobe, and other names from those open-source days are also still working at Adobe.

Tom W:
So some parts of the suite today remain open source? Or are some of the building blocks of those products still open source?

Tom C:
If you analyze what’s inside AEM, it is a composable architecture. When you run an Adobe Experience Manager server, you will have 900 individual pieces of Java software running in the OSGI framework. Only 3% of them are not open source.

Brad:
Interesting. I think it’s surprising that all three of us are hearing that there are open-source foundational components to it. Honestly, I’m surprised as well.

Tom C:
Yeah, but I think the most amazing thing is that I’ve taught a lot of developers, mentored them, trained them formally, written manuals, etc., and they always ask me: “Why does Adobe take open-source software and charge a fortune for people to use it?” That’s not what happened. Adobe created the software, donated it to the open-source world, and then charged for their services—not for the software itself.

Karim:
I see. So why do we see AEM implementation shops? Is Adobe charging for hosting in the same way we think of Drupal or WordPress?

Tom C:
Just like WordPress, you have three ways of running AEM. You can host it yourself—get a package from Adobe, install it, and you get training manuals, documentation, and the 57% of the code that isn’t open source, so you are buying a license. You also get integrations with the rest of Adobe’s suite. Don’t forget, creatives are working with Photoshop, so Adobe has connectors that allow you to save directly into AEM from Photoshop. That’s brilliant for creative shops. You can also access Adobe’s personalization service and their entire digital experience stack. They weren’t just a CMS when they started—they were one of the first DXP platforms.

Karim:
Interesting. So could I literally spin up a server and put up a version of AEM with just the open-source components? Are there major gaps, or is it a complete system without the proprietary Adobe pieces?

Tom C:
Yes, yes. There are more than one CMS systems based on the 43%. I will send you links to them after the chat. Absolutely. One of the people you met, Marta from CMS Experts, her company provides a CMS based on the 43%. Their product, StreamX, makes AEM faster—it’s a frontend optimization tool, similar to how Varnish accelerates page loads. It works with AEM and also with the open-source versions of CMSs that share common architecture. So there’s still a significant open-source contribution out there. As I said, Adobe maintains the core system, they accept input from the public, and you can see how it works. The 57% proprietary portion consists of the technical “glue” that links their ecosystem together and provides the UI for editing. However, Adobe is now migrating the UI to new, open-source ways of working, which will be attractive to users outside the corporate sphere.

The newest thing they’ve done, moving away from the past, is called Franklin (or Edge Delivery Service). It allows you to create a page inside Word or Google Docs and publish it as a fully rendered webpage directly to Adobe’s Edge Delivery Services network. If you follow Adobe’s rules, the entire frontend is open source—you can download it, modify it, and fully customize it without dealing with a backend system. I have written an extensive blog about this—it’s all on All About Network, and even Adobe recognizes it as a key source of information on Franklin and Edge Delivery.

Karim:
Amazing. Tom Willmot, this sounds truly…

Tom C:
Composable.

Tom W:
Yes, exactly. The other thing we were trying to talk about earlier is how AEM can be deployed. You mentioned that it’s available in three ways: self-hosted, cloud-managed by Adobe, or as a full cloud service with a serverless approach. Can you expand on those options?

Tom C:
Sure. AEM can be:

1. Self-hosted – You buy the package from Adobe, install it on your infrastructure, and run it yourself. You get the documentation, training, and a full set of tools, but it’s up to you to maintain it.
2. Adobe-managed cloud – Adobe hosts and manages AEM for you, handling infrastructure, updates, and scalability.
3. Full cloud service (AEM as a Service) – This is a fully serverless model where Adobe takes care of everything, and you simply use their APIs and UI to build and deploy content.

Each of these approaches comes with different pricing and levels of control, so enterprises choose based on their specific needs.

Tom W:
You mentioned earlier that AEM has always been composable in your experience. That’s quite interesting. I think in the WordPress space, many people might not fully understand what composability means in an enterprise CMS context. Some might see Adobe as a monolithic suite and composability as an alternative approach. Could you explain composability in this context and how Adobe is shifting from a suite to a more modular system?

Tom C:
Sure. Composability means that instead of having one massive system that does everything, you have independent components that can be used separately or together. When you build a website, you create the entire frontend independently, ensuring full control over how it looks and functions. Then, you can pull in backend services and APIs to supply data dynamically.

AEM’s plugin system is based on OSGI (Open Systems Gateway Interface), which allows Java components to be modular. Instead of running multiple Java applications separately, OSGI enables a single Java runtime to load and manage multiple independent modules. This means that AEM users can build and integrate their own backend components without modifying the core system.

Even if you’re using an Adobe-hosted version of AEM, you can still contribute your own OSGI components. These components can process data, retrieve content from external sources, or even render entire pages before sending them to the frontend. This makes AEM highly flexible—you’re not locked into a single workflow or infrastructure.

In the early days, AEM was more monolithic, with everything (code, assets, backend logic) stored in a Java Content Repository (JCR). But over the past 15 years, Adobe has systematically split AEM into smaller, independent services:

• The database and assets were separated into two different storage systems, with assets often hosted on AWS.
• The core system was divided into Adobe-managed components and user-provided customizations.
• The backend processing was moved to serverless components, using Apache OpenWhisk (an open-source serverless platform that Adobe contributes to).

So, AEM today is no longer a monolith—it’s a set of interconnected services, making it much more composable than in the past.

Karim:
Could I jump in with a quick question? Looking at the latest Gartner Magic Quadrant, they highlight that some CMS platforms are more composable than others. They mention systems like Squiz, which are designed as independent modules rather than tightly integrated suites. It sounds like AEM is modular at a deep engineering level rather than a product level. Does this mean enterprises still need to do significant design work before implementation?

Tom C:
Yes, you always have to design composable systems before implementation. With fully modular CMS platforms, enterprises must plan which components they need, how they integrate, and what APIs they’ll use.

Karim:
But can you swap out individual modules easily? If you don’t like one part of AEM, can you replace it with something else? Is that a big refactoring effort?

Tom C:
No, you don’t have to refactor the entire system. The way it works is through OSGI plugins. You can write a new plugin with a higher priority than the existing one, and OSGI will automatically load the highest-priority component. This means you can update or replace modules while AEM is running, without downtime.

Brad:
That’s really interesting. Tom, earlier you mentioned some of the big brands using AEM. Could we talk about real-world implementations? Maybe share some of the challenges they’ve faced at that scale? Every platform has pros and cons, so it would be great to hear about the obstacles they encountered and how they overcame them.

Tom C:
Absolutely. I’ve worked with several major brands, but one of the most fascinating cases was Twitter/X. I was working with MediaMonks, a major digital agency, when they were building AEM sites for Twitter. The challenge was that AEM developers were used to using jQuery, because Adobe’s UI had traditionally relied on it. But we decided to eliminate jQuery completely for public-facing pages and use pure JavaScript with minimal frameworks.

This was a huge mindset shift for AEM developers. Many teams were used to working with jQuery because “it’s always been done that way.” But we proved that dropping jQuery resulted in cleaner, faster, and more maintainable code. Twitter’s AEM-based microsites performed significantly better, and their team told us we were the best AEM consultants they had worked with.

Another example is Nissan, which operates globally with different backend systems for each region. In India, they stored data in Excel spreadsheets. In France, they used XML schemas. In the US, they had factory-supplied databases. Our job was to integrate all these disparate sources into a single system so that AEM could retrieve and present unified content across markets.

This is an example of backend composability—even though AEM was the frontend CMS, we had to create a facade that made multiple backend systems appear as a single, seamless source. This required advanced API engineering but ultimately provided Nissan with a unified global web presence.

Brad:
I love the irony of the JavaScript lifecycle—starting with plain JavaScript, then using every possible framework, and now going back to plain JavaScript again.

Tom C:
Yeah, but JavaScript is a completely different language now than it was when jQuery was first invented. Today’s ES6+ features make jQuery unnecessary in most cases.

Karim:
That’s a great insight. Tom, can you tell us where Adobe is heading next with composability?

Tom C:
The next major step after Franklin was the introduction of the Universal Editor. Everyone in the CMS space talks about universal editors—these are tools that let users edit content in a headless CMS while seeing a WYSIWYG preview of how the final page will look. The difference with Adobe’s Universal Editor is that it works with any CMS, not just AEM. You can use it to edit a live website directly within the browser, modify the content, and save the results back to the CMS—without needing a traditional backend interface.

Karim:
Is the Universal Editor open source?

Tom C:
No, it’s proprietary.

Karim:
Just checking, because I thought of an interesting experiment.

Tom C:
I see where you’re going with this. While the Universal Editor itself isn’t open source, it doesn’t care what CMS it’s connected to. It’s designed to work with any structured content system. You do need to add some markup to your CMS to make it compatible, but once that’s done, the Universal Editor will work with it—whether that’s AEM, another enterprise CMS, or even WordPress or Drupal.

Karim:
That’s exactly what I was wondering. Could we create a sandbox experiment in the WordPress community to see if we can make the Universal Editor work with WordPress? I’d love to know if we could bridge that editor with an open-source CMS.

Tom C:
That would be an interesting experiment. I’ll talk to my contacts at Adobe and see if we can get something going. Since Adobe is focusing on modularizing AEM and integrating with other systems through Adobe I/O and serverless APIs, this kind of cross-CMS integration might actually be feasible.

Tom W:
So Adobe’s long-term strategy seems to be making everything more composable and breaking away from traditional monolithic CMS structures. What’s next in their roadmap?

Tom C:
Yes, exactly. After Franklin and the Universal Editor, the next step is Document Authoring—a completely different initiative from Franklin. Unlike Franklin, which relies on Google Docs or Word, Document Authoring uses standard CMS-based workflows. It integrates with the Universal Editor and allows users to compose content locally while maintaining full backend capabilities like workflows, translations, and approvals.

The internal code name for Document Authoring was “Dark Alley”, but it’s now officially called “DA” (Document Authoring). The main advantage is that it stores content directly in the AEM repository, so companies can leverage all of Adobe’s enterprise-grade features—without losing the flexibility of composable content creation.

Karim:
That’s very interesting. But let’s take this further—if Adobe is becoming more composable, does that mean they’re embracing more open-source interoperability?

Tom C:
Yes, but selectively. Adobe’s strategic focus is breaking AEM into smaller, modular services that can integrate with other platforms through APIs. However, they are not making all of AEM open source. Instead, they are open-sourcing specific technologies (like Apache OpenWhisk for serverless functions) while keeping the core enterprise features proprietary.

For example, Adobe’s Firefly project is an AI-powered system that integrates across Adobe’s suite—Lightroom, Photoshop, AEM, Franklin, etc. Firefly runs inside Adobe I/O, which is powered by Apache OpenWhisk (an open-source serverless platform). This means developers can compose workflows across multiple Adobe products, treating them as modular services rather than a single suite.

Karim:
That’s fascinating. It sounds like Adobe is positioning itself as an ecosystem of interoperable tools rather than a closed suite.

Tom C:
Yes, that’s exactly what’s happening. Adobe is not just a CMS anymore. It’s moving toward composable digital experience platforms (DXPs), where companies can mix and match services instead of relying on one massive system.

Karim:
That’s a great insight. Tom, if people want to follow your work on Franklin and composability, where can they find your writings and blogs?

Tom C:
My blog is All About Network. If you go to All About Network, you’ll find an extensive collection of articles on Franklin, Edge Delivery, and AEM composability.

Karim:
Fantastic. Tom Cranstoun, thank you for joining us and for putting up with our deep dive into AEM’s composability and open-source connections. We’ve learned a lot today, and we look forward to hearing more from you in the future.

Tom C:
It was my pleasure. Thank you!

Tom W:
Thanks, Tom. Great conversation.

Brad:
Yeah, thanks, Tom. That was really enlightening.