This post was originally posted here by Martin Ottosen.
A common motivation for doing enterprise CMS solutions is the always elusive goal of building a platform (structure) which allows the organization to quickly and cheaply create new websites by leveraging the initial investment of the platform. The vision however gets tainted quickly as reality sets in. The various business units / brand owners / product managers usually have very different ideas about how they need to communicate to the outside world, they have different ideas about the form that suits their needs. So quickly you end up in a sticky situation where you have to choose between doing a lot of new development work everytime a new site is added to the platform, or restrict the flexibility of the platform to keep it financially feasible.
Form over structure
In other words, one important goal in enterprise CMS is to create a structure which is shared and cost-effective while allowing for a high degree of flexibility in the form of the different sites based on that structure. Lets consider an example problem: We are implementing a generic brand website which is to be the first (of many) sites based on a shared enterprise platform financed by the centralized IT department. Upon inspection of the detailed requirements (wire frames, use cases, information architecture, etc.) the developers are able to determine:
- What page types we need to support the requirements (in other words what data is required to render e.g. the front page)
- What templates are required to adhere to the specified layout (by transforming the data from e.g. the front page page type to html)
- How the different page types are structured (e.g. what type of page can be created as a child of front page)
There… a nice tight data model with a layout on top. Requirements have been met, jobs done… and along comes the next brand site. And it turns out they have different ideas about how they need to communicate, to the outside world. They need a different form, but we have created a very rigid structure, so we need more page types and templates to satisfy their requirements. Slowly we add more and more templates to support the requirements of new sites, driving up costs, increasing complexity (for both editors and developers) and lowering time-to-market. What to do?
Reducing structural granularity
Here is one strategy we employ using Composer: In case you are not familiar with it, Composer is an add-on to EPiServer CMS which is essentially yet another implementation of drag and drop interface components (similar to webparts, portlets, etc.). Despite it’s apparent simplicity however, I think it has profound consequences for what you can do with EPiServer, particularly in an enterprise setup. Our approach is simple:
- Every page on the website (and by page I mean something that the end-user can find on google) is just… a page. So just one template!
- Every page has just one content place holder in the full width of the master layout
- Into that place holder layout rows can be added
- Into the layout rows, content blocks can be added
We have dispensed with the notion of typed pages altogether. A page is just a structural unit which has only the necessary information for a page to work (a location in the site tree, a URL, access control settings, etc.). The form of the individual pages can be composed and changed with a very high degree of freedom by the editor with no development effort required. The templates that were previously managed by developers are replaced by composer templates, which the editors can manage themselves.
Using this strategy, we get a lot more opportunities for reuse across otherwise very diverse websites, time-to-market and TCO is greatly reduced, while quality is improved from having less code to manage. This is of course just one piece of the puzzle, but to me an important initial design decision which has a lot of impact.