Still In Development


Multi-Site CMS Print E-mail
Papers - Web Publishing
Monday, 17 May 2010 07:55

MULTI-SITE CMS: Considerations for Analysis

Author: Paul L. Sipe

Company: Amherst Web Design LLC

pdf Multi-Site CMS (pdf)

Definition of WCM 

"Content Management System" is a very broad term, from wikipedia[1]: 

A content management system (CMS) is a collection of procedures used to manage work flow in a collaborative environment. These procedures can be manual or computer-based. The procedures are designed to:

• Allow for a large number of people to contribute to and share stored data

• Control access to data, based on user roles. User roles define what information each user can view or edit

• Aid in easy storage and retrieval of data

• Reduce repetitive duplicate input

• Improve the ease of report writing

• Improve communication between users

 So what is a "WCM" system? From Wikipedia[2] :

A Web Content Management System (WCM, WCMS or Web CMS) is content management system (CMS) software, implemented as a Web application, for creating and managing HTML content. It is used to manage and control a large, dynamic collection of Web material (HTML documents and their associated images). A WCMS facilitates content creation, content control, editing, and essential Web maintenance functions.

The software provides authoring (and other) tools designed to allow users with little knowledge of programming languages or markup languages to create and manage content with relative ease.

[...]

Administration is typically done through browser-based interfaces, but some systems require the use of a fat client.

Unlike Web-site builders, a WCMS allows non-technical users to make changes to a website with little training. A WCMS typically requires an experienced coder to set up and add features, but is primarily a Web-site maintenance tool for non-technical administrators.

The popularity of WCMS probably stems from the vast need for non-web-developers (who are knowledge experts in one or more content areas)  to create, edit, and publish content on the web.  That helps us understand  why popular WCM systems have their roots as simple blogging tools, not office suites.

It should be noted that the use of WCMS can offer other benefits.  A proficient web developer may still elect to use a WCMS to develop and manage a website because it affords both a development framework and rich functionality.

The similarities, and differences in the two definitions presented above provide some insight that sets the stage for this paper.

While the two concepts are related in that they both

  • maintain (or manage) content
  • deliver content to an audience

they are otherwise relatively different systems. 

From Wikipedia[1]: 

A web content management (WCM) system is a CMS designed to simplify the publication of web content to web sites and mobile devices, in particular, allowing content creators to submit content without requiring technical knowledge of HTML or the uploading of files.

Several web based content management systems exist both in the Open Source and commercial domains. However, this is one area where OSS software have gained dominance over their proprietary counterparts.

A generic CMS (or Enterprise CMS) is an office productivity and team collaboration tool.  On the other hand WCMS is a publishing application: interested ultimately only in the online publication of content (and everything that goes with it, e.g.  lead generation and ecommerce). 

In this context, it is not surprising that leading CMS's like Documentum and SharePoint (to name only two), are not the leading WCMS's.

Multi-Site CMS

At the time of writing, searches like "Web CMS multiple sites" in either Google or Wikipedia will only yield hits to products like Jcore and Jentla  (the former, an open source CMS and the latter, a commercial  extension to Joomla).

One can find product literature that boasts  "multi-site environment" or  "multi-site capability", however trying to get down to exactly what this means is difficult.  Very little detail is generally provided about the definition and explanation of what those terms (capabilities) really mean.

In order to analyze and understand  web publishing problems, we need some vocabulary.  Starting with just what a Multi-Site WCM means.

Deriving the definition from the title is not sufficient. "A WCM that manages content for multiple web sites" would be a start.  But then every WCM fits that bill, since they are frameworks.  Of course you could install Joomla in 10 places and run 10 different websites;  that does not make Joomla a Multi-Site WCM.

Cross Publishing

One obvious and  important change is required:  the scope of the content. 

Let us define "cross publishing" to mean, in the context of this paper: "publishing content across different sites or systems".

This is the crux, and the proposed acid test for the "multi-site" label.

This gives us "a WCM that manages content  in and across multiple web sites".

Site Organization

That definition, however, doesn't address CMS integration.  Recall the differences outlined in the "Definition of WCM" section between Enterprise CMS and Web CMS.  Our working definition of Multi-Site WCM prevents us from using the term in analysis involving content that must be cross published between an ECMS, and a WCMS.

This is not a fine point!  Here we are extending the simple "multi-site-as-a-WCM-capability" idea to also include integration across different content management systems. 

So to aid in analysis and definition of problems (and their solutions), the following working definitions are proposed:

Multi-Site WCM:  a WCM that manages content  in and across multiple web sites

Multi-Site CMS:  a WCM that manages content  from multiple  CMS's, in and across one or more web sites

As defined here, Multi-Site WCM capability is a subset of Multi-Site CMS capability.

Articles vs. Modules

The multi-site capabilities of Jcore appear outside the scope of either multi-site definition. 

To most of us, "content" means the articles/documents/text/graphics/media.  However, the line is grey in web publishing:  is a maps module, configured for a web site, content?  Probably.  Is it content when it isn't configured?  Probably not, although that entity could certainly exist on multiple web sites.

From Jcore.net[3]: 

jCore is a Multi Site web Content Management System build especially for webmasters (using the well known LAMP environment) who have to maintain multiple websites for their clients and they would like to keep the source codes up to date and easily fix bugs for all clients at once.

Here, the focus of "multi-site" is common code, not cross-publishing.

Since in Jcore, it is the not the content which is multi-site, we would not include it as either a "Multi-Site WCM" or "Multi-Site CMS" as defined above, and it's capabilities are not the focus of this paper.  We might call Jcore a "WCM with multi-site code support".

However, we learn from this is an important lesson about how we view the concept of "content" in the context of a WCM (very relevant to this paper):  "Web Site Content" can include not only the classic IS types (text, calendar, even meta-data) but also "module configuration" for modules published in the WCM.  

MUTEX Multi-Site CMS

In examining the ways in which content might be cross published,  the most simple model involves a "parent/child" relationship with content that is considered "Master" content.  For example:

A large university has a flagship web site, and also each college (and a few other university organizations) have their own web sites as well.  The university takes responsibility for hosting and publishing all sites.  The university does not wish to take responsibility for managing each site's content.  Furthermore, the university has some content (e.g. schedule of tuition fees, university contacts and links) that it would like to make available on the college sites, but still manage in one place.

One way to think about this problem:

 multisite1

The distinguishing characteristic of this model is that some content is common on every site, while other content is unique to the "child".  The "parent" and "child" content items are mutually exclusive.  In other words, every content item must exist either in the Master, or on the Site, but not both.

multisite2Some obvious applications of this model would include the single-web-site version of Multi-Site CMS. 

Here, the organization has some data in an Enterprise CMS that it desires to make available on its public web site. 

The organization may wish to choose a WCM for its rich web publishing capability, but in order to prevent redundant content maintenance the WCM must be extended to cross publish (select) information from the Enterprise CMS.

 

 

OVERLOAD Multi-Site CMS

There are other ways we could think about the "parent" (besides as a common extension to the child content, as was the case for MUTEX).

In this model, the parent serves more as a "content template".  For example:

A company has retail outlets(stores) in many locations: each store has its own web presence that it optimal for the local area. The company desires each store to be able to run a "weekly special", which is advertised on its web site.  However, if the local store has no special for the given week, the company would like to advertise its company-wide special instead.

This scenarios describes the "Pull" OVERLOAD model:

multisite3
In this model, only "holes"(e.g. the weekly special) in the site content are "back-filled" by the Master.

If we always favored the Master content, then we have "Push" OVERLOAD.  It is imagined that in any OVERLOAD model, push/pull would be a configurable attribute of the content element.

Note that MUTEX is a very simple subset of OVERLOAD.  If we "reserve" holes (i.e. never assign them local content) the model degenerates to MUTEX.

Aggregation and Authority

So far, we have not considered that child web sites could be sources of content (the arrows have all been down from parent to child).  Also, we have not addressed a very important dimension of Multi-Site CMS:  administration and authority.

To show how both of these could factor into an analysis, let us consider this example:

The company has three  stores throughout the greater metro area.  Each store has its own store web site, and there is also a company website.  Each store has its own store hours, set by the store manager to whatever he or she thinks is best for that location.  The company wishes to post the hours for all stores on the company site.

That paragraph leaves out one key aspect:  who manages the web sites?

If we suppose the sites are managed by the company main office, the development team might opt for a MUTEX Multi-Site CMS implementation like this:

multisite4

This fits the administration need: all store hours are conveniently managed in one place for the main office staff.

Of course, this won't work if the store managers are responsible for the store sites and their content.  In that case, the Store Sites are sources of content themselves for the company site:

 multisite5

A very small change to the diagram, with significant consequences.  If we turn that upside-down, we have a MUTEX model that contains one child with three parents.

Only now suppose we have the same "weekly special" requirements as in the OVERLOAD example.   Now we have arrows in both directions, with varying behaviors!

Clearly: the more that the system needs to control not just the rules and delivery of the content, but also the administration and authority over the content, the more it  will require a complex, highly capable, and expensive design/implementation.  The cost and complexity are not just functions of the tools, but dimensions of the problem that will need to solved, configured (if not coded), and tested.

Aggregation

There are other ways that web sites can be content sources, and other kind of cross publishing problems we could consider.

One popular model we see (frequently implemented with web services) we shall dub the "Aggregation" model.  Here, sites push data to a master, then pull (possibly edited/filtered) aggregate information back.

These are the "show X for all Y" type web pages.  For example, show openings for all restaurants.  Or show latest news for all locations. 

Conclusion

In this paper we introduced some working definitions:

Cross Publishing:  publishing content across different sites or systems

Multi-Site WCM:  a WCM that manages content  in and across multiple web sites

Multi-Site CMS:  a WCM that manages content  from multiple  CMS's, in and across one or more web sites

We examined a simple (MUTEX) multi-site model, and a more complicated (OVERLOAD) multi-site model.  We also considered networked hybrids, and the potential challenges of the administration/authority aspects.

References

[1] Retrieved May 9 ,2010, from http://en.wikipedia.org/wiki/Content_management_system

[2] Retrieved May 9 ,2010, from http://en.wikipedia.org/wiki/Web_content_management

[3] The Webmaster's Multisite CMS, Retrieved May 9 ,2010, from http://jcore.net/