As the Web CMS marketplace pendulum has swung from content management to experience management over the past few years, we've seen a greater emphasis on "coupled" architectures. That's not always a good thing.

(Alert: somewhat techie discussion follows.)

About coupled architectures

Roughly speaking, you can divide any web content & experience management solution into two application sets:

1. Internal, editorial- and management-facing services
2. External, delivery- and experience-facing services

In a coupled architecture, those two application sets get tightly bound together -- and in some cases become indistinguishable from each other -- within a single platform.

A fully coupled architecture brings several advantages, not the least of which is giving marketers more transparent control over customer experience from a single management environment. Most major open-source WCM platforms work this way, and likewise the mid-market .NET players all emerged from a background where you managed and delivered your site from a single server.

About de-coupled architectures

In contrast, a completely de-coupled architecture totally separates content management from experience management, usually to the point of being delivery-agnostic. This was once a very common approach (Interwoven TeamSite and Percussion Rythmyx were famous for it), but has ebbed in popularity recently.

However, the enduring need for de-coupled solutions among some sectors -- as well as the desire for simplicity among many customers -- has sustained some highly de-coupled WCM products at the lower end of the market. These include Ingeniux, OmniUpdate, Hannon Hill, CrownPeak, TerminalFour, and various similar offerings from around the world. The re-birth of Moveable Type as an alternative to Wordpress probably also reflects some latent demand here. A desire for strict decoupling among some customers has also spawned a nascent "NoCMS" movement, which we'll detail in another post.

The case for loosely coupled

At the upper end of the WCM marketplace, some vendors offer "loosely-coupled" solutions where a savvy licensee can vary how closely they bind the two application environments, depending on their business context. These include vendors like Adobe, SDL-Tridion, CoreMedia, and Oracle, but notably not Sitecore. As Web CMS Report readers know, this approach makes these platforms very complicated, but also potentially quite flexible.

Unfortunately, the notion of loose coupling does not seem to have permeated the Web CMS mid-market, at a time when we see more and more customers looking for it. Consider the following use cases.

• A higher-education or public-sector organization may want to: A) "bake" primarily static content to a low-cost and reliable delivery environment such as a simple webserver, but B) still have the option of producing highly dynamic experiences for certain subsite areas
• An ecommerce firm may want to: A) retrofit a simple CMS behind their transactional, customer-facing applications, while B) separately run some content-rich, interactive microsites for marketing purposes from the same platform
• An enterprise may want to: A) deliver mobile experiences via a completely different platform (possibly 3rd-party), as well as B) deliver desktop experiences within a tightly coupled Web CMS

In each "Case A" the system doesn't actually deliver content or experiences itself to the end-consumer; in "Case B," it does. You can't readily do both with, say, Drupal. Yet you shouldn't have to license an Adobe or Oracle to fulfill these needs if you're not a Global 2000 enterprise.

So where are they?

Some mid-tier WCM solutions, like Hippo and Magnolia, can run in a loosely-coupled fashion. But once you get beyond that, in the mid-market, vendors seem to lean heavily towards highly coupled or de-coupled architectures. Theoretically you can warp some platforms to work the way you want, and you may see some examples in the comments below from integrators who have done interesting things with mid-market CMS tools. You stray from default system architectures at your own peril.

For RSG subscribers who want some more details and examples, feel free to schedule an advisory call, and we'll review your specific needs.