Data orchestration in the composable stack – with Sana Remekie of Conscia

Data orchestration is a growing priority for enterprise brands, as they seek to gain greater visibility and control of data across connected systems.

Leading the charge in this space is Sana Remekie, co-founder of Conscia, a composable data orchestration solution which works for enterprise brands. Sana joined us on this podcast episode alongside Conscia’s implementation partner Orium, with CEO Jason Cottrell returning for his second episode of Martalks.

Read the full article based on this conversation, here.

Rosenstein Group: martech & ecommerce executive search

Rosenstein Group is the only martech-specialist exectutive search firm. For over 20 years, we've been matching leadership talent in sales, marketing and customer success to pioneering startups in ecommerce, supply chain and sales enablement, and for digital agencies.

Our experience with recruiting e-commerce technology leaders for companies like SAP Hybris and Demandware has established us as an authoritative and trusted liaison for startups seeking their first sales leader, and scale-ups on their way to IPO.

Visit RosensteinGroup.com to find out more.

Transcript

Speaker 1 0:07

I'm your host here on my team today. Mark Talks is where we discuss contemporary issues in the e-commerce and Mark Tech Industries. Today we're joined by Sana Remekie, the founder of Conscious, a digital experience orchestration solution. And we're going to unpack that. And we're joined once again by Jason Cottrell. Jason, thanks for coming back. I was very fortunate a couple weeks ago to uh hold a webinar with three uh leaders of major retailers, uh Ulta Beauty, Serena and Lily, Toys of Us, uh discussing their journey to full composability. And uh it was a great uh webinar, and there's going to be links uh in this one connecting to that. But uh in the process of producing that, in the in the process of uh putting it together, I actually reached out to uh over a thousand chief digital officers, chief customer officers, chief technology officers from retailers that are not my clients. Uh they are they are your clients, but uh they connected and it was wonderful to hear from them and have them join and hopefully learn something from that. But one of the things that came very clear in our discussions was that the biggest challenge in going to full composable is mapping that data. And one of the real difficulties that the systems integrators have had is they haven't often uh had the sort of data architect that uh or the data, I would have to say, expertise to really make that transition. There's a few of you out there. Obviously, Orium is kind of in a class by itself. I mean, you got maybe two other companies out there that can that are that are in your peer group, but uh you you kind of help obviate that problem. So it was wonderful to have Sana join us because uh essentially the the the secret sauce of conscia is mapping. It's it's taking that problem right off of the uh table. So I guess uh we could start off with uh, you know, my first question is this this podcast has been mostly focused on buyers trying to do some composability, but on commerce, uh digital experience or similar solutions that weren't composable native. And more and more people are talking about composable. How is the market evolving in 2024? Uh, and we'll start with chasing.

Speaker 2 2:54

I'm gonna build off of the concept of composable native. I like that word. Um, you know, I think end of last year, early this year, it was very clear. Um, any firm, say kind of the 90% of the market that it was not composable native to begin with, uh, is now trying to add composable capability. I think it was on a webinar the other day, HCL and composable. Um uh and that's I think when you know it's gone to the mainstream. Um at some of the industry events so far this year, the terms pragmatic composable coming out, because it's just, hey, like, I don't want to do all of it with all the things. I just want enough for me, for my business, and that I can build on over time, right? And that that's and and I think that's a reasonable concept that's probably right for the majority of brands. Um what I think you do have to watch, and and you know, this is what you start to make sense of is okay, if you're using composed composable native solutions, you know, they've been building their roadmap around this for five or 10 years, and they're exceptionally robust in this use case. Uh I look at when it's um an add-on, composable is an add-on, or in some cases even worse, it's a retrofit. Um, you know, the the the product maybe wasn't built for APIs, wasn't built to be API controlled, wasn't built with the concept that other products are around it doing other things, then you know often we see that as one of the largest risk factors in moving to composable. And so we really try to guide our customers on hey, you could keep these two systems, but these ones probably are gonna underperform. Or if you keep them, you have to understand things aren't gonna take 10% longer, they'll take two to three times longer. And and that can risk a program. So you've got to set expectations around that. There's gotta be a really good reason why you would. Um, but everyone's trying to make sense of composable, what products can adapt to a composable world. Um uh and and ultimately I think that that's the right thing for the concept. Now it's how do you guide it? Uh, that's actually where where we do like uh working with Conscia because some of it as well is it's not just opening the APIs up, but sometimes the data model in a product, a legacy product or a composable, uh a non-composable native option. Um it's not just that you can't control parts of that product through API, but that the data model coming out of it is not optimized for use outside of the system. And so we start to look at at you know tools like a Concea where they can set in the middle and optimize that. And I'll say and I can speak to how they do that a little a little. I won't steal her thunder on that one, but but we really do start to see if you're if you're keeping non-composable native solutions in your stack, you should look very seriously at kind of an intermediary to improve performance and improve access to the data model.

Speaker 1 5:34

Yeah, we that that uh you bring up a point. One of the there they're obviously incomposable. There have been some failures, and the failures have been with uh that that lack of an intermediary layer uh essentially piloting the data to where it needs to go. But you know, what what are customers asking for in in plain language? And Sana, I think good time for you to pick it up here.

Speaker 5:59

So when we think about um composability, you know, you can't really just take different Lego pieces of the composable tech stack and just glue it together. Just because you glued four different composable pieces together doesn't actually make your stack composable. So that's one clarification that I think a lot of that one point that a lot of people don't understand to think that you could just build any tech stack by pulling on a bunch of different composable services. So uh when we think about orchestration, it's really uh creating an abstraction layer between all of the various back-end systems and all of the various front-end channels that you want to create so that you're not coupling any of those back-end systems like a commerce engine, like a CMS, a promotion engine, legacy systems, etc., with any one specific channel. You want swappability, you want compostability as much as you want composability. And when I say compostability, you want to be able to swap things in and out, right? Now, when a customer comes to us, that's not what they're asking. Okay, so they're not coming and saying, hey, I want to be able to start, you know, swap things in and out. There's really four different types of customers that come to us, right? So one is existing customers of all-in-one non-composable native solutions, such as Salesforce, SAP, Adobe, etc. Now they have a web channel that they've built on top of their existing solution with a presentation framework that came out of the box with those solutions, but now they're ready to, they've they've kind of outgrown it. They want to build features and functionality that would be very difficult to build on a pretty integrated, uh, you know, all in one suite that they bought. So they are starting to think, okay, how do I add more features? How do I add more flexibility into my platform? How do I even build new channels? Right. So I want to go beyond the web, I want to go beyond uh, you know, just what I have. I want to have a mobile um web, a mobile app, I want to have uh an experience on the kiosks within the store. So how am I gonna do that with this existing all-in-one suite that was really catered towards the web, right? So that's one thing. The next one is that they actually have some pretty um hardcore architects within the organization, in the engineering departments, and they're looking at all of these composable pieces that they want to bring together. They've bought into this concept of composability, they know that's the right way to go, but they're really worried that if I just tie everything together too closely again, am I gonna create another monolith once again? So there are folks out there, small number, I would say, mostly SI-led, I would say as well, who know that that's not, you know, that's not the right approach to just tie everything together too closely. Then there are others that are just worried about the time and cost of all of this. As you said, Daryl, the one of the biggest problems with building a composable uh tech stack is the amount of time and in uh and effort it takes to engineer that solution. You're essentially building a product, right? It's not again, it's not just about gluing things together, you gotta bring it together in a in the right way, and it takes time to do it the right way. So they're concerned about how do I reduce the time and effort and the total cost of ownership and the maintainability of the solution. So that's that's the third type. And then finally, they just wanna offer uh new channels. They have an architecture, it's working for their existing website, and uh, but it's they just don't know what they have to do to add on more channels. Are they gonna have to build brand new integrations with all of those back-end systems? They're starting to see the future that the writing on the wall that if I keep building like a back-end for front end, for instance, for each of my new channels, then am I gonna create fragmentation in my in the experience that the customer is gonna see as well. So they're coming at us with a whole like different set of problems. And the solution at the end of the day is what what that's why we built Conscia, is because we recognize that whether you're working with modern systems, uh API-first, composable native platforms, or you're working with legacy systems, our ICP is generally very large enterprises, so at least a billion in revenue or more. We're we're trying not to address the issues of the small more you know mid-sized market, it's more for the enterprise market, where they're they're living in a hybrid landscape, and they have all kinds of systems, data is everywhere, content is everywhere, they want to create multiple channels, multiple experiences. Now, how do we do it in the most effective, the most future-proof, the fastest, the cheapest way possible?

Speaker 1 10:46

This is about sharing data, but you know, Sana, uh, how would you describe the limitation of those applications that are not composable by design?

Speaker 10:54

A couple of big things. I think, Jason, you touched on one of them. So some of the APIs that were uh either built after the fact, so it was a bit of an afterthought in you know, trying to go composable because that's what the customer is asking. So let's add composability and headless capabilities to our solution, ended up in APIs that were not really meant to be called directly from the front end. There is too much work required by the front end to really consume those APIs. Like I'll give you an example. One of the all-in-one platforms uh that we're working with, when you look at trying to create a category navigation structure, right? So a practical example, you have to essentially make multiple calls to get the full tree back. You can't get that full tree in one call because the one call only gives you the current category and just its children. But in order to put a full navigation on your website, you need all of those and the the entire hierarchy. So in that scenario, uh the API is really an issue, but the way we solve that with an orchestration layer that sits on top of it is that the orchestration layer is making multiple calls to build that category navigation tree and then caching it dynamically. And that can be cached at a customer segment level. Maybe different customer segments need to see completely different category navigation. So that solves the problem of optimization, but also indirectly solves the problem of performance as well. Because if you can imagine if the front end had to do that work in real time to go build that category navigation structure, that's a lot of API calls going back and forth. You're doing API chaining and stitching of data and caching that, all of that stuff has to now happen somewhere else, and that's going to take time uh and the response times suffer.

Speaker 2 12:43

If I could elaborate on that a bit too, Sana, we we see customers where there's certain systems that we we keep in the mix. Maybe there's a reason why, maybe there's functionality, maybe it's just change management. Um, but you know, I can think of examples where you know everything else except one system is kind of a more modern, posable, API-oriented product. Um, but if you know one of your core systems of record is not, like I'm thinking of um a program that we we completed last year where the APIs would often take two, three seconds to respond. So now we can't use them in real time. Often there'd be limits on the number of calls coming in. So now we've got to have a middle layer to stitch it all together and then keep that in the cache. Resolve any issues with that across all the form factors we were bringing it out to. Um, sometimes we couldn't control things back in the core product. So we have to find workarounds or just accept there's no way to solve for the story, story customer. Now, in this case, you know, I think in that case, actually, the the product itself had some really industry-specific things that it probably was worth doing the workarounds, but it was a seven-figure differential compared to the the tooling that we would often work with composable native.

Speaker 13:51

Wow.

Speaker 2 13:52

To to do all of that extra abstract. Part of the problem was that the particular legacy system we were working with only had two or three customers using their APIs. The features were changing. They would change their implement. They we'd we'd use it, they'd say, Oh, you're right, maybe we should do it differently. And they'd they'd rework it. So then we'd have to go rework. It sounds like such a subtle thing. Oh, well, how different can APIs really be? And I'm there, they can be very, very different. Um, especially if you're using someone who's only has like less than a handful of customers truly using their product in a composable manner. You know, you you've got to be very careful with that. These things really do add up.

Speaker 14:30

We we often say that as well, that Consia acts as the middle layer or the brain. We we all also like to say the brain, that sounds a lot nicer of that composable stack. But one one of the things that we're also seeing and we're where we're helping a lot of our customers is not just the integration from the front end to the back ends, but the integration between systems as well. So one of the lay the recent customers that we actually just started working on uh four weeks ago, they have 26 different integrations that need to happen between um, so this is actually like commerce tools, Algolia, Content Stack, uh web service that does uh it's like an inventory web service, a pricing web service, etc. And what they need to do is to create, oh, and there's an ERP, of course there's always an ERP and a CRM. Um, so all this data from all these backend systems needs to be unified in some way before it is pushed out to other platforms that are gonna be consumer-facing, right? So, what we're doing is one of the modules of Consia here called the DXGraph, what it does is it allows you to sync your data through various methodologies, so batch exports, pub sub, so all those data providers are essentially writing the data to Cancia, and then we're pushing that data out to other systems on an ongoing basis. Like so, if a data record changes in the DXGraph, make an update to Alia. If a data record changes, make an update to Commerce tools. So this work we don't call that part orchestration, that's more integration, data integration effort. Typically, you end up using either ETL scripts or um you know uh tools like Mealsoft in large enterprise organizations to do this type of work. And it is I'm not like kidding, millions in effort and licenses to do that work. And when you start to think about a composable architecture beyond just all the various legacy systems that need to be all synced and and integrated, you add five or ten more systems with composable tech stack, now you've ballooned that problem completely out of proportion, and you can't use the traditional methods uh anymore um for integration. So we've uh with through our orchestration layer, that problem that typically would be solved between maybe nine to twelve months of development effort is now four to eight weeks of develop uh development effort. So which is and and one I would say one third to one-fourth of the cost of doing it the traditional way, um, as well. So that's what our organizations are looking to do that in this economy they wanna they wanna save money and they want to save time. They have they want to get ahead of their competition, they're not interested in year-long projects, and that's why also to Jason, Jason, and and to you, your point, um, Daryl, we can't boil the ocean, right? You gotta go one step at a time. You can't you can't expect people to platform. They are gonna have their existing systems to work with. We gotta be pragmatic. If we're gonna make composable win, we can't do re-platforms. You gotta chisel away at those back ends slowly and use the Strangler method uh to do so.

Speaker 2 17:51

It also reduces risk too. I mean, um, wherever we can find now, I always like to say, you know, if we talk to somebody who's gone down the composable route, one of the first questions out of my mouth, or two two first ones, how long ago did you start? Because your options to do this one year ago, three years ago, five years ago were very, very different. It was much harder each increment back. Even this year, it's way different than last January. That's right. And when you have a productized option, now at least like with the Kinsia, we know that integration's been done properly considered. We know what it can and can't do. We know it's probably been used by a couple customers, so you're not the first, which reduces not just time and cost, it reduces risk. I'm often looking at that as is wherever we can bring productized options in. Um uh like we're not in the interest of pipe banging. That's not the high value work that we can do. We we want to find any option we can to simplify the customer's path to compose them. And there's so many productized options now that just weren't there a year ago. The second question to go back a moment was which systems did you bring with you? Right? Because often when when we hear, hey, what did I love? And and you know, what was a challenge? What they love is in the new systems, and and what the challenge was is what they tried to bring with them. And so it if you're bringing legacy or non-composable native systems with you, productized options to bring them into a composable context, like I can see uh, that that helps at least it would alleviate my concern. It would be the first thing out of my mouth is okay, well, what are we putting in to help kind of surround that system? Ideally, that's productized, not custom.

Speaker 19:28

Definitely. And I'll I'll add something to what you just said, Jason, as well. So product is one thing, it's great, we love our product, the tooling's great. But at the end of the day, we're providing a framework and a platform to work with. It's a set of tools. You can completely use it in the wrong way and mess up your entire architecture as well, even with Consia in the middle. You can. If you really want to do it the wrong way, you still can do it the wrong way with Consia. So you need expertise. I think more and more as we move from the single sort of like all-in-one suites to the composable stack, um, the uh the role of the SIs, the true composable SIs like Orium, I think become so much more important because like something like we said earlier, which is you're building a product. You essentially are building a product. So if you think you can just build a product all by yourself without really having any expertise around how to connect all those pieces the right way, you're gonna definitely fail. You know, no matter what product you have or what piece of the puzzle you all you buy. You can buy commerce tools on its own, Agolia on its own, Craftstack on its own, consia on its own, right? But if you don't know how to put it all together and where you should actually use what product um and how they should be integrated, um you can't do it. Like it's it's going to fail and it's gonna take forever, and you're gonna redo a bunch of work um, you know, months from now. And those are the kind of implementations that actually end up failing where the customer doesn't know what they're doing or the SI doesn't know what they're doing. Um, you know, I've seen a lot of those very sad cases, and they make composable look bad.

Speaker 2 21:06

If I could think of, because I think we're all worried about making sure that everything things go smoothly if a customer, if this is the right path for a customer. I would almost think of two buckets there. Um there's, hey, I already am doing composable, whether I'm calling that that or not, right? Yeah. I've got separate search, CMS, front end, pim, OMS, POS. I've got all that separate anyways. I find that the majority of the market now, though, they're coming from something that was an all-in-one. They were used to an all-in-one, and maybe they've added one or two things around it. And that felt kind of painful. Often those are the customers we're hearing using the word pragmatic composable. What I think we're finding is different in our approach there. We're not starting with a blank slate with those customers. Most of the composed, either, either some of the uh some vendors have added enough kind of composable capability, and it's not all, but there's a couple where you know what, you can do a lot of what you need to do now. If it, if you just need to do X, Y, and Z, sure, fine. And then you'll hit the wall, but you can do that. Um or you can now go get a big commerce of commerce tools and and you can essentially spin up a full working commerce site. Start with that. And then let's figure out how we adapt and bring in. But there you can take a much more pragmatic approach, but with something that's composable native. But you can spin it up out of the box and cover a default commerce scenario. Now our expertise is less about the stitching and the build from scratch, because you don't have to do that. More around, man, let's just plug in these two or three systems well for you. And you know, we know what they can and can't do, and we'll guide you there. But but it's that pragmatic composable concept. And that's different this year. That didn't exist a year ago.

Speaker 22:41

Yeah, and and and I'm seeing exactly the same thing. And we actually recently, and I know that we were going to talk about that later anyway, but recently we partnered with Salesforce for that pragmatic or what they call hybrid composable solutions, right? So they have uh various, like thousands of customers actually on Site Genesis version of Salesforce today. And a lot of those customers are outgrowing that version of Salesforce, right? So they want to go headless because they're thinking if we go headless, we can now start to take advantage of you know just better front ends, better user experience. We can uh venture out to build more channels, um, etc., that are not currently possible on Site Genesis. And and Salesforce itself is telling their customers to either go to the next version of Salesforce, which is SFRA, or your other option is composable, Salesforce Composable, which is now using the APIs under the hood that SiteGen was also built on top of. However, those APIs were not built for a truly, truly headless solution. Right? So where Cancia comes in in that partnership, Salesforce has always been API native. It's just that the earlier versions of Salesforce assumed that a lot of the work was going to be done in that presentation layer. A lot of that business logic is also in the presentation layer. A lot of integration, remapping of data, a lot of that's going on in the presentation layer, and now they want to decouple that. But the APIs, you know, of course, they're not composable native. So what do you do? So in our case, what we've done is we've built connectors to Salesforce, so the orchestration layer sits on top of it, does essentially fill that gap that existed with those APIs and now provides a nice clean packaged response for a headless front end. So the headless front end doesn't have to talk to those APIs directly, it talks to Cadilla, and the entire integration process becomes a lot simpler. But at the same time, now you can also connect to other technologies such as Content Stack and Contentful if you want to bring in a headless CMS, because CMS is not a core capability of Salesforce, Commerces, right? Um, and then you can bring in your own pricing engine, you can bring in your own promotion engine or inventory service or even an OMS. So they're open to you bringing in other tools to the mix as long as we're using that commerce engine at uh at the core, and a lot of their customers are now starting to look at that as a very viable option. Um, so you know, to your point, uh Jason, like 90% I would say, of the market right now is starting with something, they they're not starting from scratch. Most of the time they're not starting from scratch. And so you have to figure out a way to build, introduce composability into their existing architecture one step at a time rather than assuming that they're just going to migrate completely to a brand new architecture.

Speaker 1 25:51

Well, I think it it's fair to make the point here that that is a bridging technology for Salesforce. And the the advantage of going with one of the modern cloud native solutions is obviously you have one Commerce engine that can drive all of your channels, essentially an infinite number. Whereas with the Salesforce architecture, you're still essentially tethered to create a for every channel. Uh every instance, you have to have another uh instance of that Salesforce uh Commerce engine. And the same thing with uh the Oracle, which they I I I prefer to call them decapitated versions. And even so they were they were uh uh you've made it a little bit easier to guide that torso that's running around uh you know without any direction with contour. But I I still think it's a much more aptly described as a bridging solution to actually strangle the fake more effectively and allow those customers to uh adapt the best of headless uh in that they have a better content experience, they have a better digital experience, they have a better CX, they have better uh ability to capture that data, they have better ability to use modern hyper-personalized real-time data both capturing and refreshing their site as it's being utilized. And that can only take place uh with the modern cloud native microservice, you know, microservice architecture, headless, cloud native API-led developed solutions, like obviously Commerce Tools or Elasticpath uh or uh fabric now on the uh on the cum as well. So uh just to be clear here, if I want to increase my composability but not replatform my commerce, you we my what are my options?

Speaker 2 27:52

I think again, some of it start who are you starting with and which version of their product? Because often you know the these products require a major lift and shift across major versions. So V1 versus V2 versus V3. Uh, you know, V1, don't even try. V3, hey you can do some things and let's talk about it. Um I think I would say very much that that abstraction layer, that performance layer, like choosing who you're bringing in for that matters and makes a difference. So you're gonna have to invest a little more probably in a productized solution that's doing that because um the commerce product you're keeping just was never it it's a retrofit to serve an actual performant front end. And rather than a bunch of work and work around with a firm like us, I would much rather that you you put it into a product that that has productized adaptation to make that work well, at least improve your ability to use it in a in a composable or headless content and or headless construct. Um I think sometimes as well, I would say something like a Kinsia can be nice where you know can say different from other iPads or integration products, Kinsia being very commerce focused, um, you've got the personalization capability built in. So there's a nice thing where, hey, we can abstract that. And then also you're getting personalization built in. So there's a clear win. It's not just the same thing but a little faster with a little more control. Uh customers can customers see an immediate benefit as an immediate. So we often try to package the two that um some of the commerce-specific vendors approaching this problem have added unique capabilities to their product that consumers will notice, and then it's win-win for everybody.

Speaker 29:41

Right. And and to just to add to that, Jason, um, you know, the way I see a lot of these conversations go is you're asking the customer, you know, what are you doing composable for? What's the point? Right? So the most obvious thing is the customer experience. I want to, I want to do something new, right? I want to I want to change something on my website, and I'm not able to. I can't add a new search uh capability because that just doesn't work natively with my current DXP or my current commerce platform um or or a CMS. So understanding sort of what you're trying to achieve is quite important because if you don't, then it feels almost like it's you're just philosophically making a decision to just move to um another platform just because it's cloud native and just before just because it's composed a composable native, you have to really understand what exactly is the problem right now. So there's a short-term problem to be solved, and then there's a long-term problem to be solved, right? If you only focus on the long-term, then the immediate benefit, you're not gonna get the budget, first of all, to do it, right? You have to give wins now. If I'm gonna spend $500,000 on this project, then I better get an experience that is better for the customer. And so working backwards is a good thing, and then having um this sort of a layer that sort of abstracts out everything under the hood, but still allows you to move further from an experience standpoint, offer new features, offer new capability on new channels is a more practical option than completely doing a re-platform immediately. But what it does allow you to do, having that abstraction layer for the future, is that you can start to take away some of those legacy systems out in a year, in two years. Once you start to prove out the value that, look, composability is actually doing me a favor here. I can actually build new experiences. You now can get that buy-in from your executives, and they will put money in then to get more of that long-term future-proofing benefit from the solution. Right? So that's sort of how we see it. It's not an all or nothing ever. Um, you have to move slowly, you have to move pragmatically, because that that's where most of the customers are at, and especially in today's economy, you're not gonna get five million dollars to do um like a complete replatform from scratch. You would get maybe half a million. Um, and uh, and you know, that you could use to show some value and then next year get another uh half a million. That that's at least what we've seen uh with with most of the projects that we're part of right now.

Speaker 1 32:23

Well, I mean, a lot of folks build a new house and they uh move their old furniture into it, uh or they you know, and and they might have uh an ancient easy chair that they're really comfortable with. And essentially, if they had you know a uh an interior designer uh that could find a way to make that look okay around all of their other new furniture, they'd they'd essentially have what conscious does to uh taking all of those old applications and sticking them in that wonderful new looking house.

Speaker 32:55

Uh to lipstick on a mink? Is that what I'm saying?

Speaker 1 32:59

I think it's no, I think it's far more sophisticated than that. Far more sophisticated than elegant than that. Absolutely. I would never say anything like that. I would never say anything like that. But uh, you know, I I do think that there's there's more than enough of that uh out there, but this is definitely allowing that intervening uh that intervening step that lays the groundwork for a successful full-scale transformation. And companies, as you say, uh if you're a global company that's doing more than a billion dollars in revenue and you have dozens of channels, you can't do it all at once. That's just not feasible, not tenable. But you need to, you know, you need this is uh a very reasonable, easy to achieve set of wins on getting uh a far more uh reflexive customer experience by using this this orchestration tool. But you know, there's obviously we hear the term orchestration a lot in the market. I've heard of obviously Octo and EnterSpeed use that term. How how is Concha different from them?

Speaker 34:11

Great question. I I wish I could put an entire diagram in front of you that shows all the capabilities of Concea, but the way I look at it is I can break it down into two things. So one, you have backend systems that have APIs and others uh systems in most large enterprises, I would say 100% of large enterprises that don't have APIs. So not even composable, we're not even talking composable native, we're talking no APIs, it's just batch type of systems. Now, when you're building an experience, there are two types of integrations that are involved in building one from front end to back end, and one, which I was saying earlier, horizontal integrations between systems as well. You can think of our two modules, um, the DX Engine and the DXGraph, solving those two problems respectively. So the DX Engine solves the problem of making API call to various backend systems, anything that can offer an API, and creating that abstraction there so the front end doesn't know what backend it's talking to anymore. So you can, you know, on the back end you want to replace one CMS for another, you can do that, no problem. Um so the the less less of a um I guess disruption in your customer experience as you change your technology behind the scenes. The other part is the DXGraph, which is essentially creating a data hub, an API-first data hub from all of those backend systems, and not just creating that data hub, but actually pulling the data and pushing the data to other systems at the same time. So acting in a way as an integration platform to some degree, but with that added benefit that non-technical users and uh product team can actually go in to one place and see that see not just you know know that it's there, but see the data uh all in in one place and validate it, you know, enrich it if need be, transform that data, make it ready, prepare it for that front end um as well. Octo and enter speed, uh enter speed, they act more as in my opinion, and they they may uh you know uh not completely agree, but as caching mechanisms for the back end data to make that data available to the front end faster and all from one place. So now you don't have to call those legacy systems because you can't call them anyway. You need a place for them to be cached. So you put it into Octo or EnterSpeed and you create different views of that data that the front end can then call. What it's missing is that first piece, the DX Engine piece, is not there uh at all. Uh with Oct2 and Enter speed, like so no API orchestration uh is happening there. Um and what's also not happening is a place for business users uh and non-technical users to go see what's in that repository. Can I touch and feel that data? Can I search for information within that repository? So that piece is quite different with Consia. So I'm not saying that there isn't a place for them because I think there are some use cases where something like that is very, you know, uh I think it's very beneficial to have. Um, but I I I think we have to talk about use case by use case. Can you use Kencea in this case? Can you use Octu in this case? And we I would say are a superset of a lot of integration and orchestration capabilities, whereas Octwo and Enterprise uh EnterSpeed are more maybe 20 to 30 percent of our capabilities.

Speaker 2 37:41

And if I could add on, because I I when we try to walk it through for our customers often, um look like there's there's a set of solutions which it's about caching performance and kind of maybe a common protocol that you can get to. Um there's a subset. I I you didn't use the word connectors there, uh, but I would say there's a subset. You can tell based on the systems they support with pre-written productized connectors, and then click in one step further, right? So people, you know, when you've got a vendor who's supporting fintech or or legacy finance, uh, you know, you're gonna find a different set of connectors than those specialized in commerce and DXP. So a vendor who has all that pre-supported is gonna save you a lot of time, money, effort, risk. And then we start to look at added added capability. So then again, the more specialized you get again, um, whether it's you know, you'll get some where the added capability is gonna be more CX oriented or core systems out to your CX and and and kind of user experience, you're gonna get some that are more much more specialized system to system. Um I just did a webinar on order routing, and it's it's specialists who are just trying to move order and inventory data, and that's where they are specialized, and and you're not gonna use them out to the CX the same way. Um and so uh, you know, Sana, you've got personalization capability. Um, you know, there's approaches where you're looking at you know AI capability or auto optimization. Like there's there's you can tell by that that added capability. Sometimes that's appropriate, and it's it's okay, then you're gonna want if if you want that, that's the benefit. Um so it's kind of looking at the options and seeing um uh you can start to once you go a couple steps in, you can tell like what a specialized vendor here in DX really help me. And then the last one, of course, you mentioned is do you need business user? What's the degree of code control versus business user tooling? Um that's gonna subset your options further.

Speaker 39:44

Right. Yeah, what one of the exact uh just a uh recent project that we uh worked on, the the biggest reason for them to go with Consilla, besides the the time to market, and uh was self-service. And uh the fact that they did not have the skill set, like very technical skill set to do all those integrations themselves. Uh, they wanted it, it's still they're using some APIs in Consia to do those integrations, but it's configuration. There is no deployment, there is no heavy duty coding to move data around between systems, and they can actually validate the data immediately. So, which means they can move a lot faster, their integration testing is a lot easier because now they can see, oh, this field from this system, do I see it here? Oh, I added another field from another system to my data model. Can I actually see it? Can I see all the data in that field? So immediately with our validation cards as well within within the platform, you can see like, is there something missing? Are there gaps uh in my data? It just moves things so much faster and it's more agile way of doing integrations.

Speaker 1 40:49

Well, uh Sonny, you've been very supportive of your SI community and have embarked on numerous accelerator projects. And who have you been working with mostly?

Speaker 41:01

Uh I would say SIs that actually understand composable architecture. Um and it's kind of it's it's like a needle in the haystack, um, I would say. It's not easy to find expertise uh and understanding uh and and like being aligned on the same vision of the architecture uh for our customers. Um, Orium, of course, as uh you can tell, Jason's uh you know one of our partners, and we're building some integrations together as well for Salesforce, for other commerce platforms, um, so can see as being used as an orchestration layer to showcase for customers that need this sort of capability what that architecture would look like. Uh we have others that are uh so a lot of the SIs that we actually work with, uh, because of the same uh pragmatic reason that we were talking about earlier, they have a practice for Salesforce and Adobe and Sitecore and SAP, etc., but they also have completely composable practices. So for example, EPAM uh is one of our partners. We're working with them on both fronts, both completely composable accelerators and Salesforce-specific composable accelerators. Royal Cyber is another one, which that one is actually more Salesforce and DXP all in one sort of platform focused, but they have just uh just yesterday released uh an accelerator that they've built with Consia in the middle of Salesforce and uh the web front end, their their PWA kit, uh, Valtech. So again, all of these are enterprise-level uh SIs who really understand like and and help and help the customer with their technical uh technology strategy. So not just coming in to implement something after somebody else has made the decisions to implement it or to to architect it a certain way, but they come in, they are the ones who are um really guiding the customer through that entire digital transformation journey. Um but I would love to hear uh Jason, you know, your experience with uh you know with Consia so far and and how this partnership is is going for you guys.

Speaker 2 43:09

Sure. And actually, we take a moment in Jargon Land. Yeah, let's define the word accelerator, right? Uh let's just define accelerator as a concept.

Speaker 1 43:18

I really wanted to get there. I honestly wanted to get there. I'm I'm sorry it took so long.

Speaker 2 43:23

And and in the short frame ironically. How's my background noise? Sorry, the kids are in the background. Can you hear them?

Speaker 43:30

Oh, yay.

Speaker 2 43:32

Is the background noise okay?

Speaker 43:34

That's fine. Sure, I love it. You're you're human, Jason.

Speaker 2 43:38

Accelerators are really funny.

Speaker 1 43:41

Accelerators are so much fun. The kids are playing with them in the next room.

Speaker 2 43:45

Kids love them. So let's think of accelerators. So accelerators are generally, it's not a SaaS product, but it's what um it's essentially a starter pre written integrations. And any SI worth their salt in the composable space. Should be coming to the table with that. And some have essentially produced a white paper and said, here's our accelerator. We can tell you what we like to snap together. What you really want, like we've spent millions on pre-integration. And so what you want is one of the very defined subset who have truly productized a jump start. And in our case, what's unique is uh for most that comes as here's the pre-integrations. So you don't have to pay us to write the integration we've done 10 times before. Um and and that kind of just gets you much further. It reduces risk. Um so accelerators. Now I like to say ours is the most composable accelerator because we don't have this version, this version, this version, this version. Ours has been architected in a way where we have five commerce options, four search options, three C or four CMS options, payments, checkout, promotions, loyalty, all of that, we can take that variety. Now, what we end up doing though is that only works if it's a composable native or composable performance solution. I got to be able to call them directly. If we feel that a customer is going to need to spin up multiple new channels or deal with multiple commerce systems, or it's working with a commerce system that we wouldn't consider to have sufficient composable capability. Like you can get there, but you need that performance, you need something like a consia in the middle, then that's where we work with Consilla. So I'd rather integrate with a Consilla, who can then open up a whole new realm of options. Um and so that's where we we find that that partnership can work very well. You're gonna have to pay Sana your monthly fee. Uh, but it but there's a whole added set of capability, performance, and flexibility over time, personalization, business user tooling. The unlock is worth it there. Um so I think that's that pre-written one time paired with kind of flexibility SaaS tooling over time, it's finding the right, the right balance in between. And Sonna has obviously been very focused on knowing where where the SI community has a role to play.

Speaker 46:03

Uh I would say SIs that actually understand composable architecture. Um, and it's kind of it's it's like a needle in the haystack, um, I would say it's not easy to find expertise uh and understanding, uh, and and like being aligned on the same vision of the architecture uh for our customers. Um, Orium, of course, as uh you can tell, Jason's uh you know one of our partners, and we're building some integrations together as well uh for Salesforce, for other commerce platforms, um can see as being used as an orchestration layer to showcase for customers that need this sort of capability what that architecture would look like. Uh we have others um that are uh so a lot of the SIs that that we actually work with uh because of the same uh pragmatic reason that we were talking about earlier, they have a practice for Salesforce and Adobe and Sitecore and SAP, etc. But they also have completely composable practices. So, for example, EPAM uh is one of our partners. We're working with them on both fronts, both completely composable accelerators and Salesforce-specific composable accelerators. Royal Cyber uh is another one, which that one is actually more Salesforce and DXP all in one sort of platform focused, but they have just uh just yesterday released uh an accelerator that they've built with Consia in the middle of Salesforce and uh the web front end, their their PWA kit, uh Valtech. So, again, all of these are enterprise-level uh SIs um who really understand like and and help and help the customer with their technical uh technology strategy. So not just coming in to implement something after somebody else has made the decisions to implement it or to to architect it a certain way, but they come in, they are the ones who are um really guiding the customer through that entire digital transformation journey. Um but I would love to hear uh Jason, you know, your experience with uh you know with Consia so far and and how this partnership is is going for you guys as well.

Speaker 1 48:18

Well, uh the this whole series is is really devoted to those merchants that are considering, that are, that are uh trying to remain competitive and have a problem innovating, have a problem matching the customer experience that their competitors are providing, have a problem getting into a new market, have a problem retaining their customers because they're just not presenting themselves to their best ability. And while composable, uh, in my humble opinion, is the only way to truly future-proof your their business by adopting a framework that allows them to constantly innovate and to do so easily and cheaply and very uh with a minimum of headcount. Getting there does cost money, does take time. And uh as we've outlined today, conscious with uh data experience orchestration is a very smart investment for those companies that have very large legacy commerce uh platforms that they want to add more flexibility to to provide a more modern customer experience personalization, and are on the roadmap to full composability and are partnered with a company that in Conscia that is gearing them towards that and providing them the fundamentals to make that transition easy. Uh, and to Jason's point, if you're going to go full composable, you need to do it with an agency that is fully vested in the game. And that doesn't just mean we're a partner and we have the ability to stand up a solution. It means with composable, you understand the myriad of solutions that go into crafting a platform of 15, 16, 20 components potentially, uh that's going to serve an unlimited number of channels. And that requires a far more artful approach to architecture, a far more consultative team of professionals that are devoted to composable commerce, not just doing it as a sideline, not doing it as just a line of business, but that's what they're committed to because that's the level of expertise you need and can rely on. Uh and those firms are going to have a fully realized set of technologies that are accelerators that are going to make you successful, not in two years, but in a year or less. Uh and that is uh again, my whole blab about this is for for you merchants, for you retailers out there listening, uh, this is for you. This is to make it easier for you to make that step. And Senna, I really appreciate you joining us today and sharing uh the wonderful solution you've developed there at Concha. And uh I I wish you the best of success. I'm sure you're gonna have it, because you're providing a tremendous amount of value here for those folks that are saddled with Hybris and Oracle and Salesforce. And uh Jason, Guy, thanks for putting together one of the greatest digital agencies I've ever gotten to know.

Speaker 2 51:57

Appreciate that. And thanks for continuing to tell the story and the trend of composable. Um, as especially as it continues to go mainstream, you know, more and more people are hearing about it. I I think it's great that you're you're helping guide how to do it well.

Speaker 52:09

Thank you so much for having me as well, uh, Daryl. Really appreciate it. This is this was a great conversation with uh you know experts uh in the room. It's uh rare to have that kind of a mix.

Speaker 1 52:21

Thanks for listening to Mar Talks. Please leave a review and a rating on your platform of choice. We're available on Spotify, Apple Podcasts, and all major podcast platforms. To find out more about how the Rosenstein Group can help you find the right leaders for your client development teams in Martech and e commerce, please visit our website, rosenstein group.com.