 We're going to do technical architecture with Drupal and other systems today. So that nice brief title means basically what we're going to do is we're going to go over a little bit of how I and sort of how us at Acro as well go over top-level technical architecture planning when we're integrating Drupal with a much larger setup, usually for sort of an enterprise client or something like that, although it can vary. You know, some got some clients that you know are a three-person team and they have very complex technical setups. This is going to be a bit of a hypothetical example. I didn't take a specific client, although it's kind of based off of a few that we have. It's also going to be a little bit e-commerce focused. We tend to do a lot of e-commerce. That's mostly what we do is we do Drupal and we do e-commerce. So that's what the idea is or the demo is a little slanted for. But the same principles should work for anything else that doesn't have e-commerce. And I'll try not to have it too e-commerce focused. Okay, who am I? And that arrow actually appears to have worked out correctly. I'm Sean McCabe. I'm the CTO at AcroMedia. I've been doing Drupal for 13 or something years. It's probably about what my d.o profile says. I've been working at Acro for 14 or almost 14 years now, doing technical architecture for a lot of that, although I did start as a junior developer. So it took a bit to work my way up before I was doing architecture. But hopefully I have lots of experience at this and should do a good job. I did actually have one more slide I was going to put in here, which I was in the process of editing when I thought this was happening at 11 Pacific and not 9 Pacific. In my defense, I have a three month old baby. So I'll use that as an excuse for why I couldn't understand time zones. Although I know Ryan Sarama did his talk on time and he is like a three week old baby. So maybe it's not a perfect excuse. But what we're going to do here is I have a hypothetical site example that a client has an existing site. They're looking to move away from maybe a couple of platforms and we're going to be sort of adding Drupal into their system to give them CMS functionality and also maybe replace some of their other systems. So I'm going to sort of do a quick walkthrough of what we do for that process. We have templates instead that we use. I've sort of simplified them a little for the slides so that things will move along. And this is going to be maybe go a little fast, but I hope to get sort of all the detail in here. So first of all, what we usually like to do is we start off with an audit of what systems or pieces of functionality that a client probably does already have. This is actually a slightly truncated list of the one we use normally. I just had to truncate it to fit it all on one slide here. And as you see, it's a little e-commerce focused and sometimes we'll tune this for different clients here. But we sort of try to say, hey, here's all the kind of pieces of functionality that you will have. And what do you use currently to maintain this? And we provide this list because we find if we just ask clients about their systems and what they have, they'll list like three of the eight systems they actually have because they won't remember certain parts that are done or that'll come from a different department and whoever we're talking about won't have this perfect knowledge of sort of the whole system. So we'll sort of go through and we'll maybe ask the client and get some initial stuff. And we'll get a list sort of something like this. They'll say, OK, products or product data comes from NetSuite. We're using Magento for catalog cart checkout. Our customers are sort of, or in this case, I put users to be a little more generic, but they're stored in Salesforce. We sort of do ERP functionality with NetSuite. If you don't work in commerce, much ERP is just like an awful buzzword that could mean almost anything. Usually means does order stuff, but it could be accounting. It could be whatever. And they say then they do order management through Magento. And then they've forgotten sort of what they do over anything else. And then once we give them this list, we'll sort of prod them a little bit. And it'll usually turn out that there's actually a few more things that they forgot for search. In fact, they do use Elasticsearch and they have that running. They'll talk to someone in IT and we'll figure that out. And then we'll get analytics. Oh, no one ever remembers to mention analytics. And we say, what do you use? Oh, it's usually Google Analytics or something, but we'll get that in there because it is important to make sure that still gets hooked up. And do they have any marketing staff? Sure, MailChimp, we'll put that in there. It's maybe a pretty simple setup. And then what we'll usually do next, and this can be done sort of formally or a little bit informally, and some of this might come from, say, an RFP or something. But we'll ask them sort of what's their, how much do they like or dislike the various pieces of software that they're using? What are they sort of, you know, what do they like? What are they tied to that kind of stuff? And so we'll sort of go through and we will get things like, you know, we hate, hate, you know, using NetSuite for managing products or something here. I made these arbitrarily, although NetSuite is a little user unfriendly. So hopefully this is not a rep from NetSuite in the audience or anything here. You know, and then we'll sort of go through of how they feel of various, you know, parts of the system. And there'll be lots of ones where they have sort of no strong feelings. Say whoever we're talking to doesn't work directly with them or they just don't care either way. But we're looking for sort of the ones they really love and they don't want to remove or parts that they really dislike. And it's like, OK, well, those are prime candidates to switch up then. And then we'll usually do a third. Option, which is, you know, how much do they have to keep these? Or, you know, what's the sort of internal resistance or desire to switch these? Because oftentimes we'll have something that we would love to replace. But there's just absolutely no business. Interest in moving those. So, you know, it might just be they've just transitioned to it or there's a whole other department that uses it and they don't want to get rid of it, you know, or just, you know, the transition to it is going to be so difficult that they can't do it as part of this project. And so we'll kind of go through theirs. And so we'll go, OK, we have identified that Magento, they actually need to replace it. Say, in this case, they're using, you know, a Magento one, it's end of life now. And they want to be moving to something else, but it's not necessarily. You know, Magento two, maybe it's something else. You know, and then things like, OK, NetSuite, we say we basically have to keep that. You know, we need to add a CMS. That's probably why they're talking to us to begin with. We're going to, you know, bring that one in. And then we say, OK, they have no desire for an LMSA. So we're going to, we're not going to worry about that at all at all. You know, they don't care about OAuth. This is actually sort of a bigger, even grosser spreadsheet that I use normally. But, you know, I've simplified it in here to fit in this slide. So this is kind of what we end up with. They're sort of opinions on some of these stuff. And then we'll usually try to get a technical map from them of some sort, you know, some sort of architecture map or something. These will basically 100 percent of the time be of low quality. Usually they are either done hurdly to pass them off to us or they were done five years ago. They're semi-inaccurate and someone's maybe quickly gone and deleted, you know, all the nice or all the parts that don't fit anymore. And so we'll get some sort of crude flow like this. But it usually contains some sort of useful piece of information. If you'll see, there's this MySQL section in here. And this is pretty much stolen from an actual client thing. So I'm not just making this up. And you'll go, OK, why why no one mentioned, you know, MySQL is one of this directly as one of the systems being used. And it'll turn out there's something like, you know, the products are pushed from NetSuite into a MySQL database and then Magento and Elasticsearch are both connecting into MySQL. And so we'll have this kind of hidden sort of dependency in here that we actually have to care about. And then we'll also learn what stuff sort of is and isn't connected. Like we have Salesforce and Mailchimp, they're not connected to anything at all here. And so we'll sort of get this kind of so so technical mapping here and we'll say, OK, you know, usually the first step we'll do is we'll actually clean up sort of their existing one and try to get a good feel of what is actually happening, sort of how data is flowing, if we have anything missing. So for example, in here, we'll notice that we have Magento and Elasticsearch, but we there's no way that they connect or that how does a user access this, right? Are they are they just sending, you know, API queries directly to Elasticsearch to get information that, you know, that's obviously not happening. So we're clearly missing something in here. So usually we will go through and clean it up a little bit. Also apologies in advance for the colors. I made them extra garish so they could be seen hopefully really easily on slides for people. I didn't let our creative director go in and clean them up to be something more palatable. But so we'll actually figure out that maybe they have some sort of, you know, simple HTML JavaScript front end that someone that sort of static that someone's put in front of Elasticsearch that is meant to sort of look like it's part of Magento, you know, an engine X is pushing off to these. And so we'll figure out these different little quirks, hopefully as we sort of go along anytime we identify an area that looks like, you know, it's missing or there's something that won't work right or something like that. We don't normally include stuff like engine X on these maps because it's usually pretty straightforward. But in this case, it sort of matters for how this flow is done. So we will include that. Same times as we will sometimes, you know, put databases directly or something if they have a direct connection like this. And we've given this some little color coding to show sort of what business units interact with which parts. For us, that's actually pretty important because it usually means who we're going to have to talk to with the client to get approval to do various things or to get you know, feedback on whether an integration is going to work correctly. That kind of thing. And the clients will not always be super good at doing that on their end. Ideally, they coordinate everything on the sort of their side of things. And we just interface with, you know, one primary product owner or something. But that's rarely the case. So we sort of had to be like, hey, you know, this is sales. Did you talk to anyone in sales? Can we talk to someone in sales directly? You know, ahead of sales, a VP of sales, something like that. You know, same with sort of marketing and other things. So we sort of split this up and we realized that there's actually a whole bunch of stuff here that's maintained by IT. And there's also in this net suite part, it's run by sort of some of the business divisions and also by customer service. So there's kind of overlap for how it's handled here. So that's something we're kind of going to have to be extra careful about is, okay, you know, there's two whole groups that we have to worry about this piece of software, and that's actually pretty common. I sort of simplified this a little bit, you know, you might have two, three different people all sort of interacting with one set up. So now that we've sort of cleaned up this map a little bit, what we're going to do is we're going to kind of go back to this list and we're kind of going to make up a new version. So we're going to say, okay, what can, what are we removing? And sort of what are we changing around here? So obviously we're getting rid of Magento. We already knew that in this case, maybe we've identified we're going to replace it with Drupal commerce. We're, you know, fairly slanted bias towards Drupal. So, you know, we might recommend something like Drupal commerce here. You know, we, in different instances, we might recommend a SaaS platform or something like that as well. And then we've also will maybe do a bit of a change. Like you see here, I've actually put Drupal in for the products next to NetSuite, even though NetSuite was listed as, you know, cannot get rid of kind of thing. But once we looked at the architecture, we actually saw that we weren't really using NetSuite, we were sort of using it for the products, but we were actually using this sort of intermediate MySQL database. So, you know, this might be a thing where we go back and forth with the client, we talk about, you know, what they need for products. Maybe this is a case where they, you know, with adding CMS functionality, they really want sort of really rich products. So they want, you know, lots of media, you know, lots of, you know, fancy custom layouts, that kind of thing for them, you know, maybe paragraphs will be a good choice or something like that for them to build, you know, really rich pages. We sort of use the example. Sometimes, you know, do you want like a product page like Amazon has, you know, do you want a product page, you know, like an iPhone product page looks like or something like that, you know, where it doesn't even look like, you know, it's a big long page, you know, with text and lots of hero images and banners and, you know, things like that as you go through and it's really in depth to sell sort of a single product, you know, versus something that's generic to every kind of product. And so maybe we're adding that type of flexibility, in which case Drupal will be really good and just using something that's a straight sort of product management tool, you know, a NetSuite or even a Gentoo or something like that isn't going to be able to handle that. So we say, hey, you know, let's switch in Drupal there. We're going to keep Elasticsearch. We have, you know, no complaints. They seem to like it. We have nothing against it. It'll work easily with Drupal Search API. And then we say for the OMS part, that was sort of being handled by NetSuite anyways, you know, for order management. Apologies for all the acronyms. And we're going to actually just go to using NetSuite for that. So we're going to keep, we're definitely keeping NetSuite, but we're just sort of changing what it does a little bit. And LMS and say authentication, we're not changing. Authentication, think like single sign on OAuth, something like that. We're not going to change those. So what that means is we're going to come up with a new sort of mapping here. So we're going to try to simplify things first off. And then we're also going to try to connect, you know, things together as nicely as possible. So this is maybe a little bit sort of, you know, canned for the demo to look maybe a little nicer than we always will end up getting an architecture to look, but this is kind of the idea. So what we're going to do is we're going to get rid of that little bit of static, you know, HTML that we had up here with Elasticsearch, we're going to pipe Elasticsearch right into Drupal. That also allows us to get rid of that sort of nasty little MySQL database that was floating around. So we can go back and forth between Elasticsearch here, pushing products, you know, we're indexing products with it and then getting search results out of it. We are going to hook up analytics into Drupal, just like they were hooked up into Magento. You know, we'll maybe hook Salesforce into sync, you know, customer names and emails in this case. And then we're going to hook MailChimp into Drupal. Again, that's an easy thing. You know, Drupal has a good MailChimp integration just for, you know, newsletter sign-up. You know, and unsubscribe simple stuff, but it gets, you know, everything integrated in working a little bit more together. And then we're going to sort of show what we're going to have for data moving between NetSuite and Drupal. And so since we're actually storing products in Drupal, Drupal is going to be the main source there, although we are going to have to push the products down to NetSuite. And then we're going to go back and forth between Elasticsearch and Drupal. Although we are going to have to push the products down to NetSuite so that people managing orders have access to products and pricing, although that would be simple. We're not going to push all the media or anything. We're just going to push, you know, pricing, you know, title, description, skew or something like that. And this is not like a hard and fast rule that we'd always do. Maybe that would come from NetSuite. You know, maybe that would come from something else. But in this example, we'll push it from Drupal. And then orders are actually going to go both ways is maybe how we'll come up with here. So we do something like orders will come into Drupal. They'll go through once they complete checkout. They will go down. They will get pushed to NetSuite. And then Drupal basically stops being able to change orders at that point. And all the changes from then onwards happen from NetSuite. And any changes are pushed back up to Drupal purely for read-only information. So say a customer can log in, see their account. And see what the status of their order, see if a tracking number has been added, you know, that kind of thing. And that, you know, something like that would let us keep the, you know, the two-way sync as simple as possible. Two-way syncs are sort of always a little bit of the devil because, you know, if they, you know, something gets changed on both ends, you know, what happens, what takes over, what do you do with the data that's going to get lost? How do you notify the user? So if we can do a pretty good split there that everything up and including checkout happens on the Drupal side, everything post-checkout happens on the NetSuite side. And the other side is just sort of mirroring that data for informational purposes. Or in this case, we probably wouldn't even send the data to NetSuite until the checkout was complete. So that is sort of a really top level of what we would do maybe when absolutely first talking with the client. Sometimes I do this stuff even in, you know, just in our sort of pre-sales phase, we might come up with some very generalized stuff like this to sort of show what our plan is to the client. And then it's actually going to go into a big technical architecture that we would do and everything. Josh Miller is actually in the chat there. He's written many big technical architectures for us. I usually get to pawn it off once I've done the, you know, the easy top level stuff. But that's going to be much bigger. That might be a 25-page document. That's going to talk about exactly how, say, these orders go from Drupal to NetSuite in back, you know, what we're handling for products, you know, what's going to connect in here, how much of the customer information we're going to pass back and forth between Salesforce. That kind of thing. So those are going to have, you know, a lot more detail. We'll probably have a couple more diagrams, lots of tables, all that sort of fun stuff. I might even be able to post afterwards. We have some samples of sort of how those work that we sort of show out. And of course, I'll post the slides as well. I think after that, yeah, I should still have a few minutes, even though we started a little late here, I tried to kind of be pretty prompt on that presentation to answer questions. And then also, I will be at our booth, although not immediately after this session, which I, like we know before, I thought took place at a different time. But when booths are open, I will be at Akro's booth. Oh, sorry, I just saw the comment there. Brian Sharp is trolling me. He is a Drupal developer who I've known for a very long time who used to work for Akro. And of course, he would troll me. Just mentioned that he is probably going to owe me beer again this year when he's again bad at betting at hockey, as I have quite the winning record against him. So anyways, on that note, I will be at the booth later today if anyone wants to talk to me. And also I'll be around. You can always find me on Drupal Slack and stuff like that. And let's pop over to that QA tab now. Let's see what we got going here. Will the slides be in the con drop box? They are not now, but I will drop them off as well as maybe some other samples if I can after this is over. Less content types, you create the better. How do you implement this practically? That's a really hard question. That depends a lot actually. Say on our corporate site, for example, we actually use relatively few content types and we make them very flexible with paragraphs. That one probably the most depends on the technical savviness of the client and how many business divisions they have. So how we want to split them up. Personally, I prefer more content types that are more specific. It's a little less prone to error. And so we will try to make fairly specific content types that are fairly locked down with limited customization. But for certain clients, we will actually make very wide open ones. And we'll make heavy use of paragraphs or starting to become a little bit more layout as well. Although we still lean pretty heavily on paragraphs because layouts isn't quite there to have those be functional. But it has its own difficulties. I know that's not a perfect answer, but that's how we try to split it up. Things like products and stuff, we try to be more specific so that if we have to be passing data back and forth through integrations and stuff, we have to be a little more strict on how we handle that. So then we'll get a little more inflexible there. And whereas say a blog article or something, we could be really flexible. Leo builder and paragraphs do work together. There are sort of some modules to sort of glue that together. It is imperfect at best. It ends up being a little cumbersome. It's more cumbersome from the UI than it actually is from a sort of programming standpoint. But it can be sort of fairly complicated as you have this sort of drag or you have this sort of list tables kind of view that paragraphs use and then you have sort of the drag and drop view that layouts uses to sort of map it. And it can be pretty difficult for clients to understand sometimes. So let's see, what else do we have for questions? Who do I cheer for? Vancouver Canucks, even though they can't even play because they all got riddled with COVID. And it's a big controversy right now. So try not to think about that. Centralized architecture for commerce could be risky. What if the Drupal site is slow or down? What do we do for a secondary backup service? Actually, we don't have too many problems with that. We're pretty good at having pretty performant Drupal sites and having that be a main hub of commerce. We can take 10,000 orders an hour, no problem, that kind of thing. I've actually done entire talks and we have lots of blogs, posts and stuff on our sites, all about Drupal and commerce performance. And we can run them through multiple low balance servers and things that scale up automatically and everything like that. So we're actually pretty confident in having that be a big hub as far as e-commerce is concerned. Like I said, we don't always do it that way. And as we're going more headless these days, it's not always the case. But we're pretty good at having our Drupal sites be very, very reliable. So it's not actually a big worry. And we deal with some fairly high volume. We do some big telecom stuff with iPhone preorders and things like that, which can be pretty crazy as well as sort of standard Black Fridays. Let's see, if a client is willing to accept an MVP, is it better to move forward on an MVP or spend time on architecture and discovery? If we can, we prefer the MVP wrote. And so we would do sort of just enough discovery and strategy to build said MVP. And then we would kind of continue working on it as we went along. So it's going to depend on the client, how much of the site we have to replace sort of all at once. Oftentimes, we're coming in and we're not the first build. We're a build for someone that already has a lot of existing stuff. So the MVP still has to be fairly large because it's replacing a fair bit of functionality, which lends itself to a bit more upfront planning from us. Although if we have a site where we can do simple MVPs and work from there, we prefer that there's less risk of clients not getting what they want, that kind of thing. It's a bit of a mix and it depends a lot on budgets from clients too. They'll have issues with, they might need to get approval for a fiscal year or if we work with a university or a government or something like that, getting budget approvals are really slow and cumbersome and so they might need to do this whole planning phase and so we can budget out kind of a whole huge chunk of a project at once. That said, we don't actually hard quote anything these days anymore. Everything is time and materials from us, but we try to still give fairly good estimates. Let's see, next question. Do you get down to the content type level in the sales process or do you try to be high level? In the sales process, we try to be higher level and not get down to content types. We try to stay away from that and work more with systems. Whole systems of, hey, Drupal will handle these few sections. We might say like Drupal will handle products and pricing and blog posts or something like that, but if products are actually made up of six different types of products or something like that, we try to not get into that part. That will happen in a technical architecture or something that we'll get into that level of detail. It depends a little bit on the savviness of the client. If it's a very Drupal savvy customer, then we might get into that a little more, but mostly we'll push that to sort of after sales and say, hey, we'll handle that in planning. It tends to work pretty well that way. Do you ever engage in process mapping and assisting the client in changing business workflow through your mapping discovery process? Quite a bit and it can be difficult to sort of stay in our lane a little bit there and sort of work where we are skilled and stay out of where we are not. If it's something like e-commerce, order process flows and things like that, we're quite experienced in that and we can say, hey, let's manage this here, then let's at this point in the flow, we'll push over to this process and maybe your CSR should be involved here, that kind of stuff. Once it gets outside of that flow, if it's sort of like how an accounting flow should work or something like that, we're less involved. Although we kind of still end up being fairly involved with workflows there a lot. We're pretty involved in those, even if it's just to sort of recommend that they change something or we might have a partner that we try to get involved to help us say, if it gets to the side of shipping and order fulfillment, that's a little outside of our wheelhouse, actually managing warehouses or something and we'll recommend they bring in a different consultant or something there. Although we do get quite involved in that, we try to be very consultative. In an ideal world, what's the best way to sync the CRM customer data with Drupal users, Cron, Webhooks, etc. How do you plan which fields need to be synced? We plan which fields need to be synced in pretty great detail, usually in technical architecture. We try to sync the ones that will be relevant and only the ones that they're actually going to use in the other system and limit that, and then we try to be very careful with what's going to need to change back and forth. It can be quite difficult to sort of map that in a two-way setup. Cron is probably my least favorite way of doing that. Webhooks or even what we prefer, actually, is that, say, if Drupal can connect to an API from, say, like Salesforce, and then Drupal will basically do them in near real-time to push them over, basically sort of asynchronously in real-time. So the minute they get put in, they're being pushed over to the new system, but not so much that they're blocking. In some cases, they might have to be blocking, but for the most part, they don't. So that's how we would try to do it, is basically have a non-blocking setup. So just after, say, the order gets completed, then a job gets run triggered off of an event hook on the order completion or something like that. So it can be a little fussy with PHP to make things asynchronous there or whatever, but it's not too bad. I think we're probably using up our time here, but no one's kicked us out yet. So I can answer at least one more question here. What's the average time to build a commerce site considering basic variables into consideration? We do fairly big sites. We would do something where even a planning phase from us might be 25K or something like that. So six months would be a pretty fast build for us. If you just need out-of-the-box stuff that tends to not be us, we're usually, if you need a bunch of customization built, that's why you come from us. It's six months to a year for a build process for us. And also, we tend to be an ongoing agency. So 80 plus percent of our work is recurring work for clients. So lots of RSAs and stuff like that, as we're continuing to tweak and improve and add new functionality and things to existing commerce sites. So that's what we're doing a lot of ongoing work, the clients we've been working with for years and years. Integrating to new systems, tweaking integrations, adding new functionality, upgrading tech, all that sort of stuff as we go along. But our builds are fairly high. That said, we're looking to speed up that setup now that we're switching to, as part of how we're switching to more headless setups, and we're trying to be a little leaner on how we can get parts up with sort of a services setup of maybe we can replace parts with microservices and a D coupled front end and that kind of thing. That is very, very early on in our process, and we won't be building sites like that too much until probably next year. I think I got all the questions. If I didn't get your question, I apologize, but I'm pretty sure I was able to scan through all of them there. So hopefully that went well. I will be at the booth later on, and I'm also on Slack, if anyone has any questions. So thank you for that. Oh, and apologies to that other Brian Sharp who got unfortunately chastised in here. I will go give the correct Brian Sharp crap. So thank you very much everyone, and talk to you guys hopefully some other time if you stopped by the booth or something.