“Decoupled architecture” is a phrase I hear often, especially in the context of web content & experience management tools that we cover. The term has taken on greater significance of late as enterprises look to exploit cloud-based and omni-channel delivery environments. But sometimes people throw around "decoupled" to mean different things, so I'll try to offer some clarification.
First, some background. In a typical web publishing scenario, you have at least two distinct environments:
- A management environment, which includes content creation, library services, approvals, and so forth
- A delivery environment that includes page presentation and other site management capabilities
So, “decoupled” in this context basically refers to the extent of independence and coupling of the two environments.
Types of decoupling
As with most other terms in technology marketplaces, there are many variations and meanings of decoupling.
Let’s look at two broad variants and a kind of hybrid third option:
- Completely separate but identical environments
In some tools, such as Joomla!, there is no real separation between the two environments. You basically change a flag to “live” and content appears on the website. The same application manages and delivers content. But in other tools on the higher end of complexity, you run separate environments and when you publish content, it actually moves from one environment to another. The two environments have their own separate repositories, but they are similar in most other respects. In fact, in most cases, you just install a separate instance of the same tool in different environments. Platforms such as Oracle WebCenter Sites and IBM’s WCM take this approach.
- Completely separate and distinct environments
In some WCM tools, the two environments are completely different architecturally. In fact, in some cases, you can just create your own delivery engine using APIs. Tools such as GX Software’s XperienCentral take this approach. The content still moves from one environment to another but the software that drives delivery is completely different than the codebase that handles management.
- Separate but similar environments
In many cases, a single WCM platform will handle both management and delivery with some shared components, but with specialized additional modules in the management and delivery environments that are tailored to employee-facing versus visiting-facing functionality. Or alternatively, it's the same codebase, but the environments are separated, and for security and other reasons, some management functionality gets "turned off" in the delivery tier. The line between this and option #1 above can clearly get blurry.
There are other variations as well as newly emerging terms, such as "Headless CMS" to describe decoupling, but I'll cover that in another post.
What should you do?
If you are evaluating WCM tools and anticipate wanting a decoupled architecture, don’t just go by terminology. Consider some specific questions:
- How independent are the two environments? Can they work without each other?
- How aware are they of each other? Can you make changes to one, without making changes to the other?
- Can you differentiate between application and repository coupling?
- Is the vendor proposing simple environment isolation or true decoupling?
After hearing your concerns over the past fifteen years, we've taken a keen interest in architectural models as significant part of RSG's WCM vendor evaluations.
If you'd like a preview, you can also download a sample here.