Konabos

Composable DXP Roadmapping for Sitecore Customers

Akshay Sura - Partner

20 Jan 2022

In this video, we walk through what is involved in the Composable DXP Roadmapping session. If you are a Sitecore customer, we need to tackle the move to Composable DXP as we move from the Monolith CMS.

Transcript

Note: The following is the transcription of the video produced by an automated transcription system. 

Hi, this is Akshay Sura from Konabos. Today, we'll be talking about Composable DXP road mapping sessions for Sitecore customers specifically. Why do we want to talk about possible road mapping for Sitecore customers specifically is that in the recent past, there's been a movement from going from a monolithic architecture into a composable DXP architecture, and this has been more significant from a Sitecore perspective as they have pivoted towards composable DXP and the benefits of composable DXP and the purchases cycle has made in the last year to lead us to believe that that's the direction they wanted to go, and they actually are making an effort to push quite hard on going into a Composable DXP architecture. From a Gartner perspective, Gartner says that, you know, adopt the composable DXP strategy so you can future proof your technology stack that this means different things to different organizations. But in a way, basically, it's trying to say that, you know, if you don't get on the bandwagon at this moment in time, this seems to be the buzzword of the industry you might be left behind, or you might be it might take you longer to recover. Now what people don't usually realize when we're talking about composable DXP is what is this new buzzword, right? So if we look at it from how Gartner puts it, a monolith is a system where you have everything inside of the monolith itself. There is no need for you to find another provider for personalization or analytics or anything else the monolith CMS is providing you now.

There's good and bad to that. Depending on your use case, it is probably better if you stay on the monolith as opposed to going to a composable architecture. So it is case by case, and it truly depends on your organization and your needs and how ingrained this system is in your in your organization as well. But in most cases, there is a good reason why you should be looking at a Composable DXP. And what I explain to a lot of these organizations is that whether you realize it or not, most likely you're already partway there. What I mean by that is most of the companies we look into or try to help. They are already using a different analytic provider, for instance, Google Analytics with Google Tag Manager to manage their analytics overall across all brand properties. Now they have a specific team who are really good at what they do in terms of SEO and measurements and looking at the traffic and analyzing it. So from a composable DXP perspective, the piece for analytics is already separated out. The same can be talked about in terms of how you manage your customers. Maybe you, you use Marketo or other tools where you are creating forms or landing pages or funneling something like HubSpot, for instance, where from a personalization perspective as well their providers, which can provide the same functionality in a composable DXP at the end of it, it isn't something you switch overnight.

You could do it over a period of time. You could take your time doing it. You could evaluate while you're doing it, and there's no need to rush in order for you to jump composable DXP because I'm most likely you're already halfway there. The other thing about Composable DXP people tend to forget is it's also reusability. There's things already currently in place in your organization, which you can reuse. As I mentioned the analytics, maybe you have a search provider internally, or maybe you have a PIM product information management system already in your organization doesn't necessarily mean you take everything out and then you put new things in. It's also about reusability. Basically, whatever works best for your organization is what you should be looking into. Now, I would like to tell you a marketing story. See what you take out of it. This is a story about a fictitious company who's having challenges, they are having challenges in terms of using the system where they are having to do quite a few of the custom integrations efforts been duplicated in terms of, you know, you might have already have a PIM. But then the media assets are being duplicated in the monolith. Or you probably already have a DAM, but the product and media assets are being duplicated. The processes are being duplicated. Deployments probably take longer. They are a pain. Cost of infrastructure is growing. Upgrading seems like a chore because it's in the project in itself.

Finding the right resources probably is an issue. And also the time it takes for you to get something out there for your marketing organization or your product organization is becoming longer and longer and people are getting antsy. Now does this sound, you know, do know who this story is about this sound like it may be you? And if the answer is, oh, it sounds quite similar to what you go through. The answer to this is to start looking at road mapping towards getting into a composable DXP architecture. When what we do in terms of road mapping is we come in and we look at your existing stack. What do you do? What are your current challenges? Where do we see duplication? Where do we see there might be answers already in your organization, which we can reuse those solutions to solve some of these problems as Sitecore moves more towards jamstack and composable DXP. It would be logical for you to keep moving with Sitecore into the composable DXP. Find the right fit for the things you are doing. So from our perspective, we are because we work with quite a few Sitecore customers. We solve a lot of problems. We are capable to look at your existing issues and then see how we can take you to the next level, which is composable DXP. Some of the articles you might have noticed which were published in and around last year this year talk about more from a perspective of how to use these individual pieces.

So the article here talks about OrderCloud. Ordercloud It's amazing by itself, but it's one piece of the entire puzzle, so you still have to fill in who is the analytic provider, who does the personalization, where it is the CMS information come from, and not necessarily all the pieces belong to one vendor. Or you need to only have one vendor for one specific operation, so you could in the composable DXP architecture. Unlike the monolith, you could use one CMS vendor for certain purpose and another CMS vendor who fits the business needs for another purpose. There is a concept of a second CMS, so it's not like you are truly putting everything into one. There is no vendor lock. You can switch providers whenever you choose to. That's the beauty of composable DXP. Another article by Dom from CMS Wire talks about how important it is for you to have the flexibility for your organization to go towards headless CMS or composable DXP. It is what a lot of the huge organizations are looking into testing it out, seeing if it works for them, so I definitely urge you to look into it. Sitecore themselves have talked quite a bit about the composable DXP and how much they are willing and looking forward to providing services to their customers with their offerings. Have bought a few of the companies last year which specialize in individual, you know, functionalities and all of them are really good.

And what that gives you is the flexibility to then step back. Look at it Ordercloud. Does it work for us? Yes. Ok, we'll do Ordercloud and then maybe look at Moosend if it works for you. Great? If not, you look at a provider who works for you. You might already be working with another provider so you could mix and match, and that's what helps you the best. Looking at everything you have in your ecosystem and the challenges. We come up with the recommendation with a few recommendations and also sit down with the entire team, walk through the recommendations and talk to the pain point. At this moment, we're not really looking at a specific vendor or a specific piece of technology. And more looking at, OK, we see an issue here where maybe you're pulling products from a to PIM and PIM to your commerce provider and it's not really the most optimized, maybe we could make it optimize by using something different. So that's what we are more focused on here. We're not really looking at putting brands, you know, product brands in there like Sitecore or any other vendor. We're mainly looking for, you know, what solves this specific problem. And then you evaluate and evaluate, you know, multiple CMS vendors and say which one works for you or multiple, you know, headless commerce vendors and see which one actually works for you from our perspective at that moment in time.

You have two options you can either stay the course of a I'm going to stick with the monolith and I'll see what happens. Or you could say, you know what we could start making move more towards, you know, a pivot towards jamstack and see where that takes you. Now, pivoting to jamstack doesn't mean all or nothing, right? So it's something which you have to think through. See what works for you best. If you stay on the current path, you might run into a few issues, which is one is the end of life for the product. Depending on the product that you're using, the end of life support is something that you need to consider. Also, things like, you know, how does this affect your business? So if by staying on something, knowing it's going to end, how does it look for you? Are there things you could do with the current stack that might, you know, give you a little bit more of a runway? How does it affect your process? You know, all of these are something which you owning your business would know more than anyone else. All in one do all at once. This is a really good quote. It's not everything at once. You don't switch something off and switch one, switch something on. You take more of an agile approach. You look at it and you're like, OK, you know what? We can do a proof of value trying to go headless to the composable DXP.

Let's look at maybe pick a brand that it would be a good proof of value brand to test out. You know, does this work for us? Does this work for the teams involved and see if how that works shouldn't typically cost a lot to do a proof of value? Usually, the vendors involved are more than willing to give you their time in order to build the proof of value for you to see it. Once that's built, it would be easier for you to look into what you can do. If you have commerce systems, you need to start looking at moving away from the monolith and figuring out what other headless commerce vendors they are looking into building a proof of value automation, whether it's from integrations, personalization, email, there's a ton of vendors. And again, I feel like most of the organizations are already using, for instance, HubSpot or Act-on Forms or Marketo and things like that. In terms of marketing automation, bringing in leads lead Lift is another provider, so there's so many providers who are already working with customers in this headless, composable DXP manner, so it becomes very easy to find providers to provide the functionality you need and you're not locked into them, and that's the beauty of the composable DXP experience. You could switch to that. You could try out a vendor. If it does not work, plug out, plug into another one. Most of them have migration strategies already in place, especially headless commerce and CMS vendors.

When you look at what Gartner is putting out there in terms of what they think the future is going to hold, Forrester, Gartner, all of them look at composable DXP, headless CMS as something that you need to look into. You need to go to. They talk about how easy it is for you to go to market. At this current rate, we are switching a brand from a monolith to a headless, composable DXP three to four weeks. So last year we did 10 brands. This year we're on track to do the same for one of our customers. We're starting another customer who have about 25 brands and this is something, you know, once you start first and second brand and bringing other sites on board is super easy. Really, really urge you to go look at it in terms of material out there from trusted sources, which will kind of give you an idea of what it is that it takes in terms of moving to a headless architecture. How does it compare in terms of revenue? How does it compare in terms of, you know, features, for instance? There's a lot of things out there. I urge you to look into it at the same time, just go to reputable sources where you could take a look at it. So this is a good slide in terms of monolith to a more modular composable DXP solution as to what benefits you get. And again, I do want to stress that depending on the organization you are in, maybe monolith works for you better than a modular, composable DSP, and that's something you need to weigh in terms of where you are in your journey as well.

Where do we go from here? So what we do is once all of that is done, we go through the education process. We go through what our findings are with the entire team. We come to the last part, which is building a proof of value, and this is super important and we've seen it a couple of times in the customers we deal with. The whole mindset of the organization changes once you actually show the proof of value. So building a brand site which utilizes integrations into SAP, the pin the dam and bringing in the products, pushing out the orders to SAP and building this headless CMS with the headless commerce solution out of the box with very minimal effort and being able to show this proof of value to the higher ups and the and the rest of the team brings in the buy in right. So they look at it and like, Oh, this is actually possible, then we start getting these questions. Or actually, how do you how do you do this? Does this go in as a quote to sap an actual order, how we're bringing into the products from the PIM? Can we do this? Can we do that? And they get more engaged? And once you can show the proof of value, everything changes and one it doesn't cost as much to you get to see how exactly it would work and then you can plan out and be like, OK, now we have the second track where we can move slowly a site at the time into this more compostable DXP manner.

And I really think that is a huge benefit. So recapping composable DXP might not be for every organization, but it is for most organizations. Look into it, it is an agile based process where you don't have to move everything at once. You can reuse what you already have. You don't have to get all new systems. So if you already have an analytics solution in place, we're using Google Analytics or whatever you use. You could continue doing that if you already have a marketing solution, which is Marketo or HubSpot. Whatever it is, you could continue doing that and then reuse what you have and look for things which you don't have. And you could because there is no vendor lock, you could try out different things. And but I would say, though, is time to market is much, much quicker from a composable DXP perspective, and I urge you to look into a road mapping session. We're more than happy to help reach out to us. We are available on all social channels as well as you could use our website, Konabos.com Thanks again for watching. I hope this was really useful.


If you have any questions, please get in touch with me. @akshaysura13 on Twitter or on Slack.

Sign up to our newsletter

Share on social media

Akshay Sura

Akshay Sura

Akshay is a nine-time Sitecore MVP and a two-time Kontent.ai. In addition to his work as a solution architect, Akshay is also one of the founders of SUGCON North America 2015, SUGCON India 2018 & 2019, Unofficial Sitecore Training, and Sitecore Slack.

Akshay founded and continues to run the Sitecore Hackathon. As one of the founding partners of Konabos Consulting, Akshay will continue to work with clients to lead projects and mentor their existing teams.


Subscribe to newsletter