Content Management Systems (CMS) have become one of the most powerful internet-related products. What once was a gadget for web developers and technology geeks is now a must-have tool for various business units. Because of the pace at which the world of internet technology changes, and the high demand for up-to-date content availability, there are thousands of products (commercial and open source alike) that offer a myriad of features to the companies in need of a solution to publish their content.
Unfortunately, over the past decade, the term “CMS” has become a buzz word, a commodity if you will. Everything web-related (short of social media, and that’s changing nowdays as well) has been rolled into those three characters. Originally (loosely) defined as “web application to create, edit, store and publish online content”, CMS has transformed into a much larger beast, covering e-commerce inventory management, SEO tool, workflow creator, and much much more. There are a lot (and I mean A LOT) of “How to choose CMS” articles out there, all composed from different perspectives, starting from a designer usability stand and ending with a CFO financial point of view. This article is not one of them. The goal here is to separate the term “CMS” into two very distinct components, and analyze the impact and/or the importance of each in a context of selecting a system to support your business.
There are two primary functions that people should be looking at when evaluating CMS, which I will refer to as “the engine” and “the workflow”. The best analogy to define the separation could be drawn from looking into the world of video games. In 1998 Epic Games developed a game engine that powered their newly released game Unreal. Since then – dozens of very different games, from a number of developers and publishers, were built on top of that engine; games that have nothing in common on a surface (really, who would compare Adventure Pinball and Tom Clancy’s Rainbow Six game?) All those games have completely different types of gameplay, different target audiences, but they all share a common engine under the hood to accomplish those very different goals. The same can (and should) be applied to the Content Management Systems.
Even with all the new bells and whistle in the current systems, the main purpose of the CMS is still to publish and serve the content. With that said – publishing content is easy. Publishing and serving the right type of content consistently is a bit more challenging, but this problem has been solved (with varying success) in all of the CMS products out there. Ultimately, the selection comes down to two simple questions: “will the product run in my infrustructure?” and “will the product perform well based on my current traffic, and scale with my business?”
Having said that – in no way, shape, or form, I want to downplay the importance of selecting the underlining CMS engine. Too often I see VPs of Technology and CIOs put a cart before the horse and start comparing products instead of evaluation the compatibility of them with business needs and the architecture in place. A couple of things to consider when selecting the engine, in no particular order:
Scalability – will the engine be able handle current and future traffic patterns?
Integration methods – what protocols does the engine offer for integration for both user-facing applications, as well as “the workflow”?
Technology stack – will the technology that engine is built on fit within the current architecture, and will it match the skill set of the staff?
Extensibility – how would the engine integrate with third-party business applications and support business-specific data models?
Content delivery – will the engine match the content delivery strategy of the business? (multichannel publishing, content availability, etc)
Although there is still a level of research required to identify the engine that would serve business needs the best, the availability of products makes the decision nothing but time consuming. After all – the engine is just a tool to support your business on the web.
The workflow, however, is you business. And that’s where the available products usually fall very short of the mark, no matter how much they push the “flexibility” and “usability” pitch.
There are a lot of articles and product briefs (primarily from the designer standpoint) preaching the importance of having an intuitive interface, to give users full creative control over the content. And although I don’t want to downplay the importance of the usability of the web-based systems (in fact, it’s one of the more important aspects of the process implementation), the differentiators preached are mainly irrelevant to the business needs. Listing a WYSIWYG editor as one of the primary selling points in evaluating of the system for your business is ridiculous. It’s 2011, and there is a usability level of any web based system that’s expected out of any product. However, no matter how intuitive and usable the interface and the flow may be in the off-the-shelf product, chances are, unless you’re in media publishing business (articles, images, videos, etc) it will not match the flow that’s intuitive for your business.
Every business has a unique model/approach/flow, and that flow needs to be represented by the CMS. One of the pitfalls of any CMS product out there (thought no fault of the product, but rather the conceptual design) is that it is catered to serve a specific types of content. The creators of the products try to accommodate every need, but, as with any attempt to please everyone, unsuccessfully. There are two reasons for the failure.
Catering to everyone means catering noone
Every CMS, no matter how flexible it is (or is claimed to be) can’t foreseeably cover every use case, even for a single type of business. If it was possible – we’d have one and only all-purpose CMS used by everyone. Therefore, the authors of the product try to either specialize on a niche business model (i.e. blogging, product store, etc) and/or try to cover the use-cases that they feel are most significant to generic business flows. There are obvious problems with that approach.
A classic argument for build vs buy – generic flow is just that – generic. Which means there is going to be a certain level of modification of the core product in order to get your business needs accommodated, which would vary based on complexity of the features you need. But let’s leave alone this argument for a minute, and not go into the maintenance cost, skilled staff needs, upgrade paths, etc. that are covered in lengths in other articles. Let’s assume that you managed to find a product with an exact feature set that’s perfect for your business. One thing that most people don’t consider is the product road map. As I mentioned, the feature set of the product is the vision of the creator(s), Product Manager, or CEO, depending on the product. That vision may not include the features you need in the next release, either because of the change in product direction, lack of demand, or many other reasons that drive any business. As an example, Firefox 4.0 removed RSS feed icon from the address bar, because it was only used by a small percentage of users. Logical business decision, why support the feature that’s not in high demand. However, what happens if you’re in that small group of users who used the RSS icon religiously? Now, we are talking about individuals here. Now consider the effect on the business if the core feature, that was a reason for CMS selection,and that’s a driving force behind your business, is discontinued.
Lack of subject matter expertise
So why is it so hard to find an off-the-shelf CMS product that fits your business? The short answer is actually pretty simple – creators and developers of the products don’t know your business. Internet is very young, and the demands for the online businesses change daily. The original concept behind the content management was to allow easy creation and publishing of the content that was predominant on web 10 years ago. The internet has changed. It’s no longer a medium for wiki-style information; the content nowdays is dynamic, personalized, and more importantly, it’s not uniform. Whereas before internet could’ve been viewed as a single purposed business vertical, like newspaper or magazine industry, it is now an ever-growing tool for running your business in a different channel, and as such, it has to comply to individual requirements of the business needs – in the same fashion as the businesses operate offline. Noone in a right state of mind, when opening a restaurant, would buy retail store cash register software for the bar. Even though both run on cash registers to ring our purchases, the process is very, very different between the two. And everyone knows it. And yet, people are buying into “one size fit all” CMS. So why wouldn’t people apply the same philosophy for the online businesses? Why would anyone think CMS product built specifically to create and publish media content would be good to back live sports scoreboard site?! Content type, methods for publishing, workflow, and even data model do not resemble the use cases of the available products. So why do people still try to push a square peg through a round hole?
Again, the Internet is young. And so is the concept of web content management. Right now, the products available are created, designed, and built by web generalists, who are very web-savvy, but lack knowledge of any industry specific standards. You can see the trends are shifting just a little recently, with the emergence of e-commerce specific CMS products, like Magento, designed specifically to manage the content of online stores. I envision that in the near future we’ll see a surge of industry vertical specific CMS products (finance, sports, travel, etc) lead by the experts in the field. This would provide a much-needed steam of products that would enable business to successfully operate online. Until then – unless your business overlaps close with the media angle of the available CMS – consider building a tool that’s right for your business.