The definitive guide to select an Enterprise CMS

This guide is addressed to Enterprises who are looking at either replatforming their current CMS due to existing limitations or enhancing their e-commerce experience or moving from a static html website to their first CMS for the late bloomers.

Its goal is to help you through your selection process by equipping you with the right questions and considerations based on your use case.

This guide is addressed to both the IT professional and to the marketer. An IT person will be looking at hosting cost, SLA, integration capabilities, APIs, Single Page Application (SPA) versus multipage standard website, headless CMS, etc. A marketer will be interested in functionalities, ease of use, agility, speed to market, etc.

Both perspectives are essential to consider in order to make the right choice, so if you’re a marketer, make sure your IT counterpart is included into the selection process and can validate the core requirements from an IT perspective, and vice versa. I’ll make sure to cover each point of view in this article.

Now, a general rule that I would recommend you to follow, regardless of your use case, is to select a CMS who’s well installed, has a great customer base and has a proven track record of investing in their product.

What will guide your choice will mainly be related to your objectives and ambitions and it’s important to be clear on what they are from the start. Note that I’ll refrain from arguing about which use case you should go for and assume you know what’s best for your business.

Let’s identify briefly the different use cases behind implementing a new CMS:


Aside of those business use cases, we’ll then cover in more depth, Costs and IT considerations in a second part:


"Brochureware website" brochureware cms

Brochureware websites are purely informational websites displaying what I call "static" content, meaning content that will rarely change over the course of time. The goal of such website is to display information about a company’s whereabouts, contact details and services. They are mostly a "web presence" as opposed to a customer engagement platform. Such website usually have a low volume of pages and low page complexity when it comes to design or components (text, image, list, contact forms, etc).

Considering the simplistic nature of such websites, if your company is not global, meaning if you don’t have to manage multiple languages and customers distributed across the globe, my advice would be to look at SaaS (Software as a service) options like Wordpress.com who are offering business plans that will cover your needs.

Now, I would still encourage you to look at what your competition is doing cause a "web presence" is rarely enough nowadays to stay in the race, regardless of your industry.

"Multi-site management"

Many companies have accumulated over the years multiple flavours CMS and from time to time are looking at rationalising all of them under the same roof. This usually means a series of migration projects, one site at a time, usually with the idea of building some common ground, meaning a common library of templates, functional and technical components.

For such use case, see below the capabilities that are most important:

Reusability of components
Because you’ll be migrating many websites on the same platform, it makes sense for your organisation to mutualise templates and components. The more websites you migrate, the bigger the ROI. By the 2nd or 3d already, the migration work should mostly be content related while development tasks should be minimalist or null. For that to happen, you need to ensure that the CMS’ development framework allows for that reusability of functional and technical components. Also, worth checking that the design (=CSS stylesheets) is decoupled from the components themselves and include a styles management to allow an easy "re-skin" of the components.

Reusability of content
Similarly to the previous point, the content, especially the assets, should be reusable across all websites. This requires a centralised media library or better, an integrated Digital Asset Management (DAM) with fine grained access control, to allow for certain assets to be shareable across web properties.

Multi-tenancy
Assuming that the many websites that you own require the same SLA, it should be possible to host them on a same platform, meaning you shouldn’t have to spin up a separate "environment" for each website. It might be your choice for various reasons but if you’re looking at an economy of costs and that your websites have pretty low traffic then you should be able to host them within one "environment". This means that your CMS should allow for reusability on one end, but also a strict partitioning, where required, on the other end. The last thing you want is a website to be impacted when release content or functionalities to another website.

multi-site management cms

Multi-language management:
If you’re a global company, you’ll most likely have several languages to manage for your website. This can quickly become a nightmare if you don’t have the right capabilities. This specific requirement is not trivial and you’ll need the CMS to be able to:

"Rich Media content website" rich media cms

Your website might have a certain amount of assets and high quality videos that are being consumed by your customers. Such requirements calls for specific functionalities that I’ll detail below.

Digital Asset Management (DAM)
Most CMS will offer a "Media Library" allowing you to upload assets and reference them within your page but very few will offer a full fledge Digital Asset Management module tightly integrated with the CMS. To differentiate "Media Libraries" from "DAM" platforms, refer to the corresponding DAM Forrester Wave or Gartner Magic Quadrant. Also, on top of that, make sure that the vendor has tightly integrated its CMS with its DAM otherwise your editorial/creative workflow will be clunky, error prone and time consuming.

The key features that should come with a DAM should include:

"High volume/frequent edit website" high volume cms

How many content updates or new pages do you create every day? If it’s above 20/30 a day then you fall within that use case. What you’ll be looking forward is an effective content production workflow that allows you to do more with less basically. You’ll want to automate any repetitive tasks while increasing productivity of tasks that need to be done by a human. For that you’ll need your CMS to:

"Personalised onsite experience"

First thing to call out is that you don’t need a CMS to deliver a targeted experience on your website. What you need is an Enterprise optimisation solution like Adobe Target, Optimizely or Oracle Maxymiser. Such solutions will require a simple tag to be added to your page to be able to substitute the default content with targeted content in a fully scalable way.

Still, content used within personalised experiences will have to be managed somewhere. Each of those optimisation products will have a light media library allowing you to upload HTML fragments, text fragments and assets including videos. This is fine if you’re running 2-3 A/B tests a week and 2-3 personalised experiences in parallel. However, if you’re dealing with 10-20 personas and that you’re delivering multi pages targeted experiences, you’ll start feeling the pain of managing your content in such tools. Also, assets/copies might change over the course of a marketing campaign which means you'll have to manually reupload and re-configure your targeted experiences in the optimisation tool.

Ideally, you want to create and manage that content within your Enterprise CMS and be able to synchronise it with your optimisation platform to be used for targeting purpose. Such connectors exist between solutions from a same vendor and considering the explosion of content required to drive highly personalised experiences, this will soon become a must have integration/capability.

"E-commerce" e-commerce and cms

For that retail specific use case, you need to be clear on what you need and what you’ll get when picking up either a CMS or an E-commerce platform. Most E-commerce platforms will have some element of content management on top of providing everything you need for product information management, cart management, product recommendations, order management integration, etc.

Where e-commerce platforms might fall short however is when it comes to add a lot of content around the product related components. Will it allow you to manage rich media content across all your product pages? Will it allow you to easily create content pages outside of product pages with the type of functionality or components that a CMS would provide? Will it allow you to manage multiple languages and the associated translation process across all pages? Will it allow you to leverage social user generated content (UGC) on your website to promote your product?

Probably not… at least not as well as an Enterprise CMS would.

This is why retailers often look at complementing their e-commerce platform with a full fledge Enterprise CMS. At that point, what you’ll be expecting from your future CMS is to ship either with an E-commerce integration framework or better with a built-in connector for your existing E-commerce solution.

Some Enterprise CMS will also provide additional capabilities like review/ratings components or the capability to bring onsite your customers’ social posts to directly expose your prospects to those comments. Some will also provide content/product recommendations that can complement existing capabilities from your E-commerce platform if you deem them not sufficient.

Ideally, you want respectively the E-commerce and the CMS to own the part they do best. For the CMS, it’s managing and delivering compelling content to the end consumer. For the E-commerce, it’s to manage and present the product information alongside the most relevant offers to upsell or cross-sell customers.

Finally, keep in mind as well that there’s no vendor on the market providing a best in class Enterprise CMS and a best in class Ecommerce fully integrated. So you’ll have to go down the integration path if you want the best of both world.

"Onsite social engagement (blogs, forums, ratings, UGC)"

If you are looking at developing a community and foster social engagement on your website, you might be on the look out for onsite social components like forums, blogs, ratings. You might as well consider bringing the good sentiments from your fans on your website by leveraging social engagement marketing solutions like Adobe Livefyre or Stackla.

The good news is that User-Generated Content (UGC) can also be managed by some Enterprise CMS. Beyond the obvious cost saving aspect, sharing one single platform will help delivering a consistent and seamless experience across your website, your blogs, your onsite community, not to mention the reusability of content and components.

"Portals" Portal cms

Let’s start by dissociating post-login brand websites from Portals/extranets.

An example of post-login experience would be when you log into your Telco provider's website to download a bill or look at your usage. Even though some information would come from your CRM or customer database, most of the content will still be "static" content and should be delivered by your CMS.

Without going too much into details, the 2 typical integration patterns would be:

The former pattern provides a better integrated/single experience but the latter could be an non expensive first step if the bespoke application is already in place.

Portals/Extranets on the other side are a specific breed and CMS are not necessarily the best technology to address this use case. First, CMS are usually stateless, meaning they don’t keep record of previous interactions while Portals need to be stateful. They need to manage a session along with a high level of customisation for the user environment.

You noticed that I didn’t use the term "personalisation" that I reserve to the marketing use case. In that case, customisation means that each user will be able to manage their preferences in terms of layout, favourites, list of services based on their role in the organisation.

For this use case, preferable technologies would be Websphere or Oracle portal. You can still feed those portal where required with content coming from your CMS assuming that your CMS is able to expose content to 3rd party systems. We’ll discuss that in more details in the Content as a Service (CaaS) chapter.

"Customer servicing platform (Forms)" Forms cms

Most companies will have some forms on their website to either be contacted or to provide online services to their customers. An FSI institution will typically have dozens or even hundreds of forms ranging from simple to extremely complex for the contracting, upgrade, renewal of their many products.

The same way as for the e-commerce or the post-login section of your website, hosting your forms on a different platform will ultimately make it harder to provide a seamless and unified experience between your website and your forms. Quite often, customers are redirected to a different platform sitting behind a different domain to fill in a form that just feels like a totally different website, not to mention that they are not always responsive and optimised for mobile.

Although your Enterprise CMS cannot replace the BPM engine sitting behind your form and integrating with your back end systems, it can and should provide the glass. Many CMS have well developed Forms module that will provide a responsive and adaptive experience that is fully integrated with your website experience and that can connect to any end point for the data to be processed.

"Learning Management System (LMS)"

So you have B2E (Business 2 Employee) or B2B (Business to Business) requirements around educating a certain audience and you’re wondering if a CMS can help you with that. Well the answer is yes, some Enterprise CMS do offer an integrated module with LMS functionalities and support for SCORM (Shareable Content Object Reference Model), the de facto industry standard for e-learning interoperability, as well as xAPI (Tin Can).

The advantage is to benefit from one centralised repository for your assets including your learning assets as well as having only one platform to manage and maintain.

"Digital Signage - in-store screens" Digital signage cms

Brands are not only looking at connecting their customers’ digital journey, they are now also looking at connecting digital and in-store experience. For companies having brick’n mortar stores with digital signages, those are the scenarios to consider:


"Intranet"

An Enterprise CMS will require few things to cater for intranet’s requirements:

The top end of town should be able to cater for most of those requirements but as usual, it’s worth checking.

"Cross-channel content hub" content hub cms

7-8 years ago, a CMS was essentially used to serve your website to your customers. With the proliferation of marketing channels, arised challenges around how to best manage that content, the holy grail being to create once and publish everywhere.

But where is "everywhere"? Well it is first and foremost to your website but also to your mobile/tablet Apps, to your secure portal, to your email/SMS channels, to your AdServer/DSP (Demand Side Platform), to your in-store digital signages, to your Alexa/GoogleHome or any other IOT (Internet Of Things) devices.

Modern best in class Enterprise CMS should allow brands to author and feed content to those channels either by owning the "delivery container" for the channel (eg: owning the mobile App or the digital signage App) or by providing the content within the right format to the respective platforms owning those channels.

Ideally, you want content to come from one single place, like you want your business logic to not be duplicated across each and every platforms but being centralised within an ESB (Enterprise Service Bus) for example.

Imagine rolling out a campaign’s approved assets (potentially dozens of assets if personalised) to all channels, to realise right after the launch that something needs to be updated. Every involved platform will have to manually re-upload/configure assets. This can lead to a significant rework and loss of time while your campaign is out there with the wrong asset potentially damaging your brand or wasting the campaign’s impact. Ideally, you should be able to update it centrally, generate the channel specific variations/renditions, get it approved, hit the publish button and "voila". That looks over-simplistic but this is how it should be.

Modern CMS will either manage some of those channels’ content within the CMS with specific authoring environment for that specific channel but even if they don’t, they should have Content as a Service (CaaS) capabilities to export content and integrate with 3rd party platforms according to their terms.

We’ve just covered some considerations around functionalities, let’s now spend some time on what I would classify more as IT considerations around the technology used by CMS. Again if you want to jump directly to a specific topic, see below what we’re going to address in that coming chapter.

"Proprietary vs open source" proprietary vs open source

Just so that we’re clear on what we’re talking about, let’s define those 2 categories:

Again here, the choice depends on what you’re trying to achieve. There’s no universal answer to that question. Each approach has merit and is the preferred option for a specific scenario. For the sake of you making an informed choice and to make sure you’re not biased by hearsay or old myths, I’ll touch on the usual points of contention.

Risk Management

Yes, with software vendor, you’re buying the right to use their software and the moment you stop paying… well, you need to migrate your content elsewhere while with open-source technology, you can continue using the software till the end of time if you want. You need however to understand what you’re paying for. Proprietary softwares licenses typically includes support, maintenance and access to ongoing innovation effectively. We’ll touch on that later. Note that you can mitigate that risk of being dependant on a software company by buying perpetual licenses though most companies now prefer such expense to be under their Opex as opposed to their Capex.

On the other end, if the community around the open source software is too small, there’s a risk for those people to move to another project. So regardless of proprietary or open-source, always pick a well established Enterprise CMS software that has a strong backbone and a well-furnished roadmap.

Extensibility

"Software vendors do not let you access the CMS’ source code". This is half true and you can test that out with the CMS vendors that you're investigating. Recent Enterprise CMS are built with "customisability" in mind, providing the possibility to fully customise the UI as well as APIs and "hooks" to implement custom application or specific workflows. Many of those recent Enterprise CMS are seen as development platforms beyond just being a content repository. Now, because Enterprise CMS needs to be stable, reliable, scalable and supported efficiently, certain core component inherent to the CMS won’t be modifiable by anyone and for good reasons.

Community

The large community evolving around open source softwares is usually appealing to companies who are looking at lowering the costs of development by reusing already developed components and having access to low cost development resources.

The question is: would you deploy any piece of code developed by an anonymous contributor into your Enterprise web platform, aka the facade of your company? The answer is probably no or you will at least audit that piece of code. When reusing community components, you need to consider security, quality of code, performance optimisation, coding best practices, etc. It can be hard to drive uniformity and high standards when the code is coming from 20 different sources.

Proprietary Enterprise CMS should come with a set of foundation components that all respect best practices and that can be the starting point of your implementation. Certainly, that list will be shorter than open source CMS' but it should be of higher standard and uniform.

As for the amount of developers available on the market, yes, the resource pool will be more scarce for proprietary CMS, however they should all have project experience and official training under their belt while a part of the open source developer community will be self trained on personal projects. It’s more about the quality of people compared to the quantity in that regard, to a point of course as you don’t want to struggle finding developers for your projects.

Innovation & Product Management

By definition, Open Source CMS strategic initiatives are validated/voted by the community, a community of thousands of developers who don’t necessarily have access to the same customers' spheres and the same insights as major proprietary software vendors.

Innovation is about turning an insight or idea into a solution that delivers value to someone (customers) around an existing gap, a future gap or a gap you actually create by generating demand.

To understand what Enterprises are struggling with or anticipate what they need in 5 years, you first need to understand their strategy for the next 5 years and for that you need access to their C-suite. That insight will provide ideas and opportunities to innovate to accompany their growth and objectives, but again, validating your ideas will require access to those C-suites to play it back to them.

The product management and the sourcing of the insights are fundamentally different between proprietary and open source, so I would recommend to check if their respective roadmaps and vision align with your growth as well as your industry/market’s direction. For proprietary Enterprise CMS, make sure you also check how much is invested in product development every year. This should give you an interesting element of comparison.

"Development & Maintenance/Support Costs" costs

When comparing different solutions across open source or proprietary vendors, it is crucial to not compare cost based on licenses fees only typically, but instead to consider the Total Cost of Ownership (TCO). See below the different components of the TCO:


License costs

For open source software under the GNU license, "license" costs are typically $0. Proprietary vendor will charge either a subscription fee with a commitment of 1-3 years or a perpetual license for indefinite usage. The caveat when purchasing perpetual licenses is that a maintenance and support fee will still be required to access support services and to upgrade to the latest version of the software. Also, keep in mind that subscription base licenses will fall under your Opex as opposed to perpetual licenses that will be under Capex.

Implementation costs

The development costs will depend on few things listed below:


Training/change management costs

Every proprietary Enterprise CMS will have a professional services team to deliver training to your developers, system admin and content authors. For open source ones, you’ll have to rely on the partners/SI ecosystem for that.

From a change management perspective, as intuitive as a CMS can be, there’ll always be a transition phase between the old and the new ways. This change management should actually be initiated during the functional specifications of the project when the old workflow will be mapped into the new one. As a side note, I advice to resist trying to force the old way of doing things into the new system. It often ends by a clunky and expensive project when a system’s functionalities are bent to map a workflow inherited from a different system.

Hosting costs (Physical server costs)

Different flavours will be offered by your CMS vendor or affiliate partners in the case of open source CMS.


Maintenance, upgrade, support costs

You might think that hosting costs are constituting the bulk of the costs but it is not. They are actually way less than the costs associated to deploying, fine-tuning, monitoring, maintaining and upgrading your platform.

Let's imagine that you’re starting from scratch, you’ll have to hire people either with the right expertise or train them on the CMS you’ve just purchased. You’ll need them in different timezones potentially to have a 24/7 support.

You’ll have to implement scripts or specific softwares to cater for deployment, auto-scaling, maintenance, test, monitoring and alerts around the platform. You’ll also have to maintain and update those scripts along with your people’s knowledge in relation with the CMS’ new releases and patches. You’ll also have to document the run book in details for when one of your system administrator goes on leave or quit the company. This is why managed services offerings from software vendors are so appealing to companies as they remove the burden of all the above.

Operational costs

The cost of using the platform will depend on the Enterprise CMS’ functionalities themselves. Is the CMS easy to use? Is it automating all the repetitive manual tasks of your content authors (eg: auto-tagging, automatic renditions generations, etc)? Is it providing your team with a robust workflow engine to orchestrate tasks and give visibility on progresses to everyone? Is it allowing them to collaborate around the review/approval process through annotations/comments? Etc etc.

This aspect is not to be neglected as moving from an old to a modern CMS can decrease the time to web for your content from weeks to days or hours even. It’s not only going to be a matter of optimising individual productivity but will also simplify the workflow across the different teams. For example, your content marketing team should be fully autonomous with content releases while IT should only be involved when adding new functionalities to your platform.

Java, PHP, .Net programming language

Programming language should only matter if you’re planning to leverage an internal development team to implement your CMS. Certainly, PHP developers will be more comfortable implementing Joomla/Drupal, Java developers with Adobe Experience Manager and .Net developers with Sitecore. Front-end developers especially familiar with HTML/CSS and scripting will very quickly adapt across php, jsp and asp typically. Moving from Java to .Net or vice versa might be a bit longer although there are many similarities between the 2 languages. keep in mind that if you’re planning to have your CMS implemented by either the software vendor or a 3d party, this shouldn’t matter to you.


Integration & APIs integration

When it comes to integration, your CMS needs to cater for few scenarios and I strongly advise you to verify they can be implemented.


Single Page Application (SPA) spa

SPA is a popular application design for "web applications" as opposed to a web site. It basically is a javascript based application fully loaded in your browser and providing a supposedly superior "App" like experience to end-users without page refreshing. Now, I am not going to debate around SPA vs MPA (multi-page Application) in this article as it’s a longer topic but one of the main downsides of SPAs is in relation to how you edit content. It is quite often a developer task and is not necessarily a WYSIWYG friendly UI. That being said, certain CMS are starting to support SPA's authoring so it's worth investigating that point with your vendors if you're planning to implement SPAs.

SEO also used to be a big downside of SPAs but the introduction of an updated scheme by google to crawl javascript along with the support for HTML5 mode by javascript libraries like Angular.js, are now mitigating this problem today.

Headless & CaaS (Content as a Service) headless CMS

There is an ongoing debate between headless CMS and traditional CMS however modern CMS are now offering the best of both world. Let's look at the wikipedia definition of a headless CMS: "A Headless CMS is a back-end only content management system (CMS) built from the ground up as a content repository that makes content accessible via a RESTful API for display on any device".

Some leading Enterprise CMS are meeting 100% that definition and have been providing those functionalities for the past 10 years already, in addition to providing a full fledge UI to author and publish your content. Adobe Experience Manager is one of them.

It's worth mentioning that, in the case of Adobe Experience Manager (AEM), the person who actually defined REST in 2000, Roy Fielding, has been leading the design/architecture of that product, alongside other key people from the industry, since 2002 when he joined "Day software", the company that then got acquired by Adobe.

So you can now benefit from the best of both world:

Wrap up

As you can see, picking up the right CMS for your business is no simple task but I hope that this guide provided you with useful considerations and the right questions to ask during your selection process.

Liked this article?


Interested to read more on related topics?