WCM Is a Service, Not a Product

Web Content Management (WCM) is a service. Let me say that again: It’s a service! A WCM product is implemented and from then on, the WCM system is the hub of a service delivered to the marketing team.

The service when initially launched provides the ability to manage the content on a web site. But from there, WCM is a constantly changing set of functions and integrations that enable digital marketing to do all of the things they do: adding new sites, new channels, new languages/regions, changing navigation, plugging in new functions, and so on. The product and the initial implementation are just the baseline for the constantly changing service that matures and expands over time.

That’s why it’s so crazy is when WCM selection becomes a product selection. When functions and features are evaluated in a head-to-head competition, small differences or fringe product features become the focus and one product wins over the other based on a factor with limited relationship to success in business objectives.

So the key to success for digital marketing (which is the goal of WCM, let’s not forget) is to select the product that is best at enabling an agile and innovative, high-availability shared service for web content management.

There are huge differences between the way one product and another enable delivery of a WCM service. And those differences directly correlate to the ability for the buyer of WCM to be successful in meeting their business goals. The good news is that those differences are pretty easy to see once you look for them

To understand the way a product will be used to deliver a service clearly, design the live production system the organization will need at scale for each product contemplated – hardware, software, databases, disaster recovery, monitoring, archiving and so on. Set uptime and page-delivery speed requirements for each market around the globe.

Plan for multiple environments like development, test, stage, and live, and be sure to set uptime, return to operation, and maximum data loss in adverse event requirements. (Is it ok to lose a day of data if there is a problem, or only an hour of data or no data at all? This answer has a major impact on database design and management requirements.) Build in lifetimes for each component (how often an upgrade or replacement will be required). Then develop a roadmap of the number of projects, languages, channels (mobile, social, partner, signage) and team members contributing content.

Follow that with a change plan – how often will redesigns be needed? How often will template changes be needed and how quickly should they be turned around? How frequently will a test or a targeting segment be established and modified? What new functions may need to be added and integrated over time? What security and compliance requirements are there? How often will we perform a major software or database upgrade? And be sure to ask these questions in the context of what’s desired – not what has previously been possible.

Changes should be possible very simply and rapidly. Redesigns and prototyping new solutions should be rapid and simple.

With this plan in place, it’s possible to price out the system and design the staff levels required. For example, if a bi-monthly security scan is required, it will require team members to perform the scan and to react if any results come back. If sub 3-second page deliver is required globally, add the cost of a CDN and design the dynamic content delivery environment to operate locally for remote markets. If overseas teams need to be supported during their working hours, plan for that staff and cost.

With those goals, costs and staff levels in mind, the right question can be asked: Which product will best enable the organization to deliver a service over the next 5 years?

A quick look at the way the shared service for WCM is delivered at most large organizations shows the key flaws of the last generation of products this exercise will expose. These products were not designed to deliver an efficient and agile shared service. Staffing and architecting around product issues has been the standard approach and the loss of agility in large enterprises has become the accepted standard. The proof is in the outcomes: high-costs, lack of innovation and most importantly, a long and complex release cycle to get changes into the live environment.

In other words, the model of using Vignette, Interwoven, Tridion, Adobe or SharePoint to create a WCM service has come to the end of its useful life. A WCM service can be created using those products. But the service cannot deliver an agile and innovative environment cost-effectively (or at all). Crownpeak’s SaaS approach can.