ÃÛ¶¹ÊÓƵ

Transcript

Hello and welcome everyone. I’m Joe Wax on our Partner Experience Team and I lead our partner in product alignment and strategy. I’m excited to welcome you all to part 2 of our four-part series in the partner implementation series for ÃÛ¶¹ÊÓƵ Commerce. Last week we kicked off with session 1 of lowering total cost of ownership for ÃÛ¶¹ÊÓƵ Commerce. Today is an exciting session when you think of the overall theme and goal for this four-part series. It’s to equip you, our partner ecosystem with how to plan, build, and maintain a modern ÃÛ¶¹ÊÓƵ Commerce implementation. Today starts on that planning piece. We’re pleased to be joined by a number of the ÃÛ¶¹ÊÓƵ Commerce team. We have technical architects, technical marketing, as well as product marketing. We’re really excited for today’s format. If you weren’t able to join us for part 1, I want to preface today’s session. It’s a unique presentation opportunity we have with this four-part series. We got a lot of great feedback from your partners with part 1 last week. But this is a more interactive discussion today than perhaps the normal partner webinars you’re on. But it was really great feedback. We really enjoyed the moderation that Russell led, and Russell is going to be our key moderator today between the extended ÃÛ¶¹ÊÓƵ staff. We will be posting the link and recording as well as other event details in the chat as we go. But with that, I want to turn over the floor to Russell to kick off part 2 session of Planning the Modern Commerce Implementation. Russell. Awesome. Thank you, Joe. Today, we’re going to do a semi, probably one of roundtables, probably the closest thing I can think of. We’re going to go over a couple of different topics. We’re going to start off with the discovery phase, so like that early, early on part when you guys are getting ready to either sign a contract or just wrapping up an RFQ. We’re going to go on to what some of the services are to help you make sure that you plan your project appropriately using the right tooling. We’re going to try to touch on GRA, Global Reference Architecture. We’re going to go through front-end development practices and concepts, and hopefully we can wrap it up with some just best practices, some tips, because Alexi and I have been doing this for probably a total of over 20 years between the two of us. And so, yeah, we just have a lot of things that we’ve learned, and hopefully it’ll help you guys do a better job implementing and be better prepared. So we’re going to kick this first section off with Alexi. We’ll save Surya for later because he’s the smart one. We’re just the pretty faces. So, Alexi, when you’re thinking about the discovery phase, that’s that first part right after the ink’s been dried and the contracts have been signed. When you think about that discovery phase, what parts were you the most, and how do you prepare for that phase? For the discovery phase, first of all, I would think that what roles we have on our project, whom we have had, and what key documents we have for our project. So I think that these are the most important. And I’m trying to combine these people with documents and build the documents, exactly. There you go. That’s the goal. So if we have a discovery phase, we need to understand what our project is, like how it works, what components it consists of, like how all those components work together, what potential, what interesting things we have. Like I do not want to say like issues, but yeah, that’s actually what we have. But basically, like it can be some, like all project is unique. So that’s why we need this phase to understand like what integrations we can have there, how we can build everything in such a way that it will work properly, what products we are working with, how all the flow works and- Oh, true. Yep, yep. Yeah, so, and for this, I think that like if you speak about roles, I think that, yeah, we can quickly touch like who does what. Yeah, let’s start from the SI side. So the customer would have its own group of people that I would expect to be there, but let’s start from this audience here. Like from the SI point of view, what teammates would you expect there to be? Okay, so yeah, from a like a software architect point of view and a technical architect that will be services team. So we work with partners, we have partners to build projects and so on. So from my point of view, like first of all, I expect to have myself so I can help the team to like analyze the project from the technical point of view, like find all this like weak points, find how a team can work, build not only project, but also like all the strategies, how we deploy things, like how we build the code, like what standards we have, like and so on. But I expect that I have a business solution architect from our side who actually works closely with this product owner from the client side. And when I say our side, that means like our side, it’s me, ÃÛ¶¹ÊÓƵ team frequently and a partner’s team. So it’s like people who build a project and other side, it’s like customer side. So yeah, honestly, it would be nice to have, like it’s important to have like technical leads if we have like multiple teams, so they can also be involved, they can, we can discuss who is working on which parts and like nowadays, a project can be big, you can have commerce, you can have others, you can have, for example, a team, you can have some integrations and so on. Okay, yeah, because another piece that I like to get out of the way as soon as possible when I’m going through this phase is I wanna make sure that the integrations or the known complicated parts are talked about early, because that helps you understand where like phase two of a discovery phase might go, because their data might be stored, but it might be in like seven different places, right? So getting to know those different parts and maybe not going to depth on the discovery part, or at least on the early phases, just understanding that they exist and then how soon we can get our integration developer involved, because that’s the person that’s actually going to be implementing it. So having them hear the story and know that these three points have all the data and then you have to merge it all together, that’s important.

Yeah, exactly. Is there anybody else from the SI side that you think would be important? Sure, so as you mentioned, it’s important to understand what we built. I mean, we can have migration from the other system, we can have project from the scratch, we have migration from early versions of commerce. So if you have such a station, you definitely will need to have, for example, someone who was like, we can call it like a data migration guy. Like what is also important is understand like key metrics of the project, like what speed we expect, what number of orders we should have. And for this, yeah, for this inside of our team, we usually have a performance engineer whose work is just to analyze all the projects so he can at least be planning on discovery phase. He can actually give us some advice. He can give us some best practices or we can plan when we test work and all those things will be ready. Yeah, of course, it would be nice to have like someone from design side if you’re building project from scratch to analyze what they’re building and also to see how it will look like. So like the UI, right? The customer facing experience, got it. What is also best practices for me is to have like a quality insurance engineer or quality insurance lead who can pre-plan all the testing process. So we are not only building, but we also planning how we’ll test it. Not only performance, but also like how all the phases, like what we need to deliver in what order probably for proper testing to leave more time for the critical things.

Yeah, so that’s basically will be a structure from my side. I think maybe I lost someone.

No, that’s good. I also like to toss in there like a project manager from the SI side, because it’s nice for them to be that middleman to bridge the technical gap to the customer side of the project, because those are two usually non-technical people. So they can break it down into English and make sure that hopefully nothing gets lost in between. Because unfortunately developers aren’t always the most easy to understand. And so having someone do English translation is also very helpful. Now from the customer side, I had a couple of people in mind, like the customer side should have some sort of data specialist, right? Somebody who understands at least where the data lives and maybe if it’s unstructured or structured, and if it’s really messy or not, just giving us an idea of what to expect. And hopefully a small sample of what to expect of the data, whether it just be orders or API information, whatever. Another person would be like a BSA from their side, because they’re gonna have a different approach. They’re gonna wanna know how this is gonna impact their future business. So they’re gonna wanna be able to help define tickets and things like that. But other than that, what do you think from the customer side would be nice to have on this discovery phase? Yeah, so as I already mentioned, should be like a product owner. Also, I think that it’s key to have subject matter experts. So usually business consists of different people who work in all this customer service, like someone works for example, this returns some works with customer support, someone builds this, build content for a project and so on. So we need to have all the subject matter experts who describe how they work, what they do, and the regular basis on what they expect from a platform. Because they’ll need to work with this platform in the future, so they have to- They should have some sort of say. Yeah, we need not only to understand what they want, but we also need to plan how we line the project in the future with them. Because when they say subject matter experts, they can have some specific integrations. It can be like order management systems and we can have guys from there. It can be something like, even I had an experience like when we had a custom payment gateway. It was just specific for the customer. So in this case, definitely it was worse to have these guys. Or we have some custom integrations related to how content delivered to the project. So this guy’s also nice to have. Definitely if we have a technical team on the customer side, it would be good to have that back lead. So it usually helps.

Nowadays, it’s important to have a good results in search engine. So like someone who works with all the search engines, optimization. SEO, yep. SEO is important. For some project, I would say that even some guys from a legal point of view would be nice to have because they can have special requirements for that. That’s true. That’s a really good point because I think that’s overlooked, right? Like ADA compliance, because we don’t always know what your company is required to meet. And especially these projects. So asking those questions early, is there any legal? Is there any PAI? Is there any ADA complaints that you have to follow? And then I guess the last bit that I would like to probably recommend, I wouldn’t know if it’s called a best practice, but like you need a big team and a full team, but it can’t be too big because then you can get stifled by too many voices. So there needs to be just enough people to be able to answer and drive the actual project, but not enough to where you can cloud the conversation and get derailed. And I think Lindy Kao who was at Summit, I think she was talking, might’ve been about GRA or something like that, but she found like the sweet spot was like a total of about nine people or so. And that would be like four or five from your SI side and four or five from the customer team side. And that seems to be, in her experience, because she’d been doing this for a long time, that’s what kind of she recommended, but definitely keep that in mind. Like don’t have too many cooks in the kitchen. At least do not have them at the same time, I would say. So like, again, you have like high level planning and then you go deeper. A little bit deeper silo. Which I probably already mentioned, and you include all those people that you need. So yeah, that’s how it usually works. So when you’re doing your, I don’t know, gathering of tasks, right? So you have this checklist that you’re going through. How do you organize it? Like from your perspective, if you’re the technical architect, like what do you do first? Like how do you organize your thoughts to make the discovery phase go as cleanly and as smoothly as possible? Oh, it’s a complex question. That’s why I asked you, bro. Yeah, it’s, so for discovery phase, first of all, like I want to, like usually I have like set of documents which I want to fill for myself and for the customers. And I want to go with customers, with partners, like through them. So it will be like, our, like first of all, it’s like architectural vision. So like general vision of the project, how it works, which components we have there and so on. Like it can be a systems landscape diagram which describes everything. So we can, and usually it’s very helpful because if we have someone new on the project, like during project life, first of all, share some information. So like I think lots of people refer to the documents.

So like when we build this, I think that it was to have like something like a development strategy to agree how we work, like what tools we use, like so on.

Environment strategy, if we have, if we have ÃÛ¶¹ÊÓƵ Commerce Cloud, then we have plenty of documentation. Although I would like to see that everyone understands how it works, like what is the deployment, like what environments are. So what is like, even for me, like when someone says like lower environment, upper environment, it’s like not clicks immediately. Like when you say this to someone else, they need to understand that this is like a production and we have lower environments below. So that’s kind of the things I think. Okay.

I like to give right before we get started, like especially if we’re gonna be onsite, like the week ahead of time, I like to send a proposed request from my side, which would be you, customer that we’re gonna go visit onsite, can you give us the list of your top five pain points of your current website and how you think we’re gonna be able to solve those in this new implementation, or can you make sure that you bring, like you said, a diagram of the way the data lives, even if it’s in a crayon drawing, just something so that way we can understand at least where things live. And then that gives us the opportunity to talk about it because sometimes when you ask for things upfront, it starts them internally thinking about the project and hopefully we’ll get them to even ask their own questions because you should expect them to ask questions of you.

Because I would assume that a lot of customers are being savvy these days, they’re gonna be doing their own research. Like, hey, we heard about this thing called API Mesh and App Builder, like are you guys even considering using it? And if you get that question, you’ve never even heard of it, you might be taken back. So giving them the opportunity to prepare those questions and hopefully give them to you before you get onsite would be very helpful. So having that dialogue, starting that bidirectional communication early is key, at least in my opinion, to having a good discovery phase. Yeah, I agree. I agree also from my side, I usually like to understand like project, like the client’s business and like product specific because like this is very important because you need to like map this from commerce. You need to understand how we can implement this in the most efficient way. Like what is the size of our catalog, what expected number of orders so we can plan what hardware we have or what plan we have for ÃÛ¶¹ÊÓƵ Commerce Cloud. So like things like that. Data flow is very important as well, but also not on the data flow, but also how people work with the product. I mean, like how many people we have on the backend on a daily basis, what they do is also important thing because it can, you know, like if you have too much people and if they like to input expert lots of data, like you know. It can be a headache. Yeah, so things like that are important. I would say, yeah, so for discovery phase and what I will do, so when guys explain all the things, I try to make some notes and then like ask questions, like if I see that, especially in some situations when they did their own research, they probably have their own vision. So I want to understand like if this initial vision is correct and if not, I am trying to correct this. Oh yeah, it gives you a chance to see if your visions are both the same. Cause that could be, that would be hard to fix if you got too far down the road. Especially nowadays we have lots of fancy things. I mean, we have like new modern tendencies on the front end, for example. We have like lots of interesting things and we need to understand how to integrate this. Or if, for example, nowadays we also have commerce, which can work in a headless mode. We can have IAM, we can have something else. And we can, I want to understand like how clients see the project, what benefits in all these parts, and how we can work with this team. So if you have this team, it’s nice to meet them on a discovery phase, like understand like what is the technical level. So like what language you can choose to talk to them in this case. It’s really hard to tell. Let’s segue a little bit. Cause I think this topic is going to be beneficial for pretty much every project from now on.

So, sorry, I’m going to bring you online for a second and Alexei, you can feel free to chime in too. But, you know, ÃÛ¶¹ÊÓƵ’s put a huge investment in using services and using external functionality to extend the application without having to adjust the core PHP application. So, and what I’m alluding to is, you know, the use of API Mesh using App Builder, using our services. So, you know, Suri, can you just give us like the elevator pitch on what App Builder is? And then maybe if you can touch a little bit on like how that segues into API Mesh, and then we’ll get into the like the services here in a bit. But yeah, first just high level. Sure, so as you mentioned, App Builder is part of our extensibility strategy, right? What we’re doing is we’re making our product itself, we’re architecting our product in such a way that you don’t have to customize the core product. And instead providing these well-defined extension points, which are APIs, events, web hooks, UI extensibility. So that’s part of the product, all those extension points. But we take it a step further. And instead of asking our customers like, here’s all our extension points, go build wherever you want, whatever you want. We are providing them with a serverless platform where they can build all those extensions. What I mean by that is that, you know, if you have to build a new app that goes into the admin UI, instead of having the customer go and contract with and provision and purchase yet another platform like Google Cloud or AWS or something to deploy those apps that extend our platform, we’re giving them an extensibility platform that is included with the product. And it’s already tied into our product. What that means is that if you go into App Builder, you can easily see all the APIs and events available from commerce and then build those extensions that you want. So it just simplifies that whole process of how you extend our product. And, you know, gives you some best practices, gives you a starting point to build that really, really fast. Okay, so, and I know that this, I want to kind of help some of these teammates who may have not attended the first session. Can you give us a real world example? Cause I think we have a real good rockstar example, right? Of how someone thought about this problem and this solution and came up with a very clever use of this technology. Sure. So one example, so if at Summit we had ÃÛ¶¹ÊÓƵ Summit, and I understand many of you may not have attended, but if you are interested, all the sessions are live, or sorry, are available when I say live, they’re published now. So they’re available on the Summit site, and you can go ahead and view some of the sessions. The particular one Russell is referring to is called ÃÛ¶¹ÊÓƵ Commerce Rockstar, where we invited developers who had built innovative extensions or apps for ÃÛ¶¹ÊÓƵ Commerce to showcase them at Summit. And one of them was a partner that had built for a customer. It was a real use case for a customer where they were using events within ÃÛ¶¹ÊÓƵ Commerce to integrate with instant messaging solutions. In their case, WhatsApp, but it could very well work with iMessage or any other messaging tool that you might use and they were using it to actually do order fulfillment. So the moment a customer creates a new order within ÃÛ¶¹ÊÓƵ Commerce, an event goes out to the warehouse manager who is going to then pick and pack those items that are part of the order and get it ready for shipment. And through the instant messaging app, they can click a button over there saying it’s done, and then that updates the status in ÃÛ¶¹ÊÓƵ Commerce using events again. And then the moment that gets updated, an automatic message may go to the delivery driver saying there’s this package available and it needs to be delivered here. And now the delivery driver could go pick up the package. And once again, using just there, I have no special app, custom app or anything else, just using instant messaging, they get options, pull options, they picked up the order or couldn’t pick it up or something like that. And those status just keep getting updated in ÃÛ¶¹ÊÓƵ Commerce so a customer gets real-time information about the status of the order. But at the same time, events and App Builder are managing that whole process of delivering, fulfilling that order in the backend. That was a pretty cool use case and you can take a look at it on the- And I want to call out, that meant there was zero PHP code, right? Like all of that was done in App Builder. It did not require customizing the product or ÃÛ¶¹ÊÓƵ Commerce at all. So all the events- That is fantastic. I love that story, dude.

So when you’re thinking about planning a project, so Alexei, now that you’ve, the tone’s been set, when you’re planning a project, when do you bring up these alternatives to development practices? Like, do you bring those up in the planning phase or do you bring those up as a task is, you’re going through and you’re creating JIRA tickets? At what point do you bring your customer up to date on these options? I think it’s planning phase is the best because I would honestly, I know that everyone wants to start project as soon as possible, but for me, it’s beneficial to have a good planning phase. So in this way, and concentrate on this a lot, so you have all the discovery documents, you have all this documents, as I mentioned, we have clear vision of the project, clear vision of your team, of a client team, all the integrations, like what amount of time will take development for each of these teams or functionalities, like where we have integration points, can we separate development in such a way that we build something and we wait for some other components and we use, for example, standard commerce functionality tools at point. For example, we can use some standards payment options to test all the flow till we have some work on the payment gateway or something like this. So maybe we can, if you have some customizations around taxes, we can also use standard built-in tech system before we have it. So we can pre-plan things like that. And anyway, it would be nice to identify the hardest part of your project. And I would recommend to start them first, not start from the easiest part. Like lots of people think, oh, let’s just start, like let’s take something easy and let’s start. It’s better to leave all this for the end. Let’s start from the hardest part. So that’s why I think that I just myself prefer to bring all the technical high-level solutions at the beginning so we can use them during planning. Things like the catalog as a service and the payment. Okay, yeah. So, sir, that’s definitely more in your wheelhouse. Like what do you, when you’re talking to people about our services, can you just go over like maybe our top and go from there? Yeah, absolutely. I think we look at it as, so often our customers or developers or partners may look at a particular feature or that we may release our new service. What I did want to do is take a minute to talk a little bit about our strategy itself. So where’s the product going? Because it’s really important as our partners are implementing the solution to know what our product direction is and why we’ve made those choices so that you can architect the solution accordingly. I’ll take a moment to share my screen for just a couple of minutes and just talk through a couple of things. So if you’ve been following ÃÛ¶¹ÊÓƵ Commerce for a bit, you know that we’ve made some significant changes to our product and our release strategy as well over the past, I would say three, three and a half years. And that’s, it’s been a snowball effect, right? I mean, there were incremental changes and now there are quite a few big changes. At a higher level, the way we look at our product is, first, we want our customers and partners to start with what we call the scalable commerce foundation. And what we mean by that is what you’ve traditionally known as Magento Commerce or ÃÛ¶¹ÊÓƵ Commerce. So that’s what we call it, what we call the foundation. And that provides you with everything you need to get started with commerce really, really fast. So managing your catalog, managing your customer account information, managing cart and checkout. So those are things that anybody who’s implementing commerce probably needs, right? If you’re selling a single thing on your website, you probably need those capabilities. So that’s part of our commerce foundation. And our primary focus there is to improve on performance, compliance, security, scale, and all of those things. So if you look at our releases over the past couple of years, that’s where you’ll primarily see the improvements in the product on the foundation. The second is a set of services that deliver those value added capabilities or advanced capabilities. And these are things that maybe not every single customer needs, or they may be needing it, but may already have invested with another vendor or something like that. And so the way we deliver them, they can adopt whichever ones they need as and when they need them. And then the third part to that is that every single project, every single customer has some needs that are gonna be completely unique. They’re probably not gonna be solved by us or even a third party vendor, right? So then they’ll end up having to build, to extend our capabilities or build something custom. And our goal there is to provide them, and I spoke to it a little bit earlier about that you don’t have to go out and provision AWS services or Azure. Nothing wrong with those services. It’s just that you have one app to build. You shouldn’t have to provision a whole lot of infrastructure just to do that. We provide you with a serverless platform where you can quickly deploy those apps and they are already pre-wired to make use of not just ÃÛ¶¹ÊÓƵ Commerce, but other ÃÛ¶¹ÊÓƵ solution APIs and events, et cetera. And you can plug in your custom apps and events. Now there was a poll in there and I saw most of you answered it. These are the set of services that we consider part of ÃÛ¶¹ÊÓƵ Commerce. And all of these can be deployed individually with the Commerce Foundation. And our primary goal of deploying them in this way are really when we build these as individual services, we can deliver features much, much faster to you. So rather than having a larger growing application, which takes time for us to release and for you to adopt each individual service. And many of these are releasing capabilities, new features every week or every two weeks. There’s continuously new features being deployed there, often behind feature flags so customers adopt them as they need. But we do take care that we’re not introducing latency. So if one service needs to talk very frequently, it’s very chatty with another, we’re not breaking it up in such a way that there’s latency issues over there. However, if you look at these services, I do wanna point out what they’re in. Because one thing that surprised me was that catalog service, it looked like only 14% of the respondents had used it, I’m not familiar with it. I forget how the question was phrased. So if we look at these services, catalog service and the pricing, these two are primarily scale oriented services. So we provide these services to customers to have super high performance and super large scale. So from managing a few million products and a couple of shared catalogs and price books and all, when using the catalog service, you can go up to exponentially larger sets of data. So we literally have customers managing a billion SKUs using the catalog service. And we are doing Lighthouse scores of 100 with those, less than 250 milliseconds. So if you’re not using the catalog service in any new implementation that you’re planning or not recommending it to your customers who potentially have needs for large scale, or even if they don’t, just making use of it prepares them for the future. So I would recommend you look at the catalog service. And the second part to that is that the indexing, if you’ve managed large catalogs, you probably know that when you make large scale updates to your catalog, price indexing takes the longest time. Here we are offloading the price indexing off your core commerce foundation, and that makes it really, really fast. So if I were to kind of bucket these services that you should be considering, catalog, price and edge delivery, these are focused on scale and performance. So edge delivery is the storefront we introduced, very, very highly performance storefront. Again, our goal is every customer should be in the 100 Lighthouse Core range, so not less than 90 for sure. And these services absolutely support that. If you’re looking for more of the AI powered services, then we have things like live search, product recommendations, which, you know, I did see around 50% of the people were aware of those, or at least had used them. And let me point out live search, product recommendations, catalogs, these are all included with commerce, so there’s no additional cost to the customer to use those. And then there’s the data side of things, right? I mean, you want to capture events for your data from your visitors, their behavior, and then, you know, personalize based on them, on that data or behavior or optimize based on that. That’s where segmentation, customer profile, experience, edge, all of those things. We largely, we call them data connection put together, but these are all the services behind the scene that help you capture that data about your visitor behavior, then segment those, enrich the user profiles, and then act on them to drive the, you know, your commerce behavior. So what happens when a user clicks this or reviews that, or add something to cart, capture that immediately segment it, personalize and send it back to ÃÛ¶¹ÊÓƵ commerce to activate that so that we provide them with a much richer service. Can you refresh the, no, I want you to refresh some of the stats that we’ve recently released. So for catalogs and service, what’s our current SKU count that we’ve tested against? So not just tested, but in terms of our real world usage, we are seeing, we have a couple of customers running up to a billion SKUs on the catalog service. Holy cow, all right. And just a few years ago, that was not possible unless you heavily customized the product. And Alexa, maybe to speak to that further, that you hit certain bottlenecks, right? I mean, at a certain size of catalog, you know, and effective SKUs really, because of those multipliers, et cetera. And why the catalog service is important is that that effective SKU, which is something that we have made almost irrelevant today. So the way we have denormalized how data goes into, or the way we’ve structured the data and those effective SKUs, which is multipliers with store views and shared catalogs and all of that, that no longer becomes important as it was in the past. That’s fantastic. And we are blowing through our time. So let’s segue to another topic, because I think this is also, it’s just as important because it’s a concept on how to run your project and how to prepare your customer for growth, in addition to using services. And it’s a topic called global reference architecture. And I think we might even have a poll question up for that one. But, you know, Lexi, walk us through how you educate somebody who’s maybe never even heard of this topic. Walk us through that high level, that elevator pitch, and then we’ll dig into some of the nuances that we’ve learned from implementing it here at ÃÛ¶¹ÊÓƵ. Yeah, okay. So we’ve just seen that we have lots of services and so on. And nowadays projects are very complex. So Jerry’s base for global reference architecture it’s a pattern that we created like lots of years ago in services department team, although this department evolves. So basically if you think about that, let’s start from this something simple. So for example, you build something like a module and you want to be sure that this module can be reused multiple times. Like what you will do, you will like make this module, you’ll add tests, you’ll try to be sure that you have like backend and frontend and so this module will stand alone. Like it’s like, and practically done. But what if you have more than one module? What if you have like multiple modules? And what do you will do? You will probably will do the same, but you’ll need to organize this module together in something like a foundation, which can be reusable. And then you need to think like for which you need to reuse it, for which projects. So for example, it’s a common situation when you have a retail brand and they have a store, but they can have other brand and they can have other brands in other countries. So in this case, if you think like how you can reduce part of your functionality and it should be again built in the best possible way. Yeah, I see that you’re sharing this document. Yeah, I think you’re kind of talking about this, the split Git process, right? Is that what you’re leaning towards or? Okay. So technically, yeah, technically, as I mentioned, like everything starts from the module, although we can have a group of module or I nowadays, like I would say that even like on my recent project, I called it like a meta package. So it’s like a set of modules which we can reuse and basically what is GRA? It’s a way to build efficiently multiple projects, similar multiple projects. And that’s very useful when you have a multi-brand solution or you have different countries and you want to do this or I think a very good case is when you have B2C and B2B project based on like commerce B2C and B2B and you do not want to have some of the same instance because business a little bit different and you want to separate them and you want to keep as much as possible. And if you do this in properly, you’ll need to maintain like both code bases, but what you’ve just shared, it’s actually is important because it allows us to minimize the amount of work needed to maintain the code. So like stories of them going to different development, but yeah, it’s my plan. I think it makes sense because you would normally think of GRA or global reference architecture being a geographical delineation, but in reality it doesn’t have to be, right? It can be like, let’s say you’re an automotive supplier, right? You may want to break it up into your brands like Toyota and Nissan and whatever. Sometimes it isn’t geographical, it’s based off your, or like you said, B2B, B2C, that’s an overly simplified approach, but at least you get the concept, right? You’re breaking it up, you’re delineating between your content. And then, yeah, you could have some shared modules that both sites use, but you’re going to have a couple that live only in the B2B storefront and only in the B2C storefront. Exactly, exactly. So basically it’s like a way how we build a sub-platform, I would say, which we can reduce in the future. But it’s a little bit more complex. So this pattern can be applied for backend, frontend, even for some integrations. And what I found recently, it can be used when you have a project which can be changed frequently. When a customer, for example, not sure what integration they want to use, and they want to do some experiments, and they want to replace one integration with another integration in order to test it. For example, for some time, to see what is better, what can suit them the best. In this case, it also works well because this pattern allows us to isolate appropriately these different logics. And the key concepts, it’s like we are building our sub-platform and we are building Lego-like components. We should just mention, for example, if we have different car brands, they have some specific, so the car will be our basis. But all the other things will be very specific. Our goal is to solve this puzzle, in the fastest way, and in the specific to deliver the final project.

And that’s how it works. So basically, we build the foundation. This foundation consists of rules, how we build backend, frontend, how we build integrations, how we build tests, how we create development workflow.

It’s also important because if you have strict standards, I started, when you want to make something reusable, you need to have a proper quality. Right. That’s the thing, while all this, even the proper discovery phase is important.

Yeah, and then when you have a good foundation, you need to understand how you make this usable components and how you can include and exclude them correctly. For this, you need to also build a good architectural foundation and deployment process and testing and configuration. Configuration is also important and should be possible to have, so for example, as in this car example, probably we should have something like a basic platform, which will have all the functionality for working project, even on the phase when we have this layer. So it should have everything you need. Maybe it will not have like a specific designs, maybe some nuances of- GDPR, whatever, right? Yeah, whatever. But anyway, all the other things should be there and they should work. So we should have all the layer identification with proper attributes, like maybe predict that we should know how we, we probably can have it on some car customizers there so it can be reused and we just need to fill it with the proper brand data and so on and so forth. Yeah, so basically that’s it. Yeah, that’s good. Some of the benefits to GRA is you can deploy your different regions or different brands independently of one another. So that way, especially if you’re trying to do things off hours, off hours in Australia is not off hours in LA, right? So having that flexibility, if you do a geographical delineation, allows you to do things like that.

And then, yeah, go ahead. You can do geographical delineation, you can do brand delineation. So basically, it’s a good part and if you are interested in architecture and if you want to solve the task when you need to, like how you can maintain code and how you can create projects fast when, how you can create a basis for the future projects. Like if you have similar projects or like geographical visibility projects, if you want to optimize code delivery as well, so like optimize resources for testing the code for like even development and avoid, like it’s also solves this code duplication problem but you have multiple similar things and you build them each time separately. And here you like build it on the runs and then you reuse. Yeah, I love that.

We’re- Hey, Marisol. I did want to point out a couple of questions that were there. I did answer a couple of those in the chat pod and those were around, so they were primarily around how do we get, how do we learn more about catalog service, et cetera. So, and there was also a question about whether it’s included in ÃÛ¶¹ÊÓƵ Commerce. So I do want to confirm that a catalog service, live search, product recommendations, these services are included with ÃÛ¶¹ÊÓƵ Commerce and I have dropped a link to guides. So this is an experience league and this is the great content that Russell actually produces for all of you. So it has guides for each one of those services.

There were also some implementation questions, Alexei. I don’t know if you’ve got a chance to look at them but they were around, what are the things, I think one of the questions was around, what is it that you use to understand existing architecture from a customer and technical details when documentation is kind of limited or scarce? So are there any other tips you have around understanding the customer’s architecture? Yeah, it’s interesting question. It’s context, I hope I can make it short. So I try to understand what APIs they have and what is, I already mentioned this, what APIs they have, what data flows they have, what is the typical products customer uses, like how this maps on the commerce side. So it’s like, I want to build an open discussion and I want to build the project in my head and like see like what is missed from my vision of how commerce works in this picture and fill those gaps. But also it’s always good to have like a set of standard documents. And then the standard documents, which I mentioned like in the architecture vision or systems landscape diagram, or like, even for example, development strategy. So usually what I do, and since we have experience of like building this project, what we do, we already build a set of questions which we can use and ask customers. So, and when we have answers, we can fill all those things. And since we have a history of delivered projects and we have a big history of those projects, we already have a big list of questions we need to ask. So in the worst case, we can just go through this list and ask, and I think that it would be worse for every partner to do something like this. So like you need to build a proper set of documents. You can like even do what I already said, and you need to build this list of questions which will allow you to build a document. That’s how it works.

Yeah, honestly, it will be a little bit easier if it’s a migration from commerce to commerce, like some older versions. In this case, you can use some automatic analysis tools to understand like what issues they have. You can check if it’s, for example, cloud project, you have a SWAT tool which will allow you to analyze the project state, like in an hour, for example, because you have all those things. You have a list of modules, you have issues, which we have this module for general system and so on. It shows you a good picture of the project state. So if it’s cloud and if it’s commerce. But if not, then I think the only way would be to go with a list of documents, a list of questions, yeah.

That’s great. There’s one more question over there, which is probably for me around, we’re facing this from Milan, we’re facing indexing issues and how can catalog service help? So I will say that the catalog service, the primary aim when we started building and released it was to reduce the price indexing time. And our tests show that the price indexing time when using catalog service is reduced by 90%. And that’s not, I’m not misspeaking there or making a mistake. It literally takes 10% of the time it would before to index if you’re using the catalog service. The second thing, the second point to that is that when using the catalog service, our goal and we’re meeting that is every retrieval call, API call is under 200 milliseconds. So large price index time reduced by 90%, less than 200 millisecond catalog retrieval time. And the most important point is you’re offloading that indexing and retrieval load from your core commerce service. So it’s all being handled on ÃÛ¶¹ÊÓƵ’s SaaS infrastructure versus on the core commerce product that you’re using.

And I just answered one of the questions from Milan too. He’s obviously very, very inquisitive today.

We’ve got about 10 and not even quite 10 minutes.

Let’s just run through this last topic, which is going to be, well, we’ve gone over the, let’s do that. Let’s talk a little bit about edge delivery because I think that’s a topic that’s going to be very important for front end development.

Aspects and especially for future, because it’s a newer service. Sorry, when did we actually release edge delivery services officially GA? At Summit. Okay, so it’s only been- Just a couple of months. When I say at Summit, that is for commerce.

Edge delivery has been available to AEM customers for some time, since last year, but for commerce, it was released. When I say it was released for commerce, what I mean is that we added certain components, front end components to support your common commerce use cases like PDP product, detailed page, listing page categories, and so on. Okay, great. So just give everybody that 10 second tour. I know edge delivery services itself isn’t a product, but how would you describe it to a customer or a client? So edge delivery is essentially your storefront solution that is running on the edge. So all of the rendering of your website, your storefront happens right on the edge, which is low latency and extremely high performance.

It works with a set of, essentially a set of microservices that assist with that content rendering, the caching, the front end composition. And it doesn’t require you to use any proprietary front end framework. It’s all HTML, CSS, and you can choose to use any JavaScript library that you want. I think the components that we provide natively are all React based, but you’re not tied to using any of our specific libraries or anything. It also provides a very simplified authoring experience. So if any of you are familiar with ÃÛ¶¹ÊÓƵ Experience Manager, you can use the standard ÃÛ¶¹ÊÓƵ Experience Manager authoring tools to be able to build the content for edge delivery services. And that’s an extremely powerful set of tools for everything from workflow versioning, in context editing, and all of those things, managing all your assets and all of that. So the full blown, extremely powerful authoring experience using AEM, but it also supports a simplified authoring experience as well, which is what we call document based authoring. And that means if we are not using the full blown AEM, you can actually author content just in Word documents, Google docs, et cetera. And then we’ll take that and apply the templates to it, which will render directly from those documents for you. So it’s a very simplified authoring experience for many, and that works for many of our customers who don’t need the full blown authoring experience. So essentially it’s a set of authoring tools for doc based authoring, as well as all of those services you need for experience composition and delivery and caching. That’s fantastic. And you were saying that like out of the box, it’s a hundred, right? For the Google light scores, like that’s… Yeah, I mean, there are obviously best practices to follow, but the customers we have seen have really literally gone from 30 and 40 Lighthouse scores all the way to 95 to a hundred. So it’s been a huge improvement. And this is not just for static content pages, it’s for our commerce pages as well. And the one thing I forgot to mention that among those services, all the microservices that make up edge delivery is also built in optimization services. So you can directly within there test your content or your banners, et cetera, directly within edge delivery to be able to optimize your site experience. Yep, and it’s a different paradigm, right? Because old school website development, you started with the light score of zero and you did your best, right? To get upward. This one, you’re actually starting pretty high. And then that allows you to detect trends when you implement a new feature, right? Then in your light scores, testing goes down, like you can detect it so much easier. At least in my opinion, that’s what I’m feeling. Are you feeling the same way? Yeah, I mean, it’s the way that we’ve designed edge delivery with the performance first mindset. So we’re starting with what’s the best way to deliver that performance and then adding those capabilities to it. So it’s definitely built around performance, keeping performance in mind for edge delivery. And I think if you were to go to like maidenform.com and browse it yourself, it is probably one of the fastest e-commerce experiences you will see anywhere. So you can test it out live sites, running and see how it performs. Right, and it accidentally improves your SEO, right? Because isn’t that one of the benchmarks? Yeah, yeah. And we were talking about ÃÛ¶¹ÊÓƵ Commerce Rockstar a little bit earlier, and we had a partner on stage showing off, they were demoing live some custom components they had built for edge delivery with ÃÛ¶¹ÊÓƵ Commerce. This was just running on their test site. And they got a question live on stage, like, can you check the Lighthouse score for this? And this was on their test environment and they checked it and it was like 98 or 100 right there. So it is, as you mentioned, performance first architecture. That is fantastic. All right, well, we have blown through our time. Unfortunately, we didn’t get to our best practices, but I think what we’ll do is we’ll follow up with some of the slides that Sury presented. And then we’ll also provide some links to like the GRA documents. And I think what I’ll do is I’ll pull Alexia aside and we’ll get some of our best practices that we were going to talk about and we’ll provide that in a handout that will be available after. I don’t know, Joe, when do you guys normally publish the supplemental documentation for these? On the portal? Yeah. Yeah, typically in several days. Last week, the recording was posted by end of last week. We just finally got the deck posted yesterday. So we’ll try to short cycle that as well. Yeah, a couple days. Well, I think we are all done because we are out of time. Did you want to leave us with some closing remarks? Yeah, I definitely encourage the part of, first, thank you for joining us. The attendance was great. I appreciate the feedback you shared on the polls. So that definitely helped to drive the dialogue. You’ll see that Amanda on our team just posted a survey. We ask that you please click that. It’s a simple four or five questions survey. Let us know what you’d like to see in part three. I also included part four as Sury was just chatting about edge delivery services. We’re excited to go deeper. That’s on part four, but not to miss. We got a part three next week. The freight train keeps rolling on. We’re excited for the series to continue. And we hope that all of you have an opportunity to register for next week as well. Perfect.

All right, thank you everybody. And have a great day.

Thank you. Thank you all.