Content As a Service (CaaS) In AEM

When I was consulting on a digital transformation programme, the client stakeholders presented a very interesting use case:  

As a marketer, I want a system that will produce consistent and engaging experiences across multi-channel platforms. 

After assessing their system landscape, we decided that to support their request, we needed to design a hybrid solution with a decoupled approach. Basically, we leveraged the channel-agnostic Headless Feature of Experience Manager for maximum content reusability. My team implemented a Content Delivery Framework with a scalable and Hybrid Architecture to promote content relevance with a flavour of a Content As a Service (CaaS) model.

What do I mean by Hybrid Architecture and how does it help with CaaS?

Traditionally, content operations and implementations are designed and delivered on a single technology stack aiming to minimise the cost of delivery, system maintenance and training. However, one of the limitations is templating everything which outputs fully formatted HTML, targeting a limited number of channels and forcing martech teams to invest more resources for implementing change, delays experimentation and increases go to market time. It also makes content delivery heavy for the networks.

To address the above issues, our Hybrid Architecture managed content as a Single Source of Truth, free from both business logic and presentation technology. This solution consisted of AEM as a headless CMS at the center with SpringBoot based microservices providing complex business services and multiple presentation technologies to handle on-demand experiences on various channels. The diagram below explains the content flow. 

At a first glance, the diagram looks ordinary. However, the vital part is AEM’s role in supporting the overall system configuration as described below:

1. AEM authors collect information using Core Components, Experience Fragments and Content Fragments.
2. Regular websites consume final HTML (cached over CDN) to render the pages for different markets.
3. The rest of the channels consume JSON (cached over CDN) exposed by Content Fragments with their choice of presentation technology.
4. AEM Authors create notification content using Experience Fragments (for Emails, SMSs, SaleForce channels etc) and push them through delivery networks.
5. On publication of headless content, AEM also pushes the version numbers (key/value pair in JSON) for each content file to a Spring Cloud Config server. Next, the consuming Apps (Web and Native) use the version number to request the updated content from AEM and process the JSON for their respective UI.

All of this delivers content on demand, offers a very productive workflow and fast delivery of the content. The sample JSON response below can be achieved by utilizing a combination of a Content Fragment and Content Service API in your AEM Projects.

At the very bottom layer in AEM, calling the content endpoint via HTTP GET request for a Sample Address Fragment might look like the following:

{
    "type":"sampleapp/components/structure/profile—page",
    "title":"Address Content API",
    "id":16679859345938,
    "templateName":"profile—page",
    "language":"en—US",
    "items":{
        "root":{
            "items":{
                "contentfragment":{
                    "type":"sampleapp/components/content/address—fragment",
                    "title":"My Profile",
                    "model":"sampleapp/models/address",
                    "elements":{
                        "title":{
                            "value":"My Profile",
                            "dataType":"string",
                            "title":"Profile Title"
                        },
                        "body":{
                            "value":"Address text...",
                            "dataType":"string",
                            "title":"843 Uxbridge Road, London, UX8 3YV"
                        }
                    }
                }
            }
        }
    },
    "itemOrders":[
        "title",
        "body"
    ]
}

One could also customize the Address Model as seen below:

@SlingModel(
    adaptables = SlingHttpServletRequeste.class,
    adapters = {
        AddressComponent.class,
        ComponentExporter.class
    }
)
@Exporter(
    name = ExporterConstants, SUNG_MODEL.EXPORTER_NAME,
    extensions = ExporterConstants.SLING_MODEL_EXTENSION
)
@JsonSerialize(as = AddressComponent.class)
public class AddressComponentImpl implements ComponentExporter {
    String getOfficePostCode() {
        //Some logic, if needed
        return "NY0952";
    }
    @Override String getExportedType() {
        return "sampleapp/components/content/address—fragment";
    }
}

With technical design and implementation, you can think about some good practices for the content operations too. Below are some of the best practices we recommend:

1. Divide your content strategy into smaller distinct parts that can be implemented independently.
2. Align your content strategy with marketing messages for all channels. 
3. Support your content strategy by developing visual content models.
4. Define success before implementation so you know what you’re measuring for.
5. Keep content model scalable for future.
6. Provide a good user experience and training for authors to ensure efficiency in content creation and high quality content.

For more details on benefits of implementing headless solution in AEM, please checkout one of our previous post: Going Headless Without Losing Your Head

Have a question about this or  another solution? Contact 3|SHARE and we'll put you in touch with the right person. Just visit our Contact page and submit the form.

Photo by Jeremy Bezanger on Unsplash