01 - Introduction to Composable Commerce

Show Notes

The very first episode of our podcast, an introduction to Composable Commerce. What is it? How does it work? But most importantly, Why do you need it? Explained by our very own Jamie Maria Schouren, CCO & Founder of Deity.

What is The Commerce Composers?

Welcome to the Composable Commerce Podcast powered by Deity (Acquired by Ultra Commerce), the leading platform for Composable Commerce. In this podcast we explore the world of Composable Commerce: What is it? How does it work? And most importantly, how will it help businesses grow? We talk with online merchants, agencies and tech companies about their experience in Composable Commerce, including some of the biggest retailers in the world. So, do you want to know everything about it? Please hit the subscribe button so you won’t miss an episode.

00:00:00 Jamie: Hello, my name is Jamie and I'm the co-founder of deity, a deity. We developed a platform to help online merchants adopt composable commerce so they can grow faster than ever without limitations. This is our first podcast. So today we're going to talk about the basics. What is composable commerce? Why is it changing e-commerce so much and who is going to need it? But to do that, I have to take you a little bit back to the past and where we started to build e-commerce. So when we started to build e-commerce, we basically brought our shops online, we put our products online, added prices, added buy buttons and much more taking it from there. We then eventually grew to personalization, I chats and whatnot. I mean, the world has been changing a lot, but the software architecture and the way how we build it hasn't changed that much for the last years, but we see a change happening right now. So let me take you back to how it all started. So when we started to build a platform, we built it as a way. We call it a monolith. So monolith is the software architecture name for the structure that we're building. And that sounds very complex, but let me explain it to you. So what we did is we built a shop, right? So we just started a code base and we started to add some things to that and then add some more things to that make front end look cool. And what we got is a very big box of code, let's call it that way, a big block and just everything happening inside that one block of code. And that is what we call a monolith. So there's one piece of code with a very big piece of code, for that matter, but with a lot of things added to it and in it. And what you get is one code base, obviously, but that's also very heavily depending on itself and when something goes wrong, the whole thing goes wrong. And we generally only have one developer or a team of developers who knows how it works. But there's also some good sides to that because we have one code base. It's easier to start, easy to develop, easy to test, better to maintain what you're running. Basically a one developer show. And the cons of that is that obviously we're not flexible. You cannot really extend or add new things to that. Eventually it gets really hard to maintain, and it's not so reliable because a one piece block of code, if something goes wrong, everything goes wrong. So it's not really suitable for fast growing websites, and definitely not for the ones that we have today where we have to process a lot of data. Want to add very cool new features and, you know, do some very cool, flexible stuff with that. So about two years ago, there was a thing that we said, okay, let's go a little bit wild and let's go heartless. So what did that mean? It means that we said, okay, let's break down the software architecture of a website and cut off the hat. Cut off the presentation layer. The heart is the layer that people see on the website. So your front end that separates the front end from all the business logic and from all the back end. And why would we do that? Well, basically why we do it is that we don't have a front end anymore. That is depending on the backend. So if something goes wrong, your customers can still see your shop, place orders and do stuff with it. We also have a lot of performance advantages because the front end is not connected anymore directly to the backend. It also means that it can have much more power to it. It can be much more faster. It can be much more easier to use, it can be much more scalable, and it is much more flexible because I don't have to depend on what my backend developers are doing for me to, for example, change colors or add new buttons or add new features to that. And the cool thing is that my developers are going to love it because they can work in separate teams. Backend developers is kind of a different species from front end developers, and if they can work in separate teams and do not have to be bothered by each other, I mean, that's a good thing, right? It increases productivity, it increases communication, and eventually it increases the quality of your product. But going heartless. So having a front end separate from a backend can also have some disadvantages, because in the backend you still have that one massive piece of code. You still have that big block that is going to bother you eventually if you want to do some bigger and more business with that. For example, if you want to run different languages or want to have a B2B and a B2C shop, how are you going to do that? How are you going to do that if your business processes are still all stuck together? And what if inside that whole big piece of code you have, for example, a payment method embedded and it works fine, but there's a new one coming up and we all want to use that new one, and it's much cheaper and it's better. And now you as an online merchant have to try to get rid of that old one and build in that new one. It's like, you know, we're moving some pipes from a kitchen that's already there for thirty years. That is going to be really, really hard thing to do. So it's not flexible. It's not easy to change the process once it is built in so tightly, to be able to move faster and to keep up actually with all these new future applications. That's where we need a little bit of a different architecture. We need to go beyond that front end, heartless platform. We need to take that next step and also have that benefit from going heartless. We need to get that benefits to the back end. So what we do then is basically an idea that is called composable commerce. Composable commerce describes a practice and what we think of as a tech architecture. So what composable commerce basically does from a tech point of view, is something that we call an architecture Service oriented architecture. And short. So. So what does so what does is that it has a separation of different services. So we have a front end which is my service. And then we have several services in the back end for example payment or the management product search and many many more. So my services, instead of having them all together in what we just learned, that monolithic piece of code, all these services exist as a separate service. And the good thing is I can build my own. So let's say I would love to build my own stock engine, but I can also use SaaS services, for example, for search. So I can use let's say Algolia for search, and I can use PayPal for my payments. And then I would love to combine that with my own build stock service. So all these things together are different pieces, and I know it's been used as a very popular term in e-commerce, but let's think of it as a Lego. You know, I have all these separate Lego blocks and I can stick them all together and build, actually what my business needs. On top of that, we obviously need something that is going to control and orchestrate all the data between these services, because we do not want to connect them directly to each other. If we do, we're going to get like a spider web of data running around. And that's definitely not what we're looking for. What we want is one place that connects with all these services, takes that data, controls it, makes sure you can orchestrate it, make sure you can modify it if needed, map it and do whatever with it, and then sends that data back and forth between all these services and between the front end, like a very big data control center. One main point that takes care of everything, and that is something that is called a commerce composer. So that part in your software is going to be called the commerce Composer, which connects with all these different services. So we have a Commons composer in the middle. And then surrounding that we are able to compose our commons and then in the more business way of the world, being able to choose best of breed. So say, okay, there's five different search platforms out there and I'm going to choose the best one for my business. I can add my own service to that. So all those things are being connected to the Commerce composer. And from there we're going to push it to front end, which can be one and which can be multiple, as we can say in the Commerce Composer layer. Hey, this is going left and this is going right. So we can decide by ourselves which part is getting which information. So if you're working with these different services, there's always a way you need to connect with them. And the Commerce composer is making sure you can do that in an easy way, because each platform has certain rules of the game and you have to tweak the things, right. You as a merchant, as a developer, have to tweak how all these platforms work together. And instead of building multiple integrations between them and creating that spiderweb, we use that Commerce Composer layer to make sure that the really join well and match well together. So composable commerce, from a tech point of view, is a service oriented architecture where we separate those services in backend and in front end and where we say, okay, I'm going to use services that are needed for my business and I can pick them from anywhere. I can combine my own services with existing services. The good thing is, I do not have to make integrations between all of them and create a spiderweb, but what I do is connect them all to a commerce composer, and this part allows me to orchestrate my data, to map my data, and to distribute it to all the different services that are needed. From a business perspective, composable commerce is really a change of perspective. What are them picking? One platform, for example Magento, BigCommerce or something like that, and then see what kind of plugins they have available. What I do now is really choose what my business needs. So I'm not restricted anymore to a platform and the plugins. I am fully in control of choosing what is best for my company. Obviously this can be BigCommerce and Magento and all these services, but rather than building integrations inside them, I'm going to build integrations next to them. So my search is equally important as my commerce engine. Let's call BigCommerce and Magento that my payments, etc. they're all equally important and equally a puzzle piece of my whole commerce puzzle. Composable commerce, from a business perspective, is also an evolution and not a revolution. So we do not ask you to throw away everything that you have. You've built a good business and you've built some tech, and some tech is really, really good in that. And it's really unique to your business and something that works perfectly. We do not ask you, with composable commerce to throw everything away to just, you know, get rid of everything and to, uh, to just say goodbye and, and start a whole new platform. What we do is we say, okay, let's connect to everything that is there. Let's connect to the service that is there and that are working good. And then let's start replacing the services that are less good or need some improvement. So we can keep the core of the business that have been working fine, and slowly start replacing parts that have not been working fine or that needs some improvement there. So from a business perspective, again, composable commerce is really an evolution and it's not a revolution. It gives you a possibility to be really, really flexible. You can keep up with your customers, you can build the best experience. You can really try easily new technologies. You do not have to bother your developers with everything that your marketing team wants. If your marketing team wants to try out a new feature, for developers do not have to integrate it in the main platform and do a lot of work. And because integrations are not easy in monoliths, but rather they can just connect it to that commerce composer layer to that composer, which then transfer the data. And it's really, really fast to adapt a new feature, even Gardner said. So Gardner is saying, hey, the people who in twenty twenty three have adopted a composable commerce architecture, they can implement new features eighty percent faster than the ones who did not. And that really gives your business a huge advantage in scalability, in processes and values, and obviously in customer experiences. So why do you need composable commerce? You're going to need composable commerce. If you're fast growing online merchant and you want to grow even faster, you want to expand, you want to keep up with your evolving customer needs, and you want to try new features that are coming up. You need composable commas. If you have a marketing team that is complaining that it's taking very long to introduce new features, you need composable commerce. If you're stuck with one platform and one developer and you feel highly dependent on them, you really need composable commerce. If you want to be future proof, because composable commerce is going to give you the opportunity to build a flexible environment that is trustworthy, that can have high volumes of data from different sources, and that can really help you grow fast when you're adding complex structures to it. You can have your own tech team building on the thing they've been building forever, while you keep on using other services to grow even faster. You do not have to build everything yourself anymore. You can build feature rich and very engaging services without having to use that main platform that you've always been using, and see if they have the right plugins. You can actually choose. Or rather, your marketing team can choose the services that they want to use, the new ones you know, the on edge things that are coming up, and your developer team doesn't have to be bothered by integrating them in the main platform. You can keep it safe from all these new stuff while on the other side, use it and test it on the front end. So a good example of composable commerce is a project that we did with a company called Jimmy Brings. Jimmy Brings is one of the fastest growing e-commerce companies in Australia, which delivers alcohol to your door or to your party within thirty minutes. And it's cold. So the cool thing is that they obviously have a massive service that's running around like crazy, and you see them all over town. So imagine their stock services. They need to know, can we service that area? Yes or no? Is a driver nearby? Do we have stock? But also do we have stock in the fridge? And how long has it been in the fridge? I mean imagine the amount of data that is going through that service. So Jimmy brings was growing and they grew really, really fast. And I think due to Covid, you know, had a hand in that, that they grow even faster and they needed an environment that can help them evolve and keep up with that, but also make them future ready for new stuff that is coming up. And what they did is that they, you know, they started building the platform and they were growing and growing and growing and all of a sudden the platform couldn't make it anymore. And they literally said, we knew we had to focus on where we wanted to be, and not just on patching the holes so we could deliver on customer expectations at scale. What they did is they then choose deity to help them to get there. They wanted to make sure that everything could work together and that is where deity comes in. They want to focus on business and then we could focus on connections and orchestration. So the business that they had is a very complex, as I just mentioned, and they built some very interesting own, let's say, custom bespoke services for that. They have a bespoke stock service and, you know, the driver feedback and all that kind of stuff. But on the other hand, there are fast growing companies. They want to use the SaaS that is out there. They won't use talent one for their marketing. They want payment services that are modern and flexible and local that are fast. They want to use services like for example, Contentful to create better content. They do not want to build everything themselves. And basically, with having these bespoke services and combining them with these existing services, that was going to take them a lot of time and a lot of effort. And basically they were going to have to build a spider web. So for Jimmy Brinks, they wanted to focus on their business, and they didn't want to focus on getting all these services to work together. They wanted to move fast. So with composable commerce and in the end, with the data platform, they were able to combine bespoke services and existing SaaS services altogether and then build an environment with multiple storefronts. So we had, uh, for example, the web, and they also had native app storefronts all using that same data engine. They could then transform that data, modify map, and send the data to the right place with all these different services. So we had, for example, ten one for the marketing and then would create coupons which would eventually show up or be able to be used in the cart which was created by BigCommerce. And then the stock availability came from their own bespoke services. As you can imagine, super, super complex, but now went to a highly flexible environment. Jimmy can choose what is good for their business, and deity takes care of all the orchestration with the composable commerce principle. I'm very proud to have been working with the Jimmy Brains team, and to have such a complex, fast growing merchant helped to get even more flexible and much more faster than they were before, but also the performance of the team and the performance of the processes and how to adapt new features. In the next podcast, we're going to have an interview with Jimmy and with our own product people to talk about how it was built and what challenges they had and how they choose composable commerce, and mostly why they choose composable commerce. But the thing that makes me more proud is the following quote. They said working with the data team has been amazing. The platform allows the team to build with confidence and speed due to the design of the core, and the design of the core is nothing more and nothing less than true composable commerce. That means services in the backend, bespoke or existing services all connecting to a strong core. A strong layer that's been called the Commerce Composer, which orchestrates process, modifies maps, etc. all the data and then bring it to very, very fast front ends, which can be web, which can be native and which can be both. Would you like to know more about composable commerce and how data can help to get your platform ready for future growth? Please visit our website or send an email to Jamie at Datacom. We love to hear from you.