Welcome everyone to our webinar today. Don't lose your head. The Case for the all in one dxp, so Kamruz Jaman, my partner at Konabos and partner in crime, is going to present. So Kamruz, all yours. Thanks. Akshay. Thank you everyone for joining and hopefully find some interesting info, but I want to make the case for the all in one. Dxp, this is something that I had presented at the boy and CO CMS connect 24 last month in Montreal. Really, really great event. Got some really, really good feedback from that as well, and it's also really, really great feedback from industry wide professionals and peers, so that that did make me a little bit happy, and they gave me a little bit of more confidence to present this all to you. So my name is Kamruz Jaman, for those of you that don't know me and one of the founders here at Coronavirus, along with, actually, I've been in the CMS and the XP space for over 15 years now. I am also a 12 time cycle MVP and a content.ai MVP. I have been in the IT industry development space for 25 years almost now, started as an intern, way back in the 1999 2000 like most people, most people my age. I guess I was tinkering in products such as front page, Microsoft front page, home site, Dreamweaver, the original JAMstack creation tools, if you like. I started as a full stack developer, so I was working in classic ASP, as it's known now, but I would do the backend coding, the front end coding. I would be the BA, I'd be the analyst, I'd be everything, right? But these days, I am more of a solution level architect, working at enterprise, working with enterprise customers, but my introduction into the CMS space came in around 2009 when I started for a little agency in London called precept, and we got introduced to The site core system. At the time, of course, six in those days prior to that, we've been I'd worked with some home brew, CMSs, but it was mostly application development that I was doing, as well as websites, but more generated statically. A little bit about Konabos. So hopefully, a lot of you know us from the space, but Konabos was founded in 2000 E and we're a group of digital solution specialists. We provide end to end services, including development training, design UX, ci strategy, what a strategy? Project management, etc. So we are a full end to end digital agency, but hopefully a lot of you know us from the community. We do love to share our knowledge and our experience, our learnings and our failings, and yeah, it's great to share that with you guys and to get that feedback as well. We thrive on feedback. 

So again, any feedback you have from this presentation and what you guys have also been noticing in the industry, we'd love to hear that as well. So we have been working in the headless space as well for a number of years, and we won, last year, we won a marking part Award for Best Overall change project for one of our clients, American bath group. We were using a whole host of technology, composable products, in this in this solution. But there was a it was, it was a huge, let's see, as the award implies, overall change projects. This was a huge shift in the organization in the way that we had been previously implemented, in the way that it had previous their solutions had previously implemented. And the way what we had been implemented, implementing it with this composable stack, the end to end integration with their business units, their production teams or customer teams, their partners, their B to B, the B to B partners, as well as the type of solutions, so the website itself, as well as other products such as kiosks and devices and mobile applications. So the case for this is where I'm going to make the case for the all in one the. Dxp, having just talked about composable and headless, a little bit of a shift in gear, and where I feel the all in one traditional dxp still make a lot of sense and bring a lot of value for a lot of customers. Now, when we talk about monolith, just the word monolith, when you're thinking, when someone says the word monolith to you, what comes into your mind, and what you're going to think of is something which is big, something which is old, something which is ancient, something which is almost immovable. There's no flexibility in this system or this mono yes, there's nothing you can do about it. But when we talk about the word headless or composable, what we're thinking is something which is small, something which is lightweight, something which is nimble, something which is very agile, something which is very, very modern, right? The words headless and monolith almost kind of invoke a good versus a bad connotation in at least in my mind, from what I've been seeing with all the different articles, the different marketing material, is always almost like, if you're going monolith and it's a bad choice, you know, this is a very old, old system. It's never done good for anyone. Whereas headless, headless is this new solid, sunlit uplands, and it's going to provide you all the agility to, you know, move your business forward, and it's, you know, it's the obvious choice, right from all the marketing materials that you hear. But these words matter, right? So when we, when we're using these words to describe things, just the word itself monolith, that choice of word matters. But then when we talk about these all in one systems, there are some systems where you will say, hey, you know what? An all in one system makes a lot more sense than this composable system, right? I don't want 15 different things doing this thing that there's one thing over here can do one of the things that came to comes to my mind is, I don't know if you guys have seen this advert, I'm sure you've seen this, just doing the rounds on the internet, is there's this advert where this Radio Shack art advert from. I think it's 1991 or something like that. I believe it's got all of these products on there. And this is, this is my, this is my composable analogy, whereas the all in one is your iPhone or your, you know, your smartphone, it can do every single thing on this radio shack advert from this from your one device. So why? Which? Which is better? In this case, are you going to have these 15 products, or do you want this one handheld design device that you that's with you, that can do all of these things for you? So some, again, we're not going to call the iPhone monolith, right, but it is an all in one in comparison to having lots of separate systems. 

So the first point of coming up is when we talk about headless, headless is not mean composable. I can be composable and not be headless. I don't I don't necessarily require headless is a feature. It can be. It's a feature that we have enlightening to composable, because they often go hand in hand, but they are not the same thing, right? I can be headless and not be I can be composable and not be headless, and vice versa, right? I can just have a headless system which just serves up a website and not necessarily be composable at the same time. Composable. Composable is about the use of multiple different systems to build your stack to solve the problem. And for a lot of us, we've been doing this for we've been doing this for a very long time. We've been composable, even with it, with on top of our traditional monolithic type systems, we also hear a lot of from the marketing perspective that the future is composable, or the future is headless. You have to be headless. You have to be composable in order to in order to be ready for, you know, in what is, what is to come. But headless is not the only future. As I said, you can be on a traditional, monolithic type system. These all in one dx piece and still be composable, still integrate with the different MarTech stacks, the different systems that you need to, that you need to build your solution. And again, this marketing talk always reminds me of this famous quote by Henry Ford where, when he was talking about the Model T, and somebody asked him, you know, can I have it in a different color? And said, Yes, you can have it in any colors you that you like, as long as it's black. Again. There's a narrative that everyone has to be headless and everyone has to be following the composable approach. But it's not. It's not a must for everybody. So traditional, CMSs again, they would handle everything, you know, your database, the code, the plugins. They would run some logic in the back end code. They would serve up some HTML. They would serve up the media, the CSS templates, everything that is needed to give a response to the customer, and we can integrate those traditional systems with lots of other systems, right? So there's a lot of projects we've worked on where we've integrated with external dams, external SSO systems. We obviously Google Analytics is the one that's been there since the dawn of time. But we can also feed in other systems, such as HubSpot, for example, if you want to be adding in sign up forms or other landing pages, for example, and all of that can then be handled by HubSpot and then the back downward integrations, if you have some sort of an iPad system, such as API, for example, or cycle connect, then that can also be handled from HubSpot. And you notice that we talk about a responsive output here, so your output from your traditional system, as would be best practice, should be responsive in terms of CSS and the JavaScript and the functionality, which can then be handled on multiple different devices. You know, your mobile, your tablet, your desktop, and sometimes even embedded, embedded systems where, if you just actually need something displayed in a semi interactive form, it's just a screen in most devices, even on your fridge, it is just if it can be up, if it can be opened in a browser, then it can be displayed even on that fridge. And but sometimes that fridge is not an important device for you, and your output is just responsive. You're not outputting to a separate mobile app. And so those composable, those headless elements, might not actually be that important for you. You might not even have the need for omni channel. So you can, you can still be all in one monolith and still be composable. The other important aspect is your team composition. What I mean by that is who is actually on my team that is going to be using the systems that we are building. 

The size of the team does matter. We work with a lot of enterprise we do work with a lot of enterprise customers. The American bath group that I just mentioned is a huge, huge organization. But we also work with smaller enterprise customers, where maybe the entire organization is just a couple of 100 people, and then the size of the web, of the team that's managing the web assets is just a handful of people. Sometimes it's just four people, sometimes it's a dozen people, but they are the one team that is actually doing everything. They don't have a separate team that manages their Pam. They don't have a separate team that's managing the dam. They don't have a separate team that's managing their commerce solution, and they don't have a separate team that's managing the website assets. Sometimes it's the one team that's doing everything. And they need a tech stack familiarity. They don't have the time or the luxury even to be jumping across four or five different systems in this composable stack to be able to doing these things. They don't have these separation of their job. Effectively, they are the ones who are running end to end, and they need to be agile and nimble within one system. So again, having a single neck to choke a single system that they can do everything within, where they can manage the website, where they can manage the content that goes with it, the workflows of that content, end to end, the digital asset. So with that, and also, if there's any personalization scenarios within, within, within that. They need to be managing that within one tool and not four or five different tools, and then your the skill set of your team as well. Really, really does matter. So a lot of other teams we do work with the website is the website or the web assets are not that is not the only job that they have to do. They are offer, often also managing other back end systems, custom systems, sometimes integrations. But a lot of these custom solutions have been built in the same tech stack as what their current website tech stack is. So if you're a customer that's been on a.net tech stack. I'm from a.net background myself, although I have worked with React and next js, for example, but my traditional background has been.net and when I was working at these enterprise customers, when I was working at enterprise customers, myself, as an employee, our tech stack was the one we were familiar with. So when we had to build an integration, when we had to build a synchronization process, and we had to build a custom application, it was built in C Sharp. So if that team, that team has to continue managing their business as usual processes. So if you're now moving to a headless system. The majority of these headless systems are built using React, next, JS, view, spell, whatever your JavaScript based framework of choices that will require that team to re skill. And I know it's very it's very easy to say, hey, you can just learn X, Y and Z, but it's a lot harder than it seems, because you still have your business as usual. You still have to manage those.net based applications. So sometimes and again, oftentimes the tech stack of your dxp does matter as a result, and just moving to headless is usually of a bigger concern for those teams the infrastructure changes of that, you have a new, whole new shift to the paradigm of how your infrastructure is hosted and managed, how those SaaS systems work and you interact with those you still have to manage, oftentimes, you still have to manage those front end netifiers for cells, and then those integrations back into your back end systems. And it's a big shift. So your infrastructure team also needs to now change with that. And it's, it is relearning, it is a concern. Changes. Change is hard. I mentioned the single integrated tool. It is. It is a big, it is a big, it is a big issue for, you know, singular teams, but sometimes your business requirements are actually very low. You don't you don't already have an internal that you're using. So you are actually able to, oftentimes, change your internal processes a little bit to meet what the tool can do, and then oftentimes the tool itself can be customized a bit further as well, so that that is also a consideration that you that you need to make within that choice and in terms of skill set. I don't know if this is an old article, but Scott Hanselman is really worth a read. And this is, I think it's from around 2012 and it's something that Scott Hanselman terms as dark matter developers. And when we are seeing our social media, our LinkedIn feeds, our Twitter, we always see talking about new technologies, right? Brand new stuff, bleeding edge stuff, cutting edge stuff. And this article goes on to talk about, even back then, what it deems Dark Matter developers. 

There's a huge host, host of developers, and it folk who are not on social media, but are not blogging, are not, you know, putting their opinion into every single thing that they're coming across. They they're just there in the background, just getting stuff done using tried and tested technologies and things that they know. And they're delivering huge, huge amounts of business value. And at the time, I think he was talking about as 400 and COBOL programmers. That's obviously slowly shifting. But you know, we all know there's still huge amounts of as 400 and systems and COVID programmers out there, just out there, keeping those systems going, delivering huge value. Continue to deliver huge value to those customers, particularly in those manufacturing spaces. We've seen this a lot. I'm not saying become an as 400 or a COVID programmer, but again, don't, don't knock off. You know what you deem old technology, just because it's not on the cutting edge or the bleeding edge. So. Also, we know that speed matters. Lighthouse scores really, really do matter, and composable and headless, the headless approach does, does help with this. It definitely helps with performance. It's not going to help you with accessibility, and it's not going to help you with SEO, just off the bat, because those are things that you need to have built into your design systems, your UX, your actual philosophy to begin with, but performance we know can be improved hugely by headless and. But I also know that HTML is very, very lightweight next js and single page acts is not the only way to achieve good performance scores. HTML itself is very, very light. I as part of this, I was trying to get some examples of why HTML was lightweight, and I went to apple.com and the initial page load of apple.com is 6.7 megabytes. But of that 6.7 only 45 kilobytes is actually the HTML that's delivered. And it doesn't really matter where you are in the world, 45k in this day and age is very, very small amount of data. What's adding to that is all what I did, the bloatware that goes on with that so your images, your videos, your CSS, your JavaScript, your 15 different trackers, JavaScript trackers that you're adding to this page. This, this is, this is not going to help you, right? Those JavaScript trackers are just going to slow down the page. They're going to add more weight. They, in turn, will load a bunch of things. Apple does do some good practices. Whereas you scroll the page, it lazy, loads in some additional the images and things like that. And these are just good HTML practices. They're good at good practices if you want to achieve good performance scores, right? Deliver some lightweight HTML. Deliver the minimum set of CSS, JavaScript to make that initial render and then lazy load in everything else that you need. Use CDNs. CDNs exist. You know, we can't pretend they don't exist. So use CDNs and use the maximum cachability of your static assets that you can and that's going to help you with all of these performance issues, or some of these performance issues, and help you with global scalability in delivering those. And then you can also look at some newer frameworks, like HTML. So if you're on that traditional server, asp.net, for example. It could be PHP, it could be Java. If you're using those, those traditional server side technology sets, look at technologies like HTML X to give you some of that responsiveness within your application. It's going to be easier for us traditional back end developers to implement and to integrate, and it gives the front end guys also some fun to give. Give them some of that responsiveness and front end technology wise. 

But what matters for a lot of our customers is actually time to matters, time to market. That's one of, you know, one of these elements, the lighthouse scores matter. But time to map, time to market is also one of the biggest drivers of when we talk about speed, business wants their ideas, their changes, delivered right now. And the faster you can do that, the better it's going to be. And it doesn't matter. It to me. It doesn't matter whether that's done in React or Java or PHP or.net these. You know, there are other issues at play that why that process is slow, oftentimes, complexity, composable card, it's often touted as this, like dream, dream that it's going to, you know, make, make. It's going to be a silver bullet. It's going to, it's going to solve all of these other problems, but, but it's not right. Composable is hard and gluing, gluing together. I would say gluing together in quotes, because I know people will hate me for that word, going together these proposal systems is hard, right? You're introducing lots of different systems. You want to bring in some sort of an API layer, and you got to figure that out the first time you do this, or the first few times you do this, is going to be hard, having gone through this. And this is where agencies you know that agency, knowledge and experience is going to matter. Having gone through this a few times, we've learned a lot as we've gone through this process. If I was working directly on the customer side, and this was the first time I'm doing this, I'm going to get a lot of things wrong. And this was the same when I did my first ever CMS project on Sitecore. Example, we. We got a lot of things wrong, that experience does matter. So, yeah, just, just be careful of that. That you know, there is, there is additional complexity in composable there is additional complexity in the infrastructure as you as you're going to now going to manage it. It's not just a single system. Is, there's multiple different systems. It's, it's micro services that you're using. You need to now start thinking about security when you're accessing your internal systems. You need to think about security of your rest points as well, and what data they, in turn, are going to access, and how, what data they are going to expose. So there, are, there are more endpoints and things like that that you need to start thinking about, and start thinking about the security of, because traditionally, you could, you could kind of get it. You could obscure that, right? Because you're only delivering some HTML, some images of some static assets. You could obscure all of this behind your servers. It's, it's your server that you need to secure, and what that, in turn accesses. You can, you know, you can add in additional security, but now your end users are going to be able to access some of these endpoints. And you'll, you'll, you're, you're exposing more that more of them, and there is a micro service tax that goes with it, you're thinking diff differently now. You're having to think about lots of different endpoints, lots of different systems, lots of different microservices, and how all of that fit together in the grand scheme of your solution. 

Along with that, there is a lot of we are seeing a lot of vendor fatigue. There are a lot of different systems that you're going to have to think about and bring into your solution to solve this problem. If you already have these solutions in place, you already using those, using these within your organization, then it's actually a very easy transition. Some customers we've worked with, they already have well defined systems and processes that they were using, and actually the traditional monolithic systems was a hindrance and a burden on them, because those were very, very difficult to integrate for them into those traditional systems, whereas headless, actually headless and composable solve this problem for them. But for others, where you don't have those systems already defined, going out and solving and, you know, vetting vendors and looking at demos and trying to find which one will fit and which one won't fit, going through POCs to see, only to find out something actually doesn't fit gets a little bit annoying and gets a you do end up with a lot of vendor fatigue at the end of it, along with that, for some of the larger organizations, the legal vetting, the legal process to get these vendors on boarded, and then to go through the entire procurement processes getting contracts signed can sometimes be A very, very long process, and as a result, you know some, some of these enterprises are just choosing to go with vendors that are already being procured and onboarded, or use a solution that they're not going to have to go outside of their immediate realm, debugging is a fun one, and when you have One system, you can it's quite easy to follow the track of you know what happens to this request as it goes through end to end, from the user request coming into the multiple different systems you might touch in the back end. But when you're dealing with composable you're it does become more difficult, because you're now having to debug five different streams into five different systems, and see, you know, trying to figure out where is the error occurring, just something to bear in mind, debugging, debugging is never a fun one, and when you have multiple systems, it does it gets a little bit tricky and it's not fun. And Caching, caching in our computer science world is always hard, right? That's our famous quote. There are two hard things in computer science, naming things and caching, validation, and it's not any caching is also in a Composable World and headless world, when you're when you have your when you're making changes in your headless CMS in the back end, and then it's for sale, or Netlify, or whatever you're wherever you're hosting, is your front end is caching that when you want to see those changes you're having to deal with the caching yourself, or having to building these mechanisms to either set it, you know, reset the caching in on a certain timer, or building, building the mechanism to go out and invalidate those Caching, caching for a lot of these traditional all in one systems, is something that has just been, you know, it's just been dealt with. It's sort of built into the system. It's baked into the system. And when I was talking about vendor fatigue. I always blows my mind when I see this, this MarTech map. And you know the many, many, many, many different choices of all the different solutions for all the different products, even in the past few years, I feel like this. 

You know, the number of headless CMS vendors, the number of dam systems, a number of personalization systems, a number of integration systems, has just, I just, I learn about one almost every, every week, and it's, yeah, just mind blowing as to, you know how, and if you're a small organization, this is a minefield and that you have to kind of navigate, if you if you want to go into the Composable World, and you don't already have a tech stack that you're on a large part of that tech stack that you're using, and I don't know if you're if you guys have seen this tweet from Elon Musk back in 2022 just after three took over Twitter and x, and he was talking about, essentially, the microservice tax, where they split out things into, you know, heaps of heaps of different microservices. And it really wasn't making any difference, but was just adding a lot of lot of engineering overhead. And one of the things which I've heard is, if you're not solving a problem at a Netflix such Netflix size, and you probably don't need micro services. But we've also seen a lot of cases of organizations that are actually moving away from micro services and back towards what they what it's deemed to be modular monoliths. And it's not always going to be good, a good idea for everybody to follow the modular monolith approach, even. But again, microservices also isn't going to be a good idea for everybody. It's not always going to solve the problems that you think it's going to solve. So again, just pay attention and see, do I actually need to solve this problem, or am I just introducing microservices? Because that's what everybody's telling me, I need to introduce self hosting is again, I know it's frowned upon these days, but it does come up as a requirement for and we've seen it as a requirement for some of our customers. You know, they want to be able to host their solution on prem, within their own data center, with it, even within their own cloud subscription, right? So they might have an Azure or an AWS subscription, and they want to be hosting it within that subscription itself. And when you're going down these SaaS based systems that, often times, isn't an option, right? It's hosted on the vendor hosts it, you know, and that's a beauty. They will host it, they will manage it, they will upgrade it for you. They will do everything for you. They will scale it for you and everything else. And I do agree with that, but oftentimes, where it's not our choice, you know, the customers have a requirement, and sometimes it may be a security policy that they have to host it themselves, and sometimes it's not a choice. So we have certain customers that are located within Canada, for example, and for them, the data has to reside within Canada, and some of the headless systems that we've been looking at or been using, they don't have the option to be to host it within Canada region data centers. It's, you know, it'll be within North America data centers, which is from a location wise, is fine, but from a policy wise for that particular customer, it's not fine, so we don't have a choice. So having at least the option to self host at least gives us additional options for those customers. We just need to keep it simple. At the end of the day, whatever options we're picking, whatever solutions we're picking, keep it simple and keep it simple for those customers, because these are long term investments, and sometimes, if you if you're adding complexity and introducing complexity where it doesn't really give much benefit, it's not, it's not going to be an advantage for that particular customer, total cost of ownership, because this is one that comes up a lot, especially when talking SaaS based systems. But what we often don't look at when we talk about cost of cost of ownership, or we don't pay much attention to, is API limits. Is the first one I'm going to bring up. Most of these SaaS based headless systems have specific API limits. And you might look at those limits and say, Wow, that's huge. You know, it's like 10 million API requests a month. I'm never going to be able to hit that. And then you go and hit and then you go and hit that, and then you have to, then you have the cost of overages. This is something that we. Have hit. When we first got into looking at headless, we had designed things in in ways that we had, you know, designed things in the past, and we hadn't really thought about API limits. 

Because if I'm going and hitting a database that's hosted in my own instance, I don't really care if I hit that a little bit, little bit frequently. I mean, I do become a performance wise, but I don't from a from a like, I don't have a sequel call limit, right? What I'm looking at is CPU limits and resource limits, and if I'm not hitting those, and then that's fine. I'm looking at response times, but pay attention to those API limits. You. We, we, when we did this, we were not aggressive enough with our caching strategies. We learned this the hard way. We had these massive API limit overages. Thankfully, we were working with, you know, a very thoughtful and good partner content AI, and we, we, we figured something out to manage this, and we weren't penalized heavily as a result of this, but they worked with us to go and figure out where the calls were, where we can make those optimizations. So if you are going down this route, in any case, down the headless route, pay attention to those API limits and those you know, because it can bite you very, very quickly. And we're also seeing more and more with next years, with notify, with the cell that there, they are making much more heavy use of middlewares, particularly for functionality. And again, you have limits on the number of calls you can make for the middleware and those edge computing again, pay attention to those, because particularly with the middleware, you're going to be making those calls every single request, or almost every single request, and they start to add up very, very quickly. And it can be very, very difficult to take all of these into account when you, especially when you're new, you into this, into this world, and you don't know exactly what's going to be an overage and what's you know, what's going to be an API call, what's going to be an edge function call, how many of these am I going to am I going to call? It can be quite difficult to calculate and on total cost of ownership. Also, I think one thing we don't look at is the cost of the business costs and the opportunity costs. Because if you're moving to these new particularly when you're looking to re platform completely, there is an inherent business cost and an opportunity cost there where, if you want replatforming, you could be using that time to be looking at new business, new marketing initiatives, for example, if you're going to be doing a big rebrand, for example, then that is an ideal, ideal time to look at replatforming. And that's often case when we when we look at these things, but we're also hearing cases where people are just looking to re platform for the sake of re platforming. And this, this old image came back. I love this old image from several years back when, you know, cloud became very, very big thing. And just because it's just because we're moving serverless, doesn't mean that there is not some computing involved. 

I mentioned those edge functions and those middleware functions. This isn't when we first started on our headless journey. We were taking the jam stack paradigm where, you know, we would statically build out websites and deploy those and bring me back to those front page and those Dreamweaver days. We would create a website, statically, manually, but statically, and then we would FTP those up to some sort of a server. The JAMstack approach was similar to that. And then we'd kind of build up functionality, progressive enhancement. We used to call it in those days, by, you know, layering on some JavaScript functionality, some calls to, you know, probably not in the early days, not calls to APIs. And then you build up, you know, your mobile, your CSS and imagery and things like that, for example. But yeah, again, it's, it's, it's somebody else's computer. It's going to cost you money, scalability. Is a big, big benefit of headless, composable approach. And you know, the geo scaling capabilities, the edge computing scalability gives you, you know, these quick, quick response times, functionality has been calculated closer to the closest note to that user, and they get a very, very quick response time. But, you know, this reduces huge amounts of latency as well on the systems that matter. But I think one thing we have, you have to ask the customers, have to ask themselves is, do you actually care about geoscaling? Not there are we. We work with customers that truly do need geo scaling. They serve customers in every single market across the globe. We also have customers that serve one very specific customer. And I'm not just talking North America. I'm talking about very specific states, like maybe even just the northeast, Northeast region of North America. We even have one customer that predominantly serves with one city in Canada. Do they care about geoscaling? I mean, not really. What they want to do is serve their local market and serve their local market very, very well. There may be some outliers there where they get somebody who's visiting from out of province, out of state, because, you know, they're traveling, they're visiting. Maybe they're looking up something for a relative, for example. So, I mean, take that into consideration. But that, you know, do look at your traffic, the stats, your Google Analytics, to see what market are you serving. Where is you know, where do you need to make that experience the richest? If you don't need, if you don't need that global scalability, then maybe you're over complicating things right now and then. Do take into account that if you have some internal systems, some internal databases that what you're serving up needs to access. It doesn't matter if you're if you're using edge functions, there's still going to be some latency involved there, because that edge function isn't going to need to call back to your internal system. And that internal system, maybe it's just in the Washington data center. 

Microsoft data center is where you host it. That edge function needs to call back to that data center. But you also need to now secure that endpoint. So you're going to want to use something like the cell secure compute so that the only instance that can access that database or that back end API you have is that up that you have, because if you're just using regular, edgeless edge functions, then it's, you know, the IP address range just changes all the time, so you need to then restrict that down. And then when you're using something like the seal the cell, secure compute, it's, it's, it's hosted in a specific region with a specific API IP address. So again, you you've removed the benefit of that edge functions. And again, it's only depending on what you're doing or what you're not doing, right? I don't know it's particularly cool if it's if it's just specific to some member functionality, then maybe, you know, you're okay with the members logged in, and they're going to see a slight delay as a result of that. Which brings me on to some, some the monoliths, right? And we know that the traditional monoliths have been notoriously difficult to operate. And as a result, the cycles that it takes for you to see and that it takes for you to see new features being added are often quite long, usually their annual releases, yearly, yearly releases. And for you, given the given how quickly the modern tech stack technology is moving, that might be quite long and quite slow. And of course, right now, every single person is and every single company wants to launch out all of their AI powered capabilities. Right? This is a big marketing push, and we're seeing that with every single CMS vendor, so which brings me on to what I deem to be the modern era of SAS based, all in one DSPs. What I want to call out is a majority of these here, at least, are.net core based. Unsurprisingly, because I'm, you know, my given my.net core.net background, we've been working with systems like experience by came to go, and Umbraco has been around for a very, very long time, but it's now.net core base. Same with Optimizely, which was epi server, also.net core based system. Dot CMS is an all in one dxp, Java based, I believe, but you can also work with it with other technology sets just due to its APIs. But these solve some of the pain points that we had had with these traditional monolithic systems. And this is why hang i This is why I would not deem these to be monoliths. These SAS. These are also SAS based solutions. You can just pay them the money and they will host it for you. You can also take your choice and host it yourself, if that is a requirement, they're extremely easy to operate because they're these.net based. Systems, where you just reference one NuGet package and then xperience by Kentico, for example, will release month, what they call month, which new functionality every single month. And they have a very, very well defined roadmap, and you can see what's coming up in the next three months, what's in the longer term roadmap. Obviously, go test to them and get them to bump up the variety of some of those, they will host the solution for you. They will deal with the scaling. They will deal with the security, you know, so if there's any patches that need to go out, they will go ahead and patch that that system for you. And we have also seen with these types of systems, because they.net core base that it does solve some of the issues that we had had with the traditional systems, with our front end processes, these.net systems will actually also run on a Linux system or a MacBook directly without and so the developers can be involved in that process without Having these separate repositories and broken down, broken down processes. I also do want to call out cycle, particularly their XM cloud offering and also uniform. If you guys haven't looked at those, do take a look. Look at those. I'm going to shout these out as the original composable monolith. I'm going to call them Sitecore uniform. They both have a they both provide headless and composable products. 

They follow all of the modern guidelines for what I would deem headless. But they have a they have a suite of products which are already integrated so you're not having to do the glue work and the piecing together. So cycle has offerings for XM cloud, which is your content solution, your CMS personalization through cycle, personalized CDP for gathering of customer data in the background. They have content hub for the dam solution and cycle search, for the search integration. And uniform has a number of products around the CMS personalization and the mesh system as well for integration of back end systems. So it's not the traditional what I've been doing all in one XP, but I'd say these are the kind of, kind of traditional, all in one, composable systems with full integration. And so when I talk about what I do, what I had been calling internally, the Goldilocks paradox, where things are either too big or too small or, you know, not quite right. You know, not too integrated. Not integrated in enough. And now what we're seeing is things are just right. The industry has been dealing these, deeming these as headless, heavy COVID, headless, and even the new term of universal, CMS, people are visual. Unsurprisingly, I'm a is one of the reasons I get up. Got into web development. I like development, but I didn't I didn't like traditional development. I like visual elements. I like the HTML, CMS, CSS, JavaScript, and unsurprisingly, people also like to build pages visually. They like to add components. They like to edit the content. They like to look at the content hierarchy. Versailles introduced in next js, some important features a little while back, seeing that as last year for Live Edit CMS, I think sanity, from what I understand, sanity is the only one that's back integrated this into their CMS. But lots of other CMSs have visual editors. Contentful had has had a visual editor for a little while. Content stack just yesterday, announced that visual builder. So what all the all of these headless systems, traditionally were just content there was no editing, there's no preview, there's no visual aspect to these. And just a few weeks ago, Contentful also just acquired nine tailed, which is a personalization product which integrated directly into Contentful visual builder, because, again, people are seeing that these separate systems become difficult. People are visual. People like to do the things that they're doing for the web. They would like to do that within one platform or within one solution. And they want to, they want the simple tool to handle all of those use cases. And we also seem to, and it's a bit long standing, we also seem to deem people into buckets of technologists and marketers, and for I think, as developers, as technologists, as implementers, we need to think about who. 

Who, who are we actually building this system for? And it's the CMS systems, the expertise that we're building are actually, in my mind, they're not, we're not actually as implementers. We're not actually building for the end users, and we're not, definitely not building for the developers a lot of the times, right? What we're actually building for is the marketers and the content authors. They're the ones who are going to be using our implementation day in day out. They're going to be spending way more time in this system than the developer will be right, using it day to day, and even an end user will be it's going to be these the content author's job is probably going to be eight hours a day to go into this system. So think about them when you're when you're when you're building these solutions. And what works? What is going to work best for them? Is it going to be headless, composable system? Is it going to be a an all in one, dxp, which can also deliver headlessly? By the way, they do have omnichannel capabilities. Is your team actually ready to work with different systems? And also we're looking at new systems. Just bear in mind, is the problem our dxp, or is it our actual implementation? Because we've seen this a lot as well, where people will blame the solution, the system, but actually it was your implementation that was not done well. Wasn't following best practices, or it didn't the implementation didn't fit the needs of your business and your content authors. We've seen that a lot as well, even down to how the content models, the templates are designed make sure actually flow fits the flow of your content authors and how they are working and how they need to get their job done. Headless and composable is not going to be a silver bullet and once at the end, I just want to just want to, I don't know if you guys have heard this story that in the 60s, NASA, kind of you know as a space exploration for the first time, they discovered that ballpoint pens, ballpoint pens do not work in zero gravity. So to combat this problem, NASA scientists spent a decade and $12 billion to develop a pen that writes in zero gravity, upside down, underwater and in almost any surface at any temperature, from, you know, below freezing to 300 degrees Celsius. And the Russians used a pencil. Now I'm this is another myth. And actually, the pen was developed by a private firm called the Fisher pen. But you've probably heard of the NASA Space pen. It's a great, it's a great myth. I love this myth because when you are considering composable and the need for best of breed, you know, and looking at, you know, I need the best system for all of this, first look at and evaluate whether you actually need, need to follow this room, you know, do I need a space pen when actually a pencil will do maybe for our business, an all in One dxp is actually going to be the right tool for us at this moment in time and the and the foreseeable future. And with that, love to take some questions. There's only one so far. How do you determine as an organization that all in one, dxp is the right solution for you. 

How do you assess when it might be the time to move to fully composable from all in one? And actually, I think you and I both talked about this before, before picking a product, before tip picking a technology set. Do some road mapping. Sit down with your business. Sit down with the stakeholders. Look at what where you are, what you want to achieve, how you get there, and what that looks like. And through that journey that might, that might be, you know, the it might be that you know what we need to go to a composable solution. It's going to really, really help us. It's going to improve our business processes. You might also find that you know what this other dxp with some slight tweaks and customizations is going to be really, really a good fit for us. And go in with an open mind. Don't look at your traditional DX piece that you may have been working with. Look at some of these modern, modern offerings, because we are founded to solve a lot of the pain points that we had had with traditional DX piece. Makes sense? That's the only question I see Kamruz. If you guys have any other questions. Just post them in the comments and we'll try to answer that back to you. Thank you so much for joining this webinar. Thank you everyone, and yeah, as actually said, feel free to connect with me on LinkedIn and DM me or email us, and I'll get back to you with something right i.