Crownpeak Digital Experience Layer - The five fundamental patterns
Crownpeak Digital Experience Management (DXM)’s Decoupled Content Deployment Architecture provides organisations with complete flexibility in what, how and where content is distributed. In today’s modern customer-experience-focussed world, the ability to curate content in a single location, taking advantage of centralised governance while enabling local market flexibility, then deploying this optimised content to the right channel for the customer at the right time, gives global organisations a strategic advantage over their competitors.
Having surveyed hundreds of customers and thousands of digital experiences, Crownpeak was able to distil the differing architectures down into five unique patterns - collectively, these form Crownpeak Digital Experience Layer. By categorising customers across these fundamental patterns, this gives Crownpeak customers the ability to compare their business problems directly against other customer examples, quick-starting their design choices, and ultimately producing consistent, reusable and cost-efficient digital experiences.
A collection of solutions that collectively address the majority of enterprise needs
- Standalone - The deployment of an entire application from DXM to a target delivery location
- DXL Invoke℠ - The deployment of parts of an application from DXM that interact with other back-office services within an organisation
- DXL-Inject® - Deploying parts of an application into an existing application, in a format identical to what is already present
- DXL-Ingest® - Using a current continuous integration process to form part of the content deployment pipeline of a DXM-managed application
- Headless - Using DXM’s RESTful API to request content and consume JSON
What is clear from surveying the thousands of customer deployments, is that while these patterns each have a unique usage, the majority of digital experiences features at least two of these patterns in combination - some even more!
Standalone
Crownpeak customers use the Standalone pattern in ~85% of deployments from DXM. In this pattern, the entire application is deployed [via SFTP, FTPS, to an Amazon Web Services S3 Bucket or via HTTP(S)] to the customers’ delivery targets. The Standalone pattern is suitable when an application is entirely self-contained (e.g. static web/mobile sites, marketing campaigns, landing pages, or where server-side functionality is limited in complexity and external testing requirements). A typical software development lifecycle (SDLC) suitable for this type of deployment pattern is one where the solution can be crafted entirely in isolation (i.e., via an IDE such as IntelliJ, Eclipse or Visual Studio) and then allow for Crownpeak developers to integrate that application into Templates and Library Files within DXM. The result is an experience that is wholly-managed by DXM, including the deployment of compiled assemblies (e.g., .jar, .dll, etc.), configuration files (e.g., .htaccess, web.config, etc.). For the majority of use-cases, the Standalone deployment model suits customers perfectly well, providing them with a fast-time-to-market and reduced overall development. It is not, however, suitable where an application has a more formal SDLC, or where you have heavy-integration with internal or third-party services - for that, you should consider either DXL Invoke℠, DXL-Inject®, or DXL-Ingest®.
DXL Invoke℠
DXL Invoke℠ refers to a software pattern that separates business logic and presentation layers, with the latter delivered by DXM [again via SFTP, FTPS, to an Amazon Web Services S3 Bucket or via HTTP(S)] to the customers’ delivery targets. The business logic layers (or large amounts of them), will be maintained external to DXM - perhaps due to a complex SDLC or disparate team locations and responsibilities. Again, the presentation layer will typically be authored externally to DXM, integrated into Templates and Library Files and then deployed to make just-in-time calls to its related business logic, via a well-defined data contract. As the relationship between business logic and presentation is often a defined standard (i.e., JSON or XML), then the languages and frameworks used to deliver the presentation layer need not be identical to those used to expose the business logic. This deployment model is typically suitable to a customer requiring a modern, fresh, updated look and feel to their digital experiences, while still harnessing the power of the existing line of business or third-party services, to which they do not have developmental access (nor desire to receive it).
DXL-Inject®
One of the significant advantages of a Decoupled Content Deployment Architecture is the ability to not only use whatever technology or framework that you choose, but also to be able to deliver (or “inject”) this content to any location that you desire. Consider an application that has been working exceptionally well for several years - it’s ending its supported lifetime and is looking a little “tired,”, but it just works too well for you replace! Perhaps it’s built upon an antiquated technology that you can’t find the developers for anymore? Maybe there’s that one team member that supports it from the broom cupboard? Without a Decoupled Content Deployment Architecture, this is a problem that is going to result in a re-build - but with a Decoupled Content Deployment Architecture, you can simply inject a new interface into the existing application, using the same technologies and code-structure as is already present - as far as the software is concerned, nothing has changed, but from the marketer’s perspective, everything has changed! Taking this further, many modern-day web/mobile sites rely on the separation of presentation from business logic in a model-view-controller (MVC) or model-view-viewmodel (MVVM) pattern. A good MVC example, GoogleMail, uses a single page application (SPA) framework.
Many organisations want to keep the management of a complex app separate from the content (and so they should). Having an intermediate format available for the data (i.e., JSON or XML) is perfect. What you now have is a model that is managed by DXM, and the internal team, system integrator or partner will own the remainder of the application. Now marketers have complete control over their messaging, targeting and personalisation, while the IT organisation manages the rest. The most tech-savvy customers are choosing DXL-Inject® as their “go to” deployment pattern, as it offers them the most flexibility in approach for modern web/mobile applications.
DXL-Ingest®
Perhaps you have an existing SDLC that includes continuous integration (CI)? Well, DXL Invoke℠ has been created just for you! In this deployment pattern, an existing CI artefact (in this case a Microsoft Web Deploy Package) is pushed into an S3 Bucket as part of the CI process and deployed by DXM to the target delivery location. DXM provides environment-level management of configuration settings (e.g., database connection strings, application-level variables, email addresses, etc.) as well as the relevant workflows to handle deployment and roll-back. Customers that leverage DXL Invoke℠ benefit from atomic deployments, pre-deployment failure check and roll-back, as well as guaranteed mirroring of what left their internal CI processes. Note: Although CI processes exist for many technologies, DXL Invoke℠ currently supports only Microsoft’s deployment technology for IIS (Microsoft Web Deploy).
Headless
Want to use DXM for data only? No problem! DXM has a built-in dynamic content API, which exposes either JSON or XML in a light-weight RESTful manner. Easily configured within DXM, any content asset can be configured to make its content available via the API - meaning that customers can deploy the same content WITH or WITHOUT the head (or both!). Crownpeak call this “Head Optional”. Now, Crownpeak customers can deliver the same content to their web/mobile sites via the browser AND to the mobile device application in a data-only format….and of course, the shiny single-page applications that are all the rage can use the RESTful API too! What makes DXM’s interpretation of Headless great, is that you not only get everything that all of the other “Headless Only” vendors provide, but you also get everything that they DON’T: inline editing and preview, drag-and-drop authoring, forms management, personalisation and A/B testing, translation management, compliance enforcement, role-based access control (RBAC), and many more!).
In summary
A completely flexible Decoupled Content Deployment Architecture is what gives Crownpeak customers the ability to manage all of their digital experiences, regardless of channel, from within a single platform. I have architected thousands of web/mobile sites over the years and to-date, have yet to find a customer-scenario that I cannot fit into one or more of the five fundamental patterns of Crownpeak Digital Experience Layer.