Leveraging Global Reference Architecture

Transcript

Hey, this is Russell with Adobe, and today I am going to be visiting with Anton and Lindy, both Adobe Architects. And today’s topic, we’re going to be covering how would a company leverage JEREMY? Anton, why don’t you introduce yourself real quick? 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. Hi, I’m Lindy from the Commerce Professional Service Teams. So the other day I was approached by one of our solution specialists and they asked me an interesting question. They were posed by their customer the question of how would a company leverage GRA? And it’s similar but different to the technical implementations because once again, these people are usually more interested in the business decisions on why they would leverage GRA, not necessarily the technological reasons. So Lindy, if you can think of an idea or two on how a company would leverage GRA, like what would some of those be? Sure. So GIA is, as we all know, is related to the one you have multiple brands, multiple instances, deployments, right? When you have one store, one website basically, and then the GIA will not be applicable for those at all. But if you are kind of having a multiple brands, as Adobe Commerce knows that, in Adobe Commerce you can also have multiple websites as well. But if you have multiple websites on the one Adobe Commerce instance, the GIA is not applicable to those as well. So GIA is only applicable when you are thinking about the multiple instances and then you will leverage GIA for that one. To have multiple instances or not, there are so many factors included as well. So if you have one site where most traffic is impacting the other sites, then you would like to have that site where you want its own instance because of the traffic, because of the resources and stuff like that. So then GIA can be leveraged for this type of live flow. So you would look at the traffic patterns for your different websites and if one is just always busy, that would be a good indication that GIA could be implemented. You’d move it to its own instance and then your other brands could stay on the original one and just let them share the traffic. And the same process, if one of those matures, that’s great, they could branch off to their own. Okay, that’s great. That’s a really interesting concept. So Anton, how would you do team organization to make sure that a company leverages GRA correctly? Let me think. So the team organization, so if your GRA is, for instance, a GRA that operates in multiple regions, which is a very often seen use case, you’ll have to make sure that your team is able to do maintenance in multiple time zones. So one of the organizational aspects is making sure that you can actually do maintenance in multiple time zones. And if you want to, for instance, stagger releases one after the other, you cannot have the same team do a six hour release and then right after it start the next one. So you’ll need to make sure that your team works in shifts in that case, or that you have teams in multiple regions as well. So that’s a consideration. You’ll have to make sure that you have proper governance set up in your team to handle the GRA because the GRA is not just a technical thing, right? It’s a methodology. So you’ll have to have champions that know exactly why you’ve made the choices that you have made on the GRA and make sure that all of the choices that you make subsequently follow that initial reasoning. So those are your technical architects, but also your product owners, because every time you build something new, you need to decide whether that’s going to be global or regional or just for one brand. And so that decision needs to be made every time, even though at the technical level, you’ll have to build it every time as if it would be a global thing because you want to have the flexibility to elevate something that was regional to a global functionality. So Lindy, I remember you made a comment at Summit this past year about having too many cooks in the kitchen. So we’ll save people a little bit of time. So can you just refresh everybody why you made that comment at that Summit speech? So referring to what Antoine mentioned, during the Summit, I call that a change control board, right? So for a change control board, you need to have basically platform architects, project managers, and some of the four or five regional representatives, right? If you have 50 brands, if you’re trying to be put on a change control board and you’re going to have one of our one features coming, it’s very hard to decide, right? This is going to be the foundation, this is going to be brand unique. So you want to have five or six who understands the platforms, who understands the brands, you only want them on the change control board. So easier to have the process around whenever the features come in, this change control board can decide, okay, this is going to be unique to your brands. You go to implement on your brand sites and then or otherwise, they can, okay, this can be utilized by some other few brands. So let’s put in a foundations and then we can also make it as a allow to enable or disable utilizing all these features, right, by other brands. Yeah, that’s exactly what I was getting at because like you said, if you have a big enough company and you have many, many brands having so many people at the table where it is nice to hear their opinion, you do need people one level above that, that can span multiple brands to understand what their goals and needs are. And that way, like you said, when you’re at that final decision, like, is this global? Should this be regional? Should this just be an isolated instance? Those people should help make the decisions because unfortunately with many, many people at the table, too many voices are heard and then you end up with this stall or a stagnant All right. So you also back in Summit, you made an interesting statement that GRA should be expected to follow the discovery phase and then the crawl, walk, run, fly phases. Can you just break down like the discovery phase and then when you’re done, maybe we’ll transition over to the crawl? Because I think most people would understand the crawl, walk, run, fly phases. But like in my opinion, the discovery phase is usually minimized because they think because this is a GRA and everybody is agile, but you don’t really need to do that. So can you just describe what the discovery phase is, how the ACS team implements it and what they should be considering when starting this project? During the discovery phase, we were trying to understand the requirements for the clients, where they are right now, if they already have the brands or if they already have websites. If they don’t have one, we try to get the requirements, which integration you want to integrate with, which ERP you want to have it, which payment gateway. And then these type of requirements we will try to get out and we will try to also educate to the clients, right? Hey, these can be leveraged for Adobe Commerce functionality or like, can you change the business process to leverage Adobe Commerce functionality? This is how we are trying to educate to the clients as well as during discoveries for them to adapt the Adobe Commerce features and familiar with Adobe Commerce features. And then at the end of the discovery, we will have the requirements as a features matrix, which features it’s going to use, going to use the brands and which features need to be customized as well. And we have a background for that one. So going back to what you mentioned about the right crawl, walk, run, flight approach for it. Basically, the crawl will be, after having a discovery, implementing the foundations, which are the foundations that needs to be implemented. For example, the ERP integrations, every brand needs to have a best use of SAP. They need to use SAP integrations for it. So we will implement that as a foundation to have the order come into the Adobe Commerce exposed to SAP and the data coming from the SAP orders, those need to be implemented in the foundations for that one. We call that as a crawl phase for it. The walk phase will be like having a specific brand to leverage whatever the foundations we have built and then the brand release with the foundations code for it. And then during the first brand release, you can have some knowledge about what issues with the foundations, which features need to be tightened up and stuff like that. That’s how you go to the flow. Got it. That makes sense. So Anton, when you’re going back to the discovery phase and the requirements gathering, is there anything that you can think of that you would like to share? Because I’ve been an architect for about almost a decade now, and I’ve matured as an architect in especially how I did my discovery phases over time. Because the first one I did, I’m almost embarrassed on how bad I did. But everybody thought I did a good job. But when I was done, I’m like, man, I did not do that right. And so every time I did it, I got better and better. Is there something that you’ve gained through your experience of doing all these discoveries that you’ve learned that maybe some of the key elements that would help once again, prepping this company and this project for a GRA? So yeah, definitely. One of the key aspects to look for is whether you’re making tactical or strategical changes or adding tactical or strategical roadmap items to your backlog. And tactical changes are just point to point solutions where you have just an issue that needs to be resolved, but you don’t look at the greater picture. Whereas if you’re strategically making changes, you’re looking at the wider architecture and trying to find whether this is part of a system that might need to be changed. And so like Lindy said, you might want to look at changing the business process instead of the product. So that’s definitely something to keep reminding yourself, right? Is this tactical or strategical? In the same way, you can think about is this a change that is an extension of Adobe Commerce or is it a customization? Yes. And if you’re doing customizations, you might be altering the core logic of the system and that makes it very, very hard to upgrade later on. So if you’re changing the way annexation is working or you’re changing the way that cash in validation works, you’re going to be in a hard situation a couple of years in. So this is something you’ll need to continuously ask yourself and look at the backlog and say, what am I actually doing? Am I enriching the product or am I just creating a very difficult future for myself? Exactly. Yeah. And your team needs to be on the same page, right? So you need to cultivate that way of thinking across the board. I think the easiest way to do that is to connect it to revenue generation and value of your changes. Especially with large clients that have multiple brands, you have multiple stakeholders and your backlog can get enormous. If you then increase your team size to work away that backlog, you’re going to have so many changes coming in that they’re going to bite each other and you’re going to have a very unstable start because the teammate doesn’t know what team B is doing. It’s just merging together and creating a mess. So if you can focus on the value that a change adds and be very, very strict to only allow changes that noticeably add value, think about it in the 80-20 rule, right? This adds 80% of the value, whereas another change only adds 20%. Just all of the marginal changes, push them to the bottom of your backlog, push them off. You only want to focus on those things that really make a big difference. And those usually are extensions and customizations. So Antoine, can you expand a little bit what you feel? Because Lindy did a pretty good job, but I’m just curious your opinion, like how would you describe the crawl phase and then how does that migrate to the walk, run and then fly phases? What do you consider like the crawl phase? So the crawl phase is, it’s the hardest phase, right? It’s the phase where you need to get consensus among all of the stakeholders where you’re trying to build a backlog that you can make revenue with, but that you can also finish in an acceptable amount of time. That combination is often very hard to find. So the crawl phase is really the definition of what is your minimum viable product. Then going into walk, you’re actually building, right? You’re building stuff, you’re delivering your first store. And depending on which store you choose to be your first store, that depends how hard you will be running later on or if you will be flying at all. So if you pick your most extensive implementation, which covers 80% of all your code that can be reused, you’ll be crawling very slowly at the start because you have a ton of things to define and a ton of specifications to write. And before you have a functional store that can make revenue and it has all the functionality you need and all the payment methods and all the integrations, you’ll be a couple of months in. But it may be worth the effort because once you have that 80%, setting up the subsequent store that only needs three things, that’s going to be a difficult one. Should be easy. Yeah. So compare that to picking their easiest brand. So you just described the biggest dilemma with picking your biggest brand or your most complex is just time to launch is now delayed. So what would be the downfall to picking their easiest brand? So there are two big downfalls. One is that, I mean, you will be, let’s first talk about the reason why you could do it, right? Because if you launch your smallest brand earlier, then you get something in production early and you get production feedback and there is no test like production. So you’ll see all of the flaws you’ve built and you’ll be able to stabilize them before you move on to the next time really early in the process. But at the same time, you’re increasing the time you need to build the next store. So the expectation could be that, well, we’ve done our crawl phase, we’ve made our investment and now you need to tell your stakeholders that there is yet another investment that is going to take a bit less time, but it’s still not the big run phase or fly phase that they were promised. So it’s almost like a crawl crawl walk run, right? If they go that route because they have to basically crawl two, maybe three times before they’re walking. Yeah. Yeah. So that’s down to expectation management then, right? Okay. But the other downside is that your team that implemented that first store, depending on how you do your team management, right? Because that’s what we talked about earlier. So this might be something you want to keep in mind as well. The team that implemented the first store might not also be busy maintaining a production store and so they don’t have the full focus to continue working on store number two. So you might want to develop that by making sure you have two separate teams, right? A support team that supports your production store. Team continuity. Yep. Yep. Right. Yeah. Another one that implements new stores or that continuously spins up and launches new stores and delivers them to your support team. Okay. Yeah. Okay. So upon that one, the one you choose the small brands is like the GIA is less complete, right? You don’t have a lot of the foundation core base, but as long as the leaderships can align to that, right? We just want to have an MVP and then let’s try with the small brands and then the leaderships need to be aligned like this GIA, whatever foundation core is not complete, we’re going to need to express this foundation in the next phase. Then this approach can be worked with the small brands as well. So I guess it’s not up to us to decide as we’re basically giving them all the reasons. So it almost feels like the best answer is to find that medium sized store that has enough complexity, but yet is simple enough to where either phase isn’t impacted, which is great. I think that’s great. Kind of on that same vein, API Mesh and App Builder was recently released to the world to use and explore. In my opinion, that type of leveraging of an external service is going to make a huge impact and you still have the same phases. You still have the discovery, crawl, walk around and fly, but it almost like it condenses that crawl phase from being 60% of your whole project. Because you’re offloading some of these services to API Mesh for that type of technology or just App Builder in general, it seems like that’s going to help. So Lindy, I know you’ve had six, seven months of playing around with it and different projects. Can you explain how you would leverage something like App Builder to help condense some of these phases? Yeah, especially the one is integrations for the product data or one is exporting of the orders data. That’s what we are utilizing the App Builder for. So when the catalog feed came in, the traditional is like you push the data to the call marks and the call marks pass the data and it ingests in the ways that call marks can utilize it. So by having App Builder in the middle, App Builder can do in a way that is leveraging the call marks API for it by pushing the orders data or product status to the call marks. And the same way for the one order exposure. Therefore, we need to have a tradition that you need to have customizations on the call marks and you expose the like you cannot have any connections to the like whatever the downstairs system you have and expose the orders data for it by having App Builder. You just say, hey, in advance, hey, I have orders. This is all the information. You can have App Builders doing those type of stuff. So Anton, when you’re going to be pitching this in the future, does App Builder and API Mesh, does it have any impact on GRA at all? Doesn’t feel like it, but what’s your opinion? Yeah, I do think it has an impact on GRA because now you’re all of a sudden dealing with two types of application customizations, one in PHP and one in App Builder. And depending on how many customizations you’re going to add as App Builder applications, you’ll also need potentially also need to define a GRA for that part of your code. That might be on the same GRA strategy. In fact, I would advise that because that simplifies your methodology. But it does impact GRA because right, you’re adding yet another level of complexity. You have two code pools or three if you add your front end to that. True, true. Okay, that’s good. So Anton, when you are going to be adding a QA resource to a project, right? So you’re going to be asked at some point by the company that you’re working with, how quickly should we bring in our first QA resource? What’s your advice for them? And then how much power do you recommend that they have for code promotion? So I’ll just level set why I bring this up. I personally think QA should be as soon as there’s something QA-able, they should be in on the project. So don’t wait for your first production deployment, bring them in early, early on. And then in my opinion, the QA team should almost have the go, no-go authority for whether this feature is promotable. And I do that on purpose because I want an objective third party opinion on whether everything we did met the requirements and is it still performing? All the things that they do, I want someone to prove that I did it right. I want them to give me their honest opinion. I feel that’s validation that I did everything correctly or my team did everything correctly. It’s like, when do you think QA should be brought in and what level of power do you like to see them have? Well, it also comes down to the level of maturity of the QA team. So if you have a very mature QA team, I would involve them earlier than when you have a QA team that basically acts on the scripts that you write and executes them manually, maybe even. But if you have a very mature team, I would like to involve the QA maybe even earlier than that first development phase because then they also understand the reasoning behind why certain functionality is added. And if someone understands why something is added, they know much better what to test for because they’re not going to test what you tell them to test. They’re going to use their own imagination and pretend to be real customers and that’s much better. Also, they need lead time to set up a QA automation platform because actually that’s what you want and you need to give them… I mean, if they know the reasoning behind why functionality was asked for and they know the functional requirements, they can already start building a testing platform and setting it up for testing the scenarios that you just described without a single letter of code being there. So I would say they have to develop side by side with the developers. They have to develop their tests for them. Okay. When you want to do QA, I’ll let you kind of answer a little bit what you want to do, but also throw in there how much automation of QA versus hands-on QA. Throw that in there too, if you don’t mind. So when you’re talking about QA, there are the different stages of the QA process. While we are doing the HA development for you, so when the spring development starts, we have a QA for that one. QA for the springs and then two testings, whatever during the spring development has that. And we also have the milestone. Whenever milestone reach, you’re going to have a state that test for that one. And then so to make sure all the integrations work, whatever you have ordered or have implemented should have done as well. And then the other phases is that kind of UAT. This is the way you need to test productions with the productions data, with the productions integrations to make sure these are tested properly. These are tested for it. But for automated testing, automated testing is always great when you have a continuous development for it. So you don’t need to have a manual work to go to some of the flow for it. Then for that one is also another investment. But it’s also having one, the company is thinking about the longer road map for it. It’s always great to invest in this type of the automated testing around that one. It’s going to be helped to the whenever the releasing is going to have the more testing cases going to cover and it’s going to be reduced the actual QA resources as well. By having that automated test, whenever the milestone reach deployment, you just need to click and you know that already some of the test is already covered for it. You don’t need to have two or three QA to test it. Exactly. I’m working properly or not. So Anton, I take it you said it earlier. So you do promote and probably require some sort of automated testing. But at what point do you do the manual testing? Is it just on the key workflows and do you just do those sporadically or is it kind of a mix of both? Well there’s a difference between real world and ideal situation of course. I mean in the real world there’s much more manual testing than I would like to see and much too few automated testing. But ideally I would I mean you have to think about who’s creating these tests right. If you have automated tests, functional tests, those are written by your developers. They’re the same people that are writing your code. So they’re testing their own code. Is that up to some extent? I mean you can use it to make sure that your application doesn’t crash. You can make sure you know so that it’s stable enough to go into production without breaking it. But that doesn’t mean that it meets the expectations that you set with the functional requirements. That’s where manual testing comes in because yeah the automated testing would help a QA engineer to get up until a certain starting point for instance. From which point they will have to evaluate whether the things they do afterwards are still meeting the functional requirements and that takes a human to interpret. Got it. Got it.