Content as a Service: the backbone of modern content operations (webcast)
In this presentation, Divraj Singh of Adobe and Sarah O’Keefe explore the concept of Content as a Service and provide CaaS examples.
“In a Content as a Service model, content creators write the content and make it available. Then the consumer gets to format that content and read or consume it in whatever way they want. ”
– Sarah O’Keefe
Elizabeth Patterson: Hello everyone. And welcome to The Content Strategy Experts podcast. Our presentation today is, Content as a Service: the backbone of modern content operations. And our presenters are Divraj Singh of Adobe and Sarah O’Keefe. The Content Strategy Experts webcast is brought to you by Scriptorium, since 1997, Scriptorium has helped companies manage structure, organize and distribute content in an efficient way.
EP: Before we get started, I want to go over a couple of housekeeping things. We are recording the session and it will be available on our blog on Monday. So if you have to hop off at any time, you’ll be able to catch the rest of that webcast and also share it with anyone else that you think might find it relevant and interesting.
EP: If you have any questions during the webcast, if you look along the bottom of your Zoom window, you should see a Q&A panel, and you can drop your questions there, and we will get to those questions at the end of the presentation. And with that, I’m going to go ahead and pass things over to Sarah and Divraj .
Sarah O’Keefe: Thanks, Elizabeth. And hi everyone. I’m Sarah O’Keefe. I’m here with Divraj Singh who is not on video today, but I will hold down the fort on that side of things. So Divraj and I have been working on this presentation, putting some things together, thinking about some of the big picture trends that we’re seeing. And so what we wanted to share with you today was what we’re seeing in terms of Content as a Service or CaaS, and what that means for your content delivery options, for the kinds of things that you might be able to do.
SO: And then Divraj is going to do the cool part of the presentation, where he’s actually going to show you some live demos of how all the stuff is working. So I’m going to give you a little bit of the background information and the big picture, and then we’ll launch into the good stuff that you’re here for.
SO: So by way of a little bit of background on the two of us. Divraj Singh is a Senior Solution Consultant at Adobe, and specifically works on AEM and AEM Dox, the AEM XML product to craft solutions for customers, to figure out, how do you apply those tools to specific kinds of customer problems? As you probably know, I run a company called Scriptorium here, and we’re engaged in consulting around pretty much exactly the same thing. Enterprise content strategy problems, content operations, how do we make this all work?
SO: So Divraj and I have been working together for well, several years on some different projects and some different ideas and scenarios. And so this presentation came out of that work that we’ve been doing together. So Divraj welcome. And do you have audio on your end? That would be a good thing to check now.
Divraj Singh: Thanks, Sarah. And as she said we have been working together for about more than three years now, and essentially this presentation is an outcome of our common understanding. I agree.
SO: Yeah. So thank you for being here and welcome to all of our participants. I wanted to start by giving you a tiny bit of background on our publishing model. And so I made a very sophisticated flow chart of what our publishing model has looked like since, certainly 1452 or thereabouts, but actually really since forever. You write the thing down, you figure out how to render it or make copies, which traditionally was a pretty time consuming kind of thing before this very lovely printing press came along, and then you distribute it to your end users.
SO: And so some things have changed. We’ve moved up in the world, we’ve moved to a digital workflow, and we have some things that work a little bit differently, but really the model hasn’t changed. Because even in a digital workflow, we have roughly the same exact process of you write the thing, you publish the thing and you distribute the thing.
SO: So if you jump to the next slide here, you’ll see, it’s the same model. It’s digital, it’s a lot faster. There’s a lot less of people using printing presses or modified wine presses, which is what it actually started out as a lot fewer hand copying elimination, those kinds of things from the really dark ages, but the process has remained the same. And so, if you step out of this, out of the digital workflow, just think about the big picture. Here’s what it is.
SO: You write the thing, you format it, you publish it, you distribute it and then you ship it over to the end user, whoever that may be. And finally they get to consume it. Now, the number one takeaway from this presentation today, other than, “Hey, those are cool demos.” Is this next concept, which is that Content as a Service it’s going to actually reverse your traditional publishing workflow.
SO: And so if you look at that right format distribute model, the consumer is going to get a lot more control. Because in a Content as a Service model what’s going to happen is that we as content creators, write the content and then we make it available. We publish it, but it’s not rendered. It’s not a formatted document or even a website. It’s just content out there in the world. Actually in an API, which we’ll look at, but out there in the world. And then the consumer says, “Hey, I want these kinds of content. Give me this content.”
SO: And then the consumer gets to format that content and finally read or see or consume it in whatever way. So it’s your end customer that at this point has three out of the five tasks, not one, they used to be relegated down to that consumption only, and now they’re getting these other pieces. And so this is a really, really critical point, because if you look at traditional publishing, we have those five steps. And if you look at Content as a Service, we have similar five steps, but there’s a get content in there as opposed to a distribute, and the steps are kind of out of order, and the ownership model changes.
SO: So in traditional publishing, as the publisher, the content creator, the content owner, I own those first four steps. And then you, the content consumer or the reader, you get that last step. And then on the CaaS side of the world, the balance changes. So if you take a look at this next bit, you can see where that’s happening, and how that balance of power is really shifting. Yeah. Thank you. Just a couple of builds there. There we go.
SO: So the owner used to have four out of five steps, and then there was a consumption. Like, “Here is a book for you. Please read it.” or “Here’s a website. You may consume it.” But now we’re in the CaaS model and there I write and I make it available. And then you as a consumer do the rest. So that’s where we are with CaaS. And so the implication is, we’re giving the content creators… Or actually, we’re taking away control from the content creators.
SO: In a publishing model, you’re the baker. And you get to put all these lovely things together, and you put out this lovely buffet or a smorgasbord, or calorie parade here, and you have all the control over what actually gets put on this buffet. The hypothetical restaurant guest here has control maybe over what they choose to consume. But they don’t really get to say, “I don’t want that baked good.” Or, “Can you take that one ingredient out?”
SO: So Content is a Service is content or possibly donuts on demand. As the publisher, you no longer control the end point, the consumer actually gets to control that. The publisher is just making stuff available, and then the consumer chooses, “Which of these things do I want? And how do I want to mix and match them? And I like my donuts with more sugar, less sugar, or no gluten.” Or whatever else we may come up with. And I think we’ll stop with that model because I’ve now beaten it to death.
SO: So there’s a lot of power in Content as a Service in this concept of, we’re just going to serve it up to the end point or to the customer, and then they’re going to decide what they want. Now there’s a bit of a cautionary tale here because as you can see from my very scientific graphic, if you think commercial tools like a Microsoft Word, even, just any sort of publishing tool, Word, InDesign I won’t date myself with PageMaker, but something like a Word or an InDesign, those are really interesting from a publishing point of view, and they’re relatively easy to configure, but the level of flexibility they give you is relatively lower.
SO: Because when you pick a help authoring tool and they say, “We have these five or these 10 outputs.” Which was wonderful. If you want to really step outside of those five or 10 outputs, you’re kind of out there in no man’s land. And it’s pretty difficult to fix that. To say, Well, actually, what I want to do is export to JSON.” And they’re like, “Well, we don’t have JSON.” And now you really have a problem. You can step up in flexibility and also in configuration effort by going to frameworks.
SO: So what I’m talking about here is something like DITA and the DITA Open Toolkit, where you get more flexibility, it’s possible at least to extend that and do a lot of interesting custom things, but it’s a decent amount of work. And Content as a Service or CaaS is going to give you maximum flexibility. But also the configuration effort is going to be significant in working through this. Because you’re not doing again, this traditional, write the content, format it, package it up and deliver it as a website or as a book or as whatever it is you’re delivering.
SO: You have all these different possibilities and you really have to lean into that and think about what your flexibility looks like. So I do want to caution you that there’s some effort associated with this. Now in the big picture, when we do this, when we think about CaaS, it looks pretty much like this. You’ve got your content creation happening over on one side probably in some sort of authoring system CCMS, you’ve got a content repository of some sort.
SO: Now I’m calling it a repository very often. It’s something that allows you, that’s API enabled, which means you can use software again, to connect to it and extract information. And you have a person on the back end who reaches into the repository and asks for things. And Divraj is going to give you some really interesting examples of this that kind of make more sense than just looking at this dry graphic. But the key takeaway for me here is that that requester is not necessarily a human.
SO: The requester could actually be a system of some sort, for example you could have, and he’s going to show you this. You could have a chatbot that says, “Hey, I got this query reach into the repository, get the relevant information displayed in the chatbot.” So at that point, the requester, the human typed into the chatbot, but the chatbot turned that into the actual query. So the content consumer can be either human or another system. And we need to keep that in mind that, that could happen.
SO: So with all of that in mind, just keep in mind the big picture view of the requester as potentially being a chatbot or a diagnostic system, or a learning management system, retrieving content from your content management system. It could be a lot of different things going on. And so with that, you want to think a little bit about content requirements. What’s that going to look like? And with that, I’m going to turn it over to Divraj, to talk you through, I think the gruesome technical details.
DS: Sure. Thanks Sarah. So great overview and then it all boils down to as Sarah was giving the graphical representation, when you’re moving towards CaaS, there is more of configuration. But with that, you also get more flexibility. But what that configuration looks like, and what all efforts are required to move towards CaaS, so there are two aspects. One, you have to get to a system which gives you certain capabilities. We’ll talk about that. But the content really has to get intelligent, or it has to be configured in the right way so that you can deliver the right content for the right platform.
DS: So essentially there are few factors which are important. So when you’re moving away from say the traditional ways of altering two CaaS, you need to make sure that the content is granular enough so that whatever is the end point or whoever is the requester of the content, gets the right precise piece of content. So it has to be granular. Second, it has to be reusable so that now you don’t have to write the same content for different platforms, just for meeting the CaaS requirements, it has to be a common content reused for all the platforms, and it has to be single source.
DS: It has to be kept in the same repository for all the requirements of CaaS. It sounds more like structured content, which can meet these requirements. But it can be others too, as well. Whereas if we look at the technology requirements, or the system requirements, what all should I be able to do with that content, the granular single source or reusable content, I should be able to track updates to those so that if I’m doing any updates to the single source content, whether or not can the receivers of the content be notified about the fresh content? Or can I keep the content messaging consistent across all the platforms?
DS: How can I manage such content? Whether or not I can manage the content hierarchy or I can design the information architecture in my system. Can I apply some metadata to the content so that I can find out the content in the right way? It’s not just about the content that we are writing in inside the documents, it should also be about identifying it without going into the full text of the content. You can say like associating some unique ID or assigning the country code, or assigning some product IDs to your content so that you can easily identify that.
DS: And obviously the system should give you an ability to expose all that content to API, so that you don’t have to push the content to the platforms. The whole concept is the requesters can pull the content in the way they want. So the API is been not only have to expose the content so that people can extract as it is, but they should also be in the ability to transform the content as it is demanded, let’s say from XML to, or to JSON or HTML or something else. It can be innovative in those senses.
DS: So what does it take to move to structure? Because we have learned about, or we have just spoken about two types of requirements. One, the content requirements where we said, if you want to move to CaaS, it sounds like moving to structured. So if we take that as an example, so what does it take to move to structure? So you take all your legacy content or identify all the current sources of content, and then try to transform that to structure.
DS: It can be DITA, it can be XML but when we are moving to structure, the whole point of moving to structure is not only to make it DITA or XML, but also to associate the right metadata, breaking down into right volumes or the right sizes, and also making it reusable. Identifying the right set of pieces, which can be reused in different contexts and creating a granular file or granular content of that piece. And then letting someone work on that CCMS system who can continue to follow that pattern by assigning metadata and keeping those reusable content in the system to make it a product assistant for other artists to work on it.
DS: So moving to structure is important. And while moving these other factors, which are important. And when you move to structure, the benefits that you get, obviously, so you have granular reusable content and the system provides you abilities to track the content, keep it single-sourced, and also manage it, but also deliver it using APIs. When all those things are there, then you can publish, or you can push this content not only in the traditional way through platforms like a web platform or to the partner portals, or pushing it as a PDF to your SharePoint site. Those things can anyways be done.
DS: Because if it is structured, then you can make use of tools like data, open toolkit or some of the publishing engines. But in addition, what you get is because the CCMS system or this repository is going to give you an API first or API end point, the systems which are automated, like diagnostic systems, they should be able to request the content based on some unique ID or some metadata, from the system and get the content in the raw format. And apply the presentation layer of their choice if they want.
DS: Or they can be some chat board applications, or they can be some personalized experiences in the external platforms. For example, searching the content from the repository, by using the intent or the platform that the customer is using, and showing the relevant content itself to the users. But those are some benefits. But Sarah, do you want to speak about some more benefits here? Or do you think I’m missing something? I know you also have experienced a lot of those things.
SO: I think this is right. And clearly I usually look at this at a very high level and I think this level of detail is really helpful. My takeaway is simply that people may be able to use this content in ways that you haven’t even anticipated, because you make it available. And then because I’ve given the end user the choice or the client, if you will. The content requester has the ability to go in there and do what they want.
SO: One thing I will mention, which is not a side issue, but it’s kind of on top of all of these things that you’re showing here is accessibility. If I, as the content requester have complete control over what I deliver, then I can customize the presentation to meet my requirements and not your assumptions about how I might want to see it or consume it, maybe not see it.
DS: Yep. So if I consolidate this all together, we know like there is a system which can manage all the structured content. If I divide this pipeline of delivering the content from this API first repository, this pipeline can be divided in two parts. One is the traditional way where I used to push bait content to the, in platforms like web PDF HTML five or some partner portals. So we call it big because everything is already baked by your authors. They have already created PDF for different platforms or different audiences that they saw.
DS: But think about the other way, like if it is CaaS, the second lane the green one in the diagram here, which is API driven. What it can do is there are systems in the market which can be connected to the repository, where you have authored all the structured content, which is associated with all the desired metadata, using all that metadata and the granular information that is available in the repository.
DS: Obviously the repository should allow an ability to not only author, but also mark the content as approved so that you can make a clear segregation between what can be made available to the end-users. So only the approved content can be accessed by the APIs or by the end user platforms through APIs. So those systems can be diagnostic system chatbots, knowledge basis like people searching through the knowledge base. And while they do that, it’s actually enabling faster time to market.
DS: Because you don’t have to worry about what all platforms, and I don’t have to worry about creating a presentation for each of those platforms, which are more relevant. So the presentation can be taken care of by the platforms who are going to deliver this content on behalf of you, maybe as a content aggregator for your content. And all of those platforms can get the latest content without you having to remember, what do I have to push? Or which latest content do I have to push to the latest or to what all platforms I was delivering this content?
DS: In addition, while it is structured, one of the important things is, based on the metadata that people are pulling this content from CCMS, all this content can also be dynamically filtered. You can add intelligence to the content. You can understand the intent from the query that people are making to your CCMS and then deliver the content, which is filtered dynamically. And we’ll see some examples. We have set up a few scenarios around that. You can make things contextual, because let’s say you are accessing the content from knowledge-based versus some external application, which could be a diagnostic application.
DS: So you can understand which application it is. And based on that you can filter, and you can also deliver the content, which is relevant for that application. So all those things are definitely, we say like it has all content is so as right. It is not baked as it is demanded. You deliver the content based on all the metadata, which is associated to it. So what we are going to do is based on this theory, we’ll more or less focus on the Content as a Service part.
DS: So we will not think about publishing the content in the traditional way, but we will have few examples, like real world examples, where if you are creating your content in structured way, and you’re associating enough metadata to it. So applications like a chatbot wherein you are giving the control to the end user who wants to get some information from an automated chatbot.
DS: He doesn’t have to raise a support ticket. He can directly ask some standard questions on the chatbot. And if the information is available in the structured CCMS or repository, then you can directly give the answers to the consumer. That’s one application we will look at. The second could be the support agent portal. So many of times we ever heard the support agent portals, the agents are generally creating some information in those portals. While they are doing that, they also want to access some standard articles.
DS: Now, those could be technology articles or technical documentations, which exist in your repository. Now, in most cases, what happens is they try to keep a copy of those technical documents, or they would look at the PDF documents from which they can search for the information and then write their articles in the knowledge basis sometimes. Or in some cases, they also create the support tickets based on the technology articles, which already exist.
DS: Now think about a scenario where all of these technology articles already exist in your CCMS, and you don’t want to push all this content to the knowledge basis for the support agents to find out the content in their platform. What if those support agents can actually directly access the repository or search in the repository to find the right argument? So that’s a second application we are thinking about.
DS: The third is personalized content. So in this case, it could be products that a user owns, but it could also be, we will showcase with an example that in the support portal or in a knowledge-based platform, based on the user profile, I will be able to access or dynamically filter out the content, which is already authored in the repository. Similarly, a context aware search.
DS: So whenever you’re searching to Salesforce versus web search, what differences can be made with search enabled to work as. And lastly, we will also look at an example of diagnostic system. So many times I have personally heard there can be some diagnostic systems like machinery, which is facing an error code. Now, a consumer wants to do a preliminary check or troubleshooted himself to find out what is the actual problem? If it can be fixed by following some standard steps.
DS: Obviously for every product, you also authored some technical documents for troubleshooting some of the standard problems. Now, if those machineries can be directly connected to a CCMS repository, or a repository, which is publicly available, then based on some of those error codes or the product ID, do uniquely identify the problem that the user is facing. If all that metadata can be passed on to the repository, and the APIs can give you the information on how to troubleshoot that, that is another application of CaaS with the structured content.
DS: So those five examples we’ll take a look at. And I’ll go into the first part, but in all of those five examples, what you will notice is there are a few things which are important, and these are the key ingredients I would say for delivering fried content to different platforms. So first is definitely create the content in the structured way, make it granular. We can start with bite-sized as topics, but it can be further granular.
DS: And we’ll see some examples how within a topic, we can also define some tags or conditions, so that we can make it more granular for making it dynamically filtered content for different requests. So that’s one ingredient. The second is associating the relevant metadata. Whether or not we are creating the content in a way like the different topic types within DITA, for example, task concept, reference topics. Those also have some relevance.
DS: So if that kind of metadata is available, that can obviously help us in finding out the right intent and getting the right content for that intent. Also, we can associate metadata like unique error code for your diagnostic. That could be another additional attribute at the topic level. And then the third one is obviously delivering all this over API. So these three things, will be applicable on all the five use cases that we will be presenting as an example. So the content will be structured. There will be some metadata, and the content can be exposed over API.
DS: And then the machines can obviously consume it without much effort. Taking the first example, which is the case of chatbots. So in this case, if you keep those three ingredients in mind, and you will be able to recognize all those three in each of those examples, when I present this. So one is you have CCMS where you’re storing all the structured content, and the CCMS is able to deliver the content over API. We are taking an example of Adobe Experience Manager, it’s not a hard and fast. The whole idea is that it should be a repository, which is API enabled, and it should be able to manage the structured content.
DS: And obviously the end user platform can be a chatbot. It would be a Slack. We will be using slackbot as an example in this case, but it could be telegram, or it could be another chat software. Now between those two, there has to be an API which receives all the metadata information from the end user, which is a chatbot application, and then it has to deliver that content or deliver that metadata to the CCMS, requesting for the contents when API, and then giving it back to the chatbot.
DS: If you look at this as an example, if I want to show you an example of this or real world example, what I’ll do is, I’m going to… the system here. Okay. I just had to restart the take bot behind. Now, if you look at-
SO: This is how you know the demo is real.
DS: Yeah. So this is my tech bot, if I type in something like, hi, so this chatbot is going to return a standard response that it is an automated chatbot. Let’s say, I want to ask the chatbot that I forgot my password. It is not a question, but in a way I’m saying like, I have forgot my password. I should be given instructions to reset my password. So it is able to find out the content relevant to my query. Let’s say there are more, quite easily, what is a yeti? So, because I have configured some content, which is relevant to this. So if I ask about this, the chatbot is going to return me an answer, which talks about the yeti.
DS: Now behind this, if I go back into my system, so this is the CCMS in that, what I’ve done is I’ve created some topics for a chatbot. All right. So before I show you this, I will actually show you that how this the brain works behind. So I will show you the CCMS part, the repository set apart very shortly, because I have to connect back to my VPN to go into the system. But the end user platform is the Slack, which we just saw.
DS: The brain part is actually a flow where in we configure how to receive an input from Slack, and then how to send this request to your repository and whatever response we get from the repository, how to transform it for Slack bot. So your repository will have the content which is in structured way. It doesn’t have any presentation layer associated specific to chatbot. But it is able to deliver the content. Sorry, if you want to speak a little about a chatbot overcast, I’ll quickly connect to the repository so that I can show the authoring part of this.
SO: Yeah. So if you think about this as compared to, I can’t believe I’m saying traditional chatbot, but as compared to traditional chatbot, when you go to set up things in a chatbot, what typically happens is that you have dedicated system. So you are at the end of the day, almost certainly exporting from your repository and putting all the content into some sort of a dedicated system for the chatbot. So, that’s just like an advanced version of copy and paste.
SO: So we’re in a situation where you have your CMS or CCMS content, and then you have to copy everything over to the chatbot, potentially rearrange it, break it up, do all the things in order to get the chatbot to accept the content that you’re feeding it. And so what we’re proposing or what we’re able to do in a chatbot environment with Content as a Service is, the chatbot and the brain.
SO: The middleware is going to reach into the repository, the original repository and grab what it needs, and be able to break that down based on presumably the fact that you’ve structured, organized and labeled, whether with metadata or semantic elements, you’ve labeled the information in such a way that the chatbot and the brain are able to process and render it. So what we’re eliminating is a copy of the content and a maintenance problem.
DS: Yeah. And if I go back into the repository, it was mentioned by Sarah. So I just quickly to show so that I am connected to the repository. Now, if I look at the content, so this is my Adobe Experience Manager repository, where I’m managing all this structured content. Now in this, although I have kept the chatbot as a different folder, because I wanted to keep all those topics which are relevant for chatbot, but these topics can also be common to other platforms, for example something related to account.
DS: How do I reset my password? Et cetera. So these things can also be common to other platforms like Salesforce, or some external platforms or resetting your password within your organization. So these topics can be common. And within this topic you can also define conditions like some of the steps are not relevant for chatbot. So you can always add an attribute like platform. And add the value as chat board and differentiate it with other platforms that you may have. So those things should be provided by the CCMS system. And anything related to the metadata, you can actually associate some keyword.
DS: Like I was looking for “forgot my password” as a keyword for chatbot. And so I’m using all those capabilities of structured content and the CCMS capabilities to assign metadata to it. And we’ll see more examples of using metadata with content, which are used by the CaaS services. So you can create structured content, define keywords, define metadata, break down your content into small pieces. Maybe you can start with topics first and then talking about conditions within the topics. So all that is possible. But there is always a starting point when you are unstructured.
DS: So that’s one application we wanted to talk about, and I think Sarah has already spoken about what is the difference between when you’re moving away from traditional to CaaS, in respect to a chatbot application. So the second one is a support portals. So where in, as I said in some support portals, there are lack of capabilities of storing the technical content. Or even if you store the technical content in those applications, you would be duplicating all that content. But if you want to keep all that content in a single source, which could be your structured content management repository.
DS: So if it is already there, and if all that content can be exposed over API, then the search of that content can also be exposed over API so that you don’t have to keep a duplicate copy. The agents will always get the latest content when they’re searching for it. So if you take a look at an example of this, so what we have done is we have created a small page on the Salesforce site, and this can be built as a knowledge base pallet for the support agents, wherever they are working in the Salesforce site, they can also have a pallet on the right side here.
DS: So they can search for things like, how do I do something? Or what is the definition of some dome? Whenever they are working on some articles. So they can type something like, what is a strong cluster, for example. And then they show us for this information. What you will notice is that, we are explicitly showing the type of the topics which are returned. So the intent of a concept in DITA is to define some terms or define the process of something.
DS: So if you look at the strong cluster architecture overview, what you will see is it returns the entire topic, which has this information. Now, this information can also be granted arise based on the metadata that is past. And what I’m showing you is that here, and you are actually passing in some parameters as well. This will become more relevant when we talk about the personalization piece in the next example. But the whole idea is that, the query makes a difference. For example, if I search for how to add a host cluster? So the word “how” is important here.
DS: When you search for that, it is going to return the tasks, because how is generally, how do you do, or how do you perform those steps basically? So if I look at one of those examples, this would actually be the steps. And we are not modifying the structure or modifying the output much. The presentation layer is very basic that we have presented here. But this all can also be further modified or further transformed by the consuming applications. So this is important.
DS: And another thing is like, if you just search for user account without anything, it can give you some random results. You can see a topic, a task, a reference. So based on that, based on the topic, you can look at what is the user account creation process, et cetera. So this is important when you are looking at the support portal or from the support agent perspective, whenever they’re searching, can I do an advanced search on the content? Maybe I can have more associated parameters here, like add some tags when I’m searching the content.
DS: All those things, when you pass this to a CMS repository, it should be able to give you granular results. And then the support agents can actually use that information to further fill the articles in the support portals. In addition what you can also do is, when I’m looking at the personalized results, so there is an important factor. When you are working between different platforms, the repository should also be able to return the content in various formats as it is desired by the different applications.
DS: So I consider this as a different application, not AEM, not CMS, and it is not a Salesforce application. But if you look at the type of content, if I try to search for it, so I can make this search result more granular. I can look for audience administrators, and look for this user account information. So when I look at that, not only I will be presented with a granular result or the specific result which matches the criteria, but I can also present this information in various formats. It can be JSON output format of that particular DITA topic, or it could be an HTML output.
DS: When I look at this HTML output, you will see some content. An important thing here is, the entire content that you see here, if I go ahead and open this in the editor, in the CMS, what you will notice is, the content is actually bigger. It has a lot of things inside. And there are a few things which are important. One, I am also assigning some conditions like, which audience does this paragraph belong to? So I’m having the content for administrators, internal users as well as external users, while I’m also adding some additional information like platform.
DS: So this particular paragraph is for Salesforce platform. And this one is for other platforms. So keep this content in mind, because I’m going to use this content for another example, which is personalization, but important thing here was, I can actually present the same information in various formats, and I can also make the search results more granular. So I can pass on different DITA attributes and get the fine tuned results. Just like how we saw in Salesforce. We got four results, but if I pass in the audience parameter, I’m getting only one, and then I can present this in various formats.
DS: It could be HTML, it could be XML, or it could be JSON. Now, if I move back, and we look at the differences that we or the advantage that we get in comparison to traditional approaches. Now into traditional approaches, we were storing all the support content in the dedicated system. Or in the support portals, we used to duplicate the content so that all the agents who are accessing the content locally, they should be able to find it easily and they should be able to find it based on the metadata that they’re searching on.
DS: In those cases, what would have happened is, maybe if you do not synchronize the content between two systems, the search results will become inconsistent. Whereas if you keep all the content in a single repository, the support portal will always get the latest content and it will be consistent to all of the platforms who are accessing the same content. So those things are important when you are considering CaaS in terms of support portal. The next one is personalization with CaaS. And I’m taking exactly the same example that I just presented.
DS: The important factor here is, we authored the content, a single topic, but had lot of conditions in it. We call it metadata based on the different DITA attributes which can be associated with the content. Now when different platforms or different personas are accessing this content, this content can automatically be filtered based on the parameters they pass to the CMS. For example, from Salesforce, if I am accessing the content as an audience internal, what you will see is there is a bunch of bullet points and bunch of number list and paragraphs.
DS: So this is also highlighting internal users. And if you look at the tip here, this is different on the platform for Salesforce versus the tip for the platform for any other platform basically not Salesforce. And the audience can be administrator here. And exactly the same example that we presented, if I look at other platforms, so consider this as other platform, and I’m looking for user account audience administrators.
DS: And if I search for that, and I look at the HTML of this, what you will see is the content has a table, administrators can actually access all the passwords, and if they have forgotten their password, this is one of the tip that was given to the administrator of the other platforms, that you can use your local credentials for the application. While if I go back to Salesforce and look at the user creation, what you will see is that, I am getting the result for internal users and the tip is actually different.
DS: And if you look at the content which was authored in the system, the tip or the paragraph at the bottom. So I had the audience Salesforce for the SSO login tip. And for the other one, I’m using the other platform. And in Salesforce because I’m using a profile of an internal user, which I can actually change. So I’m logged in as a user whose profile is right now an internal user. I can always change that to say, administrator, save it. I’ll close this one. And if you look at the search results now, the search results would be the same.
DS: If I’m looking for a user account, I get the same four search results. But within that, now I will get the administrator’s content, but the tip would still be the same, which was associated to the platform Salesforce. So that’s the third example that we took for Content as a Service. I hope we are keeping track of questions. I’m not looking at the chat. If there are any questions, we can also answer those towards the end.
DS: But moving to the next or before that, the benefit that you get on this type of application with CaaS, what you can do is you don’t have to bake all the content and deliver it for different audiences or different platforms. The CaaS or the APIs can be enabled in a way that all the content can be delivered dynamically for different platform requirements, and different user profile requirements. So you author it once and you don’t have to publish it for all the platforms and audiences.
DS: And this way, it is easy to manage the updates because the end user platform… So the end users are actually pulling it based on the profiles that they are associated with. So you avoid duplicate efforts. You don’t have to keep track of all the changes for all the platforms. You don’t have to worry about whether all the content is updated for all the users or platforms. So all those benefits you get with CaaS on the personalization side. The other, I think this is one of the last examples that I had which is a diagnostic system.
DS: In this case, I wanted to keep away from more complexities, but if you think about a diagnostic system, if we start on the right side. Generally the diagnostic systems, which are associated with the products or any device, what they can already do is the information they have is what type of product it is. If there is any geographical association to that product, for example, if there is a printer in Europe versus printer in USA. Or a card. Or a vehicle in Europe versus vehicle in USA. Left hand versus right hand.
DS: So those kind of metadata can already be identified by the devices which are attached to the product. Now, these diagnostic system can gather all this metadata already, or they already have it stored in their memory. Now, when that information is available, let’s say there is an error that happens. Now, the error, if that error is known, the device or this diagnostic device can identify that error code. But to show the troubleshooting steps to the user, it has to find out the latest information about it.
DS: Either you can store all the troubleshooting steps of all the error codes into the product memory, which will lead to higher cost of the device, which is associated to the product, it’ll require more memory and the content can go outdated. So people will have to upgrade their diagnostic system devices associated to the product. If you don’t do that, what can happen is the diagnostic system can gather all that metadata, send this request to a repository, which can take this metadata as an input and present the troubleshooting steps to the diagnostic system.
DS: And the diagnostic system can actually present the information which is more presentable or which is more understandable by the type of the user. So it can be, the engineer is accessing the information versus an end user is accessing the information. So in this case also, not only you can author how to troubleshoot the content, but you can also associate metadata, like what is the error code for particular troubleshooting information? Who are the audiences? And you can define those conditional attributes inside those troubleshooting steps.
DS: Like if an engineer is looking at it, you can talk more in technical language. Whereas if you’re looking at, if an end user is requesting it, you will have to give some infographics. So things like that will happen in this kind of system. Now, obviously I cannot bring in a vehicle in this video mode and show you how the car breaks and it looks for the troubleshooting steps. So what I’ve done here is, I’ve actually created another small interface which is like a diagnostic level. So there are some fields.
DS: So what we are saying is let’s say the diagnostic system understands the product group, whether it is personal care, manufacturing, aerospace. It identifies the country, and it can have more parameters. Or it can be some search terms based on which diagnostic system wants to find out the troubleshooting steps. But let’s say, I want to search for a car trouble. So when I look for car trouble, the diagnostic system already knows the error code. Let’s say the error code looks something like this car trouble 001.
DS: So when this system sends this request to the repository, now this is going to be the unique issue ID. When I search for this, the system should be able to return exactly one result, because this is a unique ID. Now, important thing here is that, generally the troubleshooting steps would be some steps within the documentation. And it would most probably be a task. So if I want to present this task as JSON, but I think the more important point here is whenever you’re presenting this to a diagnostic system, it should ideally be some interactive HTML.
DS: So if you look at this HTML, if I go to the next screen, it would be something like this. So people will have to say, “Okay, start the troubleshooting.” The car won’t start. “Okay. Turn the key.” So there could be some steps which can be authored by you in the system, and it is a task. And this is how a task can be presented. And you say, okay and the last steps is… oh, I have taken longer route though. So yeah. If it starts, it says, “Okay, have a safe trip after all this troubleshooting.”
DS: So this can be an interactive HTML way of presenting some document, if I look at the source of this content. So it is nothing, but it’s a simple task, which has some steps. It says, “Turn the key and listen to the sound.” And those were the steps that we are presenting. And primarily those alternate routes are defined by the choices that you are giving under the steps. So one way to look at this is HTML, an interactive HTML, but it could also be a tree. So maybe an engineer is there on site, and they just want to see the entire tree.
DS: So it could probably be something like this. It could be, turn the key to listen the sound and so on. They can look at the tree and then say, “Okay I’ve solved the problem for the customer. Close this.” And there can be other examples. Let’s say I think this example, I showed to Sarah before the session and it was funny that, if you have a baby trouble, how would you handle that? So it would be something like your baby is impossible, how do you manage? Do you have to change the diapers? No. Things like that. So it could be personal care, it could be manufacturing, it could be other areas, but the idea is that, how do you present this information over API?
DS: You have authored it once, you know that all this content is standalone. The troubleshooting information is all standalone. There are no dependencies on other topics, for example, you can simply present this in more innovative ways over API so that your diagnostic systems can understand, or the audience who are accessing this content over APIs can easily understand that. So those are a few examples. Then if it is going to be simple XML, it can also be simple XML as well, which could be directly the XML that you have authored, the entire task that you have authored in structured content.
DS: So those can be different formats that you can use to present your diagnostic information. Now primarily I just spoke about what happens when you move this kind of information to CaaS, you don’t have to push all the content through the machinery into the device. You don’t have to worry about the storage capacity of the device, which is associated with the product. You don’t have to worry about the updates. You don’t have to worry about keeping all the content in all languages into that device, which will lead to the storage capacity issues as well.
DS: So all this can be achieved through CaaS, because wherever the device or wherever the product is used in the context of that, the diagnostic device associated with product can send a request over API through the repository and get the desired information. Which is less complex, gives more relevant content and more fresh content. So I think I’ll switch this back to Sarah to speak more or summarize the concept again.
SO: Thanks Divraj. I love the diagnostic example. We have seen this and we’ve seen the storage issues. You do of course, have to have the machine itself with an internet, or at least a repository connection, which can be a challenge. Just a couple of key things here. One is that, when you start talking about Content as a Service, what you’re actually doing is decoupling the content from the delivery layer. And although we’ve been talking about separation of content and formatting for a really long time, typically, we do still wrap those together before making the content available to the end user. And that changes here.
SO: So you have this middleware layer, that’s just the content, which is fine. And then one other kind of, I guess, side note that goes with this, Content as a Service makes it potentially possible to solve some of our siloing issues and deliver a unified content experience. So what I mean by that is, let’s say that you have a PLM a product lifecycle management system, which contains your product data, the height and width and weight and various kinds of characteristics of your product. And what you actually want to do is give people a product description, which lives in your content, but also all these specs, which live in your PLM.
SO: Well, you could write connectors or create connectors to those two separate databases and then unify the content for presentation at the point of request. We have been trying to figure out, how do we unify content when you have multiple sources, multiple silos, and don’t necessarily have the option of, for example subsuming all the product data into the content layer? And so I think this gives us one more tool or one more way to potentially combine and integrate those things as we move towards some sort of a unified content presentation.
SO: Yeah. So, Divraj did a great job of talking through all of these issues, but basically, I would not suggest that CaaS is for everybody. But I would say that these are some of the things that it opens up for you. So if these are issues that you’re facing, then CaaS is probably something to take a look at. So do you need to give your consumers more control over their content? A different way of asking that is, do you have so many variants and so many conditionals in your content that it is practically as a practical matter, impossible to deliver all those variants, because there are just too many?
SO: Would it be easier to let people tick off a couple of choices and then get specifically what they need. Content on demand is a big concern and a big consideration. I just mentioned integration with other data sources. Divraj gave you a great example of personalization. If you, as the content consumer are logged into the system, then we know some things about you. We know who you are. We know maybe what products you’ve bought or licensed. If we’re dealing with hardware and you’re a service tech, we probably know some things about the machines that you’re servicing, that your organization has purchased.
SO: So we can personalize the content to your requirements and your needs. The regional issues would be interesting. Or perhaps you have a preferred language for the content that you want, that differs from the locale. So perhaps you work in a factory in Germany, but your native language is something else, is French or Spanish. So you might want to see those operating instructions in your preferred language, not in the language of the place that you currently are.
SO: And finally, you can decouple again. Decouple the content from the delivery and give yourself some more additional flexibility there. So these are kind of the things I see as possibilities for CaaS. And I’m hoping that that gives you some ideas for where you are with this. I’m going to turn it back over to Elizabeth. We are so very out of time. We see it right into the end there. But we do have contact information here for the two of us. And I think if you would like to reach out to us in that way, we will be more than happy to try and answer your questions.
EP: Yes. I don’t want to keep anybody since we are over time. So if you do have any questions, please contact Divraj or Sarah at the emails here, you can also drop your questions into the Q&A panel and your email, and I can have them reach out to you. But with that, we are going to go ahead and wrap up. So thank you so much, Sarah and Divraj. That was a great presentation.
SO: Thank you. And thank you Divraj.
DS: Thank you.
EP: And thank you all for attending The Content Strategy Experts webcast, follow us on Twitter at Scriptorium for upcoming events. And I believe the next event that we will be at is LavaCon. So we hope to see you there virtually.