174 days without a CMS incident
We welcome guest CMS Mythbuster Clint Lundmark to the blog. Clint oversees some large-scale CMS platforms in Portland, Oregon and literally has a sign in the office announcing the number of days without a CMS incident. Where there’s a sign, there’s a story and we had to hear what’s happening.
A while back I inherited administrative support for our CMS we migrated to a year earlier. It wasn’t the best situation. The system was considered flakey and unreliable. Users were unhappy, support staff was getting late night phone calls, and management was explaining each and every incident to other management, users and other stakeholders. Yes, I actually created a sign counting the days between CMS incidents.
It was unhappy times in CMS land.
In learning how to support our CMS, I was getting up to speed on both the product and our implementation. Given the problems, my first thought was we picked the wrong CMS. I was frustrated and could not understand how this particular solution had any market share whatsoever. “Who would ever buy this” I would quietly yell while shaking my fist in the air to no one in particular.
Then something changed.
I started to focus on learning the CMS outside of our implementation. I discovered when we deployed our CMS there was a specific business process that made sense in the old CMS but didn’t translate well to the new publishing environment. The team had forcefully implemented that same process in the new CMS which meant customizing core functionality so that it would all work like before. As it turned out, changing that core functionality had a serious impact on the system.
Coming in new to the project, I was able to take a step back and ask why. Why was this business process important and why did we need to customize our CMS platform for it?
Not only did we not need the customizations, they were the main culprit causing outages, user grief, and CMS pain. It turns out our CMS had a completely different way to handle the same process using out-of-the box functionality.
We spent hundreds of hours customizing our CMS, only to eventually find out it wasn’t needed in the first place. Needless to say we backed out all the related changes and instantly went from a few days between incidents to 23, 91, and eventually 238 days!
We still keep the sign for good measure, but are happy to report that users are more satisfied and the real incidents are few and far between. After a 238 day run we did have an incident, but it occurred shortly after we upgraded the system.
Our lessons learned were to be wary of going against the grain of how a CMS is intended to work. Customizations may be necessary, but they come at a real risk and long-term cost to the organization.
It’s like the old parable of the ham. Just because you’ve always done something, doesn’t mean you have to keep doing it. Getting a new CMS is a chance to revaluate the way web publishing works inside your organization.
So, what was the business process that lead to the fateful customization? In our old CMS there was limited access control. The “normal” thing was to have publish operations approved prior to going live. It worked OK considering the CMS published in batch once every half hour. In our new CMS we forced all content through a custom approval workflow. It resulted in EVERY published add and change going through the workflow engine regardless of need. We had to write custom code to guarantee it always went through the workflow path. Unexpectedly, normal out-of-the-box operations like move, rename and unpublish also got caught in our code and no longer worked as they should. The excessive quantity of workflows on a workflow engine that was not designed for that level of load caused performance issues. Further, content was getting stuck in workflow instead of publishing.
After better understanding what we did and why, two things surfaced. The first was that we could easily use out-of-the-box permissions on content editing and publishing, coupled with an only as-needed workflow. However, the ham in the story is that, as it turned out, the communications team didn’t want to approve content anyway. They were responsible for creating most of the content and we gave publish access to a select few additional authors who follow standards and guidelines to produce interesting, informative content.
When requirements dictate changing how a CMS fundamentally is supposed to work, we need to be asking ourselves if we’re cutting off the end of the ham.
Embrace your CMS and enjoy more incident-free days.