Content as a Service (CaaS) is a trending concept that has been brought up more and more in discussions lately. I recently had a conversation about the topic with other industry experts at the J. Boye CMS Expert Group, which gave me the idea of putting this article together. In this post I'll be listing my thoughts and how it relates to eZ Publish. Hopefully, this will provide some insights into what CaaS really means to our customers and readers. Read on.
CaaS: What is it?
Content as a Service, is the ability to think, create and distribute content as independent of the delivery channels as possible. From a technical point of view, it is basically the ability for services, sites and applications to request content via a web service from a normalized and centralized repository. The services, sites and applications are decoupled from the repository.
Content as a Service is indeed a very appealing term. It works really well, so well it seems that almost every content technology vendor would like to use it at some point. Actually, at eZ, we already have. It sounds and reads well. It embraces the "*aaS" trend, which makes sense since nowadays everything is being transformed into services. So, why not content! Most businesses are entering the services business -- whether we make software, transport people, print t-shirts, or create content!
But what does CaaS really mean when it comes to content management? What would it mean to your grandfather, or your brother who is in the plumbing industry? Surely not much.
The main idea behind CaaS comes from the digital revolution. We went through a paradigm shift where content does not carry its meaning and value in the context of a unique well defined web page that is part of a fully operational website with its context and environment, but as an independent asset that can be delivered and live in many different places (different websites, different pages, on different social networks, in different apps, on digital signage, kiosks, etc.). This is a very valid point. Today, various media channels will show the content and consume it as they would consume any other web service (information services, transactional service, etc.).
Content needs a technological environment where it can flow, and be distributed across all its locations and channels, regardless of being permanent or temporary. It also needs to be flexible and adaptable for all channels and locations! To learn more on this, I recommend listening to Karen McGrane's talk, "Adapting Ourselves to Adaptive," where she takes us through the history of NPR applying the Create Once, Publish Everywhere Concept. This is spot on.
Now, if you ask me, I must add I am not much of a fan of the term itself. Concepts of content and services are both very strong yet still abstract. This is really bringing confusion to the table. Content is not a service, it can not be consumed as a service. Content is content. It might be part of a service, or it might not. Personally, I prefer to speak about content hubs, or to use a more concrete term such as, "Create Once, Publish Everywhere," as discussed above. I find this phrase more clear, more direct and a concept that all users can easily grasp.
This might be why we don't use CaaS widely at eZ, despite having the capability to deliver Content as a Service.
What's really new about CaaS?
When we use a new expression like CaaS, it often conveys the idea that we have to deal with something extremely fresh and new. Well, it really isn't!
More than 10 years ago, we at eZ -- but also as an industry -- were already thinking of CaaS when we thought about separating content from presentation. We saw this as the natural way to transition to the Content as a Service approach. For instance, since day one (in 1999), eZ Publish made its content available, without any presentation, as XML, over APIs such as SOAP web services, XML RPC or lower-level PHP APIs. Atom and NewsML feeds were also very good illustrations of technology making it possible to deliver CaaS. Of course, not all CMSs are capable of separating content from presentation. In fact, it's quite surprising how many content management solutions are still out there that aren't able to do so. Indeed, 10 years ago, eZ was one of the first to come with this feature.
What makes this new is the rise of RESTful services. Yes, REST has been a revolution in our industry. It simplified, while standardizing the way we made and continue to make web services. REST provided standard ways to consume information from APIs, embracing clearly JSon and XML making it possible for customers and agency to quickly and thoroughly mashup services, including content from different sources and channels. This is the real disruption that is still going on, quickly moving the software world in a distributed one, and it has really allowed democratization of web services, finally realizing the power of the concept.
Still, speaking of content, if you don't have this strong separation of content and presentation, REST will not help, and you will continue to struggle. This takes us back to square one, separating content from presentation.
The challenges we'll face to fully implement CaaS
The challenge we'll face is simple. Again, it will get back to the challenges we faced while separating content and presentation. We can say that we clearly went far down that road. Still, it is very clear that separating both has a lot of inherent challenges, one of them being that, even if separated, there is a strong relation between the two. For instance, a writer ideally needs to know the subject before being able to write about it. A chief editor still needs to be able to preview the content in order to approve it. A marketer needs to see a landing page as a whole to be able to write good call to action. An copy writer needs to see the visuals and media to be able to create a killer slogan. While separating content and presentation is possible, it is clear that one does not live without the other, and this goes for content creators as well.
CaaS will face a similar challenge. The content creator will need to know the context in which the content will be used to create remarkable content! It will be all about adapting to the context and providing the tools for all the stakeholders to deal with that adaptive nature of CaaS. To be a bit more specific, if consumed as a service, content might have to change depending on elements of context, such as the device it is being read on, the geographic location, the user profile of the reader and many others.
A fantastic opportunity for the next generation
CaaS is here, and here to stay. At eZ, we actually think it is one of our strengths, even if we don't use the term so much. We believe CaaS is at the core of the content platform and the content repository. If you want eZ Publish to serve your content over REST or others, we've got what it takes!
But this is just the beginning. There is a fantastic opportunity to develop an engine for real contextual creation and delivery of content, adding personalization and contextualization of content to the equation and also having content monetization as a core part of it. Doing so would definitely reveal even more the whole potential behind the idea of CaaS. We are surely exploring these options at eZ (you can learn more here and here) and would love, in an open manner, to collect any feedback or comments on the topic. Please feel free to comment!