Data and Content Orchestration Across All Channels

Sam Brace: [00:00:00] Welcome to MX Matters. This is where we talk about the trends that are affecting the visual economy. That could be tied to e-commerce, that could be tied to website optimization, basically anything that is affecting the way that images, videos, and digital media are being used within many different channels in many different spaces.

My name is Sam Brace and I am the Senior Director of Customer Education and Community at Cloudinary. And joining me for this episode, and luckily for many episodes of MX Matters, is Maribel, who is our technology partner manager. Maribel, it’s great to have you here for this conversation.

Maribel Mullins: Thank you, Sam. Thanks for inviting me.

Sam Brace: For this conversation, we are joined with Sana, who is the CEO and co-founder of Conscia. And there’s a trend that we’ve started to see emerging in the overall digital marketing, digital outreach space that’s called data and content orchestration. [00:01:00] And if you think about an orchestra, it’s where you have violins and you have cellos, and you have all these amazing instruments.

They’re all coming together to make this beautiful sound. And I think that’s what data and content orchestration ultimately is. But instead of music, we’re now talking about digital content and digital data that is there to be able to come up with some way to orchestrate it. But we have heard this term floating around through various conversations.

It’s even mentioned at previous MX Matters podcasts. So now we wanna bring on the expert as someone that really understands what’s happening with this overall space since her company, Conscia, is directly tied to it. So with that said, Sana, welcome to the program.

Sana Remekie: Hi Sam. Hi Maribel. Thank you so much for having me here.

Sam Brace: Let’s just dive straight into it. What is data and content orchestration?

Sana Remekie: So I think Sam, you actually did a pretty good job defining what orchestration actually is in the context of music. And you’re absolutely correct. You’re really applying that same [00:02:00] concept of bringing different types of music and different types of instruments together in an orchestra, but applying that to data and content.

So when you’re thinking about large enterprises, let’s talk about enterprises upward of 1 billion in revenue. You are talking about enterprises where the data and the content is sitting in a bunch of different systems. They’re sitting in a lot of different silos. And in order to create digital experiences, what you need to be able to do is connect the dots between the data and the content from a lot of different systems so that you can build compelling, unified experiences for your customer.

Now, just to clarify, there is a slight difference between data and content. The way we speak about data and content, they’re two different things. Content is essentially anything that you are displaying to the customer or presenting to the customer. [00:03:00] Not just visual content, but any kind of content.

Data, on the other hand, is anything that you are capturing about the customer. So in order to create experiences, you have to be able to connect the customer data to the content in the right context at the right time, so that what you’re presenting to the customer is relevant, based on who they are, based on what their real time intent may be.

Secondly, the other part of the term, which is orchestration. There’s a lot of confusion between orchestration and integration. When we’re talking about integration, what we’re really talking about is just two systems connected to each other.

In today’s world, in a composable world, or a headless world, I should say, two systems can be connected to each other via APIs, or they may be connected to each other based on some sort of event triggers. That is an integration between two [00:04:00] systems. When we speak about orchestration, there’s an element that is essential to it, which is there’s an involvement of a person, a human, or some sort of decisioning that needs to be considered in order for two systems to be connected to each other.

So a human being essentially in our case, is going in and deciding how to use customer data in a very specific context to present the content to the customer. So somebody needs to be orchestrating all of this. It’s not being orchestrated on its own. There’s a decisioning element, there’s a human element to all of this, which makes integration and orchestration very different.

Sam Brace: That’s actually very, very helpful. Going back to that music analogy that I gave at the very beginning. Think about the person that is doing the overall content orchestration. They’re like the maestro. They’re the ones that’s putting everything together, [00:05:00] helping to know when the violins come in and the cellos come out.

So it seems to be the same way. So you wanna have someone that’s at the helm of the overall orchestration efforts when it comes to data and content. It’s not where we have systems that are just automating this overall effort together.

Sana Remekie: That’s exactly it.

It’s not happening on its own. Somebody’s doing it and you need to empower the right people to do it as well. So you need some sort of tooling and some processes in place where empowering the decision makers, the subject matter experts, and the business user essentially to present the right content to the customer at the right time. And that is orchestration.

Sam Brace: Now I know when we are talking about this overall concept of data orchestration, content orchestration, I like the differentiator that you shared there about why one is separated from the other. It’s data orchestration and content orchestration cause they’re two different things.

But I’ve also heard conversations about digital experience orchestration [00:06:00] and it doesn’t seem as necessarily as finite as data and content of that area, but maybe it is. What’s the difference maybe between digital experience orchestration and data and content orchestration?

Sana Remekie: So orchestration is just about giving the control to somebody to do something with data and content.

When we talk about digital experience orchestration, we’re contextualizing that conversation. What we’re saying is that we need to orchestrate this data and content in the right context in order to build digital experiences. So that is where the differentiator is. It’s basically contextualizing data and content orchestration for the purpose of building digital experiences.

Data and content could be orchestrated for other reasons as well. Sometimes you want to orchestrate data and content simply to keep two different systems in sync with each other for an operational reason, but that may not have anything to do with building a [00:07:00] digital experience. When we talk about digital experience orchestration, what we’re saying is we’re giving that control to the marketer, to the business, to connect the dots between the data and the content in the right context for the purpose of building an experience that makes sense for the customer.

Sam Brace: What would be an example of a digital experience? Maybe I’m booking travel online. Would that be considered a digital experience? Or maybe I’m purchasing new shoes online. Is there any areas that act as qualifiers of when something would be considered a digital experience for the orchestration?

Sana Remekie: Yeah, so digital experience can happen on various touchpoints throughout the customer journey, or it may not even be a customer at all. It could just be a user, like an employee of the company. So anytime a customer or a user is interacting with some digital technology, some digital interface to consume information, to make decisions about something such as a purchase, that is all types of digital experiences that we’re talking about. [00:08:00] That could be through the web interface. It could be the mobile interface, it could be the kiosk screen within a store, or a branch of a bank. So all of those are examples of digital experiences.

Maribel Mullins: And you mentioned orchestration, you were talking about how that’s the piece where you’re having people make that human decision of whether to bring the data or the content up. So do you feel that most people are struggling with understanding that? Maybe they don’t wanna automate that process? Or are you quick to see that people want to automate the process for orchestration?

Sana Remekie: No, that’s a really good question. So, I’m gonna go back to the talk about headless and composable and how that ecosystem lends itself so nicely to this new concept of digital experience orchestration.

So when we moved from the traditional DXP world where all of the data and all of the [00:09:00] content was sitting inside this one system, we took for granted that the marketer is gonna decide how experiences are gonna be presented to the customer. They would go log into this one system, one screen, and they would essentially orchestrate the experience within the walls of that DXP, but that was very much limited to the web experience for the most part. Sometimes they would be orchestrating the experience for mobile as well, but only when mobile was built based on some sort of web view and not a native mobile app. So the reason why we moved into headless and composable was because we wanted to provide that flexibility to build all types of experiences on all types of screens to our customer.

Now, in that transition from DXP to headless and composable, what ended up happening is that your data and content essentially became [00:10:00] siloed and your business user no longer had the choice or the empowerment to really present a certain type of experience to a customer at an operational level.

So on a day-to-day basis, they couldn’t just go into one screen and say, Hey, I want today for this campaign and for this type of person, I wanna show them this type of content. What instead they had to do was go talk to the developer, the front end developer, essentially, who is responsible for building that experience for that specific touchpoint, and let them know what their requirements were on a day-to-day basis.

And then they would go and hard code that experience for the customer. Now you can just imagine how many problems there are with that. So the discipline of digital experience orchestration is essentially rising because the business users and marketers are getting frustrated that [00:11:00] they’re not able to orchestrate these experiences on their own.

They need to be autonomously orchestrating these experiences at an operational level. So this is giving back the control to the right person, the person who understands the customer, who understands the content that is there to be presented to the customer. And they can do that in the moment of need, and they can do it on an ongoing basis instead of having that reliance on developer. Going back to the conversation of integration, what the developer is essentially doing is integration. They are pre-specifying all of the logic that needs to be put in place to connect this dot to that dot, and the experience becomes very static.

By empowering marketers to do this and business users to do this, you are giving them the agility, the ability to do this on their own and keep modifying the experience as they wish based on[00:12:00] the campaign that may be in place today or the type of person that’s coming in, or what their context may be.

Sam Brace: Now thinking about this, it seems a lot like ways that you would wanna connect the dots. I have this data about this user, this customer. I have this content that may align to that. That feels to me like a lot of the conversations that I’ve had about content personalization. Is that part of this effort or is there distinct differences between a content personalization effort and then what would be happening with orchestration?

Sana Remekie: So the way I see it is that content personalization is a use case of orchestration. So it’s a subset of orchestration, but you could theoretically have other use cases that fall into digital experience orchestration as well. Personalization definitely is one of the big ones because you have CDPs like Segment for instance, that are holding [00:13:00] onto customer data and you have CMSs like Contentful that are holding onto content.

So in order to personalize the content that is sitting inside the CMS, you have to be able to activate the data that is sitting in the CDP at the right time. But again, personalization is a use case. Digital experience orchestration is more of that overall capability of showing the right thing to the right person at the right time. It could be based on locale, it could be based on geography, it could be based on device. It may not be specific to a person at all. It could just be a campaign that you are running. So what you’re really doing is managing who is seeing what, when and where, and not just constraint to the use case of personalization.

Maribel Mullins: Is experience orchestration the same thing as like an omnichannel experience? Because I feel like I hear people say that synonymously.

Sana Remekie: Yeah. A good experience orchestration platform [00:14:00] should allow you to build omnichannel experiences. A lot of times people confuse digital experience orchestration with something like digital experience composition.

When we’re talking about digital experience composition, we’re specifically talking about, at least at this day and age, we’re specifically talking about the digital experience on a web framework. A React framework, a Vue.js framework, a Next.js framework. So you’re talking about server side rendering and client side rendering, and all of those web related concepts.

Digital experience orchestration goes beyond just the web. It allows the marketer to control the entire customer journey and not just be limited to the web. It’s not about just a visual composition of the page. So the concept of page is not really there in digital experience orchestration.

It’s an experience that you are managing. And that experience could be on the screen, [00:15:00] it could be on a webpage, it could be on the kiosk, it could be anywhere. So digital experience orchestration has to be completely headless in order for that to happen. That means you have to interact with the DXO or digital experience orchestration platform through an API, and you have to be able to receive a structured response that can be presented on any screen using that API response.

That would, in my mind, be the primary difference. You’re controlling who sees what, but not necessarily how exactly the page is laid out or the web. You know, here’s the CSS for the title versus the description. That is the presentation, the styling of, and the layout information that digital experience composition tools are primarily responsible for owning.

Whereas with DXO, it’s more about what you’re showing to the customer, not exactly how it looks and how it feels.

Sam Brace: One thing that [00:16:00] I have a question about, cause we’ve touched upon it a few times that we’ve been talking so far, about headless and composable architecture. And we’ve had many episodes about this, so we don’t need to dive into what it is and all the differences.

What I wonder is like some of the things that are tied to this overall orchestration effort, does it require it to be tied to a headless and composable stack, or could it be where if I have legacy systems, like, and I’m not saying these are exactly legacy, but let’s say like I have a Salesforce instance and I have a WordPress site, and none of those are necessarily headless or composable by design, but could I still do content orchestration linking those types of systems together? Or does it need to be something where truly the front end has decoupled from the back end, like the way, like a typical composable architecture stack would be?

Sana Remekie: That is a really, really good question and it’s an area of great debate I would say as well, in terms of how to handle legacy systems within a composable stack. Do you need to completely make your stack a [00:17:00] MACH or composable stack, or could part of that stack still be legacy?

Like how best to make legacy systems play nice with the overall composable ecosystem. So I am a true believer that organizations aren’t ready to fully move off of legacy systems. It’s not an overnight shift. A lot of times organizations take on an initiative to build or implement a composable technology simply for a brand new experience that they wanna roll out rather than change everything about their organization.

A DXO should be able to connect to a legacy system. Now, I say that with some caveats. One is the legacy system needs to be able to have some API that delivers some sort of structured response. That I would say is a requirement. Some legacy systems don’t have that in place at [00:18:00] all.

So what we’re seeing pop up within this space is this ability or this idea of encapsulating these legacy systems inside some sort of a caching layer or a modernization layer that has APIs that expose the rich data that is sitting in these systems without actually replacing these systems. So there are a few options within the ecosystem that provide that type of flexibility. If I were to name a few of them, for example, Netlify just came up with Valhalla, which is a content hub that is able to take the data from these older systems and expose it. Conscia has its own digital experience graph, which also syncs the data out of these systems and makes it available to downstream experiences as API responses essentially.

So it’s the same kind of idea. You’re encapsulating your legacy system and you’re not [00:19:00] replacing it. You’re just modernizing your existing stack.

Sam Brace: And I love the fact that like you and as well as Netlify, they’re addressing this because I think you’re right. We can’t fully abandon all of the systems that we have put into place and say, we’re just going headless today, because it’s just, no, that’s just not possible. So I think it’s where being able to come up with intermediary tools to say, we can make this possible.

Maribel Mullins: Yeah. And you pointed out something great in the sense of you need to be sure that the legacy systems have APIs exposed, but what other things, if somebody were to take this on that they should consider? Just because it seems like they’re doing not an overhaul, but like a restructuring of like how they’re presenting things.

Who should be the stakeholders in this as well as what else should they consider when trying to start a whole experience orchestration initiative?

Sana Remekie: There are a bunch of considerations. I think overall, in order to just implement composable and headless technologies and going down that path of [00:20:00] composability, it requires a certain level of digital maturity within the organization. What we see a lot of times is that organizations are very siloed, where each department starts their own initiative to build out a new site, for example. Like a large organization may have 200 different sites each built on different backend systems and different technologies altogether.

So when you’re moving down the path of composability, and then in essence, digital experience orchestration, there needs to be some higher level governance over the initiative. There needs to be this idea of reuse. You don’t want to keep reinventing the same wheel over and over again because what something like a DXO allows you to do is to do exactly that. It’s able to source content from all these different systems. It’s able to reuse and redeploy that content in whatever channel or whatever touchpoint. But that type of an [00:21:00] initiative requires leadership to understand that this is a new way. We’re gonna do things right for the first time, and it may not be an overhaul initially, but there has to be that culture change, a change in direction essentially that comes from the very top. And once that decision is made, it doesn’t mean that overnight you’re gonna have all of those systems, those 200 websites, all of a sudden totally composable. That’s not gonna happen.

But what can happen is that slowly one website at a time, or maybe you start with a new website that you’re about to build or a new digital touchpoint you’re about to build, you start with that to make that composable, and then others get inspired by what you’ve done, and they want to start to take advantage of the foundation that you’ve really laid out.

And so piece by piece, you are impacting that change across or affecting that change, I guess I should say, [00:22:00] across the enterprise.

Sam Brace: You’re touching upon something that I’ve definitely noticed as a trend is you’re talking about siloing and it continues to happen across the enterprise.

And frankly, with a lot of organizations where you have a CMS, you might have multiple CMSs, you have a PIM system, you have a DAM system, you have CRM systems with many different departments that are putting in various types of data. Why is this happening? I mean, obviously what Conscia is doing is it’s addressing the situations there…

Sana Remekie: You know, it’s funny, I’ve actually spent a lot of time thinking this through, like what are all of the different factors and considerations within the organization that make this happen? So one of them could be, for some organizations, it’s just the tools that they’re used to.

As the organization grows, as the number of departments increase, the people that you bring in have some sort of affinity to certain technologies, and they have certain relationships with certain vendors. So they say, all right, I’m just about to [00:23:00] build something new here. Let me show everybody that I’m gonna use this technology that they’ve never used before, which I have used before, and how that’s gonna help them achieve things faster and it’s cheaper and it’s better, and all those types of things, right? They have enough power to essentially convince the leadership that they should give this new tool a try, and that happens in large organizations, they have the money. So that’s one thing. So it’s money is not really the gating factor.

They just want speed, right? And so if you want speed, then you gotta use tools that you’re comfortable with. And so that would become the argument from a leadership standpoint that okay, let’s just use what makes sense for you.

The second thing is, as brands buy out other brands, so, these brands already are using certain technologies.

And you can’t, again, for the same reason, you can’t go from monolith [00:24:00] or legacy to composable all of a sudden, even if the brand that is buying out these other brands, even if they wanted to enforce some sort of a standard way of using technology that takes many years and it causes a lot of disruption.

So they let these smaller brands that they’re buying just do what they were always doing and act autonomously and not be consistent with the mothership all the time as well.

So you get the gist of where I’m going with this. It’s more about the people, the process and the change management that is so difficult within these larger organizations.

It’s much harder to turn a large ship. We all know that if it’s a small company, 500 million or less, you know, few websites, you can do a quick overhaul maybe within a year you are able to do that, but not with the larger corporations.

Sam Brace: One thing that you’re touching on that I hadn’t thought about, but I could see like almost being like a cycle that would happen is, let’s say you have a [00:25:00] company and they go through a process of saying, okay, we’re gonna go through data orchestration, we’re gonna do the DXO the way that we want it done, and then they buy a new company or they do a merger and acquisition, and then it’s almost like we’re constantly stepping backwards cuz they may be on monolith systems.

And so we’re constantly having to go backwards to bring them back up to what, as you said, the mothership has. So, right. There’s no way to ever be fully headless if you’re continuing growth, if when you’re thinking of it from an M&A perspective.

Sana Remekie: Yeah, it’s like two steps forward and one step back, in a sense. But I think that having a proper process in place to standardize the way in which experiences are built gives you that platform for future innovation. So if you do need to incorporate other brands into this new way of working, what the DXO essentially provides is an agile way to do that transformation on an ongoing basis [00:26:00] because it can work with legacy systems, it can work with headless systems as well. And that orchestration layer in the middle essentially can actually standardize the responses that are coming from backend systems. Say you have a CMS like Contentful in one place, and Sanity over here and Storyblok over here.

The DXO is able to take the data that comes from each of these systems and standardize it to an output that your front end needs or as an organization that you decide should be your standard API response so that anytime you build any new system or any new digital experience, doesn’t matter what your backend system is.

In fact, it could be multiple until you decide to standardize for other reasons. Like the other reasons could be that you wanna save money on your contracts. The other reason could be you wanna train the staff on all of the same tools. But from a front end [00:27:00] standpoint, if we could essentially standardize what comes out from the DXO, you don’t have to change the front end ever, regardless of what the back end may be.

Sam Brace: I think it’s kind of neat because like one thing that we say a lot of Cloudinary is that we want Cloudinary accounts to be ultimately the single source of truth for where all of your images, videos, digital assets should be. So that way if you decide to link it to a CMS, that means the whole team has access to this, and then it’s just with the web output or the mobile output.

Sana Remekie: Right.

Sam Brace: And it sounds like what we’re saying is that a DXO effort should be the single source of truth for all data and content because they may live in so many different places across the enterprise, whether it’s legacy or whether it’s headless, they’re just in many places. So it’s now, as a marketer, as an orchestrator, I can go to one space and know where everything happens to be.

Sana Remekie: Yeah. Because a DXO essentially connects to all of your backend systems, [00:28:00] right? And it connects to them in a very standard way. So you’re not coupling the DXO to the front end to the backend. It’s a very flexible way, a very decoupled way of connecting to these backend systems.

It’s through configuration. No code whatsoever should be allowed in that layer. It has to be a zero code layer, because as soon as you add custom code in that integration process with those backend systems, what you’re essentially doing is you’re creating a coupled system. And so we are very big proponents of staying away from any kind of custom code to build those types of relationships with backend systems as well.

Maribel Mullins: And along those lines, like I have been seeing more CMSs like trying to go into this orchestration capability. And I’m not sure if it’s the same in the sense that, like you hear that they’re trying to do the federation and as you mentioned, they’re trying to build as many integrations as they can to be able to pull content and keep them as the main content management [00:29:00] system and make it sticky.

And so I guess like how does that differ from what you’re trying to achieve?

Sana Remekie: This is such a controversial topic and I love it. This kind of goes back to what I said about what’s the difference between data and content orchestration versus experience orchestration. So copying and pasting data from one system to another, that is syncing of two different systems, which a lot of organizations that I’m actually speaking to right now are doing, cuz they didn’t have a way to dynamically assemble the content from two different systems together.

So for example, a CMS may pull in information from a product information management system. That’s because the content managers want to see the price and the inventory and this and that so that they can plug that data into a promotion for the product that they’re building within the CMS. It is orchestration [00:30:00] to some degree cuz you’re syncing the data between these systems.

But it also creates a problem of duplicating content over and over again in multiple systems. Cuz if you look around the organization, if you look at the example of an organization using Strapi as a CMS in one place, and Contentful as a CMS in another place. Essentially, what you’re gonna do then with that PIM to CMS connection, is you’re gonna duplicate that to all of those backend CMSs.

Instead, what we’re suggesting is you don’t do that and you let all of that data and content come together from the PIM and the CMS or wherever else dynamically through dynamic rules. You say that I’m gonna take the pricing information from the product and I’m gonna plug it into this price tag on the CMS side, but I’m gonna do it in the DXO [00:31:00] and not have to duplicate that data as well.

It’s absolutely happening right now. Most organizations in fact, are doing that today, and most CMSs are extending their capability to orchestrate, quote unquote orchestrate the data from other systems into their systems.

Because everybody wants to be the center. Everyone. PIMs wanna be the center. E-commerce systems wanna be the center. CMSs wanna be the center. The reality is, in a composable world, there is no center. There’s a lot of data sources. You shouldn’t think about it as a center. You have to think of it as a way to connect all of these different systems together.

And they’re not all converging to the same point. The system that connects all the dots between systems should also be going in between two different platforms and not just talking to the front end from a central point as well. So I think this is definitely an ongoing conversation, and there are [00:32:00] some use cases where this concept of the knowledge graph plays out, where you may have data sitting in 15 different databases and backend systems behind the scenes, and there’s no visibility from a business standpoint into what each of these different systems contain.

And in order to build experiences, you have to connect the data in a graph before you go and build out the front end experience.

In my opinion, anytime the data can be accessed in real time from another system using headless APIs, you shouldn’t be copying and pasting it anywhere. You should just get it from where it is.

A perfect example actually is Cloudinary connection into digital experience orchestration. The way we built the connector to Cloudinary was that we’re not copying the videos and images out of Cloudinary and putting them into some other repository [00:33:00] before activating those in real time.

Instead, what we’re doing is we’re connecting to your APIs in real time and giving marketing the tools to select what video, what image should be displayed to the customer in a specific context, but also how do you want to transform this image in real time. Conscia is not able to transform images. We are not able to go and overlay the video with some text or zoom into a specific part of the image, and we shouldn’t be able to do that. Cloudinary is good at that. So why would we pull the content out and copy and paste that content into another repository and lose all of that powerful capability that Cloudinary has to offer?

It just doesn’t make any sense to me to do that. When you have the APIs to deliver that content and deliver it in a dynamic [00:34:00] and transformative way, you should not be intercepting that in any way. You should leverage it to its full potential.

Maribel Mullins: Yeah. I love that because I feel like that in itself just made everything click, that everything’s in real time, and it’s not, as you mentioned, being copied over.

Sam Brace: One thing that I really have loved about the conversations about headless and composable architecture in general is it’s very humble in some ways…

Sana Remekie: mm-hmm.

Sam Brace: …where I’ve noticed a lot of cases where previous software conversations, let’s say 10, 15, 20 years ago, where they’re saying, we have to build it all ourselves cuz we’re the only ones that can know how to do it.

And it’s kind of saying, no, we recognize that there are vendors, there are people that are producing software that may know more about this than us, but we can work together through integrations and orchestration to make it all possible. So it’s not the chest beating where we’re saying, if we don’t do it, nobody else can.

It’s more of saying, yeah, let’s make it all possible because [00:35:00] we respect and like what you’re doing and how can we be like-minded in that way.

Sana Remekie: Exactly. I think that’s a perfect way of putting it, like humility within the ecosystem. I think that that’s the only way that it can work. In fact, and I see sometimes within the headless and composable players where people are trying to do too much, they are trying to expand to increase their pie.

And I don’t think that actually helps them or anybody else in the long term. I think it’s very important for each company to know what is their core value proposition? What is the one thing that they can do better than anyone else? Right? For Conscia, it’s orchestration. We know that this is something that we’re good at.

And we’re gonna keep making that capability stronger and stronger and provide more and more tooling to the business and the developers to really have everything that they need [00:36:00] to do orchestration. But if we start to say, Hey, you know what? We’re gonna start transforming images.

Forget about getting it from Cloudinary like we can. Why can’t we just get it from a repository and transform it ourselves in real time? There’s CDNs out there that you can put images on top of, but that’s silly. Now you’re expanding to something that is not what you know about. You have no clue how these images and transformations work.

And you are gonna go too broad, but not deep enough in any one single thing, and that’s what happened with the DXPs, right? They started off as a CMS. Then they started buying all these different tools like marketing automation and analytics and CDP and digital asset management and e-commerce and PIM. And then before you know it, they weren’t good for anybody. It’s like an average that doesn’t work for anyone.

What’s important is for each player within the [00:37:00] ecosystem to know who they are at the core and become better at that than anybody else. That’s the way to compete and not try to cannibalize the entire ecosystem by becoming everybody else, or be everything to everybody.

Maribel Mullins: How do you determine the ROI on this experience? And I also see where you take one step back and then two steps forward and so forth where you’re having to rebuild things. And then not just that, like I could see developers saying like, you know what, let’s just take a copy of that and do this our own thing, and I can see the marketing struggling and like, no, we wanna do our own thing.

Sana Remekie: So once the experience is out there, regardless of whether you built it as a monolithic application or a composable application, you would measure the ROI based on conversions or the average order value and those types of things. But the thing is if it took you a year to get there versus two months to get [00:38:00] there, that’s the differentiator. That’s the missed opportunity. So I think that when we make the business case for composable, it’s about agility, it’s about flexibility, it’s about speed to market, and it’s about the control that the marketing needs over the experience that they’re building, because every missed opportunity is costing them revenue that they could have had.

So it’s not really the individual metrics on, okay, I’ve now orchestrated my content and now the content sitting in the right place. So is this the right thing for the customer? And you’ll know that if the right number of people are clicking on it, assuming that you can achieve the same outcome from an experience standpoint eventually.

All things being equal, I think really the differentiating factor with going composable and doing things through orchestration instead of within silos or[00:39:00] by hard coding logic into the CMS or hard coding logic into any one specific front end, it’s really about how fast you can get there.

Does the marketer, if they wanna roll out a new campaign tomorrow, do they have to come talk to the developer to do it? And if they do, that means that they’re gonna take long or they have a backlog and they’re gonna take their sweet time. Now, what that means is that your competition could be doing what we’re suggesting here, and they would’ve rolled out that experience faster than you.

They would’ve responded to the market faster than you. And that’s where the loss is. So it’s more, I think the reason that organizations should be thinking about this is not so much about the increase in revenue, but the fear of lost revenue, if they don’t go down that path.

Sam Brace: And that makes sense to me because it really ties back to the whole need for this, because if you don’t have all the data, you don’t have all the content, there’s no way you can make actionable decisions and be able to affect a lot [00:40:00] of things that we’re talking about that are tied to ROI, like revenue that is gained or lost.

So, it definitely is where because you have all of the data, all of the content, you can now decide how you want to do things with it…

Sana Remekie: Quickly.

Given enough time, resources, and money, anybody can do it. A DXP could do it too eventually by copying and pasting things into the dxp and creating custom integrations and plugins and millions of dollars in development time. You could do it. I think it’s all a matter of how fast you could roll something out.

Sam Brace: That’s a good point. That’s a really, really good point.

So let’s say I’m a CMO or a CTO, and I’m listening to this conversation that three of us are having, and I’m saying, oh, this sounds great. I would love to be able to start orchestrating certain things within my org.

What’s the first step they should take? I mean, obviously I could just say like, oh, well you should go talk to Conscia.

Sana Remekie: That would be the right thing to do. I’m just kidding.

Sam Brace: But from a [00:41:00] more agnostic standpoint, what would be a natural first step for you to say, you’ve made a decision that you want to try this, or you want to do something about this. What’s the first natural step to go forward with it?

Sana Remekie: I think that the most important thing is to do your research on what are the tools and capabilities that are out there, look at various vendors that are offering this type of capability. See what you need within the organization. Look around and see how big of a need is it really for you to do this. Are you mature enough to do this, first of all? I think that’s the audit that first needs to be done, and it’s that introspection and that reflection on your own company and your own capabilities. Do you have a team that is able to grasp what is going on here?

If you don’t, then the first step really is to start to advocate and evangelize that change that needs to be made [00:42:00] internally and start changing the mindset. And once that mindset is there, and that will only be there through education and evangelism, that means you’ve already spoken to all the leaders within the industry.

You now understand all the various perspectives of how you should move forward. Then the next step is to start to make the change one step at a time and not try to boil the ocean. Look at a new initiative that you are about to roll out, a brand new digital experience and what you were planning to do with it. Is that something that you could build your foundation upon potentially? So you need to start with some sort of POC and fail fast. You gotta try a few different vendors, see what’s working, see what’s not working. The whole point of composable is that you should be able to replace things faster than buying a monolith and locking yourself into a five year plan of a million [00:43:00] dollars each year. That wouldn’t be a good idea. So that in my mind would be the first few steps. I guess I took the liberty to go to the next couple of steps as well.

Sam Brace: I think it helps anybody when they’re seeing like, okay, this is a playbook. I can understand this. That’s the one reassuring thing that I would feel as if I was in a new org and we’re going down this path, is that others have done this. This isn’t like brand new, such bleeding edge territory that you’re the first one to make the jump.

It’s to say there’s others that are doing this and being successful with it. I mean, Conscia has customer bases that are doing this now…

Sana Remekie: That’s a really good point. So look at the customers that are doing this today and share the stories, share the concerns, and see if they can find themselves in an existing organization that has very similar challenges as they have.

I wouldn’t say that at this point that there is a playbook fully because it is still an emerging market. It’s still very new. [00:44:00] However, any organization that wants to leapfrog their competitor, a competition has to catch the wave early. If you wait till all your competitors are already doing it, then you are already way behind.

So you gotta try something new, because what’s happening right now is it’s not working. You’re not moving fast enough. So it doesn’t hurt to give something new a try that looks pretty promising, at least on the surface.

I’d be realistic about the expectations with the customer as well. There’s so many factors that could affect the initiative. Again, your own digital maturity, your ability to accept change. All those things could impact. And it may not even be the methodology that is failing. It could be the way you adopt it that fails and you’re just not ready, right?

But you have to take the first step if you’re gonna make any change and move in the right direction.

Sam Brace: Makes perfect sense. So, we have this great [00:45:00] conversation here and hopefully people agree that it’s great that are listening to us. But in terms of where people should be going for more information about this, so like when you were talking about go do your research, go figure out, is there any like go-to spaces that are really helpful in understanding this emerging space of the DXO, the understanding of orchestration in general?

Sana Remekie: It’s a little bit scattered, I would say, but there are definite industry leaders and thought leaders within the space already that you should be following. My go-to is LinkedIn and then from that I branch out to a lot of different hosting platforms where there’s articles and blog posts about orchestration generally, or digital experience composition.

And I think the other place is also the MACH Alliance, the website itself is also a host to a whole bunch of blog posts and articles, thought leadership articles about composability and [00:46:00] building MACH ecosystems generally as well.

So that would be, I think, another, uh, resource that people should definitely give it a try.

Sam Brace: So if you’ve enjoyed this conversation, and as I said earlier, hopefully you have, but that means take the time to check out previous episodes and future episodes wherever you’re listening to this podcast, we’re gonna be in that location, but also many that includes Apple Podcast, Google Podcast, Spotify.

We put content up on YouTube, even our own Cloudinary Academy. So make sure you’re taking the time to check out all of the latest and greatest conversations that we’re having with thought leaders like Sana and others on future MX Matters episodes. And of course, if you had a good experience, like and subscribe.

It helps to know when the latest things do come out from us. On behalf of everybody at Cloudinary, thank you for taking the time to be part of this episode. And we hope to see you understanding the trends that are affecting the visual economy in future episodes. Take care.[00:47:00]