Global Reference Architecture

Transcript

And this is Russell with Adobe, and today I am going to be visiting with Anton and Lindy, both Adobe Architects and senior advisors and senior leaders in the e-commerce space, specifically around Adobe Commerce. And today’s topic, we’re going to be covering global reference architecture. But before we begin, Anton, why don’t you introduce yourself real quick, and Lindy, you’ll be next. I am Anton Evers calling in from the Netherlands. I’ve been working with Adobe for five years and prior to that, some seven and a half years with an implementation partner. And during all of that time, I have implemented tons of GRAs and also, well, created some GRAs flavors. Cool. Lindy? Hi, I’m Lindy from the Commerce Professional Service Teams. I am currently managing the talented group of the architects. And interesting, I have a unique connection to the Magento right now known as Adobe Commerce. I have the privilege of being one of the first full-time employees back in the days. It’s been quite a journey since then for me. Yes, it has. I definitely love that part of your history because only a few people, in fact, just you and two others could say that. So it’s kind of cool. All right, so let’s kick it off. Lindy, can you just give me what you would consider like a high level overview of that concept of global reference architecture? So global reference architecture is the purpose of having the reduced cost when you are having multiple brands and sharing the code base or foundations, which can be utilized by the one you are having a brand launch or the one you’re going to have a region launch for it. And so by having the same code base utilized by the other brands, so it can be maintenance, it can be also like easy as it was. Do you think it’s going to be limited to the types of products you sell or do you think it’s not a consideration? It’s not. Okay, that’s cool. So Anton, when you think about GRA and you’re trying to just give like somebody like an elevator pitch because you’re going into a meeting with them and you’re going to be kind of introducing this topic, how do you do that? Right, so GRA is essentially a way to cut costs and to become scalable. So and it’s especially about the scalability that becomes really interesting because you want to be able to scale your product without also needing to scale your team in an equal measure. So GRA is a way to allow you to spin up multiple stores with the same team size and be able to have that team manage it with low overhead costs. Because with traditionally people would just copy stores from one installation to another and with each copy your code starts diverging because you develop on one copy, you develop on the other one and they start to diverge and essentially you end up, you know, when you have five separate stores running, you end up having five completely different applications that you need to service. Even though the code may be trying to be the same, it’s still, they’re not because now you have five copies of it. That makes sense. Okay. Right. Yeah. And GRA or global reference architecture is the answer to that and make sure that you have one copy of your code that you need to service. And so if you fix a bug or add a feature, you can distribute that to all of your stores at the same time or to select stores, but the development cost, you make that only once. To add what Antoine has mentioned, so we recently have one client having the basically like almost similar code bases, but in the separate brands and a separate repository for it, it’s very hard to maintain. They thought like, oh, I just based on the code from one of the sites, but at the end there, you know, like changing a lot at the end, it’s so hard to maintain and so hard to merge into as one code base. So Lindy, when you think about like two or three, the most important benefits of GRA, what comes to mind? So if I need to pick, right? Just a couple of the bigger ones. Yes. So faster time to market with a unique five code base and then increase scale and velocity and minimize the futures, right? The tech deck because you are creating a foundation that can be used for everybody and it is also allowed to have a brand side uniqueness as well. So brands and the regions they can have their own storefront, the brand uniqueness as well. They get flexibility with the rate reusability, but they get flexibility with they’re still able to brand and do things as needed for, oh, that’s good. Okay. Yeah. The last ones would be like maintainers, right? And maintainers, stock applications. Okay. So Anton, when you think about some, your top benefits, what do you pitch when you’re talking to people? Yes, definitely the scalability is a benefit of low cost. Scalability increases when you use a GR8 because if you have five different applications, then one bug might occur in one store and it might not occur in the other or it’s a different solution, quite different solution than the other one. So your code stability becomes more predictable with a GR8. It’s very important. Yeah. Yeah. And another benefit is maybe a bit more from the last couple of years is that you are setting yourself up for potentially doing continuous deployment. Continuous deployment is very hard to manage if you have multiple stores and you don’t run a GR8. Interesting. And a GR8 enables you to do that. Yup. I love that. What are some main considerations that need to be taken into account when considering leveraging global reference architecture? So this could be infrastructure or code or personnel or anything else. What are some bigger considerations that you’ve had to educate our customers when considering this approach? So from my point of view, it’s going to be the road to match, right? Where the business want to be, transforms their business into, are they thinking about the e-commerce site just for one brand? Are they thinking about a global launch? Are they going to think about multiple brands? Need to start from there. And then when you start the point, you need to think ahead as well. For future is where you want to go. From there, you are also going to figure out, okay, do I need to have a global reference architecture? By having that one also, you also need to have a, need to put into who you want to be involved by alignment. Alignment is very good to be important part of this as well. So thinking ahead and making sure that all your business stakeholders are all aligned and all your tech teams. Okay. Yeah. Sometimes I also like when you have a multi-business stakeholder, it’s hard to align for it. So you want to choose which are the main or major ones you want to align with. The actual big ones. Yeah. Yes. Okay. Anton, same question. You’re considering you know, what are some main considerations that you take into account before leveraging global reference architecture? Yeah. So from the technical perspective, I would say that the team maturity defines for a large part which type of global reference architecture you’re able to maintain because they come in several different flavors and each one has its own benefits, but the drawback is always technical complexity. And that’s something your team will need to be able to handle. So technical maturity of the team definitely. And before that, of course, the level at which stakeholders are able to agree and because the more code you can reuse, the bigger the benefits. But that means that you need to align your business flows. And that may mean change in some people’s business flows and change is always scary, right? It’s always something we’re fighting against. But the thing is, if you change the business flow, it will cost you money once. If you change software, it will cost you money every month that you do maintenance on it. So that’s a recurring cost and people don’t always see it like that. So yeah, definitely alignment across all of the stakeholders. That’s something very important. I’d like to continue that thought. So when a company is considering this as an option, what are some ways that you can help them understand that this is actually a good idea? Because you keyed on it a little bit, but I want you to expand on that a little bit if you can. So to understand whether it’s a good idea or not, there’s a couple of things that weigh in. So one very obvious thing is the more instances you run, the more license costs you will incur because every instance needs a license. So that has to weigh out against the benefits that you get from that scale. So if, for instance, you have GDPR considerations and you need to store customer data in a specific region, there’s no way to get around it. So you’ll have to create a separate instance there. But there are also optional reasons to consider for a GRA, such as the amount of load that your server can handle or amount of orders or complexity on your catalog. So there could be considerations for spinning up a GRA, and then it has to weigh off against the incurred costs. So it’s basically a pros and pros list. You’ll have to make your… Yeah. No, that’s good. So Lindy, when you… because you manage the ACS team, is it required that we use consulting services or professional services to do a GRA? So global reference architecture GRA is not exclusive to the Adobe consulting services or Adobe commerce at all. I saw some other service provider also utilize something similar to architectures or patents as well. ACS, however, we have an expertise in implementing GRA approach for the multiple. Our clients are enabling, they are separating, they are brand launch and they’re reaching a rollout as well. So it sounds like if a company wanted to, and they had an SI, they could still consult with consulting services to make sure that it’s either implemented correctly or help them with discovery or help them with any phase of the project. Okay. That’s great. And we have the experience like the SRA are working to get already other solutions provider. We came in as I said, sometimes we come as we do the discovery and we hang out to the solutions provider to implement, or sometimes we came in as they say, hey, we’re going to put in on a GRA framework for you and you kind of continuous maintain and do the run and operate for the clients. Got it. Okay. So Anton, let’s talk about some of the problem areas and the pain points that a project might incur when doing a GRA, because it’s not all rosy, right? We all know that there’s going to be some issues. So in your opinion, like what are some of the bigger things that a company may experience? So I won’t talk about the things that can go wrong when you’re doing a GRA, right? Not in the sense of you’re doing the implementation wrong, but just about the drawbacks of doing a GRA in general. Exactly. Yeah, because the other discussion can take forever. There’s so much you can’t do it incorrectly, but that’s why we were doing this interview, right? To explain how to do it right. But if you’re doing it right, even then, so some forms of GRA take away some flexibility, right? Obviously, if you have two separate copies of a star, you’re infinitely flexible. You can completely diverge on your development. You could sell a brand and just give the copy of that code to the next maintainer. So you’re infinitely flexible. With the GRA, that becomes a bit more complex because now all of a sudden you have a shared code base and if for some reason your brand is purchased by another maintainer, then you’ll need to give a copy of that code, but you can’t install it from the location where you might be installing it from today. So your transition will be a bit more difficult. So I mean, this is not a really common scenario, but it’s still something to keep in mind, right? So it’s a business of acquiring and selling brands. But also it comes at the cost of complexity. And there are many ways to do a GRA from really simple to really complex. But the flexibility that increases in certain levels of GRA always comes at the cost of complexity. So for instance, at the very simplest level, you could do a GRA just with Git, not even with Composer. And that’s how we used to do it back in the mid-tempo one days. We would just take a couple of Git repositories with three code areas in those days, the first parties, second party and third party code, or local core community. And those would sit in separate repositories. We would add those as remotes to a fourth repository, which would contain the actual store installation. And we just like you close the zipper, we would just merge a lot of the free repositories into one and it would just fit seamlessly. And that’s a very simple way of creating a GRA because you have one copy of your local code and one copy of your third party. And you just maintain those and zip them together. However, it doesn’t give you much flexibility because you always install all of your local modules. And so adding more flexibility in the form of Composer added also another component that you now need to understand, which is Composer. And then to become even more flexible, you want to, in Magenta 2, you would create separate packages in order to install those separate packages in any combination that you could think of, because that’s the ultimate flexibility. You now need to create a separate repository for each single package in Git, adding more complexity and more architecture overhead. So yeah, that overhead, that is definitely something to watch out for. And again, there’s yet another method to avoid that overhead. But then you’re also adding a new element to the mix again, which complicates the thing even further. So now you need to involve DevOps to do some automation and to take away that overhead of multiple package management. So it’s, yeah, complexity is definitely the drawback. Lindy, is there any high key pain points that somebody might want to be aware of? The addition is to what Antoine mentioned. One thing is the foundations, whatever it is, it can have a version that continues maintenance. So it should be how you are enforcing whoever is using these foundations to go into what were the versions. It’s similar to the Adobe Commerce versions. We have the upgrade quarterly or the half year, then need to make sure as a brand also like follow that one. Sometimes brands will stick to whatever versions they have and it is very hard to maintain for it. Yeah.