CMS Consolidation
Question CMS Consolidation
by Graham Oakes
26-Mar-2007 --
Consolidation is in the air, within enterprises and across public-sector agencies. Consolidate infrastructure. Consolidate repositories. Consolidate applications. Consolidate content management systems.
For example, the UK government has announced plans (PDF) to rationalize its thousands of websites down to a small core of key sites and portals. Likewise, not long ago I worked with a major oil company to consolidate more than 100 regional websites onto a single content management platform. Talk to almost any significant content management vendor and you'll find they're aggressively targeting this market.
It's pretty easy to see why a CIO might want to surf this trend. Many organizations are looking at a portfolio of dozens of content management systems running somewhere on their network. From sheer tidiness alone, it'd be nice to have a shorter list. And such tidiness can have real benefits: better negotiating leverage with vendors, reduced overhead to manage contracts, reductions in the number of servers and hence in datacenter space (with attendant power and operational costs), and so on. Finally, increased demands for compliance and control are placing a premium on simplifying information management. That oil company was looking at a return on investment running well into eight figures based on such benefits.
But dig a little deeper and things aren't so clear. This isn't the first time the UK government has tried to consolidate websites to a single platform. It probably isn't polite to mention the 35 million spent on DotP ("Delivering on the Promise"), an initiative announced in 2003 that finally faded away in 2006. Major corporations aren't quite so public about their failures, but their track record on content technology consolidation projects isn't so great either.
So when your CIO starts to get excited about the cost savings that CMS consolidation will release, what questions should you be asking? Here are six that you'll want to answer before the project begins.
Who's driving this project?
Be wary if IT is driving the project. The IT department typically can obtain cost savings by consolidating its platforms, but only if people will use the end result. This is one of the things that hurt DotP -- they built it and the customers didn't come. Very few departments signed up to use the platform. What's going to make things work differently in your organization? Are people crying out for a better CMS, or do they have a stack of other initiatives with higher priority? If they won't sign up to use the consolidated CMS, then the project will fail.
This is the part of the economic equation that IT departments sometimes forget: these systems have a value side as well as a cost profile, and business units don't want to sacrifice hard-won benefits of their existing systems.
Meanwhile larger CMS vendors will sometimes paint a rosy picture of consolidation in order to win an enterprise deal. Just because the project is good for your CMS vendor doesn't mean it's good for you. If the vendor is driving, then at least rein things in until you're back in control.
Do our websites belong together in the first place?
There may well be a valid reason for maintaining distinct websites. Perhaps they're addressing very different audiences. Perhaps the messaging and branding behind different products demands distinct sites.
Of course, it's entirely feasible to run radically different sites from a common technical infrastructure and hence realize cost savings in the datacenter and potentially among your development staff.
But the cost savings here may be limited -- you'll be consolidating servers and technical training, but your scope to reuse content templates and other high-level assets may be small. Make sure the business case reflects this. Consider solutions like server virtualization, which might give similar benefits on the infrastructure with less pain.
If you're managing any sort of customer information through the site, then consider security and privacy too. Keeping physically separate systems reduces the likelihood of leakage between sites. Maintaining tight compartmentalization is possible on a consolidated infrastructure, but it adds to complexity and hence to costs.
Will our business and editorial processes co-exist once the sites are joined?
It's a rare business that operates the same processes across all its units. It's an even rarer government.
Sometimes these processes are different for a reason -- different markets, different regulatory environments, different product lifecycles, and, overall, an enterprise strategy of healthy decentralization to stay closer to markets and constituents. Trying to make all these different processes co-exist on a single platform can be difficult. It can be done, but you'll end up with a complex solution.
Remember this: complexity equals cost -- to implement and to operate. This may negate the benefits of consolidating in the first place.
Of course, often there's no real reason for the different processes -- they just grew that way. In this case, rationalizing processes makes a lot of sense. But consider:
- Even if you can rationalize the processes in theory, doing it in practice can be tough. People resist change. Even with carefully thought out change management, people resist change. Making business process change happen adds enormously to the complexity of the consolidation program. This doesn't mean a priori that you shouldn't do it; just calculate carefully the inevitable delays realizing benefits into any business justification.
- It's not just different processes you need to address: it's different rates of change in the processes. Some units may have stable, well-defined processes. Other units may be operating in much more dynamic markets and evolving their processes at a pace to match. A common platform may reduce operating costs, but if it also reduces the pace of change to that of the slowest business unit, then it may kill a lot of opportunities. After a certain point, you might as well stay on different platforms -- there's added cost, but there's also added flexibility.
Above all, don't hide a rationalization project behind a consolidation one, or assume you can use technical consolidation to force business process rationalization. If process rationalization is the real issue, face it head on. It's hard enough to do when you're focused on it.
Where are the benefits?
The business case for consolidation is typically based on some combination of the following elements:
- Reduced costs for software support and licences;
- Reduced number of servers, hence better use of capital and reduced operational and datacenter costs;
- Smaller range of technical skills required, hence reduced training costs and better utilization of a consolidated skills pool;
- Efficiency gains for editorial and related staff;
- Increased ability to see the "big picture" across products, websites and repositories, for example to track customer journeys or manage compliance.
All of these can give significant benefits. However, they don't happen automatically. Here are some obstacles you may need to manage:
- Software support costs don't go down when you build a new platform. They go up. They only start to go down when people stop using the old platforms. If a couple of groups decide to stay on their old systems, then these cost savings may be much less than anticipated.
- Likewise, the full economic benefit of reducing servers only comes when you either find a new use for the old servers or else forgo replacing them at the end of the hardware refresh cycle. Racks of unused servers may mean you can reduce some operational costs (e.g. no need to power or patch them), but they don't free up any capital.
- Technical people who have built specialized skills in an application may not be happy to retrain. Some people may move elsewhere to make the most of their current skills. So building the consolidated skills pool may mean more than retraining existing people -- you may also have to account for the costs of recruiting new people.
- In a call center, where there is a large pool of people doing many small, similar tasks, efficiency gains of 30 mins per person per week can lead to significant headcount savings. In an editorial or similar environment, you may have smaller pools of people doing more diverse tasks. Saving 30 mins per person in this environment may just lead to slightly longer coffee breaks. (I'm all in favor of longer coffee breaks, but why spend a seven figure sum on a new CMS to justify them?)
- Being able to see the big picture isn't a benefit in itself. First of all, consolidation brings no guarantee that the combined information is normalized in any useful way (more about that below). It only becomes a benefit when you use the information to identify actions that will increase revenue or reduce costs. Will someone use the information in this way? Will they be able to drive the appropriate actions once they've identified them?
Probe the proposed benefits very carefully. Make sure people have a clear plan for turning them into real cost savings and/or revenue gains, or in government and not-for-profits, some clear and realizable contribution to your mission.)
How big is this project really?
Buying and installing a CMS is easy. It's the other stuff that defines the size of the program. Here are some things to consider:
- How many websites do you currently have? This may seem like a silly question, but a surprising number of organizations can't answer it. Or they think they can, until they start to look around and find all the little sites that people have set up off their own initiative. Every site adds to the cost of the consolidation project (but also to the potential benefits).
- How much content do you have? It's often overlooked, but content migration can be the largest part of a consolidation project. People often don't realize how much content they've got until they start to audit it for migration. (I've seen one project where they thought they had a few thousand pages. We stopped counting at 80,000.)
- Who owns all that content? This brings up big governance questions: who can decide what is valuable enough to migrate and what isn't? Who knows what is "just content" and what constitutes a business record that must be retained? How much time and effort is it going to take to resolve these questions? Unclear content governance is a real killer for consolidation projects.
- How clean is the content? How much transformation will it require for migration? Some of this is about format and the like, but the more thorny issues revolve around semantics. Does it give a consistent message? Is it in a consistent tone of voice? Has it all been categorised consistently? Do you even have a common taxonomy and metadata schema, and if not, how will you merge the different schema? Consolidating the technology without ensuring that the content is clean and normalized may just make the glitches more apparent to the world.
Of course, all these points are worth addressing whether you consolidate or not. It's always a good idea to know what assets you have, to be clear about who is responsible for each asset, and to maintain your assets in good working order. Consolidation just tends to bring these points to the fore. You can drive many point initiatives quite successfully without addressing governance, for example. When you start to consolidate assets across units, you can no longer avoid broader governance questions.
A final note: as with process rationalization, some enterprises try to set up an IT consolidation project in order to force issues about content governance and quality onto the table. This is a very tough strategy to execute. You often end up getting the wrong people into the room, and hence make little progress. If you have governance or quality issues, address them head on and before you try to consolidate.
Have we considered all the options?
Consolidating your sites onto a common CMS is one option. There are others. They range from merging everything into a single site, to creating a portal over many subsites, to creating several distinct sites (perhaps with common design elements) running from a common infrastructure. And there's always the "do nothing" option.
Moreover if you dig further into the idea of a "common infrastructure", you'll find that this can happen in several ways. For example:
- You could run virtual servers on common hardware, each with their own flavour of application.
- You could run multiple content management systems, but from a common cluster of database servers.
- You could run a common CMS for some or all sites. "Some" because it may make sense to separate sites into clusters -- maybe sites addressing a B2B audience need different capabilities to those addressing B2C, for example?
Each of these entails different trade-offs in design, implementation, and operational cost, and in the degree of flexibility and commonality given to business units.
Consider things like the skills you'll need to operate the platform. Often you'll find that consolidation doesn't so much reduce complexity as shift it into another layer of the architecture. It makes sense to push the complexity where you have the most skills to manage it.
Too often, projects find one option (often the one proposed by someone with skills in a particular area) and fixate on it. It's worth taking a little time to think more widely.
The Case for Consolidation
There can be a strong business case for consolidation -- maybe to a single platform; maybe to two or three different platforms for different parts of the business. Either way, you can free up capital tied up in servers and licences; you can reduce IT operational costs while improving service levels; you can improve business and editorial processes.
You might even create benefits for your customers, partners, and constituents. They may find it easier to navigate through a more coherent set of websites and hence find what they need. Indeed, if you start from this perspective -- rather than from the technical infrastructure -- you may find some benefits that are really worth going after. Don't be surprised if your customers really want you to consolidate "softer" things, like information and processes -- rather than harder assets.
In any case, it's not a simple, risk-free project. Be realistic about what you're embarking on. Sometimes, it makes sense to live with a little untidiness.