Coredna – a digital platform vendor built for speed and scale

janus-boye-sam-saltisHave you ever put a new CMS, marketing or e-commerce tool in place to address a specific problem, only to find an ever-increasing workload and new problems emerge?

During the recent years, cloud and the software-as-a-service approach have been differentiators in a crowded and fast-moving marketplace, yet these have rarely really addressed the customer need for a dramatically reduced time-to-market.

Today most of our members working in large, complex and global organisations remain plagued by custom solutions and digital efforts that don’t scale, both in terms of cost and resources required.

Coredna is a Boston-based start-up with Australian roots that attempts to address these problems. Coredna is also an active member of the J. Boye community, including the US Software Product Manager Group. I met up with their CEO and Founder Sam Saltis on a recent trip to the US, to further understand their disruptive approach.

Don’t customise if you don’t have to

With a 15+ year digital agency background from Australia, Sam has experienced the ins and outs of digital projects and have seen customers overinvest in software for their digital communication projects or marketing stack, only to find painful long implementation cycles, costly integration demands and increasing costs.

One of the key parts of the Coredna approach is to offer a pre-built stack, which means that out-of-the-box Coredna comes with ecommerce, content marketing, CMS and intranet features. Unlike other vendors, say like Kentico or Sitecore, Coredna offers more than a toolbox that needs to be customised for each and every implementation, Instead it comes with the features ready to deploy and use and then you can customise only if you have a very specific requirement.

This translates to both reduced implementation times (weeks rather than months), but also removes the continuous pain felt by others which have to worry about upgrading their custom code when a new version arrives. This has certainly been a regular conversation in many groups with members using Adobe Experience Manager or similar solutions loved by the analyst community.

The ecommerce platform Shopify takes a similar approach to transactional websites and has been skyrocketing in popularity.

Innovating faster

Compared to the more well-known vendors, Coredna has a substantially smaller engineering team, yet are still able to innovate fast, release new features and fix bugs at an enviable pace.

When I spoke to Sam about this, his answer started with this question:

What is cloud really?

According to Sam, their impressive rate of innovation is not only because Coredna only has 1 product line to maintain, but also because they are a true software-as-a-service vendor (SaaS).

Unfortunately like many other terms in this industry, SaaS has been surrounded by hype and confusion and to many vendors, what it really means is: We host it for you. Really what they deliver are platforms – digital infrastructure – which you then need to customise and implement for each and every project. This makes it so much harder to release new features as testing is much more complex given the different customisations out there with customers.

Scaling your digital efforts for growth

While scalability is the holy grail to entrepreneurs and start-ups around the world, it is also very relevant to older, larger and complex organisations making the digital transformation. We all need to use digital to scale our businesses.

When it comes to pricing, Coredna starts at USD $500/month and goes upwards towards $20k/month based on consumption criteria.

With most organisations looking into 2018 with an ever more complex stack of various tools ranging from CRM via marketing automation to CMS and digital workplace platforms, we need a fundamentally different approach if we want lift-off to ever happen.

With demanding customers like Nintendo who hosts about 200 domains on the platform, Coredna has the potential to both change the game among several software categories and also help customers escape the usual gravitational forces.

We’ll be watching closely!

 

5 questions to ask before selecting a Web CMS

As content management systems largely remain the de-facto digital platform for most large and complex organisations, selecting the right one for your organisation is a critical decision. The new system should ideally last for several years to come, but how do you find the best one?

Analysts crown vendors as winners and losers in the Web CMS market, but it is still a crowded and confusing marketplace for buyers. Typically you are not just selecting a new tool, you also have to factor in important aspects such as references, community, roadmap and support.

5 key CMS selection questions

To help you find the perfect CMS for your organisation, I’ve shared extensively throughout the years on the art and science of selecting the right CMS as well as the future of CMS.

An important part of the process is to ask the right questions to make progress on CMS selection:

  • Budget; how much should the project cost? If your last CMS selection lies a few years back and you are using a CMS crowned by analysts as a leader, you are probably spending too much. Make sure to leave your tender open so that you can get competitive proposals with an attractive price
  • Decision; do you want to make the decision itself or leave it with the digital agency? Unless you have in-house IT resources to commit to the project, we usually recommend that you look for both system integrator as well as new CMS vendor in one joint process. If for example you ask a boutique Kentico partner they are likely to also propose Kentico, but many agencies and system integrators work with multiple systems.
  • Open source; are you ready to consider open source? It continues to surprise me how many organisations are ignoring open source when looking for Web CMS. Most analysts ignore it; what are your good reasons?
  • Implementation; who will do the implementation? Don’t select a tool before deciding who will actually implement it. Are you looking for someone local? Do you want agency or system integrator? Not thinking about implementation up-front is a good way to set yourself up for failure.
  • System; why don’t we just use Drupal? This inevitable question comes up from time to time as one developer on your team might claim to know a given CMS inside out. Tempting as it might seem, is it indeed a sensible decision?

Look beyond the system for CMS success

As you might have noticed, these key questions are not directly tied to how eZ support multi-language or how Magnolia does mobile sites or anything else specific to the features of a given CMS. Those are all valid questions as well, but if you don’t want your CMS selection to drag on in an ever-changing marketplace, you should start with some other key questions.

Today most organisations are into their second or third content management system and some are even running multiple systems within their organisation. Good answers to the key questions will act as decision-support along the way and ensure that you don’t get blinded by hype and marketing, but rather gets you on the right track to a successful CMS selection followed by the smooth implementation we all dream of.

The Making of ERS 2.0

There are many ways to launch a website and even more ways to use modern tools, frameworks and systems to build the underlying technical platform. Each with different strengths and weaknesses. Thanks to Samuel Pouyt at the European Respiratory Society for sharing the below extensive and detailed technical case study of their new website at shared at a recent group meeting in European CMS Expert Group.

The entire case study can be found below or downloaded as an easy-to-print PDF file (2 Mb).


By Samuel Pouyt

Executive Summary

The European Respiratory Society (ERS), a non-profit organisation, has, lately changed its approach on managing its content to accommodate a rather disparate technological landscape: CMS’s in PhP (Joomla, Drupal), another in .NET, a custom CRM written in .NET, many small apps, SAP, some servers on premises, others in the cloud, legacy systems, etc. After more than 20 years of existence, the ERS has more than 25 websites that relate to its activity and other projects, a small communication and marketing team, as well as a small IT team.

For a small team, it is difficult to manage all those websites as a lot of time is just spent in maintenance, upgrades, security patches and other migrations. There is not much time left to improve the existing websites and develop new features. That is without saying that there are entirely new website to create. The user experience suffers from this diversity and as time passes the quality of the digital experience deteriorates: broken links, missing pages, outdated content, and the worst legacy technologies that prevent the whole stack from any further improvements.

Due to the nature of common CMSs the content was tightly coupled with the technology necessary to display it. Thus any change of website implied complicated content migration and a lot of copy pasting. Mobile apps, need to access the content created in the CMS thus a way for the app to connect to the CMS to retrieve the content needs to be implemented. This adds another layer of maintenance and an additional source of bugs.

Therefore, we decided to look towards the future and change our approach. The content, whether it is news, products or anything else is center to any website, mobile app, and any other platforms (Facebook, Twitter, etc.). Thus we chose a product that only manages content, and that is doing only this, but that does it very well. It does not influence the design nor the technology we want to use to display that content. It is IOS, Android. PhP, Node, .Net, etc. friendly. It can be fully integrated in automated workflows. It is a Headless CMS: Cloud CMS. This type of CMS does not do any assumption on technology or design, it does not display content, it just serves content as JSON.

We currently have a central point were we manage our content, that we do not have to maintain and that provides a customisable administration interface for our content editors. We are now able to seamlessly integrate our content within different technologies. We could also reduce the time we spend on maintenance to improve the quality of our user experience. We have reduced the amount of website we need to manage, but we are not yet done. Indeed, we need to migrate other websites, but we also plan to add some automation as, for example,  AI services to extract keywords, suggest hashtags, extract topics, a recommendation engine, and many other features.

It was long over due for the European Respiratory Society — one of the leading medical organisations that brings together physicians, healthcare professionals, scientists and other experts working in respiratory medicine, with a growing membership representing over 140 countries worldwide — to revamp its main website as well as to start standardizing its brand in the digital sphere.

Two solutions were offered to us: do as usual or look towards the future. We are a small team managing around 25 websites. Some are purely informational, some are event based. Every year we have few websites that are decommissioned and new ones that need to be created. We also have a member portal — MyERS — where members can create an account and manage their activities within the ERS, a CRM — the admin side of the member portal, an abstract platform, an event management platform, SAP to manage our accounting, etc.

All these application need to communicate among themselves to variable degrees, whether it is sending payment information to the accounting system, check if the user is a member or simply display content in more than one place e.g. news on the main website or in an app. Changing the main corporate website allowed us to solve the content management issue to accommodate, the IT team, but also the marketing and communication teams. Indeed changing our content management strategy helped us save a lot of time and simplify our content editor’s lives.

The usual way

Until now we have always developed websites using a CMS, mostly Joomla! to create new websites. We know that CMS inside out, and we are really able to produce websites quickly as we have a set of extensions that we have vetted and that solve most of our typical use cases.

Going that direction does not require much thought. We just have to concentrate in the design, migrate the content and we are all set. Our users know the CMS and they can, with no training, start using the new website right away. For few years we have worked this way, and we know it works, but it is not an optimal long-term strategy.

Starting a project

The CMS needs to be installed, then all the extensions required by the project. Usually, as the project is new, the latest versions of those extensions are installed. We never managed to create a starter project, as it was not up to date almost as soon as it was created. And that was an additional element that we would have needed to maintain. After a few years, all our websites were using different versions of those extensions as you never find time to go through all website to update those. Indeed, if you want to do these updates in a safe way, ideally you would have a test version of that website which you would update before publishing the changes to production. Git and modern CI (continuous integration) workflow do not really help either as many settings (in Joomla! at least are saved to the database) thus you cannot always just pull your new files in the production environment as you need to “install” that update or patch, or run some database migrations

Security patches

The other problem is security updates. Those open source CMSs (Joomla!, WordPress, Drupal, etc.) are very well-know by hackers too, thus security patches need to be constantly implemented, that is if the website was not already hacked. On one website that is ok. But when multiplied by 25, the process of patching eat up a lot of development time. It is time consuming because to patch a website, you have to make sure that the patch is compatible with the installation on which it is deployed. To make sure that everything works as expected, the patch needs to be deployed first on a testing environment, then deployed in production.

Updated or deprecated extensions

Additionally, extensions have their own update cycles. Sometimes it might happen that they are not supported anymore or they are not upgraded to be compatible with the latest version of the CMS… We tried to mitigate this risk by choosing extensions backed by reputable company. But, nevertheless, those companies have their own plans… It has happened that we had a website that relied heavily on such extensions and when the extension was not supported anymore, it prevented us from updating the CMS making us face three possible choices: migrate our content to a different extension, write our own extension based on the one that was not supported, or do nothing and have an aging website.

Custom code

The code we write is not really reusable even if we create installable extensions (plugin, components or templates).  It is difficult to share the code with other websites as, very often the underlying database schema is different; thus, to manage all the edge cases it is sometimes inevitable that the extensions become extremely complex.

And if we create a template package that we use on many websites, we then need to update it on each website when we want to change something… Very quickly, we end up having discrepancies on all the different websites. Indeed some custom component need to work slightly differently on different website and soon enough you have two or more versions that you need to maintain.

Users

We also need to maintain access rights to all our CMSs. The solution we chose was to keep it simple and to create accounts upon request. This choice of having multiple CMSs made sense at some point as we could have a website up for few month and take it down without impacting anything else. On the other hands, our editors need to login in multiple administration interface, and remember the small nuances that each one of them is providing. We tested some multi-site extension, but they just complicated maintenance as Joomla! Is not really build for it. There are of course better CMSs than Joomla! to manage this use case but by that point in time our choice had already been made.

Design

The main idea with the redesign of the ERS website was that we wanted to separate concerns: the design would be distributed from a central point and would have nothing to do with the website implementation, thus we would serve our CSS and JS so that any website could use it and we could update all websites at once.

So after multiple iterations on sketch and photoshop and concept approval by stakeholders we created a custom version of bootstrap implementing our designs. We started distributing it. Thus all new websites started using it and we could manage it with a simple workflow to publish all the assets. Our Bootstrap has its own Github repository, can be tested separately and new versions can be published on their own. It is now easy for us to add new design features to all our websites. Doing so we solved one of our maintenance problem. We do not need anymore to create installable templates that we need to install on each website. We just plug our CSS and Javascript.

However, it was not only challenging to manage the design, but also the content… For example, we have courses, that we advertise on the main website, but the registration takes place on MyERS. We display news on the main website, but also on other websites and apps. Much of the content is — at least in part — duplicated. For example our content editors need to create courses in two places: one that manages prices and checks the user status (MyCRM), the other — where all marketing attributes and other descriptions are added (CMS).

If we were able to  distribute the design across websites from a central point, wasn’t it possible to distribute the content from a central point as well?

The headless Meet Cloud CMS

What is Cloud CMS

Cloud CMS website we can find the following description. “Cloud CMS is a headless, API-first approach to content management, built around JSON and a high performance cloud architecture. It delivers enterprise features, including flexible content models and a full editorial environment, allowing your business users to create, manage and publish fresh content with ease.”

fig1-ers
Fig. 1 – Few API endpoints

Content is just… content

This is what a headless CMS, or an API first CMS does. It manages content, and this is the only thing it does… but it does it well. It does not have any impact on design, it just serves content via an API. The only thing that the CMS returns is JSON (or binaries e.g. documents, images). Actually everything in Cloud CMS is JSON: configuration, models, forms, relations. Cloud CMS API lets you manage any aspect of the platform and retrieve everything as JSON.

fig2-json
Fig. 2 – Partial JSON response

Multi-device, multi-technology

JSON is like the English language for scientific papers, but for applications. It is the lingua franca of the internet. As far as everything is JSON in Cloud CMS the content is de facto multi-platform, multi-technology, multi-device. Cloud CMS lets you get content with its powerful API but it also lets you write to it.

At ERS, we can from our custom CRM written with .NET create a course: our business user input all the data that the CRM needs, the CRM can push this data to Cloud CMS and programmatically create an article. The content editor can then add marketing information using the Cloud CMS administration interface to the newly created article. Then full content, price and marketing content can be displayed anywhere, on the main website, in an app, in the members portal etc. This really improves the workflows for all teams at ERS, as different people can seamlessly work together, saving time but also insure a better quality content. The content is really centralised, versioned and easily accessible. Here is how our infrastructure looks like at the time of writing:

fig3-integration

Fig. 3 – Cloud CMS integration at ERS

Development

At first sight it seems that choosing a headless CMS will greatly increase time needed to develop the website as the whole user interface/experience (UX) needs to be developed from scratch. Indeed, before, we were always starting a website from a “base”: the fresh installation of the CMS, that we were tweaking for our needs.

But in fact, it was a very liberating experience to start from a white sheet (or a black screen). Our code base is much cleaner, as we have only the functionality we need, we do not have code that we do not use, as it is part of the functionality that is shipped with the CMS. This approach gives a lot of freedom to the development team, whether it is an agency or an in house team. In fact, when you need to develop a new website, you can hire subcontractor and provide them the API documentation, API keys and they can start using your content right away! There are no more content migration, synchronisation or replication.

fig4-ers-code

Fig. 4 – PHP method to get an article based on its slug/alias (part of the url)

The web development world evolves very quickly, new standards appear, new frameworks. This is not a problem, if the developers want to transform the front-end and use the last framework à la mode, they have that freedom. The developers can even have part of the website using one technology, while the other uses another. Developers loves this freedom as they can always choose the technology that works best for a given task. That would have been difficult to achieve with a traditional CMS.

Time saver

It might seem that a headless CMS is more difficult to put in place and that you will need more time and resources, because you need to develop everything from scratch (Cloud CMS provides seed projects for different technologies to get developers started). This is true to some extent, if we compare the time needed to deploy a CMS with a ready made template that was slightly adapted to our needs. In the past we have deployed brand new websites in 3 days. But these website are not complicated and are not very customised. They also feel like the CMS that was used to create them in the first place.

As we have seen, “erasing” the look and feel of the CMS takes a lot of time as it is necessary to rewrite all the outputs (views) of all the components, plugins and module installed on the system. Otherwise the website does have a look and feel of Joomla!, Drupal, or WordPress. This might be acceptable, unless you want your brand to be coherent.

This is a lot of work and it takes a lot of time. Sometimes components do not implement very well with the MVC (Model View Controller) structure of the CMS, thus core files of the component need to be modified and the update is not anymore just a click on a button or a simple package install: a migration is need in order to preserve the design modifications.

On the other hand, starting with a white page can help saving a lot of time by developing personalized views and partials that can easily be reused. Yes, the initial workload is bigger but when the first boilerplates are ready, it takes no time to create new pages.

For the main corporate website of the ERS with the brand new design we planned 10 days for the integration into Joomla!, while we planned 6 for the headless CMS. 4 days do not sound like a lot, but it quickly increases as soon as we started adding new features. With our implementation of Bootstrap ready, we managed to have a fully working website in less than 25 days of work. As for every project, we presented it to stakeholders, reworked it a little and we were ready for launch.  

A standard CMS also comes with many features you do not need as it needs to cover a broad range of use cases. This is is also true with Cloud CMS, you have many features like content workflows, versioning, task management that help teams collaborate on content, but these features never get in the way nor for the user, nor for the developers. When the content is ready to publish, it is just content and it can be retrieved as plain content.

What could be better (and it will)

Cloud CMS can be at first overwhelming. For us the learning curve was steep, and we are still learning. Conceptually Cloud CMS is different, as you will see below, the underlying structure is a content graph. It changes the way you think about content and the way it is modelled. Of course, it is possible to reproduce a traditional structure, but there are much more efficient ways to work with, create and query content from a graph, but this needs to be learned… It is also necessary to learn the Cloud CMS vocabulary: definitions, features, associations, relators, etc. There is documentation, but it is as huge as the functionalities of the CMS.

Every aspect of the editor interface can be customized. It is good, but at first, it is also overwhelming. The look and feel of the interface is very sleek, but, in some area, it has a technological touch, a geeky feel: the impression is that everything can be customized. This was a little bit scary at first, until we found our way.

The Cloud CMS team is continually working to improve the user experience and functionalities, the team has helped us a lot and implemented new features that we had suggested. Thus many aspects that we have mentioned are getting better and simpler.

fig5-editors

Fig. 5 – Simplified interface for content editors

All these options allowed us to provide the users with a custom experience as well as a simplified interface that corresponded to our needs but it also allowed us implement all the enterprise features we could imagine: complex workflows, versioning, releases, granularity, etc. As a result, the we found that the user interface of the CMS is well thought through and, with experience we know that we can teach a new content editor in about an hour and the transition from Joomla! was very easy for them.

All the previously mentioned points are linked to Cloud CMS’s own successes: an enormous set of functionalities that somehow they have to give access to…

Technology

MongoDB

One of the excellent features of Cloud CMS that is the fact that it uses MongoDB to store content. This schema less document store is very flexible as it only saves the the used properties and new properties can easily be added later on.

It also helps migration as the data can be of any shape. It is much simpler than editing the schema of a traditional relational database and you can do it right from the CMS, with a visual interface or right in the JSON, but this is not all.

Content can also be queried through the API using MongoDB operators such as “$in” or Elasticsearch queries can be used which guarantee that the search queries are as quick and flexible as possible.

Content Model

The content model is defined using a JSON schema. The schema can be created, updated, deleted with the API, but the administration interface let you quickly update it as well. The content model can inherit properties from other models and you can add new properties with “features”. Using features we add different options to all our content instances without having to maintain them inside the content model. For example we use a publication features that adds a check box to let the user unpublish an item or, for events, we add latitude and longitude in order to display a map on the website or to search by location.

Forms

It is as easy to create or edit forms as it is to edit the model. The forms engine is called Alpaca and it is an open source library maintained by the Cloud CMS team. It can render html forms based on a JSON schema. It is quite easy to use and very flexible. We use a very complex form that displays different fields based on the content types, but the underlying content model is the same. Thus we are able to simplify the experience of our users and keep a consistent data model.

We have chosen to use Markdown as the format to input text. Our editors were used to it as they manage projects on Basecamp thus the transition was not complicated. We have taken this decision to prevent users from inadvertently breaking the layout of the website. But of course Cloud CMS has a classic WYSWIG editor available.

fig6-form
Fig. 6 – Form to edit an article

Graph

For us, starting working with Cloud CMS was a little bit surprising. Used to work with relational databases we had to face new technologies and concept that are not common among CMS’s. We knew that we would be using a NoSQL database, but we discovered that actually we had to deal with a graph. The documentation that mentions OUTGOING and INCOMING relations pointed us into that direction. We had no idea what were those, thus after some googling, we were introduced to graphs and its theory. (This is not necessary to work with the CMS, but it is very interesting…)

In its implementation of MongoDB, Cloud CMS uses many concepts of Graph databases. Thus you can not only query documents based on some parameters, or index, but you can also query documents based on the relation, and the direction of this relation from on document to another or others.

fig7-graph
Fig. 7 – Graph displaying an article (center) and all the incoming (←) and outgoing (→) relations

Although very useful, this approach challenges the usual understanding of items and categories as an article which has a “parent” relation to another article can be a node that links to many articles. The parent article becomes the de facto category, but it is just an article. Thus it is easy to query all articles “authored” by someone, or all the document related to another document. The relations are by themselves JSON object, thus they can be enhanced with their own properties.

Versioning

All content in Cloud CMS is versioned. Thus the user can easily go back to a previous version or compare changes between versions. Cloud CMS even features the ability to branch content. It works like Git. But through a visual interface for the content editor, and of course you can access those features through the API. Branching is a powerful mechanism that let the user publish batches of content at a certain point in time. New content can be published when a branch is released (merged to the master), but a release can as well modify existing content and merge the branch to the master branch at a future date. This is really powerful as you could imagine a news website, that published a very short article for a breaking news, while an extended version of that article is being written, and approved, and then released.

SDK

Cloud CMS has numerous Software Development Kits (SDK) to get you started. They greatly speed up the process of connecting to the the CMS via the API (OAuth2) or to perform operations on content.

When we started the project, Cloud CMS did not have any PHP SDK, thus we had to write our own framework agnostic SDK. It is fairly simple and should be easy to use. We developed a wrapper to for the Laravel framework as well. With few environment variable to set such as your API key, token storage path, you should be up and running quickly.

What’s next

During the course of the first year using Cloud CMS we have changed many things. First of all we introduced the node.js server developed by Cloud CMS. We use it to serve and cache images and documents. Thanks to the API we can resize images on the fly and saves them locally (or on a CDN), we can also generate thumbnails etc. This was a really easy process as Cloud CMS provides all these tools out of the “cloud”. To clear the cache we use AWS (Fig. 3) SQS and SNS that are integrated with Cloud CMS.

When we started developing the main website of the ERS, our approach was a little bit wrong. Our website developped in PhP is doing request through the PhP SDK to Cloud CMS, we then parse all these requests, as we need to parse dates so that they visually follow the corporate guidelines, parse markdown to html, format titles, generate, a short lead, etc. This approach is fine for one website, but we realize that basically, we would have to reproduce this parser on every website or platform where we want to integrate Cloud CMS. Additionally, we would have to trust our contractors to read and know our corporate guideline in order to parse everything correctly.

The solution was quite simple, we externalised the parser, and we created an API that proxies Cloud CMS with the added benefit, that it is this API that authenticates against the OAuth2 endpoint of Cloud CMS. Thus we can provide content endpoints without authentication and we can have our own authentication provider. And we can also cache all successful requests making following requests really fast.

This API was made with node.js, is fully tested,  and uses MongoDB to store our API users and their JWT tokens. We use Redis for caching. We have also developed a small JS library, with many useful parsing methods that implement ERS good practices and corporate guidelines. This library as a 100% coverage, which gives us a lot of confidence.

This approach allowed to have fun as well as, for example, we created a GraphQL endpoint that resolves to Cloud CMS and allows us to have a unique endpoint for all the content and all the benefit of a GraphQL endpoint on the top of Cloud CMS.

We are in the process of making a mobile app that will make use of this API, a recommendation engine and some automatic tagging with AI API’s. We are also migrating other websites to Cloud CMS.

The journey to the cloud was a very satisfactory one, as we have learned much on the way and we have improved our content delivery. The Cloud CMS teams has been really available at all levels, to help us and answer all our questions.

Resources

A one-page look into the CMS marketplace in 2017 with Jonathan Phillips

Jonathan PhillipsAs a technology buyer, the marketplace for content management systems might seem somewhat mature by now, but with requirements shifting and plenty of confusion, it is always good to attempt a fresh look.

Jonathan Phillips is a long-time member of the J. Boye community and past J. Boye Aarhus conference speaker. He’s widely known for his contributions to the digital workplace community and one of the smart minds behind Intranetizen. After leaving Coca Cola European Partners, he has founded ClarityDW and taken some time in 2017 to try to untangle the marketplace for external facing websites as it looks today.

The below list is based on a conversation with Jonathan and intended as a quick look into the marketplace. Before making your decision, do consult peers!

4 broad categories for selection and their key vendors

#1. If you see your website as a shop window, a business necessity, a small number of published pages then go cheap:
Wordpress is just fine and the most widely used option. Alternatives include Shopify, Squarespace, Wix. All these platforms are simple, capable and cheap.

#2. If your risk compliance teams allow, open source can often allow for more functionality at lower costs.
Leading vendors here include Drupal, Typo3 and Umbraco

#3. If you need more than a publishing platform and want to bring some customer experience features
Vendors: e-Spirit, Kentico, Progress, SDL

#4. If you need all the gear and you need to serve up a customer experience website, you need to invest in an experience platform.
Vendors: Adobe, EPiServer, Sitecore

Open source has won but not everywhere

Open source has been on a tremendous journey. Alain Veuve, in his post aptly titled open source has won, discusses the broad acceptance of open source by enterprises and he’s right according to Jonathan. These technologies are so main stream (think WordPress, Drupal and more) that we’ve almost forgotten their roots. 

However, in some business sectors, there’s still considerable and understandable hesitancy. Some clients wishes to avoid open source because, simply, they want someone to be responsible for the code should there be an issue.

Learn more about how to navigate the CMS marketplace

You can meet peers in J. Boye groups around Europe and North America and CMS and other digital platforms come up regularly in meetings and in-between. We also have 2 relevant groups CMS Expert Europe or CMS Experts North American.

What’s the future of CMS?

janus-boye-frankfurt-cms-marketplace-yesterdayWhile I’ve worked with content management systems in various roles since 1999, I was still humbled when the friendly organisers of the 2017 Umbraco Festival in Germany, asked me to present on the future of CMS.

Upon rehearsing I found that the vast majority of my Future of CMS slides covered the past and the current marketplace. To my defense, it is difficult predicting the future and the marketplace is still quite confusing, even to me.

One of my initial points is that the role of the CMS has fundamentally shifted. CMS used to be considered required to build a website and as such CMS vendors saw themselves as the center of the digital universe – providers of a web operating system. This has changed and to put things in perspective, try to find CMS in the crowded MarTech landscape by Scott Brinker.

With agile, cloud, experience journeys and marketing automation already beginning to feel old, below are my 5 key points for what lies ahead:

1) Privacy & security, incl GDPR

In Europe, we can thank the EU politicians for getting the General Data Protection Regulation (GDPR) passed and finally and firmly establishing privacy on the agenda for any one responsible for websites.  Alongside security which has been absent from both vendor roadmaps , privacy represents a huge challenge for customers and a similar huge opportunity for vendors.

Customers expect their digital platform to be able to help them ensure both privacy and security are taken good care of and I’m already seeing innovative vendors making moves in this direction.

As a customer, I need validation and reporting that shows me what data I’m collecting, that enables me to forget customers, and that makes sure my website is not a hackers paradise.

For more on this topic read this article by Tim Walters, Principal Strategist and Privacy Lead at The Content AdvisorySeven Things Marketers Need To Know About The New Data Protection Rules.

2) Artificial intelligence

Almost exactly a year ago, Google made the public announcement to say AI-first as a follow up to their much misunderstood “mobile-first mantra about 5 years ago. This means that artificial intelligence is built in from the get go in Google solutions. 

Similarly IBM Watson, the supercomputer which combines AI with sophisticated analytical software, has played a huge role redefining IBM as a company. 

In the CMS space, customers expect much smarter content platforms. Today what they get, is basically the dumb and old form-based systems from the late 90’s with an updated design and some nifty usability hacks.

As a customer, I would like recommendations on what content I’m missing on my site, built-in analytics and why not offer my website visitors (aka the customers) AI functionality on the site?

3) Next level SEO

Search engine optimisation (SEO) has been big business for a while and while CMS vendors have been busy doing other things, they’ve left an increasing piece of the cake for digital marketing agencies.

Yesterday, today and in the foreseeable future SEO is all about being found on Google. Whether we like it or not, that’s where the customer journey starts and if we are not found on the first page of Google, your competitor gets the business.

WordPress has been among the leaders when it comes to SEO improvements inside the system, but to reach the next level, including for complex e-business sites, much more work is required.

For more on this prediction, read:

4) Be where users are

One of the key changes in consumer behavior is that your website is no longer the center of the universe. It really never was and today customers are interacting with you and your organisation on numerous channels. To name a few: Facebook, Instagram, LinkedIn, Snapchat, Twitter, custom apps and the list continues. And the list will grow longer in the foreseeable future. 

Content management systems were built for websites. And that’s the problem.  

Today smart customers sees the website as one of several planets in the digital solar system and they have understood the need to be where their users are. Customers  expect that a modern digital platform can assist them in working across platforms, re-using and re-purposing relevant content, combining metrics and delivering a great user experience on the platform of choice for the user.

5) Think business development

Clearly the days of brochure websites are behind us. Well, to be fair, they are not really as many new brochure websites are being created every single day using content management systems built for the age of the digital brochures.

GEA is a German-based large, complex and global engineering firm and I’m impressed at how Head of Online Mikkel Andersen and his team have taken their website from essentially a brochure to a B2B lead generation engine.

If you are working in B2C, thinking digital business development is probably not a new thing, but you don’t get much help from your usual CMS vendor.

There is plenty of room for improvement to make it easier out-of-the-box to capture leads, increase conversions and to do business.

Business development has been a big theme at recent J. Boye group meetings, where I’ve written this post on the topic: How to think about business development

What do you see in the future of CMS?

Do you agree or disagree with my predictions? Feel free to leave a comment below, also if I missed something.

Kentico now has 2 CMS products

It is not unusual for software vendors of all sizes to release new products, but it is a bit unusual when a vendor releases something overlapping and potentially competing.

That’s effectively what Czech-based CMS vendor Kentico did back in November with the release of Kentico Cloud, a completely new and separate product that runs as a parallel product line.

To learn more about both the vision and reality behind Kentico Cloud, I talked to Kentico CEO Petr Palas and Director of Product Karol Jarkovsky. In addition, I sought guidance from MMT Digital, a Kentico Gold Partner based in the UK.

Introducing Kentico Cloud

According to Petr and Karol from Kentico, there were 3 main drivers behind the introduction of their new product:

  1. Cloud: Most companies still running their CMS in inefficient way
  2. Omni-channel: Web is no longer the primary channel which finally moves us away from the page-oriented world.
  3. Digital transformation: Which requires organisations to be more agile, including on digital content

To address these big changes, Kentico has had internal resources work in internal start-up mode for a while on smaller stand-alone products that used to be called:

  1. Kentico Draft for producing content in an omnichannel world
  2. Kentico Deliver for content delivery via an API
  3. Kentico Engage for marketing and experience optimization.

These were the three main components that came together and became Kentico Cloud. As Petr wrote in the release announcement for Kentico Cloud it is a new Cloud CMS, not just CMS in the cloud. In an honest quote from the blog post Petr continued:

“If you know Kentico CMS, our traditional CMS product, you’re probably asking yourself: “Is this Kentico CMS hosted in the cloud?” Not really. That’s what we did previously with Kentico+, which was Kentico CMS hosted in Microsoft Azure and managed by Kentico… and it didn’t work”

According to Kentico, not a single line of code has been reused from Kentico CMS.

Kentico also has a bit of edutainment on their website with the below summary of the advantages:

 

traditional-cms-kentico-cms
A light-hearted illustration from the Kentico Cloud website where the headless knight comes out victorious

 

A partner’s perspective on the new direction for Kentico

MMT Digital is one of the Kentico Gold Partners and has worked with Kentico for more than 5 years implementing Kentico CMS with customers around Europe and North America.

I spoke to Rich Madigan, who is a Senior Project Manager at MMT. To quote Rich:

“Kentico Cloud does bring a new approach to development and the use of Kentico Draft is a big deal for clients. They’re now able to get started on content creation and curation much earlier which helps streamline project delivery”

In our conversation, Rich also highlighted that while Kentico Cloud is still in its infancy, the product is a pleasure to work with, particularly from a development perspective as it provides greater freedom and the ability to embrace more modern front end technologies.

Rich also mentioned that the shift to the cloud has had a customer impact when it comes to ownership. Particularly for IT teams that have to get used to both a subscription model and a new and modern infrastructure.

The J. Boye take

To be fair, innovation is a good thing and Kentico deserves credit for executing on their vision.

Needless to say, customer requirements and the underlying technology platform has radically changed in recent years. To just name a few buzzwords: Cloud, headless, marketing automation, personalisation, omnichannel. The CMS space in 2017 is far from the same as in 2012.

Kentico Cloud does not come with the bells-and-whistles compared to the legacy Kentico CMS. Based on requirements, agencies and customers will have to choose the best fit for them.

As usual: Use your requirements to choose the best fit for your projects.

Learn more about recent CMS innovation

Full disclosure: Kentico is a long-time J. Boye member with seats in our CMS Expert and Software Product Management groups while MMT Digital is a member of our UK Kentico Partner Group.

Solodev – an innovative enterprise CMS based on AWS

shawn-moore-snow
Shawn Moore from Florida-based Solodev enjoyed the snow in Washington DC

While in Washington DC to moderate a meeting in the J. Boye CMS Expert Group, I had a longer conversation with our member Shawn Moore from software vendor Solodev. We spoke about tech trends, recent developments and how some of the big problems in the industry remain unsolved.

Solodev is a Florida-based content management vendor, which rebuilt their system from the ground up to be based on Amazon Web Services (AWS) in 2016. They are now working to redefine what it means to be a true cloud-based digital experience platform.

In our conversation Shawn highlighted these as some of the unsolved industry problems:

  1. The time to implement remains very high as it still easily takes over 9 months to launch a new website using modern software. It certainly usually takes much more than a 30-day free trial to deliver value
  2. Getting access to the software is one thing, but this is then followed by training, certification and then the months of implementation
  3. The cost of specialised staff is high and many customers have experienced trained staff leaving quickly to get a higher salary somewhere else

Without claiming to have the solution for all of these, our conversation touched on several aspects that Shawn and his team are trying to address. It was refreshing to hear a vendor speak openly about how we still need to make progress.

Innovating and learning in a changing marketplace

“We have found that the best defence against major unexpected failures is to fail often”

This memorable quote is from the Netflix blog on Chaos Monkey. Shawn highlighted this attitude as an important part of their innovative mindset, just like it played a big role in the Netflix cloud evolution towards making their infrastructure more resilient.

At the cloud-level, Solodev offers support for load balancing, content distribution networks (CDNs), and disaster recovery to keep customer data safe-and-secure across the AWS global network of data centers.

To be fair, it still takes considerable time and skill to implement an enterprise website using Solodev, but by offering easy access to the software and taking issues like deployments out of the equation, they are trying to save time for the buyers.

Making it easier to buy

To quote Shawn:

Every other industry has on-demand software which you can buy online, yet building enterprise websites lives in the legacy world with traditional software sales processes

At quick look at other cloud-based vendors like Crownpeak and Umbraco confirms that while pricing is available for starter packages, you have to fill out the contact us form before getting started at an enterprise level. In other words, you can’t buy an enterprise-level cloud solution without speaking to sales guys. There might be good reasons for this, but does it still need to be this way?

There’s been a market for software vendors using technology to build websites since the late 90’s, but some of the procurement processes remain unchanged.

At Solodev you can buy from their own website where small, medium and cluster versions are available. Their enterprise version with 10+ Hours per Month Support also requires you to fill out the contact us form.

In terms of pricing, you can also purchase Solodev on the AWS Marketplace as the 1st CMS available in there. The pricing model is hourly and  I have never seen that before in this space.

aws-marketplace-solodev

This different pricing approach might not be easy to digest for a buyer, but it does offer very low cost compared to traditional approaches to hosting a website infrastructure.

Introducing serverless CMS

I first heard about the term serverless CMS in May 2016, where Razorfish published an article on a reactive serverless CMS. They basically wanted to move their blog from WordPress and ended up with an architecture without running any servers, either locally or in the cloud.

AWS Lambda was an important part of the equation for Razorfish as the event-driven serverless computing platform that is a part of AWS and Shawn and the team at Solodev are investigating ways to supplement serverless next to a traditional CMS.

While the term serverless seems very new to the CMS space, Amazon is not the only that offers serverless compute options in the cloud. IBM, Google and Microsoft are in that space as well.

To read more about serverless, you can get a free ebook from O’Really: Serverless Ops – A Beginner’s Guide to AWS Lambda and Beyond. Thanks to Deane Barker for the book recommendation.

Learn more about going to the cloud

I’ve previously said that there are no sane reasons not to take your digital experience to the cloud.

Cloud and digital innovation are frequent topics in several J. Boye groups. Meet with your peers and set the agenda for the next steps in the industry.