Unlike traditional CMS platforms, like web content management systems—which are tightly bound to a particular presentation technology (e.g., .NET, Java, Rails, etc.) and target channel (e.g., web, mobile, e-commerce, etc.)—headless CMS platforms free themselves from prescribing a specific target presentation model. A headless CMS, often known as an API-first, focus on the freedom from any specific presentation technology or channel.  This approach enables the CMS to live up to the promise of managing content in place and publishing anywhere.  Adobe Experience Manager supports a headless approach, freeing it from being bound to its historical Java-based web development. With Adobe Experience Manager version 6.3, Adobe has fully delivered its content-as-a-service (CaaS) implementation using its web services layer.This approach uses the familiar Content Fragments that allow users to create channel-neutral content with variations, which are fully independent of any notion of pages. In today’s competitive world, organizations are looking to adapt quickly to market changes, while providing a unified, engaging experience to customers across various channels such as web, mobile, business applications, and email.  Adobe Experience Manager, now with its CaaS abilities, provides organizations a modern content management foundation to build upon. With this different approach to content management, in what common logical application layers does Adobe Experience Manager play? Let us quickly review these layers. Presentation Tier: This represents the layer responsible for the interaction between people and the application, often seen as a browser, desktop application, or a form of graphical user interface (GUI). Application Tier: This represents the layer responsible for the business logic and business rules. This tier modifies and updates the information within the Data Tier. Data Tier: This represents the layer responsible for storing and managing the data that is used by applications. What would an imaginary, modern content-managed application look like using Adobe Experience Manager 6.3? Using the CaaS capabilities of AEM, the platform remains solely in the Data Tier, where APIs provide us with access to content. For the business tier, our imaginary application will use a custom Spring implementation. Finally, for the Presentation Tier, we can use technologies and frameworks like JavaScript, React, Angular, Spring, or .NET. Business Challenges When Multiple Disparate Applications Require Content Long Release Cycles A common challenge for organizations that publish content for internally and public-facing applications is having the publishing cadence limited to the application release cycles.  Applications, like an e-commerce platform, may follow a two-week release cycle based on the organization’s sprint duration.  With content releases tied to the software release, a marketer depends upon the timing of the technical team. By separating content from the application or presentation tiers, and accessing it on-demand from within applications, the marketers can update and publish content without dependencies upon the development team’s cadence. Content Duplication It is usual to find some overlap of content consumption across business applications. As a best practice, content is managed in a single location, but is then consumed by or published to a distributed set of applications. To avoid duplication of content and to allow efficient content governance, a company needs to have a central repository where content is created, managed, and from which it is published. Messaging Inconsistencies Messaging and brand inconsistencies emerge when many disparate applications within the same organization, built at different times, share common but varied content.These inconsistencies, created by managing content locally within an application, rather than within a common repository, vary sufficiently to impact the messaging and brand experience for the organization. A Reference Architecture for Robust Content Availability: AEM as Headless CMS (Data Tier) + Spring Boot Application (Application Tier) + Open Technologies (Presentation Tier) Let us explore an architecture that eliminates the previous challenges. In the following reference architecture that uses Adobe Experience Manager in a headless manner, we provide a perspective of how to create a robust, highly scalable content delivery solution, while continuing to leverage AEM’s mature, easy-to-use content creation and management environment—the challenge for many CMS platforms is making access to this content through applications just as easy. All content within AEM is accessible through the Content Service as an API endpoint. Requests made of these APIs make the content available as JSON responses for developers to consume as they need.  Content created is exposed as JSON response through the CaaS feature in AEM to the web services layer. The web services layer is built on Spring Boot outside the AEM platform to ensure that the content/data messaging can be processed, business logic can be implemented, and the response can be cached. The separation of this layer from AEM also ensures a long-term stable web services layer, agnostic of changes in the underlying CMS. This pluggable architecture makes it possible for the web services layer to continue relaying services seamlessly to several business applications, even if the underlying CMS is replaced with a different one. The web services layer uses Amazon S3 to serialize the cached response. In the event of a crash, the cache stored in the JVM (Java Virtual Machine) or memory gets wiped out. In such cases, the cache can be reinstated by deserializing from Amazon S3. Alternatively, we can use packaged caching software like Redis. Redis provides Java APIs, called Jedis, to manipulate its cache, which is like Amazon S3 APIs. The web services layer is fronted with Apigee and uses OAuth2 protocol for the security of web services APIs. The business applications pull the content via Apigee. The architecture diagram below shows the process flow. Request Flow A business application loads on a customer’s device. In the process, it makes a call to an Apigee URL with a token (token is provided to an application when it makes the first call to Apigee with credentials). Apigee checks the token (for invalid tokens, it returns 403 Forbidden). For valid tokens, it passes the request to the web services layer. The web services layer looks up for the response in its cache (Amazon/Redis) based on the request parameters concatenated as the cache key. If found, the response is returned from this layer (typically, 95% of the requests get returned from the cache). If not found in the cache, the web services layer dispatches the request to AEM, receives the response from AEM, messages the data tier, applies business logic, caches the response (using the parameters concatenated as key), and returns the response. When new content is created or when existing content is modified in AEM and published, it makes a call to an endpoint in the web services layer, signaling it to clear the cache corresponding to the item published. This ensures that stale content is not shown on business applications. Configuration of Systems Adobe Experience Manager Create a Content Fragment model from which the business content team can create content fragments representing the textual data and digital assets such as images, videos, documents, and more. Enable CaaS in AEM and use the models and entities to aggregate content as a service. Alternatively, develop custom servlets by leveraging the CaaS feature in AEM to expose the content as JSON response. If using custom servlets, develop the supporting structure using the components and templates in AEM. Leverage the language copy feature for multi-lingual content (if applicable) and variations for channel-based content (separate variations could be created for various fragments such as mobile, web, kiosk, email, etc.) Develop a workflow to automate and streamline the business approval process and email notifications for the authors, approvers, and publishers. Integrate AEM replication with the web services layer to ensure that real-time content changes are reflected despite caching at the web services layer. Set up AEM Author, AEM Publish, Dispatcher, and Web Server stack for AEM. Web Services Layer Develop a Spring Boot application and configure deployments into a hosting platform, such as Pivotal Cloud Foundry (PCF) or server containers. Build custom business logic and data messaging (like data format conversion, designating the fetched content as active/inactive based on time of day, etc.) into the services. Set up multi-node architecture on PCF/container for the Spring Boot application. This is elastic and adds additional server nodes based on traffic in real-time, to efficiently handle the load. Implement caching for the generated response and integrate the web services layer with Amazon S3 (or Redis) for serializing the cache. Integrate the web services layer with Apigee for OAuth 2-based security for the APIs. Business Applications Develop a business application in React or Angular that shows offers, messages, labels, disclosures, and other content to customers by making API calls to the Web Service layer for fetching the content from AEM. Integrate business applications and Apigee (with Authorization and Refresh tokens). Apigee acts as a proxy directing requests to the web services layer if the token is valid. Read here how a US-based brokerage firm enhanced user experience by switching to AEM. Business Benefits of Using AEM as a Headless CMS with the CaaS Model Utilizing the above-prescribed robust, integrated software solution, a company can improve its business operations dramatically. Here is how. Shorter Release Cycles Lead to a Faster Time-to-Market The use of the AEM platform allows for a very swift content creation-to-publishing pipeline that reduces the time-to-market to mere hours from days or weeks. An efficient content governance model, streamlined deployments, automated workflows, and scheduled publishing allows for quick launches of new products and helps the company stay ahead in the competition. Central Repository of Content for Consistent Branding With features like CaaS, content fragment variation for channels and language copy for multiple languages is possible, which can help a company expand the business across geographies and channels rapidly. The dedicated caching mechanism results in impressive page load speed for a company’s business applications. Standardize Content Structure to Make Quick Changes Using CaaS features like Content Fragments, the existing business applications can continue to use their respective technologies like React, Angular, etc., and yet become smart and agile when pushing content changes rapidly. The dedicated web services layer ensures a long-standing, central layer to provision content as service seamlessly even if a company decides to switch to a different CMS later. To conclude, implementing an integrated solution with AEM CaaS and web services can do wonders in business revenue generation. The ease of using the AEM content management system to author information and a swift publishing mechanism significantly decreases the time-to-market for new products. Further, provisioning the content via web services eliminates the time and effort otherwise spent on migrating business applications onto the AEM platform. The company gets complete benefits of AEM for content management without incurring high costs while migrating these business applications. Also, by configuring several applications to consume data from the central AEM repository via a single entry-point in the web services layer, the company can project a more unified brand image across all its business applications.