We've been implementing websites and Content Management Systems (WCM/CMS) for customers for a number of years and many patterns have emerged. Glenn talks about some technical patterns here and I've talked previously about how WCM projects are different than other Application Development projects here.
Something that we always need to address is "integration". As with any website you are building, integrating into back-end systems is a challenge that needs to be handled directly and explicitly, however, when a WCM is in the mix and the need is to have data from back end systems AND content from the WCM merged, the difficulty increases.
There are 4 main types of pages that need to be accounted for during a WCM website implementation:
A. Content Pages - Pages that are predominantly a single item of content (with possibly related content in left or right gutter)
B. One Page - One page that merges both multiple content items as well as back end functionality. This functionality normally will touch your back-end systems and is typically the MOST complex type of page to build.
- C. Managed Static Information - Content that typically gets managed through the CMS's Digital Asset Management system (and sometimes plugged into a 3rd party DAM)
- D. Unmanaged Static Information - These are "site" assets such as CSS, JS, images for buttons and other parts of the templates. Sometimes these are managed similar to "C", however, they usually have a very different lifecycle. Theirs more closely aligns with "E"
- E. Pure Functionality - this is code that provides various features for end users on the site. Many times, this code integrates with internal back-end systems. This code needs to follow the standard Enterprise SDLC and configuration management process. It is a common misstep amongst CMS implementations to try to manage this code through the CMS. It is unnatural and destined to fail.
Understanding how to handle each of these page types is key to success in a WCM implementation. Understanding how to integrate content AND functionality (Type "C"), is one of the first and most crucial things to accomplish with any implementation.
Some possible strategies to consider are:
1. Keep them as separate as possible on the page. Don't have content and data from a back-end system in the same SENTENCE (most times this isn't possible).
2. Use AJAX to dynamically fetch the functionality into a predominantly content page
3. Use the Dynamic coding capability of your CMS to connect to the internal systems, however keep it clearly separated in an "Integration Layer" as these items are more likely to change rapidly.
4. Componentize the functionality so it can be easily modifed and released without impacting your Content Editors
That's all I can think of right now. Let me know if you've got other strategies or identified other types of content/page types for a WCM/CMS implementation.