Ep 3: Unlocking Composable Commerce Benefits with Ray

These new technologies in ecommerce are not always a silver bullet, I would say. Always look back to the digital transformation - what are my business needs and what elements fit in to this architectural and stuff. Simple.

- Ray Bogman, Adobe

Key Takeaways

🫴 Composable Commerce is an architectural approach to e-commerce that lets merchants build applications using individual, loosely coupled business services. Components can be scaled, upgraded, or replaced without impacting the entire system.

🫴 It offers flexibility, scalability, and adaptability for businesses. It simplifies cross-border expansion, enables rapid development, and allows for the addition of new functionalities.

🫴 APIs, API mesh/gateway, and tools like Adobe Builder and API Builder are key to implementing composable commerce. These elements facilitate seamless integration, scalability, and maintenance.

In a nutshell, composable commerce helps businesses meet specific needs and adapt to changes in the market, while fostering collaboration between business and IT teams.

Episode Transcript

Everybody. We are back again. And today we are live with Ray. You know, the interesting thing about race is that he wears many hats. He's a tech evangelist by night and night, pro by day. He's from the lens. And in the past, his work for one of the largest Dutch telecom companies, I'm sure all of us have heard about a job, KPN, and he was heading I.T. security there.

But that's not all. He's also co-founded so many different businesses as CTO edge ICD Y real well hibiscus support this there's a bunch and today he also acts as a trainer and consultant really motivates and trains a lot of different folks and experts globally from what I understand thousand Magento experts worldwide since 2000 it's just mind blowing number.

Right now, Ray works at Adobe. He manages Global Support Software, a bit of focus on automation and we are super excited to have it on, to have a re on show. Today, I'm going to be talking about the key elements of composable commerce approach and I've done a lot there. I'm excited. But before we dove into all these different key elements and just understanding composable better, let's get started with a quick intro for our audience.

Tell us a bit about yourself. What do you do and how do you help ecommerce teams?

Well, thank you. First of all of these and this invites, I'm really happy and grateful to be on this great show. Well, I think you said already so much already. You know what's out there. Well, again, my name's Roy Bachman, based out of the Netherlands. Started with the Magento ecosystem 2008 beta version. Fell in love with the whole e-commerce bits besides the other things that you already mentioned.

And for the last almost five years now, a part of the Adobe ecosystem for a couple of months was still the official Magento, you know, the acquisition happening with Adobe, but I wasn't really happy where I'm currently at. Initially started as a senior business architect supporting some of the larger projects that we have within our e-commerce landscape. And now, since the beginning of this year, about to be helping our support engineering team as our global software support manager, making sure that our merchants are using the best software available and supporting them with patches where needed or doing some debugging.

Yeah. And you learn so much every day helping merchants succeed, right? That that's super exciting and fulfilling. I'm sure it's something to do every day. But as we were kind of discussing you, me about what are we going to talk about? I think my first thought was let's get started with like a baseline. And we are still early into Shell and composable commerce still.

And what I see is that different people approach it from different perspectives. So I would love to hear from you. How would you explain what's composable commerce to merchants that you talk to?

I think that's a really good question and we get that a lot. Actually. If you look at the definition of composable commerce, that's more or less an architectural approach to digital commerce that enables those customers merchants to build e-commerce application composed of individual business services. And they are loosely coupled and can be scaled, upgraded or replaced without impacting the either application stack, for that matter.

And I think one key word there is business, right? So from a business perspective, why is it such a game changer? What are some of the positive business outcomes steps brands and merchants can expect if they are thinking composable?

Well, maybe go a little bit back. And this might be interesting for a viewer listening in. When we started with Magento back in the day, and actually that was in 2009, we saw that there was a lack of commerce and content. So actually the company that we founded back then, we created a component that connected commerce and content together.

And you would say, well, 2009, you know, that's more than ten years ago. But you can imagine. And that's going back to the business components we've seen that having these different businesses and connecting them together and, well, not only replacing or upgrading or scaling them at once. Now the business, the scale up depending on their business needs. So if this merchant, I would say, or business needs to have additional content components, well, at Adobe we have a solution which scale am if you don't need it, you don't need to use it.

But this way it's like using multiple Lego blocks and fitting that together for your specific business needs.

Hmm. Interesting. By the way, like the whole Lego block, you wouldn't believe everyone that we've spoken to have consistently mentioned that as an analogy, and I love that. That's like one common thread that's coming across it. When you think, of course, you think of blocks and blocks and essentially blocks that kind of fit together and make sense, right?

And that leads me back to the question, like, why is it a game changer? Why is it so important, especially in today's world where there's multiple channels, customers are changing our priorities as consumers also change so fast. We've seen that during COVID and then post COVID too. So why do you think it's such a game changer? And could you explain that reason in a simple way and maybe with one or two success stories that you see?

Yeah, actually having the scalability and I think that's one of the things that I came across over the last, I would say even decade. Maybe people will like to have the freedom to either replace or upgrade a component that makes sense for their business. And one of the most common ones is actually the front ends. So if the front end needs to scale, depending on the business needs, I think Atlas from that that's composable helps to focus on one element where the remaining business element, let's say the backend ERP systems still remain in place and this way it doesn't impact.

And I think that's the most important thing about the proposal is it doesn't impact all the elements within the ecosystem of the architecture.

You know. And have you helped any brand in the recent year or so or a couple of years actually move from a non composable mindset to a composable mindset?

Well, I actually this is a funny one. One of the projects that I've managed before while being not a support manager, I was involved with HP, which is a well pretty known brand, I would say. And the other one is one which is fairly known in the entire region. That's all Shi'a. All Shi'a there are known for H&M, Footlocker, Victoria's Secret.

And actually those brands are composable, for that matter. So if we look at, for instance, HP, they started off using Adobe Commerce as a base element. And with the future that HP juice they wanted to endeavor the use of BW studio our had those components. So several years ago we started architecture and now we can replace the current frontend which is embedded from a monolith within the ecosystem and start leveraging all the new countries that they needed to be on board us using that technology for the studio.

So I have this approach.

Got it. And are there any like immediately pulls? Of course, the full implementation cycle would take its time. You know, architecting, planning, implementing, going live. What are some of the successes or differences rather that HP started seeing globally when they move from monolith to composable?

Well, actually, and this is a funny way, since HP has multiple countries using Adobe Commerce, we already started from day one with a global reference architecture approach. And this global reference architecture to keep it really simple has one more base layer, one specific layer for all the necessary elements that we need to support the business and then come up with specific components like payment, shipping, their need for those specific countries, adding new countries already has that say 75% of the code that it's reusable.

So this way it's much easier to still having that JIRA on the front end as well helps you to scale up much quicker. So this way HP had the ability to really start architecture and planning out. That takes a little bit longer for us, but now going in months to come, years to come, it's much easier to add new countries, let's say, like Canada, United States or other remaining countries within Europe, using that data we have from that within the ecosystem of the HP dot com domain name.

Yeah. Wow, that's so interesting. And for brands who are today, cross-border is so important for brands to even smaller brands and younger brands and upcoming brands to think about and understanding that, hey, using something like a composable architecture, what you are empowering is also cross-border and how you can want to have the logistics, figuring out how you can actually walk from one region to another and without affecting your everyday business.

So great example. Thank you so much for that. Now I want to go a little, I think one level deeper. We've kind of understood a little bit about composable. I think the common thread of Legos definitely come across. I love this real tangible example of how composable can help brands with their different business needs. For example, if you are cross-border or growing across different regions, how can having a composer connected to help you?

So great, great examples there. But now going a level deeper, what could be some of these key elements and technical as you can it's totally fine they will build try to double click on things that I don't understand or I need your help on. But what are the key elements that actually make up the composable commerce, architecture, for example, UI components, business logic?

You give a little bit of it. You've touched upon a little bit of the stack, better explaining. SB But let me dove a little bit deeper into each of these now.

Oh yeah, definitely. One of the things that I'm really happy about on what we had Adobe Creative started off as a project called Adobe IO in the beginning, but now it's known as our builder. And actually our builder is this bridge that's not only connects, I would say composable commerce elements together, but also orchestrate this in a single fashion.

And let me give an example. So what in the ecosystem we have composable components, which is going to like search this life search has the ability to connect within our Adobe commerce stack, either on prem or on clouds, and make sure that the enrichment of the search data based on air has been available depending on the search needs and makes sense for those particular use cases.

Looking right now connecting those well similarly together within the ecosystem can for some some merchants require additional things to connect that well with the use of API builder. We have now one file, one JSON file and within the JSON file we can construct what API needs to be connected to. Well, the end point in this way, it's the app actually.

If you connect multiple endpoints together. So let's say you have a you have analytics, you have middleware, all those API endpoints can be orchestrated within this one file. We also called this the API mesh. So technically it's API gateway, which is used by technologies like antivirus. But these are being construct within one JSON file and now the power comes to light, having those singular composable elements like search A, A, B or whatever, we are able to use one single endpoint back to our from that.

So the from this so let's assume by the way, studio wouldn't need any data would needs to be constructed from using snap codes from my search data from and for that matter now it can be bundled together and shown that data in one singular graph will add data feed to this particular front. So in this way. So let's assume that we would need to replace or add a new composable common.

Let's say a new ERP system would be added or middleware layer would be added. Now would in this API mesh only small changes need to be made. And the interesting thing is and speaking I really like this, we sometimes see that I would say legacy systems using techniques like rest or so, then leveraging the new graph. Well, I would say technology actually this API mesh as a way to transform older technique.

So newer endpoints, which means that although we are using techniques on scope, like I just mentioned, that data will which will go into the front end will remain just graph and this way it doesn't impact the businesses that much from a business migration standpoint or from across perspectives and let's say that would replace this with a new technology.

Give an example MuleSoft or Lumi or whatever middleware is available using the modern technology that just need to update that file and automatically the front end doesn't impact. So that's why replacing newer on all the components has never been much easier, like using tools like Apple or within the ecosystem of Adobe.

And for for the audience will also feel curious about visualizing what Ray just mentioned. We'll link it out to a visual version of the architecture out in the blog and in our comments. So stay tuned for that one question that was coming to my mind is that for the novice, for people who are dipping their toes into this whole space, what can they find this information somewhere?

What are some of these, you know, resources online or in person maybe that you recommend so that they can dip their toes further, look at it, read it at their own time and understand the space better.

Well, I think I love this question, actually, to be really accurate. Yesterday, actually, Adobe Developer Life Events happens and that event was mainly just about composable handlers and all what the future holds. So I would even say keep a close eye on search for developer live experience. Those videos that will be promptly available anytime soon, but also the experience platform that we have at Adobe.

This is one source of truth for all related not only commerce but all related. Adobe products. So if you would start leveraging app builder or Adobe Commerce for A or a B or whatever component we have connected within this composable element, it's available on the experience link. So definitely everybody. So go out there and search for all the content that's available out the next to each other.

We are definitely going to lead this as well as the visual architecture up in the show notes. Audience So please stay tuned for that. Now, the next question, I think more moving into a space where, let's say as a merchant, I kind of understand composable now and I'm moving into my evaluation stage, right? So how do I do that?

What kind of business should I be to know that, hey, what? I'm an ideal candidate for composable, for example, are the key considerations, like a checklist that I need to kind of be aware of just to know that I'm making the right choice.

I think there's some motion, important question maybe that we are asking. When do we start with composable? Is it available from me? Why? What do we need to to worry about? Well, actually, this was a funny question that came around actually a couple of days ago. And long story short, at the end of this conversation, we concluded that having a discussion board workshop about digital transformation helps to define actually, you know, where are we currently as a business?

What needs to happen within the future and what elements can we start creating in a composable sense and this particular use case, having optimizations on the front end was one of the most crucial ones. So we concluded, it's like, okay, what kind of next steps is this particular merchant ready to go? Headless and headless in the broader sense, how do we construct it?

What kind of technology, you know, comes with that? But the conclusion was more or less that I needed to have a really good rapid UI that makes sense for their merchants to be converting more or less. And that was step one. But you can imagine going through those elements at some point, having a modern middleware layer helps them to construct this using the technology like little like we just discussed.

But again, I don't want to rush too quickly again back to the legal system. Be careful on what makes sense. Make sure that the business is ready because so many technology is ready to be used. But you need to make sure that the business is ready to use it as well as could be that within your organization, new skills need to be taught and new technologies need to be arising.

So always be aware that just adding a new component is not a singular. I would say success story takes a digital transformation to be successful at the end.

And that leads you to a thought in my mind. Like there could be challenges. There definitely challenges, but there could be also like points of failure and points of weakness in this whole transition. Right. In your experience and you have so much experience now helping teams even decide and move and probably implement and use composable. What are some of these top challenges that you've noticed across these years as teams that are espousing?

Or of course that's a really good one looking at our software issues that we will get in from from a merchant perspective, we get a lot of questions in regards to requirements. You know, some of the things that's really powerful about this composable elements is that they are ready to go and the product team, they're all involving new technologies on the fly.

But true, it may be that not all requirements match the business needs. Back in the day, there was definitely more flexibility to create those, but that had also across regards to total cost of ownership because you needed to develop everything. Now with the commodity of these services, these are services that scale, which means that the solution is available for everybody.

It's being maintained by the product team or to support them for that matter. But it could be that those small or specialized requirements that you used to have may not be available maybe over time. So this is more or less the discussion that we sometimes seems like, well, you know, we miss this. How do we go about that?

But one thing's for sure, I know that our team at least has full visibility on that, making sure that we deliver the best product available for the majority out there using well, the services like live search that actually have been available already for several years but all involve and that's the power of new functionality can be added really quickly on the back end.

So actually they releases weekly releases on monthly releases are just a common thing where back in the day, when did you wait maybe a quarter to get a new version that needs to be upgraded? Now we don't have that anymore. It automatically updates new functionality on the floor.

You know, and so there's like cost considerations to think of change management bringing in kind of like your whole team into the loop and all of that. Do you see that composable having a very strong business first approach to it? Is it more helpful for only business teams within a company or is it something that you've seen actually in the longer term really be a resource full and meaningful for even tech?

I think both in general. I mean, units, first of all, I mean, the business decides on what they need, want to well, continue the business in general. I mean, this is all where it starts. But they need to work together even closer now with indexing, making sure that available and scalable for that matter. And actually, you know, once you have baked a solution, that's what I'm seeing definitely with the larger ones, you know, that pick a solution at least for several years because that's an investment they make and that that makes sense for them.

And that's the thing. I mean, the power of composable is that it's replaceable really quickly. But you don't replace everything, you know, every month or every year. So constructing these Lego blocks together in a sensible way from a business needs, using that technology piece on that, then that's really powerful. And I think this is where actually the power lies being well and successful at the end.

Yeah, for sure. And any recommendations that you want to mention here to avoid kind of like avoid the negative that could come with implementing something new and different in your E commerce step?

Well, first of all, be open minded. These are new technologies. It's not a silver bullet, I would say. Always look back to the digital transformation. What are my business needs and what elements fit in to this architectural and stuff? Simple. I mean, you know, if it's just headless or if it's an ERP system and actually composable, it's not just about the front end, although many think about, you know, just from an elements, but actually it's the entire architectural landscape.

But having this constructive way where you can well it's mainly driven just on API. So having this construct this way on leveraging US APIs, using the APIs in the most sensible way, actually this is where the power lies and that helps you to evolve over time. Instead of doing everything at once. So please be aware of that.

Yeah, take it one step at a time. Take it piecemeal at a time and build your blocks. You know, one step towards totality the the outcome that you are driving towards.

And actually, maybe one last thing. If there no a no reason, don't do it.

Yeah. Have you yourself recommended that to someone anytime?

Well, I think from an architectural perspective, it's always important to not overdo it. I mean, once you start overdoing it, initially, the cost of will go up, but there's no actual value in that. So always look at the business needs, the growth, the digital transformation on what kind of necessary goods are available and make sense for this business.

And every use case would composable might be different for all the businesses out there. It's not just copy based. What works for, let's say HP works full time. Everybody has their own story, everybody has their own technology and also teams that need to adapt this new way of working.

You mentioned Ashby and can you highlight some differences like what are some of these differences? If that's your need for HP and someone else that you've actually seen, that's I think would be great. Kind of like a P.O.V. for the audience here.

Well, mentioning Alshaya, they have unique brands. I mentioned H&M, Victoria's Secrets and many other brands. So that means there are single label fronts and those from them. So they need to have a rich attraction from a user perspective. So they decided to use this composable element which is called Aqua Drupal, and they have been using it now since the early days.

And on top of that, the Aqua team has involved many new technologies that relate to personalization to surge, making sure that there was a rich environment available to supporting all those different merchants across all different brands. Again, it's scalable at HP. I wouldn't say it's kind of similar, but it's different in that kind of way. Since HP has one brands and all those brands have different countries and use different ways of expressing it.

And I would say what I really love about HP is that if you go over to the HP brands, I mean, besides laptop printers and things that have as well software that's available. And actually if you look at the UI and I think this is really impressive on what they've done, they have a centralized global UI, which means that you don't feel making a change between system A or system B and actually if you go to the shop is and if you go to a specific country that some countries they still have some of the older infrastructure still on the latest versions but using I would say a monolithic UI from that where the newer ones definitely in Europe they have the new technology, but actually you don't feel the difference because the UI itself is constructed in a global way. If you go to docs or to downloads, it's using different technologies as well. But from a UI, again, it's everything is centralized. So I wanted to make sure that the enrichments of the user experience is fully centralized, and that doesn't actually mean that underlying systems should be impactful about that from an overall user experience.

Well, this is actually a super cool piece, an audience. We're going to try and actually translate that into visual to just a difference between the two and how they approach it. Thank you. That's super helpful. Yeah, pretty much at the end of of our conversation. But I don't want you to leave it out. One final thought. Right. The holiday season, I mean, if you're in ecommerce in some way or the other, we all know this is the crazy time and in the context of holiday season, it's not just this, but there's so many upcoming in the new year, too.

How do you think or how have you seen it or how would you recommend brand strategy leverage the power of composable to see greater success, not just this holiday season, but going ahead?

Well, I think as once maybe comment, keep it simple and don't overdo it. And the reason why I'm saying this actually, I mean, we are in the middle of off, you know, all preparations and we still see brands struggling at some point. Well, first of all, what are my business goals objective? And then the technical elements come to place and sometimes communication from tech back to business may be difficult, I would say.

And let's say there's a big campaign being planned, but it didn't have the ability to test. So you can imagine if thousands of thousands or even million people visit your Web sites. I mean, that would be a good thing. But is the platform ready to support that? So what I always recommend is have a good discussion with the business and it to make sure that the goals are being spread across all departments and plan but also test these scenarios.

You know, is this campaign ready to be supported on the platform, for that matter? Because that will tell at the end if the business results are, well, positively, and everybody can successfully celebrate their common goal. But I've seen too many cases over the years that the communication again, between business and i.t. Isn't that smooth? I would say so.

I always recommend everybody be prepared, start early every scenario in place and prepare for success.

I love that. On that note, we are closing out today's discussion, but a lot to unpack in the short amount of time for sure. In the show notes you'll be able to find a lot of the references that Ray mentioned, including a visualization, a couple of visualizations around the architecture of the elements, as well as the comparison between HP and Chaya.

And what we're also going to do is link out the references to all the different Adobe products and the control panel for where you can actually find information on all of the different apps and solutions in the stack, in the composable stack of four. Thank you, Ray. This was a lot of information and a lot of learning in a short amount of time.

Thank you so much for coming on the show and hope to have you back again someday.

Latest episodes

Ⓒ 2023 Creative Sparks Inc.