This article was originally published on the Kentico Kontent blog.

Establishing your architecture is understandably a nerve-wracking process for most businesses. You are making technical decisions across your infrastructure and solution architecture that will impact the future of your digital landscape, knowing full well that technology and software is evolving at such a rapid pace that the wrong decision can land you squarely in digital no man's land.

For years, the playing field was relatively stable. The market was full of content management platforms that offered “everything under one roof”. Whether you were after content management, ecommerce or online marketing, you could usually shortlist a collection of platforms which would give you all those features and more. It was all down to choosing a single product. A single decision but a big one.

However, in recent years, the microservices architecture has emerged as a viable alternative as technology has raced ahead into new and unexpected avenues. Challenging the perceived weaknesses of the traditional model, this new architectural type relies on a collection of products rather than a singular CMS to deliver the underlying functionality for your digital landscape. For example, a Content-as-a-Service provider such as Kentico Kontent handles your content creation and delivery while separate products are introduced to handle user authentication or authorization, ecommerce, contact management, personalization, and optimization testing – all typically (but not necessarily) operating on Software-as-a-Service models. The separation of functionality provides businesses with access to the products that are right for their needs, supports scalability and flexibility, provides faster speed-to-market thanks to modern DevOps processes and, if architected correctly, streamlines investment.

For many we speak to, the benefits sound too good to miss and interest in the microservices model (including Content as a Service) is on the rise. However, just because it sounds good does not mean it's right for you. As consultants and strategists, it's important to take a step back and look at the bigger picture.

The Folly of Project Type

When faced with the two very different options – traditional CMS and microservices – the most common misconception is that each option favors certain types of projects. Nothing could be further from the truth. Using project type to try and determine whether to adopt a traditional CMS or a Content-as-a-Service (CaaS) provider can often lead to problems.

The reality is that there is no easy answer. Determining the right route for you and your business hinges on several factors, all of which need to be carefully considered to provide you with the best recommendation:

• Features / Project
• Technical
• Infrastructure
• Data
• Personnel
• Cost of Ownership

Building your recommendation

The key thing to understand is that one person alone is unlikely to be able to conduct this review. For best results, you will often have a multi-disciplined team, drawing in expertise from Architects, SaaS experts, DevOps, and Trainers. This may mean leaning on your strategic delivery partners (e.g., digital agencies) to help build this recommendation. Their experience and knowledge of the sector will be vital. With a team in place, you can explore each of the factors.

Features/Project

Of all the factors, this can often be the trickiest. Most businesses and digital agencies have shifted towards an Agile model which prides itself on iterative development. You're going against the grain a little here by attempting to predict what features you may need to satisfy the requirements of the project.

For simplicity's sake, you can group features together (e.g., Content, Widgets, Ecommerce, Forms, Personalization). Your aim is really to understand whether a traditional CMS with “everything under one roof” offers more value than a CaaS product (focusing purely on the creation, management, and delivery of content) working alongside a suite of other products. It's a tall order. The exact functionality is likely not fully defined and things always change in Agile development. This is very much a high-level view with necessary assumptions.

Technical

Traditional CMS and CaaS products have both moved towards the separation of front end (what the user sees) and back end (where content management and business logic lie)—assuming that the traditional CMS is utilizing an MVC model, of course! However, they are still two different architectural models which each have consequences on your ongoing development and maintenance.

“Technical” can mean many things and it's important to be a little more specific. In an ideal world, you would cover all the angles, but reality often dictates that you focus on the areas of greatest importance or highest value. The following list is a good starting point for where to spend your time and effort:

1. Roadmap. By roadmap, we're considering the roadmaps of the products themselves. Specifically, how these products are looking to adapt. In the world of CaaS, this becomes less relevant as the only real point of concern will be around the APIs that you will use to consume content in your applications. Changes still need to be considered but you can expect a lower impact. However, with traditional CMS, this becomes much more important. The “everything under one roof” solution creates a higher dependency on your technical solution and any changes (e.g., the re-write of features or admin UI) can have a significant budgetary and technical impact (especially if new languages or frameworks are adopted in place of existing ones).

2. Technical stack. Whether you're beholden to the current industry trends or have your own internal standards, the choice of technical stack is an important consideration in this decision-making process. Each option must be taken in turn to determine whether your chosen stack is supported and whether there are any hidden challenges. Take, for example, the traditional CMS. Most are now operating MVC models. However, if we were to be truly honest, it's either never “pure MVC” or there isn't a complete separation. This can alter and affect your own development standards and needs clear discussion before you proceed.

3. Performance. Your own business objectives can usually be boiled down to specific key metrics and, more often than not, performance is linked to (if not one of) those key metrics. Enhancements and additions to the search engine ranking algorithms have continually pushed the importance of page speed and performance. Taking each option in turn, think carefully about whether it can help you to achieve these performance metrics and whether there are any obstacles introduced by the technology.

4. SEO. Building on the performance angle, we need to carefully consider SEO requirements. Best practices should be baked into what you do. Friendly URLs, metadata, canonical URLs, aliases, redirects, schema, robots files, rules, and sitemaps are just a handful of the things to consider. Understanding whether the product supports your SEO standards or whether there is additional work required is important.

5. Build and deployment. Depending on your organization's own digital maturity, your build and deployment processes and branching and release strategies may range from relatively simple through to granular levels of control. Your processes are often an understated contributor in wider successes as they can help you get information or change out to your audience quickly and efficiently. Understanding how each option fits with your current (and/or desired) process will soon highlight the recommended option.

6. Wider landscape. There is some overlap here with our first assessment criteria (Features / Project) but we are now casting our net wider. It is important to consider the wider digital landscape. The systems you currently have in play and the functions they cover are all important elements for consideration. The key here is to understand how options fit into this wider landscape. Is there duplication of functionality? Can we create smooth integrations between systems?

Infrastructure

Each option has its own influence on your hosting infrastructure. This can be further complicated if you factor in servicing multiple countries, dependencies on existing systems and key integrations.

With traditional CMS, particularly those using the MVC model, you need to consider the type of infrastructure that can support not only your front end but also your admin area and database. Often, this may mean a heavy-duty infrastructure built up using Virtual Machines or Application Services.

With CaaS, the options widen considerably, especially if you're leveraging SaaS products for not only the CaaS but also your search, authentication, ecommerce, etc. You can often (but not always) build out lighter infrastructures (e.g., serving sites through serverless and CDNs in the case of static sites).

Options aside, your starting point is to create a list of what is important to you when it comes to infrastructure. This could be the level of performance you expect, the resilience you require, or the level of encryption and security required by the organization.

With the list in hand, you can map out the infrastructure (resources, processes, etc.) that you will need to deliver your solution using each option. While it's possible to simply trot out the same infrastructure for both options, there is a greater opportunity at hand to refine the solution for each option and give yourself a much clearer view.

On top of the resources and processes, also think about the other BAU activities tied to your infrastructure and architecture – think upgrades, hot fixes, security patches, etc. You need to think across both infrastructure and software to get a picture of what's involved in maintaining your system.

Data

Since the emergence of GDPR in all its variations across the EU, there has been a heightened scrutiny on how data is secured, transported and handled across all organizations. There's obviously a bar you must meet when it comes to data privacy and security (which is broadly the same across the EU) but for some organizations the regulations provided the impetus to pursue the ideals of “privacy by design”. It's important to first understand where your organization stands, and that stance is typically defined by the DPO or compliance team in charge.

With that in mind, you can start to map out your data, understanding where it sits and how it is used. Ideally, you build upon any existing data maps created by the organization in response to the GDPR. The data map is then key in assessing how each option fits into your data map.

For CaaS platforms, it is relatively straight-forward as they focus on content and end user data is not stored. However, this does raise the question of where data will go and whether there are systems and processes in place to handle this. You need to consider the work required to support that.

For traditional CMS, the concern lies more on the duplication and security of data. Often these products come with authentication and online marketing features which require data to perform and, if architected incorrectly, can swiftly introduce security concerns and heighten your own responsibilities when it comes to data protection (potentially unnecessarily). Take the time to map these items out carefully and understand the picture completely.

Personnel

Your people are an important consideration. Whether you're considering your editors, your internal development teams, or your business' digital maturity, it is essential to consider how each option will fit within your business. You can break this down into three areas – training, engagement and processes.

Training is likely to be required whichever option you choose, and that training will span across both development and content management. You will know the systems that your content and development teams are familiar with and you can use this information to assess the likely investment in training required for each option. One key note to mention is not to focus purely on initial training but also consider ongoing support.

In most companies, change can be pretty divisive – especially if handled incorrectly. Some embrace it while others worry about the effect on their own roles and work lives. Both options bring change, but the degree of change differs. Using your current landscape as a guide, you can assess the degree of change (with the information gathered from previous assessment criteria) and start to define the level of investment required in engagement with your teams to keep them onside.

And, finally, consider your business processes. While some have very little connection to online, there is typically some sort of connection – no matter how tenuous. And, this is where you often encounter resistance. Carefully consider how processes may change (either in an ideal world or by sheer necessity) against each option.

Cost of Ownership

And, finally, money. Cost of ownership is an important consideration. You start with licensing—typically traditional CMSs come with a one-off license fee followed by annual maintenance fees while microservices architectures will come with individual subscriptions for each product based on the plans you sign up to.

The license is just the start. On top of this, you need to consider the cost of infrastructure, the cost of ongoing upgrades and hotfixes (which isn't typically applicable for the microservices architecture when you are using SaaS products), the cost of training and the cost of change. This can be difficult as you won't necessarily have all the answers but, as with Features, a high-level view is enough for this initial pass.

Summary

These key assessment criteria are not the be-all and end-all when it comes to making the assessment of the right option for you. With enough time and budget, it is easy to take these assessment criteria and expand into ever-increasing amounts of detail. However, the real world rarely affords you the time and budget that you need to make these decisions and you often must make decisions quicker than you like.

Hopefully, the assessment criteria we have outlined in this article is a strong starting point for you to help make a key decision in your business' ongoing digital evolution. While the assessment criteria provide you with structure to your assessment, it's essential to remember that no one person can conduct this assessment and recommend alone. A collaborative, multi-disciplined team will have far greater success and provide you with a stronger business case.

If you want to know more about selecting the right solution, get in touch with us and we can help guide and inform the process.