Apr 25, 2011
Integrating a new CMS (beginning of an n-part series)
“I asked for a systems integration, and for my sins… they gave me one.”
Okay, so integrating a CMS isn’t exactly Apocalypse Now. I’m not going to have to kill Marlon Brando. But the “sins” part is accurate. My employer has used the same, proprietary CMS for nearly six years now. My relationship with it began as a content admin. Later my role evolved into acting as project manager for enhancements to the system (and to the presentation channels it supplies with content). These days, I wear the software business analyst hat most of the time.
My company’s CMS — and the ways it feeds our web, print, and e-mail channels — resulted in part from choices made by our internal stakeholders and software vendors, but also from my stewardship. And now I’m part of a team that’s been sent to kill it, and replace it with something better. Our old CMS is my Marlon Brando.
This mission is still in the secret phase. But I can say a bit.
Background, then. Our current CMS is an octopus. It started out as an SQL database connected to a .NET web site. The travel industry operates in a complex regulatory environment. Our customers need a lot of information, and our products have a lot of moving parts. Hence it’s 100% proprietary.
As time went by, we began to build hooks into the company’s AS/400 customer and inventory database. Later, we began using it to feed content to two other applications — a .NET customer service web app, and an online booking app written in IBM Websphere eCommerce. At the same time, we built feeds to share its content with our e-mail marketing provider. And finally, we integrated it to share content data with our print CMS, Quad Systems Catalog Studio.
Six years of learning later, it’s clearly time to move on. Our CMS is a system of impressive scope and an important tool for our organization. But organizational change and rapidly shifting priorities have meant that some of the design choices we made were just the lesser of two evils.
The good news is that the amassed knowledge of how to map our business rules to our software is relatively portable. Riding herd on the business requirements and seeing that the transition is a seamless one for stakeholders will be my primary responsibility during the project. As I go, I’ll be blogging, inasmuch as I can without publicizing my employer’s internal processes, about the project, its challenges, and our solutions.
We’ll be moving to a single, unified CMS for all digital. It’s an off the shelf solution produced by a major player in the CMS game, but we expect their integration team to customize it very heavily for our use. As it always goes with such projects, our timeline is an ambitious one. And there won’t be any interoperability between new and old systems, since we’re moving from SQL to a very different storage model — meaning challenges in migrating our current content data.
All that said, I’m looking forward to it. Sorry, Marlon Brando. Been nice knowing you.