Decoupled Architecture

The growth of channels and devices impacts how you manage and deliver content in your CMS.

You need to connect with your audiences on many channels, including websites, web and mobile apps, smartphones, wearables, social networks, digital signage, telematics, and more. These channels are only going to change and grow and whatever is next will impact the way you plan, create, and distribute content in the future.

You have to think strategically about how you can easily deliver to different channels in a personalized and contextual manner. You need a CMS with a decoupled architecture.

So what is a decoupled architecture? It is the separation of the back-end content management administration capabilities from the front-end delivery tier, enabling you to publish your content to multiple front-ends, regardless of whether they are built within the CMS or not. With a decoupled architecture, it's easier for organizations to build experiences for their customers across channels and devices.

Ingeniux CMS is built on a decoupled architecture. It leverages new technologies that lay the groundwork for how you can future proof your content and your content management platform, including NoSQL-based content databases, JSON, and XML. With Ingeniux CMS, you can create and deliver intelligent (structured) content across a range of channels and in a variety of formats.

Our CMS supports solid backend content management capabilities and, at the same time, ensures you can easily update and create new front-end delivery formats without having to re-implement the backend CMS.

If you're still not sure a decoupled CMS is the right choice for your organization, let's go through some of its advantages in more detail.

Agile Content Updates

Most enterprises need to update their content on a regular basis, including adding new content and updating existing content. With the Ingeniux decoupled CMS, you can make all your changes in the backend without affecting the front-end deliver tier. Test your updates on a separate staging server, and when the updates are ready to go live, you simply publish out the changes to the delivery tier.

Security

Because a decoupled architecture separates content development from content delivery, you can set up a firewall between the two environments. The firewall protects your network and ensures that content will not be accessed by third-parties until it is published.

A decoupled architecture also reduces the risk of denial of service attacks (DDOS) because the software that delivers the content does not need to access the CMS database, thus eliminating the risk of SQL injection.

Performance

With a decoupled architecture, you do not have the overhead of the CMS application on every web server. This improves the speed of the delivery tier. Separating the front-end delivery tier also allows you to scale your website using commodity hardware.

With Ingeniux CMS, you can deliver content as files, so you do not have the I/O read-write overhead of a database.

Performance is an important focus for content management. The speed at which your website or web application loads has the potential to affect sales and other campaign conversions. 

Ease of Upgrades

Upgrading a decoupled application is vastly easier than upgrading a tightly coupled CMS application. With a decoupled CMS, when you upgrade the software you are only upgrading the CMS application, not your live website. This allows your live website to continue running; there is no risk of breaking the site, or customizations to the CMS from the site implementation.

Availability

With a decoupled CMS, if the backend CMS software were to go down or need maintenance, your live website would continue to operate.

Most enterprises also implement load-balancing software for the front-end web servers, so there's no reason for the website to have any downtime, even for scheduled server maintenance.

Multi-Site Management

The publishing model for decoupled architecture provides much more flexibility. You can publish multiple websites using different servers and technology for different sites. Your CMS should include a replication system that keeps content in-sync and provides much more flexibility.

Headless and self-running deployment

With a decoupled CMS you can easily create and manage content for highly customized websites and rich web-based applications. These websites and apps may take advantage of new client-side JavaScript frameworks such as Backbone, Ember, or AngularJS.

The CMS includes a RESTful API that provides content services to other websites and applications. This content is typically statically delivered (read-only) and consumed by the receiving website or web application.

For example, if you wanted to offer a digital signage solution or kiosk, you don't need to install the CMS on each kiosk. You simply pull content from the CMS using the API and store it within the front-end tier. Even if a persistent internet connection is not available, you can still deliver content to your kiosk application.

Another example is a rich web application for a financial loan application. You may want to offer a series of guides or posts that discuss the application processes, or loans in general within the application. To ensure you have a way to update this content easily without needing to rebuild the web application, you manage the content in the CMS and deliver it to the loan application using the CMS content API.

Flexible deployment

Flexible deployment means that you can deploy your content anywhere, to a website on another server in your environment, to a cloud-based environment, or a CDN (content delivery network). A decoupled architecture enables you to set up multiple publishing locations and deploy your content quickly.

With Ingeniux CMS you can also set up development, test, staging, and publishing servers as deployment locations. This allows you to develop new content, websites, or applications and easily move them through the development lifecycle without a lot of manual, time-consuming effort.

Are there situations when decoupled isn't the right decision?

If you only deal with one or two websites and implement a responsive design approach for mobile, then you may not need a decoupled architecture. This situation is more often true of small businesses than it is of mid-to-large organizations.