Implementing Global Reference Architecture

Transcript

This is Russell with Adobe and I am here with Anton Evers. Hi, I’m Anton Evers, Senior Technical Architect at Adobe Consulting Services. How can you implement mobile reference architecture? This one is broad, but we’re going to try to narrow the scope down a little bit. And the intent for this section, this topic, is to give you guys an understanding of, look, your company has already been taught what GRA is. You as a leader or as some sort of technical leader, you understand technologically what to do, what to expect. Everybody’s on board. Now you’re literally ready to get started, right? So this is how can you implement it? So for architecting GRA, we want to make sure that everyone is very aware that the decisions that you make early on can be fundamental and they should be fundamental to the way the whole project is going to work. Your tools, your software, your teammates. You know, if you know that somebody is going to be on a 12-week sabbatical right in the middle, they may not want to be that right person that’s at the table making decisions on whether modules are going to be in or out, right? Especially like if they’re a financial decision maker. So having deep thought, getting all of your thoughts in place, your requirements, getting that set up is going to get you to this point where you’re ready to implement. So, Anton, can you give us some common areas that people have used to decide whether this thing needs to be on its own instance? So, yeah, the usual suspects are, of course, geography, but also you may have flash sales in one of your brands. You don’t want them to impact your other brands, right? So that’s, it could be one of the reasons that you isolate that brand into a single instance. A practical example is one of the brands that I maintain is a sneaker store. And there is such a thing as a sneaker bots. They’re a specific type of bot traffic that tries to purchase all of your sneakers automatically and then sell them on another site for a much higher price. But that means that, I mean, this is a cat and mouse game that goes on continuously, right? So your cloud flare or maybe Fastly also has botnet detection. Your WAF may not be able to continuously keep up with that level or with the interest receipts that sneaker bots have. Yeah, and so that particular brand pulls a ton more traffic, but it doesn’t make more revenue. So in order to be able to handle that traffic and not have outages all the time, that brand is on a single instance. Got it, okay. Yeah, it could also be catalog complexity, right? Adobe Commerce has certain, well, they’re not hard limits, but their recommendations as in how many website times products times customer groups. Effective SKUs, right, yeah. Yeah, effective SKUs can you have until it gives you a performance. Yeah, and of course with customization, you can like that and you can increase those limits, but you can also, instead of adding custom code, you can also decide to just split a catalog in two and make sure you have two instances. Oh, right. And that way cutting the problem in half. So that’s a very easy no code solution that you can apply there, which doesn’t add any complexity that doesn’t cost you maintenance and that doesn’t, it’s bugs and that doesn’t make your upgrades more complex. Yeah, other reasons, of course GDPR is one of the main ones. Also admins should not always have access to all of the brands that you’re hosting. And Adobe commercial was an intricate set of ACL rules, but websites are not part of that. So your admins can always access every website on the store. So if you want to have a separate comment management team for one brand and another for the other brand when they shouldn’t mix, you can have different instances. Interesting, okay, that’s a brilliant, I forgot about the admin limitations like that. That’s an interesting reason, but it actually makes perfect sense, especially if they’re not conflicting brands, but you don’t always want those teams to accidentally make a change or see something that they shouldn’t. So yeah, that makes perfect sense. One more thing that is, it’s not so common, but it’s definitely a reason to take into consideration is that Adobe commerce, it knows translation, but it also knows the concept of store specific values. And for your catalog, for instance, your categories and products, they have store specific values that translate to languages effectively. So if you have a Spanish store and a French store, your Spanish store view will have Spanish store specific attribute values, like the color, and the French one has French ones, but the system doesn’t really know that those are languages. I mean, for the same, that’s by design because we don’t know if you’re gonna split up your store in languages or the same language, but just different wording, it could be either way. So to solve that, you also have that global configuration level where you can set something once and then it applies to all of the store views below it. You could even decide that you want to have separate instances to make sure that you don’t have to add the same translations to product attributes for every single store view that is in the shared language. But if you have 14 English language store views and you have 14 other language store views, of course you should always tackle that problem in the import at the source. But yeah, if you’re a company that does a lot of manual things in the admin and it doesn’t, you know, it overrides things that come in from the source, if that is your choice, if that’s by design, then having two instances for the different language distributions could save you a lot of admin and save you a lot of merchandising work so that you can do everything at a global level. Interesting. Kind of an edge case, but it has to be right. Right, right. Everybody has some experience and it’s always, as long as you have experience that proves that at least one person would have used it. All right, so let’s talk about some basic keys to success for GRA. So some of this might be more flexible. It might flex out of GRA, but we’ll try to keep it contained to the concept of GRA. So an example that I thought of is like, the governance team for this, that should be properly sized. And we talked about this on a previous call. We guessed it between like six and eight is about the right size of a team, regardless of your overall company size. That’s who should be on this governance team. What are some other things that you can think of that would be great takeaways for someone to successfully do a GRA project? Well, have the right number of developers in your team. Make sure that you’re able to have a team that’s large enough to work away your backlog of your minimum viable product, but also small enough to understand all of the parts that are being built as a foundation, because a foundation has to work together. And if your teams are not working together, if you have too many developers working at the same thing at the same time, then you’re gonna have issues. So, but I mean, that goes for a GRA as for us for non-GRA, right? That’s kind of a generic comment there. Yeah, make sure you have your documentation in order and make sure you agree on the methodology being used and on the tools that you use. And if you identify decisions that you need to make later on, if they don’t cost too much, you can delay them. So know that you can start with a single instance and move to a GRA later if you need to. And you can also change strategies, right? You can pick one type of GRA and migrate to another type of GRA later. That’s a really good thing to point out. We can help you with that. Yeah, that’s a great thing is you don’t have to have 50 instances on day one. You can start with one, even though that you’re not GRA at that point, you’re not classically defined as using GRA if it’s single, but if the goal is within a year or whatever, you’re going to have that second and third, as long as you’re heading down the path, you’re setting yourself up for success, which is the whole point of this topic. You mentioned something earlier. Yeah, if you see people working around, I’m sorry, yeah. I was going to say, if you see people working around your methodologies or working around the rules that make up your GRA, then take a break, right? And figure out why that’s happening. Because most of the times it’s because people don’t see a way to complete their job within the rules that you’ve set. And often it’s just part of education around GRA that they maybe skipped. But if you see something like that happening, don’t reprimand the developer and say, you’re doing it wrong, but understand why that’s happening. Because yeah, it’s probably happening more times than you were able to notice. You just happened to catch it. Yeah, exactly. So you mentioned something earlier, and I think it actually is more important when you consider a GRA approach is proper naming conventions and just having the strategy that everyone is aware of laid out ahead of time. And as a new developer joins the team, make sure that they’re aware. You can expand on that, but that naming convention, once again, if you don’t do it right, you can have collisions down the road or just awkwardly name things that, like you mentioned about a Spain module landing in the French store. If you don’t do it right, it can cause headaches, even though they’re not wrong, they’re just awkward. We want to avoid that. Yeah, in general, the advice is to always name things functionally. So if you’re, Spain has a second last name, for instance. If you are calling that the Spain customer module, Spain customer module, because it’s adding functionality for your customer that’s only happening in Spain, sure, that works. Or you could call it the second last name module. Right? So- And it could be used everywhere without any, yeah. Right, if you’re operating in Latin America, where they may also have a second last name in some countries, then you can install it there later on as well. And the second thing is, I mean, this is just for organization’s sake, and to make sure that all of the modules that are related end up in lists. Near one another. Yep. You make sure that you name things from generic to specific. So if you’re creating something that is related to the catalog, specifically to products, it’s adding an attribute that is around, or it’s combining attributes or in such a way that you create group products or something like that. You could call it the catalog product attribute grouping module, instead of attribute grouping catalog product. So that way that all of the customizations that have something to do with each other are nicely together. Yeah, and then add the module prefix before your modules, like Magento does in its modules, because that gives you the opportunity to apply automation to your packages in a way that’s different from evaluating your Composer JSON files. You can just apply a wildcard to some regular expressions and just take all of your modules or all of your language pegs and apply some logic to it. But other than that, don’t add anything in the name that’s also available elsewhere, right? Don’t apply the Smurf naming convention where every Smurf is called Smurf, because obviously we know that they’re all Smurfs. You could just leave it out and you’ll have as much value in the name as with Smurf. That’s a great global tip. So let’s talk a little bit about, and it’s an underutilized tool, at least in my opinion, is load testing, right? So my opinion, because I come from a more of a DevOps background, I’m a backend developer with a DevOps history, I believe in load testing early and often. And I do that for the reasoning. We know what a vanilla instance should be because there’s plenty of benchmarks that have been set. We can then test against those as every PR comes in, or maybe not at that level, but maybe more like an entire feature set, right? We can then bench test against our known benchmarks and see if there’s differences. Like how often and when do you bring in, not only like automated MFTF testing and static code analysis and stuff like, but when do you start to implement these bigger tools that look for performance issues? Yeah, so bring them in at the start because you want to have a benchmark indeed. So your catalog is going to be different from the catalog that Adobe tests with, right? So we do tests with tons of products for white papers, and it’s going to be a fixed set of products with so many variables, some examples. You may have a completely different product type created custom, or you might connect products to each other with something else than rule-based relations and that is some logic. And that’s going to add to your cost, your performance cost. So make sure, ideally I would create the load test before doing any custom development. So, yeah, even with also with the GRA, right? The ideal situation is to work backwards from where you want to end up. So start with a deployment, start with a deployment of a vanilla Magento store and make sure that all of your automated testing is working in that deployment because Adobe Commerce comes with automated testing. Make sure that that is running and passing. It should pass because at that point, everything should pass. But make sure you’re executing those tests and you’re seeing them pass. Then go one step back and make sure that you have a right deployment set up so that you can, you know, you have your automated deployment scripts for whenever a pull request comes in, make sure that that runs into an automated deployment if need be. And include in those tests that can be fired automatically, include some performance testing in there. So you should do a manual test first to see how fast your software is on the hardware that you’re intending to use on production because that hardware will be different from the hardware that we use in our tests at Adobe. And then add in some automated performance testing for KPIs that you find important, right? And if those KPIs are not met in a pull request, make sure that the pull request fails. And this is something that I don’t think anybody does or hardly anyone does it, but I think it should go down to have a pull request fail whenever you’re adding a performance increase of 50% or something, right? You can add some leeway in there because if you’re adding software, you’re always increasing the amount of code that needs to be executed. And so you’re increasing the amount of time that’s needed to do it. But if you’re going over 20% performance degradation, then the pull request should fail because that means that someone is doing something that they’re not supposed to do. They’re doing database operations in a loop or something unintended. So that’s at the very start, I would add a performance testing. Soon as possible. No, not that jives. Yeah. Not that jives. Yeah. Let’s talk about some of the key roles, some of the people who are involved and their responsibilities. And I’m just going to go ahead and give everybody the titles that we’re looking for. So there’s a project sponsor. There’s a change control board. There’s this concept of project management. This some places just referred to as a PMO or project management offices. And then there’s also a project manager. So if you don’t mind, let’s just start with the project sponsor. Like describe to me a little bit about this role, anything that you know about it, and then what people should look for. Because remember, you’re trying to field your team at this point, right? You’re trying to launch this. What would somebody look for in a project sponsor? Oh yeah, now you’ve caught me. This is an area where I don’t have that much expertise. No, that’s cool. I’ll give you a little bit. And Lindy would probably would have been better at this one, but unfortunately she couldn’t be with us today. So a project sponsor, they typically do the financial decisions. So they’re that one person that can sit at the table. And if there’s some sort of cost coming in, they’ve been given X amount of budget. And this budget is, it’s up to them to decide how it gets dispersed, right? The CEO said, look, you have a million dollars to do this project. If you want to hire 7,000 employees, go for it. You just have a million dollars to spend, but we don’t have any software to deliver at that point. So this project sponsor is supposed to take care of all the financial decisions. So they, and then they’re also responsible if something creeps up in this discovery phase and through time, this project sponsor would then also go ask for more funds. So they should always be granted a certain level of funding, but then they’re also that single person that would then go and ask. Cause remember our team is only supposed to be six to eight people. So this one person should make all your financial decisions or at least the bulk of them. Okay. The next person is, the next group would be a change control board. So do you know much about this team and what the people would be consisting of? I mean, there has to be people that are in close relationship with the, well, if you have multiple brands that are closely, closely connected to the people that, right? That basically describe your functional requirements. Yep. Usually a teammate, it would be like an architect, like, and it could be a global architect. They may not know Adobe commerce per se, because once again, Jerry isn’t Adobe commerce, right? It’s a concept. So you need a global architect. You hit it nail on the head, all of your regional brands up to about six people, six, maybe up to eight. If you really had that many brands, those key leaders should be there. And hopefully you can find, you know, three or four that can span a few of them to understand what their requirements are. Because once again, there’s this concept of too many cooks in the kitchen. This is where your team can balloon if you don’t think carefully about who’s going to be representing your team. Yeah, absolutely. Yep. Yep. And then an overall project manager. And this is a key role. You mentioned earlier, I don’t think it was in this phase of the interview, but stressing your developers unnecessarily. A good project manager will understand when the entire project is at risk versus just a, you know, a sprint. And preventing undue stress to your team, a good project manager at this key role is going to know when to step on the gas and when to let the, you know, just let things go through attrition. Yeah, which decisions need to be made, right? Because your developer’s not going to be able to know which decisions you need to make in order to create some leeway in your timeline. Or, you know, a good product manager should know that the options they have in order to meet a timeline that’s, you know, at risk. So scope production, adding resources, or just moving the deadline. Yep, yep, which is unfortunate. But once again, if you have early, constant communication, changes in your deadline should be expected, literally from day one. Everybody should pick a date, hope that that’s your hopeful date. But by the end of your first sprint, you should reevaluate. Are we still on target? Now, granted, it’s your end of your first sprint, you’re probably still, hopefully still aiming for that date. But if every sprint you take a deep breath and you look up and you verify where you’re trending, you can know basically week to week if your date needs to come forward or get pushed out. So a good project manager will help everyone be aware of the overall project in that capacity. Another division of this key personnel is the PMO, the project management office. Now these guys are gonna be the day-to-day project management. So in any of your projects, did you ever have that type of engagement, or do you normally just defer that to a change management board? No, I think indeed in the projects that have been part of in the past few years have been the change management part. Yeah, it’s a good pattern to follow. And then the last big role is gonna be, like you said, just the project manager. Cause you’re gonna have a platform manager and then you’re gonna have that program or that project manager. And we touched a little bit about them earlier. They can be independent or they can be a part of that change control board. Once again, we’re not describing, or phrase that, we’re not prescribing how to set up your team. These are just ideas to make sure that you have thought for personnel that you have, because the worst thing to do is to come into this and just forget that you need your project sponsor with those financial decisions. And then you just have to keep reaching out to them. Sometimes they’re two to three days in delay. And so if they can’t make those decisions on the spot, your project is gonna suffer. Yeah, and I think the most important role that’s most often overlooked is the product owner. I mean, it has part a group of product owners that really make the decisions on what goes on to the backlog and what doesn’t, or what gets built and what doesn’t. Because this is something that often, you have those many chefs in the kitchen, you have all of the stakeholders, but no one can make decisions for anyone else. And on the other hand, you have your scrum team that just does what they’re told basically, because they got the backlog and they work on it. And if you have no one that is actively looking at whether it’s realistic to build that backlog and whether it’s really adding value, that’s the biggest risk for completing on time and completing something valuable. But it’s at the same time a scenario I see very often. Right, right. Yeah, and actually that person would typically fall under that PMO, that project management office, because they’re supposed to do the day-to-day management. And once again, that same team should be that final decision-maker, decision-makers of this is a global requirement. This is definitely not a global requirement. They should be able to make those fundamental decisions because what ends up happening, as you just described it, you have infighting because of feature may be applicable to one, and for whatever reason, they don’t want it to be shared, or maybe they want it to be shared, but none of the other brands thinking it’s worthy, right? So that PMO should be- Or that didn’t come up worth it. Yeah, right. Well, we’re gonna just discuss on what features to work on. So this global control board or this change management board, or whatever you wanna call it, they should understand the business value versus technical complexity, right? So walk me through what makes something valuable in both cases, which means it should be done right away versus something that can be deferred for future backlog work. Right. So if something adds value to only a specific region, but it’s legally mandatory, then do it right away. Anything that’s legally mandatory, do it right away. Anything that connects systems to other systems, right? That has to be done. Or that is something, if you don’t do it, you’re not able to store a certain type of data that needs to be done. So those are your technical minimums, right? So if something is a technical minimum you actually needed to perform your operations, then that’s a no brainer. But then everything else should come down to either adding revenue or adding a business value. And it’s not always a monetary decision, right? It can also be aligned with your core values. You have to give this service to your customer because that is who you are as a company. That can be, it can even cost you money, but that can be a completely valid reason to have that as a must have. But then when it comes to technical complexity, the trade off, right? The trade off would be whether it’s, well, whether it’s feasible to deliver on time basically. Right, right. That’s where it comes down to. It’s gonna back your timeline. Yeah, yeah. Yeah, if you have a super complex piece of software that’s also mandatory and you’re not gonna be able to deliver anything else before delivering that, that’s a big risk, but then pull it forward in your timeline. Make sure that that part is behind you when the deadline approaches so that you have more flexibility in the other things that you deliver. I think about if you can cut that up. If something is really, really complex, think about if you can cut it up into multiple languages because sometimes it’s possible to first deliver the skeleton or something, and then have your stakeholders interact with it to make sure that that skeleton is at least the right skeleton, right? And that it doesn’t have to be proponents in the wrong places because then all of the other development will be wrong as well, even if it’s done right. Yeah, that makes sense. And then maybe considering the rule of thumb of trying to get three sprints of work clearly defined and keeping that pattern. So that way you can tell all of your stakeholders what you’ve done and what you’re gonna be doing for the next month to month and a half, right? That’s important. Once again, it’s all about communication and keeping high priority items high in the queue and always being worked on. And then once again, once you have that high complexity thing out of the way, you can then, unfortunately, you may have to draw it out over three or four sprints, but if you do, then you know that when you’re done, it should be basically done. And that big project is behind you before the deadline. Yeah. So let’s- I mean, get that backlog estimated, right? Because that’s- That’s a big project, yeah. It’s a, yeah. It can be very difficult to estimate things, but if your developers don’t agree, don’t settle on that estimation, but make sure that everyone understands if two people differ in their estimation, probably one of them is not getting it right. And it might need to be the upper limit instead of an average. Yep. Another topic is making sure that all of your global requirements, so thinking about all those global features, those should be decided upfront and decide on anything else that’s needed for your initial launch. We don’t have to dive into that too much because it’s pretty self-explanatory, but I think that’s a pretty big feature that most people should, they want to bring in more features for that MVP. And the important thing is to make sure that the MVP is literally the minimal viable product. And if that means it’s 60% of your features, great. If that means it’s 80% of their features, well, we can do it, but great. It’s better to have that a little bit as shrunk down as possible with still delivering some value to your customers. Yeah, and more often it’s 100% of your features, but 60% on each. Yeah, and that’s not good for anybody. Well, no, it is because you may want to have all of the areas developed that touch the customer, you know, that are being used by your customer, but you may want to do some concessions on your backend or on your process, or you can always upload a product file manually in Adobe Commerce as a workload before creating a product import. Even that is completely viable as a MVP, right? That’s true, that’s true, that’s true. That’s a good point. The next area is gonna be deciding on your initial project. Like we talked about this earlier, picking that complex enough website, brand, whatever it is, that isn’t your hardest, most complex brand, but it’s also not your easiest. Finding that happy middle ground. So hopefully you have more than three brands. Finding one that kind of fits right in the middle. That should be what your core functionality is based off of. Because, you know, we talked about this earlier, if you pick your hardest one, when you’re done, great, you’re gonna have more of your core features built. The problem is your time to launch is gonna be much longer than if you picked your medium to your easiest. So once again, the advice from us from here at ACS and Adobe is to pick one of your brands that kind of fits most of your features and use that as your foundation. Because once again, too much time dedicated to your hard project means your launch may be a jeopardy, especially if you’re timeline based. If you’re not, if you can be flexible, then you can pick any brand that you want. But finding one that fits most of use cases is probably the best advice that we can give you. Yeah, and if you feel like that’s going to take you too long, then think about that you’re actually developing on all of your source at once and not just the first one. So that’s what you’re doing, right? So it could take a little longer than just building that smallest store, but you’re building all of them at the same time. Yep, and piggybacking off that, there’s a recommendation that Lindy Kao gave at the Imagine 2023 was a 70-30 rule, right? So what she meant by that is 70% of your global requirements should be on your MVP, which would be things, big items, catalog integrations, order processing, checkout flow, account management, leaving that last 30% for your localization, your payment methods, your languages, your storefront, any modifications that you may need in there. That’s a great recommendation for us because once again, that sets you up for reasonable expectations for your stakeholders and your business, your business stakeholders, what to expect, because that’s the goal is to give, if you can give them a 70-30 rule, you can then, should be easy enough for you to deliver technologically on that. And then there was one other topic that you brought up when we started this conversation, and it was about if an SI had the capacity to do a global reference architecture for themselves, it was an interesting topic. So for our last couple of minutes, would you mind just opening up that topic and just explaining what you meant by that? Yeah, of course. So you might be a store owner and then decide to implement a GRA, but if you look at a GRA from another angle, a GRA is basically being your own software marketplace, your own Magento package marketplace, but also your own client of that marketplace. SIs could be either their own client or not, but essentially they would also do good to host a marketplace of modules and then install those in the installations of the stores that they maintain for clients. And in that way, I mean, you could have a global reference store of your own that you can use to demo the customizations that you have on offer, but then install them across your customer base. And then each customer on itself will not have a GRA, but their software will be installed in the GRA. Reflected in that manner. But from the perspective of the SI, it would be a GRA because they have a store with deviations per brand. They’re just not owned by the same owner. Even for SIs, I think thinking in terms of a GRA, even if you run multiple stores that are not related in any way, they will all have a product import. They will all have a stock import and a price import. Store locator, like whatever. Yeah, exactly. Exactly. Maybe 80% of that under the hood is the same. And only the visual expression has many differences. So you could build stubs of your modules as a GRA and then build preferences or implementations or socket, right, and plugs specifically for the clients that you said. No, that’s great, dude. I love that. When you brought that up, I’m like, what a great angle for a topic like global reference architecture. But that’s the whole point, right? It’s not an Adobe commerce, ACS, professional services thing. It’s just a concept. It’s a methodology. We have completely ran through my questions. This has been phenomenal. I really appreciate your time. We’re gonna wrap this up for today and thank you, Anton, for your time. And we will have another series on this, hopefully in the future. Take care. Thank you. Take care.