In the continuing Baby Steps to SOA series, we follow Doug and the IT team behind BuyMyWidget.com as they take steps to renovate their digital asset architecture. Previously, we introduced the problem and the team, started planning and analysis, decided on some metrics, and refactored the website applications. Most recently, the team has tackled identity management, and now continues with introducing a CMS into their architecture.

The Evolutionary Roadmap

• Step One: Analyze and Plan
• Step Two: Measure It
• Step Three: Three Tiers for the Website
• Step Four: Single Sign-On
• Step Five: The Move to a CMS
• Step Six: Data Services
• Step Seven: Centralizing eCommerce
• Step Eight: Sharing the Business Tier
• Step Nine: Moving beyond the website
• Step Ten: Riding the ESB

Step Five: The Move to a CMS

The first element we removed from our applications was Identity Management.  This centralized the administration of identities, and also allowed the various applications to move to a single logical authentication domain rather than maintaining their own.  We now want to take a similar tactic with the website by introducing a Content Management System (CMS).

Having refactored the website into a traditional 3-tier architecture, we can now begin removing content management from the presentation layer.  Unless already using a CMS, web applications often have their presentation code littered with hard-coded strings, resource files, or content coming from a custom database.  In most cases, the IT team needs to manage all of this, and handle all requests for reformatting or typos, along with creation of new content.

There are three problems we are trying to solve with the introduction of the CMS:

1. Ownership:
   Content Owners should own the content on the site, and that content is usually something that comes from the Sales, Marketing, or Communications departments.  Without a manner to update content using a tool that is designed for business users, these teams cannot control their own messaging, and are reliant on another party.
2. Centralized Management:
   In many cases, the way in which content is pulled into a site is not consistent, and managing the content could mean accessing code, accessing a database, updating resource files, or changing HTML templates on a server.  Without centralized management of these resources, additional effort is required to locate what needs to be changed each time a change is necessary, often requiring somebody to have to look at the code to find out where a particular text string is coming from.
   
3. Logical separation:
   As with any of the steps taken towards a service-oriented architecture, we are trying to separate distinct services from each other.  Content is not the same as the server code that executes an order transaction, or the CSS that controls the design of the site.  As such, it should not be intertwined with these other logical layers and should be presented as a distinct service for content management which the application can then consume.

Taking Ownership

One of the most difficult parts of a transition to a CMS is how to roll the solution out past the IT team.  This cannot be a discussion that only happens within the technical team, otherwise it will just be seen as IT trying to dump its work on other departments.  There needs to be a buy-in with the content authors and owners who will ultimately now be responsible for owning updates to the application content.

Do not underestimate the desire for individuals to have control.  These individuals are usually very skilled, highly intelligent, but don’t have development experience.  This means they need to work in an environment they are used to (something similar to Microsoft Word, for example). For years these individuals have been told they can’t manage the website because they don’t have the technical knowledge necessary.  To overcome this fear, this requires showing your new content authors that the technical parts will still remain within the technical team, but that they will have easy access to configuring and editing their messaging on the site.

There are many different content management systems out there, so remember your target audience when making a selection.  This tool is for the authors, not for the technical team.  It must be easy to use, and it must be able to separate technical website components (such as CSS, scripting, layout HTML) from the content and content formatting.

Centralizing Management

Introducing a CMS tool does not necessarily mean centralizing the management of content.  It may do so for a single digital asset, but when planning for the CMS we need to also identify how we can centrally manage multiple assets.

If your system architecture contains multiple systems that need to have their content managed, then your CMS selection criteria should also include the capability for multi-site content management.  You should be able to have your authors access a single authoring system and be able to manage the content for as many sites as they have access to.  This will aid your adoption by the author user base and also simplify your system architecture by reducing the number of individual system instances you will need.

Creating a Logical separation

The goal of introducing the CMS is to remove the content from your applications and push that management to another centralized service.  Your presentation layer will now need to be updated to pull this content from the centralized service, usually by providing some sort of identifier for the item being requested.

Different CMS solutions will provide different development support capabilities.  As somebody who primarily deals with .NET web applications, I have been using Sitecore as it provides the easy user interface for the authors but a lot of flexibility in what I can accomplish as a developer.  When selecting your tool, make sure it provides an easy way to pull the content from the centralized system without doing massive rebuilds of your solution.  You should be able to update your presentation code with relative ease if you are only moving content to the centralized system.

If you also wish to move page layout and design into the content management system, then a re-architecture of the site may be needed.  Most ‘pages’ from your existing application will need to become a collection of re-usable controls that can be applied by the content author to build a page instance.  Depending on the CMS capabilities, and the amount of granularity you would like in your page components, this can take quite some time.  If you are short on time, I suggest a direct port with few page components. However, your team should then put into place an iterative plan to break these pages into multiple components over time, allowing for a richer authoring experience.

In Our Scenario

Lynn’s team has two primary websites (eCommerce and Event) that they can update to take advantage of a CMS.  The other applications are all third-party systems or do not face outwards to the public so have lower priority for central management of the content.  Both of these websites have been written as ASP.NET web forms, and the team has completed refactoring the application into tiers.  Unfortunately, during the refactoring, the developers noticed a lot of duplicate code in the presentation layer, which could probably have been better built as user controls.  Unfortunately, without more time to refactor, this will remain in place.  Lynn has added this to the list of items to tackle during the CMS integration.

Doug and the purchasing team have gone through vendor selection and have decided on the Sitecore CMS as it provides a decent author experience coupled with some great marketing support for goal definition, personalization, and A/B testing.  The marketing department is ecstatic about the possibility of being able to run some campaigns on their own without needing to involve the development team.  This has greatly improved the likelihood of adoption, although Lynn is not convinced the timeline they have will be adequate to give the marketing team everything they need in the first rollout.

Analyzing the CMS, Lynn discovers that Sitecore is built as a .NET application that can be installed as either an authoring website, or as a content delivery website.  It does have an option to pull content in from a webservice, but this seems to make it more difficult to offer some of the personalization options the marketing team is interested in.

From this analysis, Lynn comes to the conclusion that they will need to make the Sitecore website application their base website, and then begin moving their existing pages into the application as a “Sublayout” (ASCX) that is tied to a record in Sitecore.  They will also have to build content items and tie these Sublayouts to the presentation details of each content item they build.  In this way, they’ll be able to recreate their pages.

By moving to this control-based architecture, Lynn’s team can also take advantage of trying to cut-down the duplication of code. Since the code must already be moved into user controls, the team can now centralize some of their presentation layer.  Previously, however, it was very simple to tie all of their controls together as they all belonged to the same ASPX page.  With the CMS now assembling the site, and authors being able to control the construction of presentation, this connection between controls is lost. While better from a content management perspective and from a decoupling perspective, this does mean that a significant portion of page-level logic will now have to be rebuilt into more modular forms that depend on partial input, or on data from the CMS.

Once the team has completed this port over to the CMS of the presentation layer, the team then needs to focus on the author experience and ensure that all of the pages can be properly secured, authored, and go through workflow approval.  This involves several planning sessions with representatives from the author base and also governance committees.

How much will this step cost?

Each content management system will have its own licensing cost, and sometimes this is not insignificant.  In some cases, open source CMS may provide the functionality you need for your systems.  In other cases, if you need more marketing capabilities, analytics, and personalization, you will need to invest more for licenses in all your environments.

Training costs is also a factor.  Your development team will need to be trained on the new tool, as will all of the content authors and content owners who will be using it to manage the content.  Remember to include the cost of travel and hotels if the training is held at a remote location.  I strongly encourage face-to-face training for this, as this system will be a very important piece of ongoing operations and remote training sessions have great difficulty with engaging audience to the level needed.

The development refactoring to port the system to a CMS will vary by the tool, but you should plan for around 6 months of effort by a project team of 3-4 developers along with one or two testing resources, and at least two senior team lead positions to handle requirements planning, architecture, and leading the team.

Most organizations also try to package a redesign of the website along with this move.  If you can avoid it, you will reduce the cost of this step of the project and also decouple redesign problems from the adoption of the new CMS.  However, if your current design is quite outdated, the existing design may affect the adoption of the new CMS.  Rebuilding the website without some sort of improvement to the outward facing portion will make it difficult for some individuals to accept the budget expenditure.  If this happens, and a redesign is packaged with the migration to a CMS, make sure to resource design individuals for wireframes and composites, as well as a front-end developer to create the necessary CSS, HTML, and prototypes for the development team.

What’s next?

This series continues with the team moving their data layer into web services.