Joshua Warren  0:00  
O Mark stands for micro services API first cloud native, headless. No I thought omni channel when that that was first the big buzzword I thought that was kind of a big concept big word to kind of wrap your head around but try saying microservices API first cloud native, headless fast if he was omni channel, exactly. Omni channel mock or mock omni channel

Darin Newbold  0:36  
Good day and welcome to Commerce today. My name is Darren and I am sitting here as always with the commerce futurist Josh to to really help us out with some some really fun topics. And this one, well, it started out seeming like it might be boring. When we were prepping for this, I suddenly found Wow, this is some neat, neat stuff. So basically, our topic today is breaking it down at Mach Speed composable. That's not compostable, but it is composable. Commerce. Josh helped me out. This sounds cool.

Joshua Warren  1:15  
Yeah, so this is kind of two new concepts or relatively new concepts that more and more commerce teams are starting to ask us about and mock being the first one composable commerce being the second one, I gotta admit, I'm actually going to take it the other way around. Because MOQ is a little a little more technical, a little more complicated. We're gonna start with composable commerce and kind of before we dive in, if you've heard of headless, headless ecommerce solution or headless implementation, this is in some ways the not even just the next evolution in headless but like, basically taking headless times 1000 in a lot of ways. So composable commerce. Once we break it down, I think it's basically what it sounds like. But first, I guess the easiest way to wrap your head around it is if you think of your traditional commerce, implementation, ecommerce build things like that. Think of that as like a toy racecar that you might buy for your child, you buy, just a premade toy racecar goes for it goes backwards looks a certain way, versus composable. Commerce is more like buying your child a set of Legos that they can build into a car of whatever shape they want, even change it building other shapes. So basically, traditional commerce implementation, you're taking an off the shelf e commerce platform, maybe modifying a bit connecting to other ones, but you're not typically taking the whole thing apart and rebuilding it in some other way. Other than the way the creator of it intended. With composable commerce, you're basically encouraged to rip everything apart. And you really work with bits and pieces from here and there and combine them in unique ways to meet your customers needs.

Darin Newbold  2:58  
So one of the things I mentioned to you, Josh on this was the example, instead of buying microsoft word per se that has every which way to craft words on a page and create things, if I only need a certain level of basic text editor, but maybe the only piece that I really want is to be able to do text art. So I can write words around circles or make them wavy lines or whatever. What you're saying is, is I just by the text art plug in to my basic text editor, and I'm off to the races.

Joshua Warren  3:30  
Yep, Yep, definitely. And first of all, I think sometimes we date ourselves with our examples. Oh, yeah, I don't know if anyone listening out there still uses Microsoft Word, or if they're doing all their text ordering in Canva, or some other web platform, web three now. But anyway, to take your example a step further even. You can, with composable commerce, these building blocks, these Legos, they don't have to be things you buy. So you could buy that text art piece. But then you could say, Hey, I don't really like the printing system here, I'm going to write my own custom way to print this text art. And then you have a pretty module that you kind of plug in. So it's really, it's about having these very small pieces that you can put together however you'd like bringing the examples kind of back to commerce. One example is if you, you go out there and instead of buying an E commerce platform, you say, hey, I really liked this checkout system over here, I'm gonna buy this checkout capability. But I really liked the way this other platform this vendor, they have an amazing way that they store product data and allow me to maintain my product data. So I'm going to buy product data capability from them. And then I'm going to combine those two maybe with some other custom pieces connected in with other systems, things like that.

Darin Newbold  4:46  
Okay, that that makes sense. All right, but now kind of to take it to Mach speeds, if you will. Tell us about what is the mach

Joshua Warren  4:55  
architecture? Yeah, so I feel like it's not just our industry. things, a lot of industries. But there are two things we love, and that is acronyms and new buzzwords. And so moc combines both moc stands for microservices, API first, cloud native, headless, you know, I thought omni channel when that that was first the big buzzword I thought that was kind of a big concept, big word to kind of wrap your head around. But try saying microservices API, first cloud, native, headless fast a few times with omni channel, exactly. Well, you have to have omni channel mock, or mock omni channel, I don't know. But all joking aside, when you actually break it down word by word, it's not that complicated. So microservices, basically means instead of writing one big program, one big piece of code that does everything, for each and every capability you need, you're writing a separate micro service. So you might have a micro service that literally is just something that says, hey, is this the correct username and password for someone to log in. And that is completely separate runs as an independent service can be used by any of the other pieces of your mock architecture, and can kind of be very, not really dependent on anything else. And it makes all these pieces are very independent from each other. API first, the A and mock, that means that all of the functionality, and all of these pieces are exposed via an API. I think most of us are pretty familiar with API's these days. But all an API is is a defined way that another piece of software can talk to a piece of code. So that's kind of, that's what allows you to connect these different Legos, so to speak, cloud native, as someone who first started learning, programming, while programming in the 80s, and software engineering in the 90s, cloud native is a shift for me. So I am very much used to sitting down writing a piece of code and really thinking, hey, this is going to run on my computer, maybe it's going to run on one server out there. That's it. Cloud native means you are really focusing on I'm writing something that may never run on just a computer may always run in the cloud, may not even run on a typical server may be running on all sorts of different capabilities that services like Amazon AWS provides. So it's really about as you're building out these Lego blocks, you you're designing them so that they run wall in the cloud. And then the H I mentioned kind of at the top of the show that all of this is based on headless, the H stands for headless. And if you're not familiar with the headless that basically means having a way that you can seamlessly keep your front end experience and your back end code separate so that maybe you have a kind of current before composable commerce kind of current way of thinking about headless, you might have an E commerce platform that you really liked the technology, you really like what it can do, but you don't like the user experience it provides, well, then you can buy that platform and implement a headless front end on it, which basically means you're building a custom front end that does whatever you'd like. So in composable commerce and with this Mock approach, everything is designed with a headless implementation in mind out there, and that was a lot of buzzwords pretty fast.

Darin Newbold  8:15  
So yeah, yeah, I'm gonna hit Moatize there. But no, this is all good. And kind of for the simpler, people like myself, I'll put that out there right away. When you were explaining this to me, I kind of use this as the example. And because I liked the Marvel Universe, and superheroes, I was thinking of Iron Man. And when you think about Iron Man and his latest suits, they were all nano nanite technology. And so basically, it meant he could have whatever turn into I mean, a suitcase or whatever can turn into his suit. And it would move and on the way, what you're describing is kind of like that, from a commerce perspective, or a programming perspective. Oh, definitely, definitely. And kind of just like that, that example, you can very easily pull different pieces out, change them plug in other pieces, it can, it can definitely, it is a lot easier and quicker for it to evolve as your business evolves, do you. And I'm gonna put you a little on the spot here, because we didn't talk about this in advance. And I always like doing that. So anyway, is there some examples of where you're, have you seen this? And we is this out in the wild? Or is this still thinking about it?

Joshua Warren  9:24  
There's actually there are a few examples. It's something that's really emerged in the past couple of years, and there are even platforms that are appearing that specialize in this approach. I don't know any of them off the top of my head, that's fine. But there's a couple out there we'll find in some way we can put them in the

Darin Newbold  9:39  
show notes. Okay. And I guess thinking thinking from the listeners perspective, and definitely a merchants perspective, what's the advantage here? What does this what does this really get me and why would I? Why would I want to go down this approach? Because often, new approaches like this, they tend to be more expensive in some way. How does this help

Joshua Warren  9:59  
ya This is definitely one of those technologies where eventually this will be, I don't wanna say inexpensive, but this will be affordable for merchants of all sizes, this will be, I feel like the way commerce is done within a few years. Right now, it requires more of a technical team than maybe your average smaller retailer. So I would say if you have a, if you have an in house team, and you're supporting, say, an in house platform or in house integrations, now's the time to look at this just because it will, if you start building, even if you don't replace everything and say, Hey, we're going completely composable completely mock. But if anything new, you're building any new code you're writing, if you follow that Mock approach, then it will be easy over time to move in that direction. It's interesting.

Darin Newbold  10:47  
One of the other pieces that I was thinking of on this is this is almost like the brand new entrepreneur, starting their business. And you think of all the little tools that that you grab to do. Okay, this is the best in breed. So you grab that and you grab the other one. And then you end up having to get some integration tool like a Zapier or Infogram out or whatever that puts it all together. And now, instead of having to do that, having those tools already be instantaneously be able to plug and play in way.

Joshua Warren  11:18  
Now, I can definitely lower your cost of ownership and even just your headaches over time.

Darin Newbold  11:23  
Amen. Amen to that, and happen to manage all those tools. Wow. All right, any last thoughts on on mock and composable commerce,

Joshua Warren  11:33  
just that I would be interested in hearing from anybody out there that's listening that if your team your company is going in this direction, experimenting of this technology, let me know how it's going. And kind of this is another area where the best practices are still evolving? And I would love to chat more about that.

Darin Newbold  11:49  
Yes. And probably some of the less than best practices might be evolving as well. Those are always the ones we find first it seems like Well, yeah, that's because Murphy hangs out there so well. Anyway, good. As always, thanks a bunch for joining us on this episode of Commerce today and we wish you all the best. See you next time.