Real Story Group. Make Better Technology Decisions.

David Hobbs

Follow David on Twitter @jdavidhobbs

Subsites - up front vs. ongoing costs

2-Aug-2010

Tags: Web Content and Experience Management, Governance, Implementation

Do you run or plan a site with hundreds or thousands of subsites?  If so, you have many unique issues to deal with, including complex permissions, templating, taxonomy, and UI requirements that are completely irrelevant for smaller sites.  And don't forget another important area -- cost -- both in money and time.  Here are some thoughts on trade-offs and how you might address them.

Let's start with the assumption that if you have a large number of subsites, chances are you have complicated politics.  Your reaction may be to just do whatever it takes to get business units into the system, including adding complicated functionality specific to a unit.  I've personally been a party of this approach, but you can easily end up with Frankenstein systems that cannot be maintained or innovated.  Why?  If you implement a disjointed system then it's harder to regression test and to add features since you don't know all of the impacts you will have in making changes.

Let's consider the steps of a subsite launch:

1. Request.  The process for requesting a subsite.
2. Approve.  The process to approve or reject a site creation.
3. Negotiate.  Negotiating the details, especially the functionality.
4. Train.  Training the team that will be managing the site.
5. Create.  The technical creation of the subsite.
6. Embody.  The site owners adding their content.
7. Review.  Quality review before launch.
8. Launch.  Launching the subsite.
9. Maintain and Innovate.  Ongoing maintenance and innovation across all the subsites.

When deciding on your architecture and processes, consider the cost of each of these steps, and not just some.

There are several approaches / philosophies to subsites, but one extreme would be the completely lenient approach where everyone can do whatever they want on whatever platform they want.  In that case, steps 1 through 8 are easy (or last can be dealt with on a group-by-group basis).  But watch out for number 9: if you wanted to add a new and innovative feature across all the sites?  Share content across sites automatically?  Standardize look and feel for you site visitors?  Next to impossible. 

Probably the most common approach is a centralized platform, but where the core web team is lenient about what sites are created and the functionality details.  This can happen when there is weak governance, with the basic idea of "let's just get them in a common system first."  In this case, the request and approval process is easy.  But watch out: the Negotiate stage can take a long time.  Now you've got to not only work out site or group-specific functionality, but argue about which features should be added.  Also, the training and creation process isn't standardized, so takes more time.  Similarly, the review process can take a long time as there may have been misunderstandings of what is possible and not possible.  But the real problem is the maintenance and innovation.  The system becomes so complicated that it's difficult to maintain.  Also, if everyone did their own thing, then it also is difficult to roll out innovative features across all subsites.

Another approach is to "package" your subsites so that creating a new site is almost trivial.  This could include an extremely simple form that would be filled out to create a site, that would just have selections (no free-form written requirements) for the different options of creating your site.  In general, the negotiation would be simple since most folks would want to just fill out the form and get a site.  But if an option wasn't available for a particular group, then there could be a discussion of whether it was worth adding the functionality to the core system (or adding a parameter for an existing piece of functionality) so that it is preferably available to all sites for use.  Obviously negotiating changes to the core system would take time, but by carefully guarding the core functionality, and biasing toward packaging items for everyone, you wind up with a more stable system.  In addition, your system is more maintainable and features can be rolled out more easily across all subsites.  Training should be easier as well.  To pull this off, you will need strong web operations management, and in particular strong product management. 

Yes, there are other possible approaches.  But one thing is for sure: consider all the steps of your subsite and platform lifecycle when deciding on your subsite creation approach.