Architecting for GRA

This is Russell with Adobe and I am here with Anton Evers. I’ll let you go ahead and introduce yourself. I am Anton Evers, senior technical architect at Adobe Consulting Services. In the Netherlands, right? In the Netherlands, indeed. That’s where I am. That’s beautiful. All right. So this next topic is how do you architect GRA? So obviously this is going to take it out of the hands of the business owners and those stakeholders and we’re getting to talk, this is meant for the architects, the people who are going to be implementing this global reference architecture. So Anton, can you just start off with what is not GRA? So what fundamentally, like what is not considered a GRA? Right. So if you have multiple stores and you just implement them by configuring several websites in Adobe Commerce, that is not necessarily a GRA. It’s not a GRA. And similarly, if you are installing Adobe Commerce on multiple servers at the same time, but all of those servers contain the exact same copy of the software and they all share a database, that’s not a GRA. So yeah, what is a GRA is when you have several instances of Adobe Commerce and with an instance, I mean, how to recognize an instance is basically counting your production databases and replicas don’t count. So if you have two separate production databases, one for one region and one for another, or one for one brand and one for the other, then you have two instances. So if you have multiple instances, then you might benefit from a GRA, which means basically implemented architectural principle of build one, use many. So you build it once, you install it to many of your instances. And the benefit for this is that once you have that core feature set to bring on another brand, you’ve reduced it down to weeks, if not days. That’s the whole future goal, is to have that core feature set. And when brand F comes along, you could just plop in the theme and pick a location for it to live on and it’s up and running. That’s the future happy path goal. Okay. All right. So what would be just a couple of reasons why a brand or a company would remove GRA from consideration? One of the examples I had is that every single brand is completely unique and they have no shared features. So you’re talking like a brand that builds rockets and another brand that sells rubber bands. They have nothing to do with one another. They’re never going to share the same catalog. They’re never going to share any of the same features. So in your opinion, what would be a reason why a company might just completely take GRA off the table? Well, I think it’s always good to ask the question, can we not implement GRA because GRA is out of complexity. And so if you can avoid it, if you can make a concession here or there to avoid it, that’s most of the times that’s better for you. So if you run multiple brands and they sell both self-fashion, you don’t need a GRA. But if you have multiple brands that sell different types of products, you still don’t need a GRA necessarily because you can have multiple websites with multiple product attribute sets in Adobe Commerce. And so it can help handle that. And even if you’re connecting to different backend systems, in some cases you could do without a GRA because you can connect to multiple systems and depending on which website initiates the request, you could switch between those services. So even then you don’t necessarily need a GRA. What about like your technical team maturity? Would that sway a company from considering GRA? No, I wouldn’t say so, because even if your team isn’t technically mature enough to handle a GRA, if there are convincing reasons that you need a GRA, then the team’s maturity will need to change instead of your products. Got it. Got it. That’s great. You’re forcing the business to think outside of its own short term goals and wins and forcing them to look long term. That’s great because I was kind of expecting you to say yes, but I love your answer. That’s phenomenal. So when we talk about some issues that if you avoid GRA, and you did bring some of these up, like if you don’t go with the GRA knowing that a company is compatible and should do it, can you just run down a list of some of those things that would bite them in the future? And I think you brought up like management, code management and tech debt being one of them. Is there anything else that you could think of that would be a detriment if they were a good candidate, but they just chose not to do it? I think so. It’s easier to split up a code base than to merge it back together. Oh, good point. You can’t delay the decision. If you’re not entirely sure and you don’t have the means to make the decision right away, then you can delay it. It does come at a bit of extra cost because once your stores are in production, changing your methodology of working is going to cost you extra. But it can be a valid approach. If you don’t do it because of the wrong reasons, for instance, your team is not mature enough, well, then because of the lack of maturity of the team, there could be other things that might be built architecturally or suboptimally because of your team’s maturity level. So that might be a good reason to take on someone or to email the consulting services to bring on someone who can help them implement the right type of tiering. And another thing that came to mind when I actually wrote this question was people’s privacy and data is every day becoming more and more important. And so if you choose not to go with the GRA methodology early on as brands mature and your company matures and you branch out into different areas, if you’re not already following that principle, maintaining that GDPR requirements and regulations will get even harder because once again, once you’ve got production instances and things are running to break them out to allow them to be compliant, can be very cumbersome and very expensive. And so that was the big one that I had thought of when I wrote this question and you touched on several others. So that’s great. Thank you for opening up that one. No, definitely. But you can split up the single store and even untangle the GDPR related data. It’s going to be harder. It’s going to cost you. It’s harder. You can do it. A definite disadvantage is that when you’re building a single store, you’re often building only for the thing that you are doing right now. And GRA forces you to think about the broader set of options that you might have in the future. So if you’re thinking with the three, four brands in the back of your head and the back of your mind and you’re building brand number one, then you’re already creating openings and customization paths in the places where you know that another brand will be doing something else. And so you’re going to build something architecturally more solid, more modular actually, more personal, flexible. Yeah, that’s great. That’s a really good pro tip right there. Thinking globally instead of in your single instance. So this next topic is going to be kind of vague. It’s on purpose. When you are going to give a few benefits for considering GRA, like we’ve already gone through some of the disadvantages. In my opinion, once you consider GRA, you kind of negate all of those disadvantages. For example, the simple story of you have one instance of commerce with two to three websites but if you’re going to do a production deployment, you don’t just get to pick which brand is affected. You’re forced to deploy to that one instance, which means all of them could unfortunately have to have the rollback procedure if it doesn’t go right. A myriad of things can happen. GRA does give you that flexibility. If you want to deploy and you know that it’s noon on a Friday and it’s a busy weekend, but it’s like 2 a.m. on Sunday because your stores are just geographically so far apart that it’s okay to deploy to that one brand and then let your other ones wait till the off hours. So when you’re thinking about benefits for your GRA, now that was just one, what would you think of a few others that just come to mind? Because once again, this is meant for architects who may have to pitch this idea to their stakeholders. So what would you give them for some benefits? Well with the GRA, you can get a significant performance increase because you get to pick which software is installed on which instance. If you don’t have a GRA, you can disable or functionally disable some of the software based on your store configuration in the admin, but that doesn’t mean that each single line of code is going to be disabled. Most often, you just disable the parts that are visible to the customer or that make a significant impact and the rest will still execute. So you’ll get a performance increase by installing less software and the less software is executed the faster your program runs. And by that same measure, you get more stability because a bug that occurs in a piece of software that isn’t installed, might be expressed on your website. That’s a great one. I love that. That’s a double negative there. No, no, it paints a really good picture. What about data privacy and isolation? Obviously, it just makes sense, right? If you have two different stores, your data is completely separate. So you’re almost instantly compliant with some of the fundamentals of GDPR. Is there something else that you could think of that would fall under that same vein? Right. So your stores might be serving from different warehouses. Of course, you can configure multi-source inventory in other becomeers. But making sure that your inventory syncs with the right warehouse could mean that you want to have a single instance for one warehouse and a single instance for the other. That simplifies your code. Most of the times you’re not just talking about warehouses, right? You’re talking about warehouse, you’re talking about pricing, pricing for one brand. That might come from another source than for the other brand. So the more integrations you have, and the more differences in integrations you have between instances, the more benefits the GRA is going to bring you. Because you only have to build for one integration type implementation. No, that makes sense. You only have to build one price import, one stock import, one product import, and you only have one active counterpart at the same time. And the reason why I brought it up is I was on a project of really complex one where they sold liquor, beverages, wine, but they had this side business that they had running along with it. But what we did before, this was before, and they weren’t a great candidate for GRA, but this is why we pitched it, was we were having to do inline logic. If you’re displaying this product to this type of customer, you have to go get the inventory from this warehouse because certain products could only be sold within a city’s border or a county’s border. So it was completely unavailable to somebody who was in a different region. And so we had this inline logic. It made the page loads kind of slow. And that was my pitch to them was like with the GRA model, once that customer is looking at it from this persona, that APN, this would take them to that other GRA instance. They would only talk to that inventory. They would only know what products are available. Otherwise we were doing real-time code logic and it was really complex and it was slow and it just didn’t work very well. And so a huge benefit is, like you said, is that data isolation piece, which is great because it keeps it manageable at that point. You don’t have this if else tree going on. No, definitely. And in terms of your catalog, I mean, what you’re saying, it paints a picture of a situation that can also go wrong, right? You could accidentally show the wrong content to the wrong person or in the wrong region. If you have two completely different brands that sell, that maybe can perceive to consumer as competitors. Or even if they’re not competitors, you don’t want to have that content accidentally mixed because someone ticked the box that a product is also enabled on a different website, right? That’s just impossible if that product isn’t in the catalog on the other stores. That’s a good point. Our next topic is going to be on the code management. So as far as I’m aware, there’s three methodologies that have been proven to work in multiple Adobe Commerce ACS implementations. There’s a fourth one that we’ll bring up. In fact, I’ll just lead with that one. And that way the rest one will be open for your input. But the first one that I was, when I did some interviews trying to do some research for this topic, one of the companies that I talked to had to implement GRA on their own because at the time they did the implementation, there really wasn’t a lot of guidance from Adobe in our current experience in documentation. So they took what they could and they came up with their own concept, which was branch level code management. So that meant that they would have a main Git repository and they would have branch A for brand, you know, brand A, they would have different branches and that’s how they separated their code. What they found is that pattern was very efficient as far as like conceptual for the developers. But what they failed to think through entirely was what happens if a feature is developed for a specific brand, then has to be merged into the core shareable code base. That turned into a nightmare for them and they found different ways to dance around it. But once again, if you don’t pick the right strategy, it can lead you down a path of complexity and then eventually it turns into that nest of like a bunch of wires all grouped up together that you can untangle it, but it just takes a lot. And then you have to have a certain level of experience doing the Git management in order to do it properly to not affect everything accidentally in a bad way. So that was kind of the first one that I was introduced. I did learn from some of the ACS counterparts that probably the more traditional ones that we would recommend would be having a split package for every single module that you write. Then there’s this concept of split Git and then there’s this concept of monorepo. So Anton, if you don’t mind, can you just pick one of those and just let’s walk through some benefits. Let’s walk through some disadvantages. And then if you feel like it’s necessary, give it a little bit of a primer on what the different options are. All right. So basically there is a deficient into two types of GRAs and that’s also historical, but I’ll get to that later. There’s the Git based GRAs and the Composer based GRAs. So what you described just now is a purely Git based GRA. So you have, for instance, the split Git approach, which I mentioned earlier in this interview as well. It’s where you basically have a separate repository for the, and this is historically from Magento one. So keep that in mind. You have a separate repository for your core code, which includes Adobe Commerce or back back Magento one. Then a separate repository for your third party code. That would be a community and a separate repository for your local code. So for your second party code. Now those three repositories would be added as remotes to a fourth repository, which would then merge everything together into a full installation. So that one repository would contain everything except the local code and the community code. And the other one would contain everything except the core code, the community code and the third one would only contain the local code. So merging that all together creates the directory structure of a full Adobe Commerce installation or back then Magento installation and it would build your store. And you needed a kind of setup because modules weren’t neatly organized in packages back then, right? You had some code in that code, you had some code in that design, maybe a lib. And those were all different root directories. And so in order to merge that together, you could use Modman back in the days. But alternatively, you could also just create those directories in Git and merge them together and then they would fit as well, which is much easier and much more low level. That’s one way to do it. But the disadvantage is of course that you’re not leveraging Composer, one of the biggest advantages of Magento 2. So when Magento 2 arrived, Composer was introduced and that gave us the opportunity to build actual packages. You could then create all of your customizations in a single Git repository and define that as a Composer package. Basically install Adobe Commerce from Composer and also require your single customization package which contains multiple modules and install those as well into the app code directory. So then still you wouldn’t leverage Composer for your modules, but at least for the Adobe Commerce and third party marketplace modules. And you would just install your code into our code. So that could be done with a Git remote as well. Alternatively, you can bake a package with a Composer JSON and host that in, well, in your Git repository, add your Git repository as a Composer repo in the Composer JSON of the main project and then install it that way. So that’s describing the, well, we call it the bulk package, the array where you create a package with bulk of modules and just install those modules into your GRA all at the same time. It keeps it simple because all of your code is in your customization code is in one repository. So if you have a pull request that spans multiple modules, just have one pull request and it’s fine.

Very easy, but it has the drawback that you don’t have the flexibility of installing package A, B and C to brand one and then only installing package A and B on brand two. You could have callers use your app.etc config.php file to disable certain modules. But again, that’s a risk because you’re not taking your Composer dependencies into account there. You could disable the module that is required by another module that’s still enabled. And if you have set up your Composer dependencies right, but you didn’t set up the dependencies in your module that X and L, right, then still you can install a combination of modules that’s functionally incompatible. So you could take away that disadvantage by installing everything through Composer. So now you’re going to a situation where you’re fully leveraging Composer and fully leveraging dependency management. You physically can no longer install packages that are incompatible with each other because Composer prevents you. And to set that up, you’re looking at a GRA version that creates separate packages for each single module or each single Composer package will have its own Git repository. And so each Git repository will represent a Composer repository as well. So you would add each repository as a Composer repository that you can install or not install from those Git repos. And your tags in Git would be the versions of your packages in that case. The disadvantage there is that this tends to become really slow because Git repositories aren’t really optimal Composer repositories. They work quite slowly and you will have a ton of Git repositories in your repository. We ended up, you know, we had clients where they had like 250 modules and it would take forever to deploy. So the solution there is to bring in a private Composer repository. So you have multiple solutions for that, right? Like status or private packages or JFrog or any of them, right? I think Azure also offers a solution for that. So, you know, the easiest ones just can be set up to mirror your Git host of choice, right? GitHub, GitLab, any of them. And automatically ingest any package that has a Composer JSON on the root. So they will, you know, as soon as you create a repository, you add a Composer JSON file, you’ll have a package in your Composer repository as well. And that’s the easiest way to get around that. So now you have a single Composer repository that mirrors your entire Git code base. And it can also mirror, rip it up, Gento to come, it can mirror your third party Composer repositories. So you install everything from one place. You’ll have your keys nicely stored in that place. You don’t have to distribute them to developers. So that’s all really nice, but it comes at an enormous overhead because you now all of a sudden have 250 Git repositories. And if you have a pull request that spans multiple modules, then you’ll have to make sure that you’ll code review all of them before giving the okay and start merging. Because otherwise you’ll end up in a situation where two thirds of your changes have been merged and in one module there’s an issue that needs to be resolved. And now you have pushed something to QA that’s only two thirds present. So that’s a nightmare. And this is where the Mano repo comes around. And Mano repo is essentially exactly the same thing as the Magento 2 Git repository. Because it too is a single repository with all of the modules installed. And they’re installed in that code. They’re not installed as separate packages. But somehow there’s some magic that turns them into packages and hosts them module per module in a composer repository. So that’s exactly what you’ll do with the Mano repo. You’ll build in one place inside of an Adobe Commerce installation. Maybe not in app code, but you can create a packages directory where you host all of your modules. And then you can locally also install them through composer with a path type repository. So that you’ll have your dependency management working and all of your composer JSON files in your modules will be evaluated locally as well. But that way you’ll have all of your code in the same repository. You can still work with meta packages to group packages to certain regions or to certain countries. And you’ll have the benefit of making pull requests once for multiple modules or maybe modules on the theme or everything can be combined. And you can even add your front end to that Mano repository while we’re at it. I mean, if you want to make sure that a certain version of the backend and a certain version of the front end are always deployed in tandem, then you can put them in the same repository and then connect the versioning so that they always have the same release schedule. And you can make sure that they’re connected and compatible. But what you’ll need to do is add a DevOps integration. Maybe a Git action or something like that. Those are available online where a tag in Git will be converted into a packaging action that picks apart your code and takes every single module, makes a package out of it and hosts it in your composer repository. And the easiest way to do it is to have those 250 separate Git repositories still there. You’ll make them read only so that only your automation can publish new changes to them. And then you just connect that to your private packages, for instance, which automatically reads those new packages and hosts them as a composer repository. So that way you’ll still have the flexibility to install composer packages one by one for your production environments and for your UAT environments. But when it comes to development and maybe even QA, you’re developing in a single code base that has everything installed. And there you have the benefit of not having that enormous management overhead on the technical architecture side. Interesting. So unfortunately there’s not a one size fits all, right? So when you pose the question, well, what should we do? Because once again, the people that are going to be interested in this topic for this particular section is going to be the architects because they have to make that final decision. Does it literally just depend on the technical maturity of the DevOps plus the integration engineers plus the automation engineers? Or is it something that anybody can figure out any one of these and they just have to decide? How would you guide them to picking the right one? Because once again, we can only give them advice, right? We can’t tell them you must do this. How would you guide them? No, definitely. So there’s a couple of things to take into account. So one is your team’s maturity level. If your team is still growing in maturity and you think that you don’t have dedicated DevOps maybe, then maintaining all of that automation may be too big of an ask. But that’s not the only thing to keep in mind because your code complexity also plays a role. If you only have 10 customizations or 10 extensions that you maintain, then your overhead on pull requests, that’s going to be that big. So there’s the cost of introducing the complexity of a DevOps workflow. You can have action and the connection to your private packages might cost you more than just managing those couple of pull requests and making sure that they happen at the same time. So then by all means, take a simpler version. True. And if you always install the same set of packages as a foundation to your stores, if you don’t need the flexibility, then by all means, use both packages. Make sure that your code is all in one big composite packages. They need to be installed together anyway, so why not have them in the same package? Right. But don’t be lazy. Don’t do that just because it’s easy. Right? That’s the other key to the equation. No, no, no. It has to be. Thoughtful. Yeah. Very thoughtful. Think about the need for flexibility on the production deployment side. Not only today, but also in the future. If you foresee that at one point you’re going to need to make choices or you need to maybe shift packages from localized to global or the other way around, if you need that flexibility or you foresee that you will need it in the future, then choose a version of a GRA type that is able to handle that flexibility. Got it. All right. All right. So getting away from code, how would you recommend that an architect prepare his team and his management CEO and all that? How would you have them prepare the personnel required to implement GRA correctly? Right. So of course the technical architect will need to do some homework in understanding which GRA fits the organization or the use cases. You need a good product owner or product manager that can make the decisions whether your code will be global or will be local. If it is global, they need to be able to make decisions on what features will be supported and which won’t because it’s going to be shared code, right? There’s going to be multiple stakeholders. They might not agree on some things, but in the end you will need to deliver something. And you don’t want to have a delay every time a decision needs to be made because it needs to go up the tree and down again. So you need people that can make decisions there and then really own the product or the outcome of the product division. Make sure you have the right QA staff in place that they understand what the GRA is as well because they need to know the difference between testing code in a global perspective and localized because your localized code, your country installations or your brand installations will contain a different set of modules than maybe your GRA itself, right? You’ll have your foundation plus something else and for another country you’ll have yet another combination. They need to understand the difference there. Another person I thought of while you were talking was the financial decisions because you know at sometimes a feature will incur costs. So making sure that you have that purchasing person at the table, that person that can make that decision of yes, this is within my approved budget. I can make that instant decision because once again the last thing you want is for every decision to have to be made to somebody to make another decision and if that incurs costs then they usually have to ask somebody else. And so making sure that that team is small but big enough. And I think one of the recommendations from the summit presentation from Lindy Cow was about six to eight people was what you should have for that core team. Do you think that’s a little big, a little smaller? Did Lindy hit it on the head? No, I think that’s about right because that’s the amount of people that you can put into a meeting where they are still all actively participating and you’ll notice when someone is tuning out. So with that amount of people you’ll be able to make decisions and still agree on the outcome later on. Right, right. And actually this is pertinent for any size organization. So like even you know enterprise level down to mid-market that same type of people need to be at that same meeting. It’s going to be harder for the bigger companies right because they’re going to want their bigger stakeholders in place. But the guidance from us from Adobe is keep that team as small as possible and put the right people at these meetings and don’t introduce 15, 20, 30 people because you’re just going to stagnate the process. For organizational alignment, this topic is very important as far as I’m concerned because if the organization that you’re working with does not have their goals and objectives clearly defined that has ruined more projects than I ever care to admit. As far as you’re concerned like organizational alignment, what types of things should they be considering and what types of decisions should they already have in mind before the first meeting with your technical team? And then maybe the subsequent ones after that. But more importantly how would you advise them to prepare for their first meeting? Well the decisions that need to be made about what is becoming the foundation of all of your stores, that decision needs to be based on something and it can be just revenue, right? Sure. But it can also not be revenue but just value creation for your customers or value for another part of your organization. I think clear company objectives and a clear vision on what your organization aims to achieve, that helps you in aligning with those goals. Because if something is potentially adding a lot of revenue but it’s completely contrary to your goals, you’re misleading your customers in one way or another, you can end up there even without intending to do so. Then you’re not spending your resources in the right way. So prepare by having your decision makers aligned on what the bigger picture needs to be. What’s the image of your company? What’s your company identity that you need to work towards? Trying to achieve. And then we’re done from there. And this is something you lose track of that very quickly and get into the details and the smaller decisions. But every now and then you need to check yourself and see if you’re still aligned to those goals or not. Yep. That actually leads nicely to the next topic, which is clear documentation. So by this I mean requirements for those features. Those should be thought ahead. Now, remember, at this phase, we’re just talking about preparation, but having clear documentation of what the requirements are, any known technical specifications or architectural diagrams that need to be provided. Because once again, if you’re going to be bringing in an SI or Adobe Consulting, we need to know how these systems talk to one another. So bringing that clear documentation to that first meeting is important. I’ll let you go from there, but that’s kind of what I’m talking about. Is there anything else that you want to add to that? I definitely bring that documentation and having an idea of which problems you are trying to solve and not having an idea about which solutions you’re aiming to. Right. Yes. So don’t solutionize, but think about the problems you solve. I only described that, right? That should be in your functional requirements. What are we going for? What are we, you know, what should be the outcome and not what should be the path to it? And let the tech team figure out how to technically conceive it. Bring in functional requirements. Make sure you’re also aligned on the methodology that you’re going to follow because those documents could be part of a waterfall methodology or a scrub methodology. And depending on that, the level of detail you need to know in advance may be completely different. And that connects also to expectation setting, right? Are you going to set the expectation that you will go live on exactly this date or are you going to be more agile and more flexible and say, okay, we’re aiming for that month. And if by the beginning of the month we have delivered a release that meets our expectations, then we go for it. But if there is something that really absolutely needs to be done and it hasn’t quite done yet, we still have another couple of weeks of Slack to make sure that that is part of the first release. Yeah. Yeah. No, that’s important because it’s unfortunate when companies pick dates that are hard and fast and they expect a waterfall outcome, but don’t do any discovery to properly lead an agile approach to actually accomplish it. So it’s this mentality of we want to be flexible, but we want to be hard and they have to be one or the other or just literally just be flexible. If they could just be flexible and understand that things happen, yes, we did project two weeks to finish this feature, but sometimes it takes three. Sometimes it takes four because of QA issues and being flexible, being aware that flexibility is required. Then going back to what you said earlier, setting expectations. If they’re aware that flexibility is required, then they’re not going to be so… And if we’re open and honest on every PR and every iteration that things are trending green or red, then it will keep everybody informed. It’s all about communication. Like if anybody takes anything out of this talk at all is this open communication and making sure that everyone’s always aware at all times of where you’re at leads to much better conversations. Because if you know four weeks into your project that you’re already behind and you know that you’re not going to meet your deadline just because you’re already behind and you’re only four weeks into your project. So yeah, just keeping open communication is pretty important, at least in my opinion. Yeah, definitely. And then, you know, this may be hard, but try to make sure that you don’t increase the pressure too much on the development team. I mean, of course you get pressure from maybe from your managers about the timeline that’s slipping. But from my experience, a development team that starts to really feel the pressure where there is no filter above them and there’s a feeling of safety in the team, that’s going to only be like much, much more because if developers are stressed and there are no pressure, they’re going to make more mistakes or they’re going to deliver software when they’re only 90 percent done. It just needs to be delivered and it’s 90 percent done. So it’s cut by. Yeah, that’s where the flexibility is a great tool where you can, you know, you can know that, OK, we’re maybe a little later than we expected, but I’m going to give the team the confidence that, you know, I know they can solve it and they can deliver what we need instead of adding pressure, try to remove scope. So if you think that this feature definitely has to be there, but not all of it, right, we may be able to replace some of the admin functionality with a manual workflow and then we can go live either way next week. Right. So try to think of those options. OK. Just another topic is making sure that your change management, your bug management, your JIRA management is all properly aligned and ready to go and everybody’s aware of the tools that are going to be used. It’s just it’s a shame when somebody starts with, you know, using something like BaseCamp or something that isn’t like a more ticket based JIRA system and then mid project trying to switch over, it just it gets to be really hard to make those changes. And so picking your tools ahead of time, making sure that your local environment set up, all of your scripts, you know, all those things are just done and your teams are just ready to go. It’s just it’s all about prep work, to be honest. And that’s not just for JIRA. It’s pretty, pretty typical for any project. Yeah, this is even more important in large organizations. So do a test run of the process in your head and talk through it with the key stakeholders, because if you’re part of an organization where it takes three months to procure a new piece of software, that can be detrimental if you only recognize that during development. Right. And, you know, you add three months to your delivery without yeah, without any. Oh, yeah, that’s bad. Okay, so we’re gonna just dive into the last two sections, which is DevOps, technical leads and Git and the workflow or composer, however you once again, there’s many ways you can can do a JIRA. What advice do you have for the level of DevOps? Can you outsource that your technical leads? Like, how much do you think they need to be on top of like, either Adobe commerce specifically, or can they just be a general tech lead that understands, you know, just multiple languages? And then what’s your idea on how much can you learn on the job for Git or composer for a JIRA to be successful? Right. So you don’t necessarily need to be a good Adobe commerce architect to be able to set up a JIRA. JIRA is a generic architectural pattern. And so it, I mean, it could apply to many types of products, many languages, doesn’t really matter. What you do need to be able to do is to think about the whole conceptual idea and how it all comes together with branching strategies. Right. How, you know, how are you going to set up your branches in such a way that you’re going to be able to create an environment that contain the right set of software. And in terms of DevOps, you know, it can help to have, for instance, ephemeral environments that can be created as soon as a pull request is being filed, so that you’ll have your production code base plus the single change that you’re about to introduce on a fresh installation. Yeah. So if, yeah, if you’ve figured that that might benefit you, if you are highly advanced, you’re aiming to do continuous deployment where as soon as a change is ready and it’s safe to be released, going to be released and it might be enabled later on, then yeah, you may need ephemeral environments and your DevOps need to be very, yeah, very well-trained in that experience. But yeah, architects need to know how it all comes together. How do you do your versioning? How do you do your naming conventions? I mean, naming conventions are critical in GRAs because, imagine if you add the name of a country to a module and you want to install it to a different country, then all of a sudden your Spain module is installed in France and no one will get that. It will cause a ton of confusion. So yeah, naming conventions are critical. But all of that, it’s all of the intricate details, right? Branch X, Y, Z, naming convention, package distribution, meta package grouping, right? You need to be able to, are you going to create one GRA or are you going to create multiple groups of modules based on the different regions and then sub regions or countries or brand types that you have? All of those things, they can either be done or not be done, but you need to conceptualize and understand when and why to do it and when and why not. And that’s what the technical architects decide. Yeah, and that’s a good segue to this next one. So I almost skipped this question, but I’m glad I didn’t. When a PR comes in, if you do happen to see something that the naming convention is deviated, you should reject that PR and force that developer to rethink because he might have gotten back into that old habit of thinking, well, this is only going to one instance. And like you said, even it’s as simple as the naming convention of putting the country in the module, for example. Like that alone says that the developer wasn’t thinking in a GRA methodology. He had his blinders on. And so is there anything else about like the pull requests or that process that you’d like to expand on? Yeah, definitely make sure you understand Git and Composer well, because it is possible. I mean, if you arrange the process in the optimum way, then you’re limiting the chance of mistakes being made because your GRA should be based on technical steps and not on conventions and agreements, right? You shouldn’t have verbal agreements or written agreements that this should be done in this way, that should be done in that way. It should be impossible to do it otherwise because people are going to forget. People are going to make mistakes. And so you’ll have to make it impossible to make those mistakes wherever you can. But even then, you’re going to be able to mess it up if you really want to, or if you really don’t understand. So make sure that you know what it means when Composer throws a compatibility error and how to resolve it, or that you know how to get a certain part of Git history into another place if some of your automation failed and you need to make sure that your packages are all in sync with your monoree plugin or something like that, right? Right. Right. So make sure you know your tools. That’s in general, that’s the advice. And if something goes wrong, invest the time to understand exactly what is going on instead of doing a quick fix and finding it out later because that’s never going to happen. You never have the time later on. Oh, God. So true. Okay. Well, that is the end of the architecture discussion for GRA.