Composable commerce strategies for scalable and agile e-commerce

Good afternoon. Good afternoon. Good morning. Welcome to the APAC Commerce webinar and thank you for joining us today. If you haven’t attended one of these before, this is a monthly series for Adobe Commerce customers across the Asia Pacific region and is aimed at helping you understand more about the commerce platform you’ve invested in, as well as the key business and technology trends that are impacting the digital commerce landscape today as well. My name is Ben Popplestone. I’ve been leading the Adobe Commerce post sales teams across the region for the last four and a half years. And prior to that, I was leading agency teams implementing commerce solutions globally. We all know that commerce is a rapidly evolving place. And today we’re going to be diving into the topic of composable commerce and how that can help facilitate the fast pace of change. Composable system architecture has been gathering a lot of attention across the digital community in the last couple of years. On one hand, it’s been seen as the antidote to monolith platforms, providing greater agility for customer experience and reducing total cost of ownership, both important levers for driving competitive advantage. On the other hand, there are some prerequisite considerations to ensure that the business can deliver and operate a composable model. At the start of this year, Forrester predicted that a third of digital businesses will abandon or restructure midstream projects that prove too complex to execute or maintain. So it’s important to get it right. At Adobe, our approach to commerce is a composed platform with composable capabilities, core capabilities and a scalable commerce foundation with packaged business services that provide advanced capabilities, and then the ability to extend further with for bespoke needs with custom microservices and apps. These capabilities are available to all Adobe Commerce customers and allow you to take a staged approach to your composable journey. Our presenter today is Shakir Anver, a Senior Solutions Consultant for Adobe, joining us from Singapore. He will be taking us through composable commerce strategies and the capabilities within Adobe Commerce. We are then privileged to have senior technology leaders from two Adobe customers joining us for a conversation on how they’ve architected their composable transformation journeys and the learning so far. Before I hand over to Shakir, this is a topic I’m sure will generate a number of questions as we go through the session. So please add any questions into the Q&A. We have team members here on standby to answer in line, and we will leave time at the end for Q&A where we’ll answer some of these live as well. If you have any issues viewing the content, please drop and then rejoin and we will be recording the session and that will be available through Adobe’s Experience League after this. We also have a few poll questions running throughout, so do engage with these as they come up. The first of these should be coming up now to kick us off. And whilst you’re just answering this poll question, Shakir, I’ll hand over to you. Thank you, Ben. Thank you. Hi, everyone. It’s great to be in this session and sharing about composable commerce today. And as Ben mentioned, composable commerce today is an important theme that we’re all looking for. And we’re all looking for a way to make sure that we are, as you guys said, working on composable commerce. Today is an important theme that’s going on. And what I’m going to share with you today is about the definition and the understanding of composable commerce. It’s a little gray today, I must say. But to clear the air there with the composable commerce definition, being able to explain what composable approaches it and what you should be and should not be doing to adopt composable commerce. So I think today’s session is about that. And with that, I just want to kind of start with an introduction about myself. My background has been commerce and data analytics for the past 13-plus years, almost 14 years now. And some of my career mentions is that I started as a Java programmer, but eventually progressed into leading commerce solution implementations, primarily across airlines. Then I’ve moved on to looking at decision analytics and data analytics across banks and telcos. I’ve also founded a semi-precious jewelry business back in 2011. 2013, 2014 was when I became closer to Magento. At that time, Adobe Commerce Now sold it off in 2015. And then now I’m also an investor and advisor for Pure Online gender neutral skincare in Southeast Asia. And I’ve done my commerce management certification. This is not on the technical side, but to understand businesses and how businesses are run, especially on the digital commerce space. So that’s a little bit about myself. And with that, I want to just quickly jump on to the whole meat of the session. So before we begin, I think one of the things that we really need to talk about is the digital commerce landscape today. And we must agree that digital landscape of commerce is rapidly and ever-evolving. Customer expectations. First, we know that your customers’ expectations are evolving. Customers want compelling and relevant experiences that are personalized in real time across multiple touch points and channels. So those expectations are set by the very best brands and experiences out there. So I think that’s one of the important points to highlight. As a result of that acceleration, as your customers’ expectations are evolving, digital commerce has continued to accelerate. Back in 2022, the increase in digital sales year on year outpaced that of the stores and grew faster than total retail sales. 7.3% of e-commerce sales, 6.2% of total retail sales. As a result, brands are improving further the digital experiences across markets, channels, and business models to capture increasing dollars spent via digital commerce. And now lines are blurring as well. We’re also moving to the omnichannel. So there is also a heavy investment done on digital transformations by organizations. All of this leads to increased focus on digital transformation to deliver the high-relevant and personalized digital commerce experiences. So this is a little bit about the current landscape. But then what are businesses doing to drive that innovation? So one of the challenges the businesses are facing today is basically they have to rely on a variety of solutions and often a lot of multiple vendors to deliver the solution, the overall solution to build a cohesive customer journey, bringing together dozens of individual services requires custom integrations, proprietary data exchange mechanisms, and custom UIs, and even administrative capabilities where business users are able to use. This could lead to a system that’s brittle, costly to maintain. Brands need a platform that helps them drive innovation. And we have to be careful when we implement such composable and modular systems today. So a lot of businesses today are adopting different approaches to taking this kind of architecture. One is, of course, the way of approaching is in-house. Everything is built in-house by the organization, usually have good control. You have to have good technical teams. There are some challenges there. On the extreme right side, what we would say is outsourced platforms that are managed and maintained by your external partners, usually the ones who run, build, and the solution. And there is also now a lot of the companies or organizations doing hybrid where there is an element of business user-friendly configurations, but at the same time, there is also the element of the technical element of it where integrations and all are required where a partner comes in. Underpinning this, I think all these implementation strategies, composable architecture is a theme of things where be it in-house, be it outsourced, or be it hybrid, a lot of the organizations are taking the composable architecture kind of stance and organizations are moving that direction. But later on this session, we’ll have to look at the way we implement composable commerce and how careful we have to be in terms of building the composable commerce architecture. So when we speak about composable commerce, we need to understand what composable commerce is. So in a bare-bone kind of definition-wise, what we’d like to highlight, it’s mostly composable commerce is a development approach by selecting best of breed commerce components and combining or composing them into a custom application built for your specific business needs. So it’s a development approach. It’s an architectural consideration, bringing components together, combining and composing them into an application specific to your business needs. Different businesses, different verticals will have different type of business services that are required for the customer journey. And for that, you need to bring the best of breed applications. And for that, to some extent, commerce has been composable for some time now. You may be getting, back in the days or even today, pricing from an ERP. You’re probably using a third-party search engine. You’re managing content from a CMS and so on. However, the shift more recently is towards more focused business capabilities. So what we’re talking about is having modules that are business-focused or business-capability-focused. These services should be designed with an API-first mindset or are designed in an API-first mindset, meaning the primary way of interacting with them is through the API. And they are often SaaS-like or SaaS functionalities, making it easier to deliver new features faster and cost-effectively. Services that have unique business services, such as search and merchandising or content management, pricing, in fact, even marketing automation, et cetera, can be modular services that can be stitched together. You bring these best of breed applications together, and then you’re basically exposing them as a solution. And the customers experience that journey using these different components. This approach, though, brings a set of unique challenges. Businesses are now responsible for stitching together these services to build cohesive applications, which also includes standardizing the way you’re sharing data across these services. So with the understanding of composable commerce, let’s see what this means for your business and your teams. I think there are a number of reasons organizations move into composable commerce. But what’s important is to highlight the key elements. And I believe there are six elements highlighted. There could be more, but mainly the six elements that we identify as a part of our conversations. First and foremost, it’s agility and flexibility. Composable commerce enables businesses to quickly adapt and respond to changing market conditions, customer demands. By using modular components, organizations can easily add or remove functionalities, integrate new services, and experiment different technologies without disrupting the entire system. This flexibility allows businesses to stay ahead of competition and rapidly innovate. There’s an example that I can talk about from my experience. There was a pharma company here in Singapore, but it’s a regional one. They had wanted to implement a trial marketplace. And what they really wanted was a simple logistics partner integration, simple payment gateway. And they just want to go ahead. And this was an implementation we wanted to do in pretty much six weeks. So this is one of those use cases that we can think of in terms of implementing for agility and flexibility. Then we’re talking about scalability. Composable commerce allows for scalable growth as business expands. You can keep on adding new functionalities, scale the existing ones, not only in terms of features, but also in terms of infrastructure. This modular approach eliminates the need to replace the entire platform again, reducing cost, minimizing the risk of disruptions during your high growth period. There is another example I can quote here from my experience, actually two, I would say. There were two clients, one in Indonesia, one in Malaysia. One was a retail department store, and the other one was a hospitality and entertainment. Both of them on their front-end customer journeys, they were experiencing integration bottlenecks. They had a lot of integrations to different systems. And as a result of that, Adobe implemented a certain solution that we provide for composability. And that’s being reviewed to kind of bring the integration down and the integration speeds from the delays from seven, eight seconds. It’s being brought down to roughly around four seconds now. So it’s a reasonable or rather a tremendous improvement in that sense. And on the customization, we’re talking about composable commerce, empowering businesses to create highly customized solutions or like modules to personalize customer experience again. Organizations can selectively choose which modules to include and which modules to not include. The inventory management, payment processing, product recommendations, et cetera. Another example that I can quote here is a fast food restaurant in Malaysia. They wanted a solution that would look at the speed at which the kitchen is operating so that this can be shown to the front-end customers, and they can decide which outlet they want to order from. So this was a pretty interesting one. They wanted to have a customized solution there. Then we’re talking about fast time to market. We’re talking about pre-built components, integrations already done. Developers can just focus on assembling it so you’re not building everything from scratch and you’re pretty much going really fast to market. We’re talking about cost efficiency. We’re talking about pre-built components. Again, instead of maintaining and managing a monolithic system, we’re talking about bringing in those components and reducing the development and the maintenance cost. Innovation and experimentation. We’re talking about bringing in new components where you want to experiment fast, fail fast, or be successful fast, and then move on with the business. So this sort of architecture infrastructure allows you to do that. The flexibility allows the organization to reiterate, evolve the offerings as they grow. Another example I can quote here is a fast fashion organization in South America that I’ve worked on. They wanted to try augmented reality. This is still in the works, but this is something of an example of experimenting and innovating. So these are some of the benefits, what it means for your business, and how you could leverage with composable commerce architecture. How Adobe allows you to do this is basically in three steps. In Adobe, we have the new Adobe API Mesh and App Builder. Adobe Core Commerce functionality already comes from an API first fashion. So SaaS-based services such as live search, merchandising, product recommendations, catalog, and payments, these are all SaaS-based services, separate components. And then we have the API Mesh that allows you to integrate and orchestrate third-party services and applications that can be integrated and exposed to the front end as a single graph. And the other one, the other part is where we allow to integrate, extend, and innovate. So basically we are talking about App Builder. App Builder has the capability to build some integrations and customizations, I wouldn’t say some, but a lot of integrations and customizations at low cost. It’s a serverless self-scaling infrastructure, minimal code to maintain, and basically what you’re doing is integrating that again to API Mesh, providing a single graph to the front end touchpoints. This allows you to standardize data and bring an element of event sharing. App Builder has all the I O events from Adobe Commerce, and that’s pretty much pushed towards the third-party services as well. And not only that, Adobe now has extended with our data and events connector, AEP connector to other Adobe platforms or products, and that pretty much allows you to bring in a real-time essence to an event that happens and then you can take action on it. So we’re not only allowing you to add on components as you go through API Mesh, but it’s also bringing in the real-time essence and personalizing at scale for customers. Quickly on Composable Commerce. So with Adobe approaching Composable Commerce with the App Builder and API Mesh, with bringing in APIs, we’re making it modular, being able to bring in service-based app. Now what we’re going to look at is what are the prerequisites that you as an organization will need to look at first in order to be able to embark on this journey. So we’re talking about API-first approach. Composable Commerce relies heavily on APIs and to connect and integrate various modules and services. Therefore, it’s crucial to adopt an API-first approach. We’re also talking about a modular architecture approach. You need to have well-defined boundaries to encapsulate specific functionality of business services. This needs to be identified at the beginning itself just so that you’re able to modularize and have a very flexible approach to facilitate integrations as well. Then we talk about service-oriented architecture. This is fundamental foundation for Composable Commerce. It involves organizing systems into a loosely coupled service, not only because of the functionality, but we’re also talking about independently developing it, deploying it, and scaling it as a service. So it’s very important to understand that we need to adopt a service-oriented architecture. As an organization, we have to think about a robust integration strategy. We’re talking about standardizing protocols, data formats, communication patterns for smooth operation. And this is very important because the different modules will need to have this sort of a structure in order to communicate seamlessly and eliminate any sort of performance constraints. Then we’re talking about component ownership. Very, very important, I believe. You have to establish clear ownership and accountability within teams, taking care of the relevant governances of each of these components, have SLAs, et cetera. We’re talking about governance and security. We’re talking about compliance and regulatory for secure APIs because it’s API-intense, authentication, data encryption. These have to be in place, and you need a platform that provides this. Then we’re talking about monitoring and analytics. Whatever the different components are doing, you should be able to track the performance, the usage, and the reliability to optimize and minimize any bottlenecks to improve the business performance. So with that, I think one of the things, the way to go forward is to start off with a focused commerce foundation. And what we mean here is to have those fundamental components of a co-commerce foundation to accelerate time to value, have those rich capabilities out of the box, minimal deployment and deployment time, and just straightaway have to go to market faster. So built on cloud native or highly performant infrastructure that is auto scaling and also reducing the risk of resilient, secure, compliant environment. So basically you’re looking at all the compliance and security checks in place in the beginning itself. Later on, what you can do on top of the commerce foundations is then add on services that you require for your business, roll out those capabilities rapidly using App Builder API Mesh in the case of Adobe Commerce, and then stay up to date with the services. And each of these services would scale automatically to the need of your business demands, reduce the cost of ownership, and get all the benefits of microservices and the complexity in a single platform. So microservices that work out of the box is also important, especially with the API first approach. Now coming towards the tail end of my session, one of the things or thoughts that I want to leave in everyone’s mind here is when should you and when should you not adopt composable commerce? There is a lot of talk about it. Some themes I think from my point of view. On the left side in red is when you should be, which is when you have a legacy system modernization and you’re revamping the platform. You could think of a composable commerce, rapidly growing plans of expansion, your business is growing fast, you need for unique functionalities, your need for innovation and experimentation, like the example I mentioned about the fast fashion earlier, integrating with one or more third party services and as you add on services, you need something that’s more manageable, like something like the API Mesh I spoke about. And if you’re working in a competitive fast-paced market where features and functionalities need to go fast and then you want to stay ahead of your competition, you need to think of composable commerce. But on the flip side, you also need to think of when you should not be implementing composable commerce or when you should be careful when implementing composable commerce is when you’re in highly regulated industries like banking, telcos, because each of those components will have to align to the regulations, which is a little difficult to achieve. Not that it’s not achievable, but it’s something that you need to think about very, very strongly and you have to keep a close eye on those projects. You need stable and mature e-commerce infra. If you already have a stable and mature e-commerce infra, it doesn’t make sense moving into composable commerce, but again, you’ve got to keep out a refresher for your infra time and time again as time progresses. The other way is simple. The other one is if you already have just a simple business, a simple product, a single product e-commerce requirement, it doesn’t make sense to over engineer. So that’s another reason why you should stay away from composable commerce. These days, a lot of events now that we are off COVID, short term, like temporary commerce implementations like bookings and simple ones. Again, you would not spend so much time going around looking for different composable modules. The other two are pretty much more strategy based or what you’re looking at in terms of competition. If your company does not have an e-commerce strategy defined yet clearly, I think you should still take a step back and not go composable commerce direction. Look at the business first and define it properly first and then move on and then make the decision. And lastly, one of the things that I’ve always, always seen is following competition. You should not follow your competition just because they’re following composable commerce. See if it is suitable for your business, your infra, your cost base and all that. Then take the call. So I think these are some of the things that I want to kind of leave your thoughts on. Of course, there’ll be more of these when and when not. Happy to hear in the quick Q&A. And with that, I would just like to kind of remind again about the poll questions. I conclude my bit of the session here and I would say back to Ben again.

That was excellent, Shakir. Thank you. Really good introduction to composability and overview of the composable capabilities within Adobe Commerce. Now, as I mentioned earlier, we’re fortunate to have two veterans of digital transformation join us today. Both are leading composable programs for their organisations and have agreed to share their experience of putting this into practice. So today we have Naresh Tekchandani, who is the GM of IT at ForeverNew. ForeverNew is a leading Australian fashion brand and retailer that is expanding globally. And we also have Matt Mann, the CIO at Blundstone, an Australian manufacturer and retailer known for their iconic boots. Before we start, please do add any questions in the Q&A. You should have a button at the top of your screen and we’ll answer these with the panel at the end. So Naresh, thank you so much for joining us today. I’ll turn my questions to you, Matt, first. And I wonder if you can just tell us a bit about Blundstone, where you’ve come from as an organisation and the strategy that the business is building for the future. Thanks very much, Ben. So Blundstone is a global footwear brand and we have over 150 years of history. We’re very proud of our heritage. We’re known for making very durable and comfortable boots and we sell our products all around the world. So our products are available in over 70 countries. We also manufacture internationally. So these add some interesting business challenges. We’re based in Hobart, Tasmania, and that’s where our headquarters is. So we manage quite a large and complex global supply chain and distribution network around the world. Similar to most other businesses, we’re on quite a major digital transformation journey. And that journey is all about improving our customer experience. The customer is the centre of everything we do at Blundstone. So as we’ve undertaken that digital transformation journey, we’ve really been focusing on what does the customer require? What are our business needs in order to deliver for the customer? We’ve recently completed quite a large global cloud-based ERP implementation. And while we haven’t done a lot of composable in commerce, we do have a lot of learnings from how we approached our cloud-based ERP project. The first thing we did on that project was we mapped out all the business requirements as you would and worked out where we had integrations into the ERP. And we had to make some very strategic choices around would we have extensions or add-ons that were built into the ERP or would we integrate? And what we ended up doing was we ended up building an integration layer outside of the ERP platform that has well over 100 integrations. And as we abstracted each one out, we made a choice to go in a composable approach. And we would build each one of those discrete pieces of workload in an integration platform and then connect that into our ERP.

That’s great. It’s great to have you on talking about having gone through part of this, the journey already, and building composability into your tech stack. And I know there’s more to do on that. It’s a journey, of course. But right at the start, you talked about the business is growing quickly. It’s got lofty growth targets. Scalability is part of that. What were some of the business drivers that made you consider building out Composable from the start? Yeah, cloud platforms are fantastic because they have a lot of benefits. We don’t have to maintain on-premise infrastructure. We’re outsourcing some of the cybersecurity risk and we get scalability through selection of really good cloud vendors that have a scalable platform. Why we decided to extend that further and build a Composable integration layer was we really liked the idea of microservices. So having small components, a discrete piece of business logic that we would put in software in the cloud. And what that gave us from a business perspective was we could scale more easily so we can have those parts of our integrations queue and scale sideways, scale out as demand grows. So our peak season in one of our markets, we receive much, much higher volume than we do in any other market on any given week. So we didn’t want to build the entire platform to have that scalability. We wanted to add queuing and scalable microservice points into that framework. Another reason was fault isolation. So if we have a problem with one of these microservices, we want to be able to fix it quickly. So why does that matter to the business? Well, let’s say we have a new business need and we want to roll that out. Instead of going and changing the whole ERP, if it fits within one of those integration layers, we can go and update that first. We can roll that out quickly. We can test it quickly. We can isolate problems in it quickly. And we can reuse some of them. So I’ve talked with Nuresh before about having a multi-point kind of approach to these integrations was critical. And a part of that has been we’ve gone API first where we can. And we’re using as much cloud native services as we can. And the idea behind that is that if we’re API-ing instead of building an extension, if the platform changes on either end, as long as the API standard stays the same, the integration will continue to work. Yeah. You said coming out the other side, having delivered this initial project, what have been some of the results? What have you realised as benefits for the business? So scalability-wise, we’ve gone through our first peak season in the US and we had quite lofty growth targets that we hit and the system held up fine. I think we used less than 10% of the capacity we provisioned. So one lesson there was don’t over-provision. But it was risk mitigation. Another thing we’ve really learned is there’s a lot of benefits to doing it, but there are some things to consider as well. And one is additional complexity. So you’re adding complexity. You’re adding a support layer. Those things will have costs in certain circumstances. One good example is instead of having a single vendor that’s over seeing one of our particular workflows, now we’ve got seven. So if something does happen, we’ve got to bring seven people to the table to have a conversation. That certainly is a challenge. The other part is we’ve increased complexity. So our internal teams need to be comfortable and aware that we’ve got more complex architectures now sitting behind this. But from a business perspective, it’s been very beneficial. It’s just weighing up those pros and cons. Yeah. So I guess like most IT, I probably should know that I’m in a room with a light sensor at the moment. So keep the light back on. So yeah, I guess like most IT projects, it’s not just technology. There’s people and processes involved. There’s some deep considerations in terms of the people element as part of your businesses and the maturity of the organization as well. So we’ll come back to that. Nuresh, if I can turn to you. I know you’ve been building transformation for ForeverNew. You’ve had prior transformation experience before that, of course, as well. And you’ve been building that for ForeverNew since you came on board last year. There were some technology challenges the business faced and some things which were top priority. How did you go through prioritizing some of those work streams and identifying what you wanted to hit first? Yeah, certainly. I think it’s quite a big ask in terms of a business model, hop on to a big transformation journey. So I think just very quickly in terms of ForeverNew, everybody knows ForeverNew is headquartered from Melbourne. What people don’t know is we’ve got about 400 stores globally and we are present in almost 24 countries. And we’ve got e-commerce platforms supporting various geographies. So when I took over this GM role, I think one of the biggest things for us was the business had such huge ambitious growth plans and technology was the key driver for them. As Matt was saying. And for us, it was basically a start of a massive transformation journey in terms of everything lining up for that growth. So my first biggest challenge was having the right skill sets, building that IT team, which was key to succeed, building the right strategic relationships with the partners that we really wanted to grow with. And Adobe was one of them. So thank you, Ben. So in fact, you were one of the first winners I started having discussions. And really what business wanted to see was how do we start adding value much faster, speed to market. So there was a lot to be done in that space. So the past three, four months, I spent time and getting the BAU in order. Your business as usual needs to be in order. Right. Need to give you that space to think, work on this big initiatives. We cleared the runway. So I know some of my team members might be listening. We cleared the runway. We prioritized a number of initiatives in terms of what makes sense, what doesn’t make sense so that we had bandwidth to start on this big journey. And then when you and as you would think, when you start on big transformation journeys, you want to plan it out. You want to phase it in multiple phases. And sequencing is so critical as the business grows, the criticality dependencies on other systems. That becomes quite challenging. Business wants to see value being added incrementally, not wait for two years for your transformation to complete. Right. So that becomes critical. So I think that’s where most of my focus was. And as Matt mentioned about his integration layer, we also chose Microsoft Azure as our integration platform. And it was key. Having microservices built there, having service oriented architecture was key for us to start integrating and making, I would say complex a little simple, if that’s the way to say it. So that was key to us. Yeah. And I know since you’ve been there, you’ve made great strides in having the IT department be a partner to the business as well and really driving that partnership. Yeah. It is key. It is key to the success. Yeah. Yeah. So you’re in the process of implementing the first phase of your composable architecture currently. What is it that you’re building and how’s it going? Yeah, certainly. So everything is centered around customer, obviously. A lot of these digital transformation projects, Matt is smiling away. It’s exactly the same, right? Customers arrive, change. And we are here for our customers, obviously. So we are on a journey of a multi-phase omnichannel strategy that we’re trying to implement. And the first phase is around building our real time inventory services globally. You would know for any omnichannel to be successful, inventory is critical and having that real time inventory is key. So that’s part of our phase one, including the order management system and fulfillment for our global business. The second phase that we’ll be going in is then understanding a customer profit mode. So we’ve got customer data platforms that we’re building and bringing on. Loyalty, which is again, big. Loyalty was great when we started off and now demands are changing and we want to pivot, shift. So loyalty becomes next for us. And then finally, a big thing for us will be to wrap around all this around our only experience for our customers. Many people understand omnichannel in very different ways. For me, it is very simple. Customers shouldn’t be able to differentiate that I’m in your physical channel or digital channel. They should experience the same level of service, be able to do mixed card transactions, be able to do anything and everything that they want to do, both sitting at home. And which we learned very, very, very soon and very quick during this COVID times that we had, little blip that we had in between. And we learned. And as I think Shakir was saying, we did probably online attributed to more sales than the actual physical science. So I think that’s the multiple phases that we’re working on on that. And I know that as part of this journey, you’re using Adobe IO, the Adobe composable capabilities. So I’m just bringing up part of the architecture that you’re designing and in full build for at the moment. And how’s that going? What’s the first impressions of Adobe IO? First impressions of Adobe look very promising Ben, certainly. You know, a few things that I straight away got looking at your platform, especially the whole IO platform is, A, it is event driven. It’s got an event driven architecture. It is cloud native API first that we heard. And it’s serverless. So this is what the key ingredients are for a composable architecture. For us, you know, we don’t want to manage any of our infrastructure. The complexity around servers and everything. So that is all managed in the cloud by yourselves. So for us, my developers and everyone, they don’t see that complexity. So certainly that brings in efficiencies and we focus on the actual business value. And hopefully it lets us drive some cost efficiencies as well with that. So when you look at this particular architecture, very timely for us, you see that we’ve got the Adobe Commerce on our left. And what we’ve done is we are basically eventing out everything in that phase one that I talked about, the real time inventory and orchestration of order management system. So all those events are being fired into this Adobe IO platform. Right. So here we are using Adobe native cues to publish those events out, transform them and get them out to the subscribers. So in this case, we’ve got the whole integration layer that you see in blue color is actually built on Azure platform. We’ve codenamed it Maverick. Thanks to Tanura, who’s part of my team. He’s come up with a beautiful name, Maverick. But and we’ve got all the listeners sitting there. I would say as your business service person sitting there and then integrating with the rest of our platforms. Likewise, then on the coming in, we are subscribed to listening to those events as they’re coming. Right. Again, another important with the PubSub model, as you know, we are subscribed to listening to those events. And based on that, we are firing off the right functions required to consume that data that’s coming in using the app builder. So app builder, part of the Adobe IO is really orchestrating everything that we want to do from our phase one of composable architecture. Yeah. Yeah. So the the event driven side of it is allowing you to access real time data and for Absolutely. Omni channel inventory is absolutely critical for that. Absolutely critical. And with the runtime, you don’t have to worry about the scalability. You know, that can run in peak periods as well. Absolutely. And that’s and that’s rightly said, right? Because we don’t want to worry about what we want to do during our peak trade period. Some scalability, whether it’s horizontal scaling or vertical scaling, it’s all taken care by the platform. We are just focused on those microservices and components that we’re building and up to when they are cost rate in the right way. Yeah. That’s that’s a key to this particular model. Right. And if you look at, you know, as the business grows and complexity comes on, you know, you really want to, you know, I think Matt said it as well. You know, you want to you know, you want to expose the data once you want to publish that once. Right. And then leave it to the APIs, leave it to those services to to manage that at the subscriber ends. Right. So there it is. I mean, you know, we’re giving this data once it’s available. We’ll listen to it. We’ll subscribe to it. Yeah. Yeah. Yeah. Fantastic. Well, it’s great to hear, you know, two different journeys that, you know, one’s already part way part way through, you know, the first project, the other one’s being completed. Question to you both, you know, what does the next phases look like for both of you? Matt, you touched on Comet earlier on. Are there elements of what you’ve both designed and in the process of implementing that can be, will make the next phase easier for you? And what does that look like? I’m very interested to see where Nuresh ends up with his IO. So I’ll be staying in touch Nuresh. Oh, absolutely. I think it’s because, you know, composable has been around for a while, and particularly micro services. But the event driven nature of it has so many business benefits. We’re really watching the market, we’re trying not to react early. What we’ve implemented so far through our ERP and Azure integration platforms been very successful. And we do have a large digital transformation roadmap ahead of us. That’s just the nature of the business of the way. We need to balance complexity, cost, business competitiveness, all of those things together, because that’s the landscape we’re in. And as the more we go digital, the more pressures come that way. So we’re certainly focusing on some of our customer engagement, customer data platform, like Nuresh touched on that. That’s one we’re working on scoping now. And then there will be a piece of work to uplift or to change some components of our commerce platform, because we have the same requirements. Inventory is a challenge in real time. Pricing and taxation in certain markets is a challenge in real time. And so a discounting and sale period. So there’s certain things we need to abstract out, manage centrally in a composable manner and then have subscribed from our e-commerce platform. Yeah. And just to add on to that, I think composable, the whole architecture is really a journey. I told you what multiple phases that we are in. So for us really in that ever changing world, I think this is the best way to actually meet that requirements and what is there on the other side. To keep things operating on their own. I think that’s the key thing for us. Just as a business, I think I was saying complexity comes over the period. I was taking account of not only number of stores, but number of partners who consume our data. You’ve got 40, 50 partners who are consuming our data, sending us orders and all that. So you really, really don’t want to have point to point solutions, which is probably the worst thing that we’ll end up with, maintaining and managing all these little interfaces. So I think this comes to the rescue, this part of our architecture. Yeah, absolutely. Matt, you touched on this earlier, but a question to both of you in terms of what were your considerations internally for your organizations and also what would you advise others? Composable is not necessarily the right choice for all businesses at all stages. What are some of the factors that you’d advise others to consider before they undertake their own composable transformation? Do you want to go, Nuresh, first and I’ll tag on this? No, you go, Nuresh. I think for me, it is horses for horses. Really, Ben. That’s how I see it. My only advice will be choose your platforms very wisely. I think that’s key. If you’re a simple business, keep it simple. And maybe that’s the best option. Composable architecture, I think Shakyesh said it right, don’t just copy it for copying sake, just because your competition is doing just good. Don’t go do it for that particular sake. Your business will evolve, complexity will come in. That’s when you start looking at, looking in, bringing in a little bit of complexity in the business to make business simple. That’s how I say it. Because you don’t see on the other side, businesses, oh wow, it’s all functioning beautifully and everything is coming in the right way. But the complexity really sits behind. I think that’s what it is. And what I like about Adobe is really it offers you that. So it’s a single platform. You want a composable architecture, it’s there. You want to use it as one big platform giving you all these things. It is available. So I think that’s what I see. It’s really good what Adobe is doing in this space. Yeah. I’ll throw one extra thing on there, Naresh. Speed to market is the major thing for us. So that’s the areas we focus from, the ones that change the most, the ones we need the most agility in, and where speed to market is important. Because as we all know, in the markets that we’re in, Naresh, which is around customer-centric selling product, retail, whatever you want to call it, omni-channel approaches, it doesn’t matter. The needs of the consumer change and we’ve got to be able to change with them. But there is a cost to complexity, as you said, Naresh. So you’ve got to balance the advantages and the things to consider. Yeah. I remember you made a great point when we were talking before, Matt, that the complexity can sometimes increase the cost. There’d be an overall cost reduction, but it can bring in an additional cost. But that’s a lever for your competitive advantage, like go to market. So sometimes there’s this fine tuning internally of your own competitive advantage, which is why this can’t be a one size fits all. It’s really down to what the business needs are. Fantastic. Thank you. One last question. And I think Naresh, you touched on this, but what’s important for both of you in planning the approach when you’re looking at composable architecture? Maybe technology selection. What else is important in your planning? I think we’ve touched on a lot of these things, but just to summarize it, I think for me, the complexity of your business. I think that’s certainly. If I look at our business, I mean, the complexity of business just doesn’t come across various channels, various time zones. Can you afford down times? That’s another one that always comes into play of this. With scalability always is the availability and redundancy as well. So all these three things play a big part and sum it all up from a business perspective, keep it simple for the business side and obviously keep control on your costs. So that’s how I see it. Yeah, it’s that triangle, isn’t it, Naresh? Understand the business requirements, deliver something that’s not overly complex and then control your costs. Because if you don’t control your costs, you become uncompetitive. If you’re not competitive, you don’t make the spend. So every use case is different and I completely agree with all those things. We made a very clear choice when we started. We’d already started down a different track and we pulled that back and said, you know what? If we don’t have a really clear understanding of what the architecture requirements are to make this business requirement, we’re not going to start. We’re not just going to select something and run because it needs to be a strategic choice. Yeah, fantastic summary, guys. Thank you very much for joining and a really good salient note to finish off with, which is, you know, consideration is absolutely key and understanding your business first and your customers. Of course, everything is designed around their needs. I’m just going to check the Q&A. Shukir, have we had any questions raised from the audience? Yes, Ben. We have two questions for now. Mainly, I think it’s of course directed towards our speakers. Pick up the first one. It’s from Alvin and it’s directed towards Matt. Thanks for sharing. Having now implemented Composable Commerce. There are two points. What is the one thing you would wish you knew before starting the journey? Good question. And the second one is in terms of team scaling as complexity has grown, what’s the comparison both in terms of number and skill set of the dev team before Composable Commerce and after? Great question. I’m going to tie in some outsourcing of this because Naresh and I have some different views. So the one thing I wish I knew was that the architecture we ended up with wasn’t what we designed at the start. And we thought we had it right. So I won’t go into all the details, but we could have spent more time on scoping and business requirements and really nail that down because we did have to go back and retrofit some components of it. We had our business requirements. We just could have improved in mapping it. So the thing I wish I knew was given all the complexity, having those architectural designs really spot on at the start is critical. And then team scaling to support it, we ended up outsourcing a lot of the support. And we made that decision because we wanted to be able to have a vendor that we could have 24-7 relationship with. And we’ve increased the support agreements by about 20% of cost for the integration layer. But we’ve also bought a lot of business benefits. 24-7 support. We’ve got a level 1, 2, 3 tiered support agreement with our vendor. And they’re bringing a lot of expertise into the mix as well. Awesome. Okay. On to our next question. I think the next question is from Vikrant. I think question for Naresh basically. Just to understand, what’s your experience so far with the flexibility, in your case, Adobe IO, but App Builder API Mesh obviously is on top of Adobe IO runtime. So what was your experience so far with the flexibility of Adobe IO? What sort of benefits does it bring for your customers and how would you expand to e-commerce operations? Yeah, good question again. And I think experience so far has been really good. And I think most importantly, I think the support from Adobe has been fantastic as well. So Ben and his team have been behind us and supporting us through our journey. I think connecting what Matt was saying earlier on as well, having that architecture and understanding your requirements is a key thing. Once you’ve defined that, once you’ve done that, we spent a lot of time in just making sure our architecture was right. And we wanted to build it once and make sure that it was reusable multiple times across whichever platform we want or whichever platform or SaaS platforms that we wanted to integrate with. So I think that was key to it. So I think from that perspective, my only answer would be just think through your requirements right and have your architecture right in place. And as we were saying, Adobe gives you all that, certainly from that perspective, to be able to achieve that.

Perfect. That makes very much more sense. And actually, I think for me, I think there was a question I think to both of you as well, at least from my side. The question that I had is, you know, composable commerce also brings in challenges in terms of data, right? So I think bringing in multiple modules in the way data is handled in the third party services as opposed to your core source is different. How did you did you face any challenges then? How did you kind of address it in that sense? I think, Niresh, you’ve built a data platform out as well, haven’t you? So we’ve built a data platform out and we’re aggregating data in from lots of sources. And you can’t deliver any composable solution without that because you’re abstracting data from the flow. So then you’ve got to deal with your data requirements in another way. Yeah, I agree with that. Yeah. Perfect. Yeah. Makes sense. Okay. I don’t think we have any further questions, Shakir, do we? I think that’s pretty much it from where I see. Let me just double check. Yeah, I think that’s it. That’s pretty much it for today. Okay. So I’ll ask. Yeah, that’s great. So there will be a recording on Experience League going forward. I’ll just ask if we can have the last two poll questions pop up and give an extra minute if anybody has any last questions to put to Shakir or Niresh and Matt. And just one more minute before we close.

Well, I think we’re at time and we don’t have any other questions coming up, so thank you, everybody, for attending today. I hope you found it useful and given you a greater understanding of composable commerce considerations. A reminder, the recording for the session will be available through Experience League after this. And if you would like to discuss the topic any further, please reach out to your account contact Adobe. Thank you to Shakir for presenting today. And a big thank you to Niresh and Matt for joining, providing a view into their composable programs and their insights. Thanks again. And I hope to see you on the next webinar next month. Thank you.