How to Choose an Experience Platform That Fits Your Architecture and Skills

Vendor legitimacy

Make sure the vendor is legitimate and has a stable economy by investigating everything you can before continuing the procurement process. Check the vendor website, LinkedIn company profile, judicial data, business data, and testimonials.

Product maturity

Explore the community, documentation, source code, and quality systems to assess the maturity of the product. What version is it? What is the technical release frequency? How has the vendor solved previously reported future requests and bug fixes?

Development roadmap

Is there a roadmap available? Reading what is planned for the next months and years, as well as comparing what was scheduled to what was actually done can give you invaluable insights into the efficiency and reliability of the vendor.

Hybrid CMS

Don’t put all your eggs in one basket, whether it is a classic CMS or a headless CMS. Make sure the platform features a hybrid CMS, which provides classic solutions for editors and headless solutions for developers—with all alternatives being fully optional.

Product vision

Is the vendor a visionary with focus on flexible and agile work methods, and modern web technologies, or does it cling to legacy systems and business as usual?

Content primacy

The litmus test of discovering a true hybrid CMS fit for today’s and tomorrow’s omnichannel world. Make sure that the content is given primacy—that the platform presupposes flexible content types and structured content, as opposed to page building and presentation.

Beyond CMS: apps, APIs, etc.

Do you have other needs besides CMS, like apps and APIs? A future-proof platform should also support building customs services and APIs, as well as user-generated content.

Limitations

Check this if you have some pervasive limitations in your organisations, like integrations to legacy systems, CRMs, ERPs, design systems, or the choice of what front-end frameworks you can work with.

 

Now for the more technical stuff, the architectural requirements themselves.

Investments

How well does the potential experience platform fit in with the existing technologies of your organisation—essentially your heavy investments? Remember, not everything has to be thrown out on account of simply being old. Great and agile systems are still exactly that, regardless of age.

In any case, do research on how well the digital experience platform fit with your current technology, including, but not limited to:

• Framework
• Design system
• Integrations
• Programming tools
• Legacy systems

On premises vs. managed service

The question of hosting your digital experience platform on premises or by a managed service in e.g. the cloud is important due to concerns of security, maintenance, backups, scaling, and other issues from the world of DevOps

On premise

On premise keeps more control in the hands of your organisation, but can be more costly due to internal DevOps teams and hardware resources.

Managed service

A managed service offers no need for a deep understanding of backups, the basics of security, etc., with all of these being handled by DevOps professionals.
 

Open-source vs. closed source vs. cloud native

In addition to choosing an appropriate hosting solution for your organisation, you also need to consider another, somewhat overlapping aspect: the question of license and framework technology.

Open-source

An open-source solution is the most secure option and gives you full control, but can be costly depending on whether the tool is fully serviced and operated or not.

Closed source

A closed source solution allows the vendor to be in full control, but locks the customer in, while development and progress is solely dependent on the legal owner. Models vary greatly on closed source solutions, so be sure to assess them thoroughly.

Cloud native

Cloud native solutions are the same as SaaS, which can deliver great performance. However, they give the end user no control and makes him fully dependent on the vendor.

Suite vs. best of breed

Yet another architectural aspect to consider in regard to experience platforms is the type of solution your organisation will choose in terms of default features. A classical alternative is a full marketing suite vs. a best of breed, modular solution.

Full suite

A full suite is usually offered by large vendors, for large corporate customers. A full suite with everything you seemingly need from the start sounds promising, but be sure to thoroughly investigate how well integrated all the different features really are, as the vendors often come as a result of M&As.

Best of breed integrations

An alternative in the face of full marketing suites is a solution offering a flexible core and integrations with the best of breed features on the market. In this way, you can handpick separate systems for e.g. CRM, marketing automation, and SEO—whatever fits your requirements the best.

Continuous deployment

Do your potential vendors work by agile development principles and deliver continuous deployment of their solution, as opposed to waterfall processes and fixed release windows?

SDK

Is a software development kit included in the potential solution? What is required to start building, is it possible to run on all machines, how is the installation process, and can developers use their favourite editors in conjunction with the SDK?

Microservices

Microservices may be in the wind, but do your organisation really need such an architecture? And if “yes,” how does it fit with your current plan, and how do you wish to run services?

Use cases

While headless and hybrid CMS have been mentioned already, it is useful to envision a use case to really know exactly what solution your organisation needs.

Classic

A classic CMS is primarily meant for building and maintaining websites.

Headless

A headless CMS is primarily meant for apps.

Hybrid

A hybrid CMS is meant for both websites and apps.

Security

Experience platform security is essential for many reasons, including protection of customer data and your brand reputation. Check these in order to make sure security is on the agenda.

Hardening, battle tested

How well is the solution being tested? Has it been through several documented stress tests, demonstrably hardening its resilience towards threats?

Identity and access management (IAM)

How easy is it to delegate and revoke access to involved users in your organisation and third parties?

Quality

How is the quality system of the potential vendors? Make sure your vendor of choice has documented processes for every essential operation it commits to, including:

Automated testing

Is the solution tested automatically every day for bugs and critical issues?

Ease of use / complexity

How complex is the quality system to verify?

Performance

The performance of your digital experiences depend on a variety of factors, but which the underlying experience platform can contribute to enhance:

CDN

Does the vendor support a content delivery network model?

Local

Or is only local delivery possible with the setup?

Data storage

Is the solution based on NoSQL or a relational database? Relational databases might be a bottleneck or require more skills for management and tuning.

Scalability

Scaling your digital experiences is important to meet increased (or decreased) traffic demands in a secure, predictable, and affordable way. A cloud solution does not necessarily mean automatic scalability, so make sure to investigate this issue properly.

Resilience

How robust is the solution and how does it handle unexpected events? As usual, it boils down to what your organisation needs, and it is traditionally more expensive with higher demands. However, the cloud can solve many of these problems.

Routing

How do you manage the structure of your digital experiences? If you are opting in for a pure headless solution, no URL routing is available out of the box.

URL management

Usually associated with classic CMSs, for handling the URL of any given web page.

Routing app

As a headless CMS is a database with APIs, there is no inherent URL management. A dedicated routing app would instead be permissible.

Web server? Editors?

Other important routing topics can be solved with a hybrid CMS.