has been conducting content management system
implementations for more than 8 years. In that time, our firm has encountered a wide swath of varying requirements, but nearly all have the same central goals:
- Aggregation and loading of disparate content
- Easy-to-use editorial tools (without the need to understand XML)
- Component-level versioning and re-use of content
- Distribution of assembled products into multiple channels (print, web, mobile, tablets, etc)
Publishers implementing CMS solutions in recent years have a significant advantage, as there is available, commercial software that can be deployed to get them started within weeks, if not days. Unfortunately, however, too many publishers are implementing large-scale, custom solutions that are both difficult to manage, non-intuitive, and require costly ongoing support and maintenance.
With that, and without further adieu, I present to you the top 10 signs that your CMS implementation is in trouble.
#10: All integration work is done by the vendor themselves
Good software companies focus on their product and let their partners conduct implementations. If your CMS vendor is also your integrator, it means that the integration is highly customized. This will present long term challenges for your organization in both support and cost.
#9: Your solution is not standards-based
Simply put, in embracing standards publishers invite lower long term maintenance costs. At Yuxi Pacific, we are not strong proponents of any specific XML standard, be it DITA
, or others. However the adoption of a standard is paramount to creating a more flexible framework and easier integrations with other applications within your ecosystem.
#8: You need to write custom Java or C# modules as part of the base CMS implementation
Very often publishers believe that their needs are unique, and sometimes they are correct. However before embarking upon a custom software solution, it is imperative that each organization look deeply at their needs and evaluate whether they can be met without such development.
Truth be told, with the abundance of software available, both commercial and open source, the creation of custom software is rarely necessary. Heavy customization, particularly with compiled languages such as Java and C#, result in long term maintenance of custom solutions that well outweigh any possible benefits.
#7: Your technology stack is complicated, with multiple databases and an abundance of third-party tools
As most of our customers know, we are big fans of the MarkLogic
Server, which is a native-XML database, search engine and web application server. More than being an XML database, however, MarkLogic has out-of-the-box capabilities to house unstructured, non-XML content and provide a framework to enrich that content with metadata to make it more discoverable.
From a practical standpoint, collecting all of your content into a single data source is highly advantageous. Workflow metadata is a prime example - if it is not contained in your principal database, multiple queries using multiple query languages are necessary to not only interrogate that data, but then to properly merge it. These queries are difficult, slow, and sometimes impossible.
Now, it may be that your existing solution utilizes an RDBMS, in which case integration is critical. There are tools within MarkLogic to accommodate this, including the MLSAM
project. However due to the complexities introduced to query across multiple databases, the storage of data in disparate container databases within your CMS is strongly discouraged.
#6: You have ongoing stability issues with your implementation that require constant support
Yuxi Pacific is, afterall, a services firm and one might think that ongoing support and maintenance of CMS solutions is part of the business. Think again. As the President of Yuxi Pacific, I understand that successful CMS implementations should be nearly "lights-out" - implementations should be fast, easy and require little long-term maintenance.
If you are trapped with a CMS implementation that requires constant software support with no light at the end of the tunnel, it's a sure sign that your CMS implementation is in trouble.
#5: Changes to your DTDs and Schemas wreak havoc in your CMS
Native XML databases are schema-agnostic, so why should you need to load and manage your DTDs and Schemas in your CMS? The true utilities of these constructs is their utility for validation when loading content and governance of your content model. However content models are fluid and therefore implicitly so are your schemas. Your CMS solution should allow you to quickly and easily change your DTD or schema without a complicated re-ingestion process.
#4: What you saw was not what you received
This is, as the saying goes, the "bait and switch". A CMS vendor arrives on-site and conducts a demonstration of the product. Then, when the product arrives after purchase, the features seen in the demonstration are additional cost or simply do not exist.
We strongly encourage publishers to schedule a detailed demonstration with a valid use case of any software before they purchase. MarkLogic
, for example, offers a free developer version of the software that can be downloaded from their web site
. The team at Lex Paradigm
provide demonstrations with customer content as well. If a proof of concept is not a possibility, we suggest terms with the vendor that stipulate very clearly the functionality and performance metrics of the software in writing before purchase.
#3: Your editorial team needs complex training to use the software
CMS implementations should be simple and intuitive for your users. A training program is reasonable, of course. However if your editorial team is being required to understand terms such as DTD, Schema, DITA or Action Handler, they are effectively being transitioned into new roles which will at best create inefficiency, and at worst create an ongoing support issue.
I cannot emphasize enough the value of intuitive editorial tools. If your editors typically work in Microsoft Word, then why force them into an XML editor? Word is, afterall, the world's best known XML editor. Yes, XML editor, as DOCX is a compressed XML format. With proper styling, Word documents can be easily converted into the XML flavor of your choice within the CMS.
#2: Your CMS tool is embedding additional XML directly within your content
Whether your CMS solution is developed over a native XML or relational database, keeping your content pristine is paramount. Embedding system metadata into content is poor practice as it requires more complex transforms, changes to your DTD/Schema, and complex rules in your editorial tools.
There are no exceptions here. XML is as a container format for storing your content. Ancillary metadata that breaks your content model, no matter how slight, does not belong in your content!
.. and the number one sign that your CMS implementation might be in trouble ..
#1: The cost of your CMS implementation was higher than the cost of the CMS itself
I have heard it again and again, the common wisdom among publishers is that the cost of a CMS implementation is typically 4x that of the CMS license. I could not disagree more. The fact is, with emerging CMS toolkits such as the XQuire CCMS
, a CMS implementation should be only a fraction of the CMS cost.
If your CMS vendor is proposing implementation costs that are significantly higher than the license fee, it means that they will be developing highly customized software. Highly customized software results in high implementation costs and a long term maintenance problem that will continue to cost the organization time and money over the long haul.