Introducing Content as a Service
Today’s approaches in agile software development such as Microservice architectures and techniques such as continuous deployment and infrastructure as code empower short development cycles and autonomous teams. APIs are no longer a communication protocol between two systems only- they are treated as a product. Keeping changes small and automate whatever is required to bring them into production is a key success factor.
When looking at Enterprise Content Management Systems it often feels as they were designed for print, treating websites as paper. Many CMS came with complex inheritance hierarchies, workflows and vendor-specific customization. None of these features makes us fast or flexible.
Through the last years, Headless CMS products gained a rapidly growing market share. Headless CMS separates representation from the content. The content itself is available through APIs, its representation will be implemented from the respective client applications. But publishing a Content API is only one part of the story. At My Porsche we evaluated different Headless CMS products and introduced Contentful as a fundamental part of our Content as a Service platform one year ago.
Enable content creation
Obviously, content editing is a major part of any CMS product. While developers often do not think about content creation, it is a crucial success factor. Many Enterprise CMS are powerful, but at the same time complex to use. Editors often need a comprehensive training to learn how to maintain content. Usually content is organized in tree structures, following an inheritance schema. For instance there is a content tree for a certain language. If you want to reuse content of a page for other languages, it is often required to duplicate that page into the schema of the second language. Customizing requires in-depth knowledge of the product.
What makes a Headless CMS different and why do we call it Content as a Service? First of all we don’t edit entire pages only functional components. Editors don’t have to deal with the complexity of the entire frontend. Contentful is fully based on APIs and comes with an easy to use editing interface, which also relies on the same APIs the developers use. It provides full control over the content model allowing us to quickly implement our use cases, without having to consult agencies or tasking the CMS vendor to customize their product.
At My Porsche we started with local content maintained by our partners in the markets. The editor user interface is just a graphical representation of the content model. Ease of use is important, as our editors are not CMS experts but experts in marketing or sales of the respective market. There is no time for comprehensive trainings.
As we develop new content models, we can directly provide access to the future editors and improve with their feedback. This way we gained speed and reduced organizational overhead. We don’t need highly specialized CMS developers for that. Having knowledge in REST and a major programming language is enough to get used to the provided SDKs and Content Management APIs.
WYSIWYG?
In a world of devices thinking about break points and supported browsers is not enough anymore. The boundaries between HTML based frontends and native applications are fluid. One big advantage of many CMS products is the ability to see a preview of the future site. As content editors also have control over the layout.
When using a Headless CMS the API is the product and the representation is implemented at client applications. So how do we deal with the lack of previews?
We strongly believe the best preview is to look at the latest content changes in the target frontend. Contentful provides a Preview API having draft contents and production contents. Usually client applications integrate the Preview API in their non-productive stages.
If it comes to content for authenticated areas, such as the My Porsche Portal, our editors have to deal with a bunch of different test accounts having different roles and capabilities. As a problem solver we started to invent own demo pages using the same components as our frontends do. This of course does not replace a full review in the target frontend, but it allows to quickly set some dropdowns and flags and see what content pieces will be visible for the target user having this context. At the same time it is a good practice in development, it forces our team to think about the content API as a consumer prior to the actual integration with the target frontends.
Content modeling
Content modeling is really important as the Content Type defines the API endpoint as well as the editing experience. In the past we had to consult an agency forwarding our requirements to the CMS vendor if any change at the Content Model was required. Now we can define Content Models on our own in code and highly automated.
We usually start do discuss requirements with dependent teams and intiative owners as soon as possible on the whiteboard. If the basic concept is aligned, we start to develop the first content models within our development environments just by clicking the fields together in the web app of Contentful. This enables us to get early feedback from the future editors of that content and adapt. Typical discussions are mandatory or optional fields, localization and so on. As editing is really easy most editors can immediately create their first contents without reading manuals or receiving extensive trainings.
After we have a certain state mature enough to continue we start to develop the content models in code, using the vendors SDK. In the end we have the full model in code, including tests and we are ready to deploy. As the content model also designs the content API, we are always aiming at a balance of having an easy editorial frontend and an API that allows all sort of filtering and selection with a minimal set of queries for the client developers.
Having flat content models is quite easy and straight forward. The complexity grows when you have to link the content pieces with each other. The content is organized in a content graph, allowing to associate the content entries with each other.
References are very powerful but they also come with additional complexity. Editors have to be aware of publishing all references of a content piece as well. Especially cyclic dependencies must be avoided. For client developers it also gets more complex to fetch all content pieces with ideally a single query when using references.
As an easy example we do have a simple banner rotation, distinguishing which banners to display at My Porsche for a certain target audience. Using a reference to the banners allows to reuse a banner in multiple rotations while not having to duplicate the actual banner.
At the same time the Banner Rotation limits us when it comes to tagging with further attributes, that are not dependent on the banner rotation. What if we want to tag Banners with ‘Golf’ or ‘Electric Vehicle’? Think about the queries a client must request to fetch these information. This easy example illustrates pitfalls you have to be aware of at designing Content Models. We are constantly learning and evolving our content models.
Content API consumption
Across uses cases currently running on our platform we see both, clients that directly integrate content APIs in their frontends as well as applications having a server-side aggregation. While such an Aggregation Service allows to integrate further logic and apply specific rules on top of the content, it misses the advantage of the content API which computes queries at globally distributed Edge servers.
Workflows
Content creation must be easy and fast. This applies to publishing as well. If publishing is limited through headquarters only, it feels save but it does not scale pretty well. We believe our editors must be empowered to take over responsibility for their contents.
Workflows are not supported, basically Contentful is mainly distinguishing between content in draft state and published content for production. As the product is highly extensible, from alerting to custom UI components and complex workflows tend to feel as overhead, we see this fact more as an advantage. For instance we can define a webhook that is triggered on certain events and fires a request to an AWS Lambda function, having all event data and parameters inside the JSON body.
Providing a content platform for product teams
Another important aspect is the capability of developing and deploying content models. In the past we had to describe requirements which where provided to the vendor through an agency. Having a content as a service product we can now describe content models on our own. As all content management tasks are available through a fully documented API it is possible to describe the complete content models in code, using practices such as a CI/CD pipelines and automated tests. This makes us faster but even more important, we can enable other product teams to develop their own content models for specific use cases. Usually a small kick-off is enough to explain the basics and share best practices with the other teams.
We distinguish between ‘Content’ and ‘Platform’ as products. For use cases having ‘Content’ as a product we develop all content models, take care about APIs and editors. The editors maintain content and assets.
If other teams want to develop their own content models and manage their own space, we onboard their developers and share best practices. The product team is fully responsible over content modeling, editing and API client integration.
Conclusion
Looking at the past year the ability the create content models on our own really made us faster and more flexible. It also encourages our partners in the markets to directly get involved instead of just writing down requirements.
The Contentful web app is easy to use and the product is pretty popular among our editors. Markets are able to directly maintain content for their respective customers on their own.
As content team our major advantage is to have all the building blocks like content model, editing interface, web hooks and so on under full control to rapidly develop and deploy new uses cases. Contentful allows us to focus on the content and to limit organizational overhead.
Providing new content models fast is only one part of the story, we still need to improve our planning and dependency management with regards to content to decrease time 2 market.
Do we miss classic CMS features like Content Preview, Asset Management or Workflows? I think we have to answer this with the classic enigneering quote — “it depends”.
We strongly believe that the best preview is to have a look at the contents in the target client application. The Asset Management in Contentful is pretty basic. We also do not miss Workflows, but something like scheduled Publishing or assigning some unfinished content entry to somebody would be appreciated by our editors.
Definitely Contentful is highly extensible. Developing custom scripts and tools always comes with the cost of having to maintain and operate these tools. I would recommend to define a Code of Conduct of how you want to use your platform. Sometimes complex problems lead to a simple conclusion — business logic should not be implemented in the CMS. Implicit logic and dependencies between content fragments make editing and API consumption more complex and error prone.
Whats next?
Content as a Service based on Contentful gave us new capabilities. For the future it will be important to integrate further content sources. We’ll have to aggregate these contents based on certain rules and provide more dynamic APIs, aware of the user context. It will be a big challenge to provide new approaches while keeping the client APIs simple and the frontends generic enough to keep flexibility.
