Area Architect Dreams of Model Architecture
Most software architects are idealists at heart and think in terms of clean UML diagrams. In approaching a content management project, their tendency is to apply best practices in software development and design an architecture that supports highly structured and reusable content and separates concerns of management (authoring, workflow, and persistence) and delivery (formatting, personalization, and branding). The resulting picture is a "pluggable" architecture of components that can be swapped out as needed. As a software architect myself, I too am drawn to this model and, in many cases, it makes a lot of sense. However, most content management software applications try to play on both the management and delivery sides of the content management problem. If you want to achieve this de-coupled, pluggable architecture, you will most likely need to behead your CMS and put another delivery tier in front of it. Should you cut off the head to spite the face of your CMS? Maybe, but here are some things to think about.
Where a software architect's "separation of concerns" is on functional lines, a business user's concerns are task oriented. A business user's task is to produce content. But they don't just write. They write, review, write, review, then submit. And these loops are not long workflow steps involving many people. They consist of tiny cycles of typing and previewing. Interestingly, this is how software programmers work nowadays. They code a little, then they test. It has been 20 years since programmers have been asked to write a whole program and then send it over the wall to see if it worked. Now we give programmers IDEs (Integrated Development Environments) so that they can write and review (test) in the same environment. Modern software development methodologies stress continuous testing by the developers not just a separate group of quality assurance staff.
End to end CMS, which own the management and delivery tier, perform the same service as a programmer's IDE. They create a sandbox for the content author to develop the site (notice word choice here, I will talk about that later). When the delivery tier is decoupled from the management tier, this integrated environment must be custom built if it is to be provided. You need to be able to replicate the delivery sandbox and build publishing functionality to point to different delivery targets.
The other area where the concerns of management and delivery are not so clearly separated is that most users want to use their CMS to control how the content is displayed - a domain that should philosophically be owned by the delivery tier in that model architecture. This control is on two levels: at the content detail level (with layouts); and at the overall information architecture level - where the content will appear. Preview and control of the former is often easier to provide because it is simpler to push a single piece of content to a presentation template than to refresh the entire instance of the site (remember people like to preview every couple of minutes). Showing where a piece of content would appear in a search result list requires all the proposed content to be staged in the staging instance of the site.
These requirements of being able to control the the composition and behavior of the site is what I was referring to earlier when I said "develop a site." Typical needs include explicitly determining the order of lists of content and what reusable assets appear where. When the content producer is a site developer, the qualities that he must control and test do not end with the spelling, grammar, and accuracy of the text. He needs an environment that gives him a round trip preview experience of the whole site. He needs the IDE to develop the site not just a tool to produce content.
Now, in many cases, it may be reasonable to limit the scope of a content contributor to the composition of words and images. After all, your average Associated Press reporter is not able to control how his article will appear on the Daily Hampshire Gazette. If you are doing a lot of personalization, preview is also less valuable because there is no way an author can simulate all the different conditions that drive personalization rules. But this is not how your average corporate website works. Corporate websites are less query based and programmatic and more explicitly and manually composed.
Systems that publish to different channels and have complex delivery logic (where preview is less useful) tend to make better candidates for decoupled architectures because of the investment that it takes to develop the delivery tier. These sites have lots of custom code (or configuration files) that has evolved over time and is extremely expensive to port. In fact, it is usually hard to even estimate the time to port these applications because no one really knows the rules and algorithms. The behavior is totally undocumented except for in the code itself.
So if you are designing your dream architecture with different pluggable tiers and your business users are hassling you about preview and control, you need to ask yourself "is my delivery tier sophisticated and complex enough to warrant having to build my own?" If it is, you need to be able to explain to the users that the delivery tier is a complex application that drives the presentation and their job is to fill the tank. You can give them a single page simulated preview and they can share a full staging instance of the site if they wanted to review the whole site before a mass publish. If they don't buy it, you can build in the additional integration to support "site developer" tasks or wait for the next project to design that precious architecture.