 Hey everyone, nice to meet folks really excited to be talking with you today. I am Megan Donahue VP of Business Development and Growth at Bounteous. I oversee our AQUIA partnership and really closely with both Larone and Chris who you'll hear from today on all things Drupal, AQUIA. Really looking forward to today's discussion. Larone, do you want to introduce yourself. Absolutely. Thank you. My name is Larone Walker, Senior Director of AQUIA Development. And I help our clients win with Drupal and also help support our partnership with AQUIA. Awesome. Thanks Larone. Chris, what about you? I'm Chris Kretens. I'm VP of Drupal Engineering here at Bounteous. I've been working with Drupal for a long, long time and working with Megan and Larone on the AQUIA partnership. So happy to share some information with you today. Great. Thanks guys. Alright, so why are we here today? Well, we've all been hearing I think over and over again about headless or decoupled or some form of that terminology. And then we hear a lot about, well, what does that mean for me as an organization? You know, I'm in the marketing department. What does that mean? I'm part of the technology team. What does that mean? But the questions we get asked most often are about the approach that a company should take and why and what the impact might be. And so there's clearly kind of a lack of understanding the value and the differences between the various approaches and what it can mean for a business. And today we hope to clarify that a bit by answering some of the common questions that our customers are asking themselves and oftentimes asking us to answer for them. So we're going to spend a little bit of time covering off on these four items here. The first one, you've been charged with enabling a transformative brand experience, but what does that really mean for your organization? Drupal is your platform of choice, but where do you start? What approaches to build are there to consider? Third, how do you determine the best approach for your organization today and in the future? And fourth, how do you avoid some of the common pitfalls with any of these approaches? We all know that nothing is perfect, but having an understanding of sort of the common pitfalls is really helpful in terms of thinking about what the best approach is for your organization. And before I get started today, I just wanted to spend a few minutes telling you a little bit about Bounteous, really who we are and why we're all so passionate about helping our customers get this Drupal approach thing right in today's in today's world. At Bounteous, we exist to help leading companies win digitally by continuously innovating brand experiences that drive transformative results. Continuous innovation in our world is really about a culture of capturing insights, applying those insights, testing and learning digital experiences, and transformation means changing business models, introducing new and improved streams of revenue, evolving brands, platform evolution to drive enablement and operational efficiencies and so much more. At the crux, we are a digital first firm that sits at the intersection of a management consultancy. So a lot of the work that we do is really about supporting our customers through their digital transformation, helping define their overarching brand strategies and visions and bringing those to life. We are also a digital agency where we spend a lot of time designing, building, optimizing and marketing digital experiences for our customers. And we are a systems integrator with a big focus on platforms and a longstanding relationship that we have with Acquia and the Drupal community, for example. And this is where we're going to spend most of our time today. As a company, we work very closely with our customers to drive transformative experiences via what we call our Coordination Framework, which is made up of three core elements that you see here on the screen. Critical insight or insights being the first one, we must have critical insight or insights to drive hypotheses for the things that we create. We can no longer create things because it sounds fun or it's the newest and greatest thing to do. We have to create based on insights that we have about our customers, our business, the changing landscape, something. Digital flow second here is really about our ability to apply those insights repeatedly into the digital experiences that we create to deliver optimized experiences and continue to get smarter and smarter as a business about how we're enabling our customers to get to some kind of end result. You know, things like machine learning come into play here as we continue to gather more and more insights about our customers and determine how best to apply those. And none of this is possible without enablement. And this is really about ensuring we have the right approaches and the right models and the right people and processes in place to be able to deliver continuous innovation. And if we peel back our enablement model further, this is where today's conversation really becomes applicable. The aspect of this model must be custom built for you in order to successfully deliver, you know, these innovative brand experiences that we talked about and that meet your individual businesses goals and objectives. On the outer ring here we must have a clear strategy for what the business is trying to achieve. You know what are our business goals and objectives, what are we as an organization trying to enable to be able to support those goals and objectives. What are these inner circles, you know what are the people and the methods that are going to be required to deliver these experiences, what data and technology platforms must be in place to support in achieving these goals and objectives. And if we look at technology and methods and talents, you know this is where we see questions around platforms and capabilities and approaches like headless or decoupled really come up more and more. And we're not going to spend a lot of time today talking about you know how we help you solve the entire enablement model equation. We will start to help you think about your decision around Drupal builds by way of leveraging this enablement model. These pieces are critical to being able to help you deliver your next innovative brand experience. And with that I invite LaRone, who you met earlier in the call to get into the meat of today's discussion. Thank you so much Megan. So how to approach Drupal builds today we're going to cover three approaches to building digital experiences in Drupal. But before we get into specifics, let's highlight a few scenarios you may have experienced within your own organization. So do any of these scenarios sound familiar. You're trying to gain operational efficiencies by not waiting weeks to update the homepage. Or maybe there's a desire to put more control in the hands of marketing with less reliance on it, because content is ready, but you need to coordinate with developers to add it to the site, or maybe you have this amazing story to tell. It's difficult to share that compelling story on your current site. So if any of these scenarios sound familiar even just a little bit. Don't worry, you're not alone. We're going to shift our focus today to talk about how we can use technology to solve business problems. And by defining the problem clearly, we can determine the correct architecture. Now choosing a fully decoupled or headless approach because it's cool. And trust me, I love things that are cool and I love technology. But ultimately that's not the best decision. The ultimately the business needs, the business needs and requirements will drive you to the correct solution. So that let's start by taking a high level look at the different approaches. Now, there is a spectrum of approaches when it comes to building these digital experiences and Drupal. Now on the left side of the spectrum is Drupal rendered, or what you can consider the out of the box experience with core Drupal. The far right of that spectrum is a fully decoupled approach, which is fully separating Drupal content administration from the display layer or what the user or the public sees. And right in the middle of Drupal rendered and fully decoupled is this third option this progressively decoupled solution. And that takes the best of both worlds where you have some content that's rendered by Drupal, and the rest is carried through API's. The other spectrum are typically pretty clearly defined and you've probably seen other webinars or articles about this where they talk about what you can get with core Drupal or Drupal rendered and then what you can do with a headless solution or fully decoupled. But we find that the middle that progressively decoupled solution tends to not be as clear. So I know that we've just highlighted the approaches and we'll get back to these in more detail in a little bit. But how do we determine which approach makes sense. And gaining clarity on the approach comes down to asking the right questions and understanding the needs of your organization. It's also important that these questions aren't solely technical and again, this is coming from me so it must be true right here are some examples of clarifying questions that can help you determine the right solution. So what business problems are you solving. Where is your organization in terms of digital maturity. What resources and skills do you need to build and maintain your site. What out of the box Drupal features are important to your business. Now, no, it would be very easy for me to go into what is cool or what fad is out there as far as frameworks and platforms but that really there are a lot of other questions that used to be asking that can help you clarify what approach makes the most sense. So let's take these questions and dive a little deeper and impact them a little further. So that first question, what business problem, are you trying to solve. So maybe your Drupal site is powering multiple experiences so for this example we can assume Drupal is powering your core website but maybe also digital signage, and maybe have a mobile application that's pulling data out of Drupal. Maybe a case where fully decoupled, where the web experience is coming from Drupal rendered. And then you have another experience that could be partially decoupled, where Drupal is kind of core website, but digital signage in the mobile application is coming through via API so again you're separating that the core Drupal render layer with Drupal is coming from progressively decoupled. Now, another scenario could be maybe you have a content team or a marketing team that works independently and doesn't want to be tied to code releases and we see this a lot so maybe the marketing team has a campaign that they're trying to launch or maybe you have a sales arm to what you're doing and there are sales or promotions that you're responding to and we've seen a lot of that in the past, you know, 15 or so months with COVID, just having the ability to respond quickly to the needs of your clients and your customers. You don't want to be held up with a release cycle or having to wait on developers or it to promote that code to push that live. So if there's a scenario where there's critical content and you want your marketing team or your content team to be able to move quickly Drupal rendered would probably be a better solution because that doesn't rely on code pushes or releases. Once you make that update in Drupal you can publish and that content is live for all to see. Now, if your Drupal site works with an API driven external commerce solution, and that could be something like commerce tools or maybe elastic path, leading to a progressively the couple or fully the couple of approach may make more sense now again you're relying on API from external systems, and then you also have your core Drupal experience. So Drupal rendered most likely wouldn't be a great fit for that type of scenario. So where is your organization in terms of digital maturity so supporting the platform is vital to success. The more complicated the platform, the harder it is to support. Now if your organization has not made a significant effort to create content simple solution probably makes sense there's no need to unnecessarily complicate things. So an example of this could be you have content editors that only spend a couple of hours one day a month editing content on your site. A simple solution like Drupal rendered may be best. However, maybe you're on closely the other side of the spectrum, where you have a team of content editors and they want flexibility to create content and varied and creative ways, and send that content to multiple channels so remember the example where we talked about Drupal power on the main website and maybe digital signage in a mobile app this will be a scenario where content is going to different platforms, a solution like the couple Drupal maybe best in that scenario. Another question what resources and skills do you need. So maybe your team doesn't really know Drupal theming or no react at this point but you have a solid foundation and CSS. Drupal rendered solution using Aqua site studio maybe best because that allows you to make updates to the site UI without fully understanding the Drupal theming buyer so you can move quickly. Or maybe your internal team has a particular skill set that can also make this option more appealing so an example of this is maybe you have a strong a team that's strong and react for you, and you're there one of the other popular front end technologies. And that may very well guide your decision in here to figure out where on a spectrum, you should pursue. And it isn't just what skills your team has now so one thing to also consider is not where you're today but strategically where are you heading what skills do you think your team will gain in the future. What strategic hires are you playing to make moving forward and let that be part of your decision in here. What's triple features are important to your organization. The biggest biggest advantages to using a platform like Drupal, and I love talking about this because, well I love Drupal but you also get a lot of features and functionality out of the box and there are 40 plus 1000 community models modules also to support what you get from core Drupal there's a lot there. It's not just what's included in Drupal core, but also is community supporting models modules that are already built out and ready for you to use. So you can leverage all that pre built functionality to make your builds go faster to spend less of an investment, make it easier to maintain, and you don't have to create a custom solution. Now, when you build a decoupled site, you are now building a custom front end for your Drupal website, and by going to coupled you're either giving up functionality that Drupal already has, either in core with this supported community modules, or you need to build those features of functionality yourself. An example that we use often here is preview. So if you have a Drupal rendered site or kind of core Drupal, you know that out of the box you can preview pages before you publish and push that content live so it's an out of the box feature that you get with Drupal. Now if you're in a decoupled scenario where you're separated Drupal administration from the front end and you still want content preview that is now a feature that you have to build separate you need to roll your own solution. And that could be a blocker and there are others there is like that where just knowing that you have you're losing these features that you get out of the box and it's extra work not just to build the first time but also for your team to maintain you should be considering that as you're picking your solution. So as you're wearing different features, consider what matters most to your organization. So we've asked a number of questions and hopefully that's starting to shed light on how you can clarify the approach that makes the most sense but let's dive in a little deeper on these three approaches Drupal rendered progressively the couple in the middle and then fully the couple there on the end. Let's start with Drupal rendered on the left side of the spectrum. So this is plain Drupal. This is the most straightforward implementation consists of building templates out for each content type. And it's also the easiest for content editors so a workflow can be your content editor you log into the triple admin and maybe you're pushing a press release or an article onto your your main site. You can log into that content type fill out the fields, publish that content, and then you're done. That's live for the world to see. The downside though to this kind of playing out of the box Drupal experience is that it's also the least flexible of these approaches. And one way you can get around that and gain a little more flexibility is introducing a tool like layout builder, which is now included in Drupal core. And what layout builder allows you to do is allows your editors to break free from the rigid templates that you get with just taking a, a content type editing kind of process where all you're seeing from a display standpoint is coming from the templates that you built out in Drupal. And instead, you have some more flexibility by introducing layout builder into the equation to build unique components. Now with this addition of layout builder comes a little more complexity and but you also get more flexibility with the display so there are trade offs. If you want to take it a step further, there is a low cost solution. If you're an awkward client awkward has a fantastic solution it's a drag and drop component based driven interface called Aqua site studio and that allows you to create these component based experiences which is kind of like layer layout builder but it's a level above that and you get a lot more flexibility there. I think we mentioned in a few slides earlier as well that if you have a team that's maybe not as familiar with Drupal theming that layout builder allows you to do a lot right there in the UI assuming that you know CSS so there's a lot of advantages to do a lot from like that. One disadvantage though could be that if you're not in a tool like site studio often so an example could be maybe you built your site and site studio and kind of week one month one quarter one you're in there every day but as time goes on, you find that your content editors aren't in there that often and then all of a sudden you need to jump in because there's content that needs to go live really quickly. That's for all the steps that you took to modify templates within Drupal using site studio so if you're not in there often, maybe that's not the right approach for you. Now let's jump to the far right side of the spectrum was fully decoupled. This is the new hotness this is what everyone's talking about. This is where all the articles seem to be coming from talking about the couple or headless and you probably have questions about what does this mean and how does it fit within our organization. And we're seeing it here at Bounteous you know more and more of our clients are exploring this approach that allows you to serve Drupal data via API calls without relying fully on Drupal to render pages. And with fully decoupled there are some great advantages here, you have complete control over the presentation layer, and you're not limited by the CMS presentation layer and it's also easy to compose and present content for multiple systems. For example, if you have a CMS powering part of the experience and then commerce powering other parts. So we've also seen that performance can typically be better as well. And an example of this is maybe using Drupal API to pull content out of Drupal, and that content is going to a static site generator like Gatsby. For the public site users or people visiting your site, what they're hitting is static pages that are probably being served off a CDN. They're not really hitting Drupal they're not really hitting your API and they're not really hitting your database. So that allows you to have a really formative experience. And also by creating that separation, you could have the Drupal administration happened behind a firewall kind of off the main internet, and then have all these pages rendered separately so there are some security implications by separating your content in a fully decoupled manner. However, and there's always a however right with great flexibility comes great responsibility, you need to build the presentation layer. So you lose out on functionality the CMS has already built and we talked about this previously with the previous example, this is a scenario where, if that's important to you, you don't get it with this fully decoupled solution unless you build it yourself. Now lastly, this partially decoupled solution right here in the middle this approach. This lies right between coupled and headless. So the Drupal rendered and a fully decoupled solution progress with the couples right there in the middle. And this relies on rendering content from Drupal, but also relying on API that are coming out of Drupal so you get the best of both worlds. So on kind of the best side of that is you take advantage of Drupal's rendering while layering parts of the experience that are decoupled, and then more complicated digital experience platforms you can choose to decouple certain items or certain systems. So for another example is commerce we talked about pulling in APIs maybe full commerce tools or from elastic path. That's easy to do and kind of mix and match approaches here with this progressively decoupled solution. So ultimately, you have great flexibility and also great ability to highly leverage Drupal where it makes sense. But not so best because we talked about the best of both worlds here complexity of the implementation increases with this solution so ultimately everyone on the team needs to understand how to work with the different pieces of the system. Content editors need to know how to add edit and preview content, your design team needs to know what components can be used and where your development team needs to know how to affect rendering and multiple ways. So this can also change how you're, you're promoting content and how you're releasing code publicly so there may be parts of the site where you're able hop in and make changes right in the admin and others that require a code release so it's just important that you're considerate of all those factors. We've looked at the different approaches to building enterprise triple experiences we've highlighted some key questions. You can ask to help you decide what approach makes sense for your organization. And dove a little deeper into what those approaches look like and kind of where on the spectrum, you can go. And with that, I'd like to invite Chris to talk now about how we've applied these approaches to projects. Chris Larone. So understanding the spectrum of approaches, and the questions we should be, you know, thinking about and give us the tools to choose the correct approach. So let's, you know, talk a little bit about how we've applied this of the few projects that bounties has worked on. You know, one great example is Enterprise Bank of Trust Enterprise Bank of Trust is a regional financial services company, and they needed to update their branding as well as their platform. And so they're really looking to rethink the approach to the web and to create a more engaging experience for the customers. They already selected Drupal so we knew that Drupal was going to be the CMS. So the question really was how do we leverage Drupal. So thinking back to some of the questions Larone talked about, you know, we started asking these things and thinking about them. How do you want your content and marketing teams to work independently of the development team? In this case they did, you know, they wanted to give them some freedom, but they also wanted some guardrails as they got acquainted to a new system. Is this part of a digital experience project where you're looking to tie, you know, the CMS together with other systems, and you know they were really focused on the web. We didn't have to worry about other systems as much, but we did know that they were going to do some personalization into their future. Who will be adding and maintaining the content on the site? What are their skills? Is this their sole responsibility or one of many responsibilities? So they had a talented team that was really comfortable in maintaining the content, but they also had several other responsibilities. So Larone's point, you want to make sure that that system is as easy to remember how to do those things as possible. What about the development team? What did that look like? And they didn't have any Drupal experience in-house, but they were definitely looking to grow that in the future. So based on these answers, you know, what do you think the approach was? Well, given these responses, you know, we thought the Drupal render was the right approach for them. The frequency or maybe infrequency of the content changes, and knowing that the content editors wouldn't necessarily be in the Drupal system every day, because they had other responsibilities to tend to, made building an easy to use interface with some guardrails in good place, or a good choice for them. And Drupal is a great framework for this. The focus was on the web, so there were no other channels for us to really think about in the short term. So, you know, using a coupled approach and taking full advantage of Drupal made sense for them. The next step for them in the DXP was to add personalization, but we already knew that they were using accurate personalization, which integrates really nicely with a coupled Drupal approach. And they had no Drupal experience on development team, but they did desire to bring somebody on in the future. Building and documenting the platform to make it easy for IT to take over the future was pretty important. Let's look at another example with a few different factors. So, ENJ Gallo Winery is a client of ours, they were looking to replatform onto a new CMS and a new commerce platform. They had a number of different brands as well as tasting rooms and wine clubs. And one of the goals of the transformation was to make it possible to give a highly personalized journey to the wine customers, while also giving the marketers the advanced tools and flexibility that they needed. And so we had a couple of questions to help us hone in on, you know, what was the best approach for using Drupal? Are you looking to support multiple channels like, you know, mobile apps and digital signs besides your website. And other channels were in the future, but also multiple websites. Right. So we knew that the platform needed to support a bunch of different scenarios. So, you know, we're part of a digital experience platform with multiple systems or websites. Well, you know, we knew that the commerce and content needed to be pulled together and pulled together seamlessly to give the user experience that they wanted to. And of course the multiple brands affected us as well. So all of these questions start to get us thinking. What's the development team's composition and what experiences does it have? In this example, you know, they had a really talented development team. And they were really skilled in some of the JavaScript front end frameworks that are used to do, you know, or build a couple of experiences. But they really had no Drupal 18 experience. Right. So, given this, you know, what do you think? Well, the answer here we thought was a fully decoupled approach to the platform. You know, the development team already had the JavaScript framework skills that could really help the project and push it forward. And just as importantly, they wanted to continue to develop those skills as well. And both Drupal and Elastic Path, which was the commerce background here, they work in a decoupled fashion really nicely. So that was great. But, you know, because they didn't have any Drupal theming skills, by going decoupled with both ends of the equation, it made it so that they didn't have to learn how to theme in Drupal. And finally, by decoupling, it really made the approach to mixing the commerce and content on the platform less complex as we created these highly personalized journeys. So instead of having to have Drupal and just content from Elastic Path to display it as you would in maybe a couple of experience, we didn't have to worry about the complex migration. All right, one last example to show us how these questions can help drive our approach. So we recently went through some updates to our existing web platform. And we had originally built the platform on Drupal 8, and we had an implementation that we're very happy with. The original implementation was a coupled approach that use layout builder to give our marketing team some flexibility in building up the content. So after a couple of years on the new platform, we wanted to update the look and feel, which included plenty of complex animations, and to implement that some complicated JavaScript. We're looking to update a few key areas on the site, rather than going with a complete redesign. So what are some of the questions that we asked ourselves? Does the team have deep knowledge of frameworks like React and Gatsby in Drupal? And yes, as an agency that does this every day, all day for our customers, we have really solid experience in knowledge and both of the couple of technologies as well as Drupal. Who will be adding and maintaining that content on the site? What are the skills? So we had an excellent marketing team and also an excellent development team. So they're both used to working with these tools every day. And so we were pretty excited about that. How quickly does the project need to be completed? So we were under a pretty tight timeline. And so we needed to make sure that whatever approach we used could work with that as well. And what matters to the organization? Were we okay rebuilding features that Drupal provided as we custom built and custom solution? And we felt that executing the design vision was more important than keeping the out of the box Drupal features there. So given that, what do you think our approach was? So basically these factors we decided to begin decoupling pieces of the site, but not the entire site. So progressively the couple is where we ended. And in fact, we may end up there as we go in the future as well. There's no reason that we will necessarily decouple every part of the site as we go forward. So our development team had a variety of skill sets, including Drupal and Gatsby and React, which were how we chose to implement the progressively decoupled piece of the site. But one of the things that's interesting about our project was that the developers had other commitments as well. And so we needed an approach that would allow us to work in multiple work streams to be as efficient as possible. So some developers had client work, some developers had some thought leadership work they were working on. And we needed to make sure that we could separate the Drupal Web's work stream from the React and the Gatsby work streams as well and allow them to build independently and then meet in the middle. We have a dedicated marketing team in place to support the content and the dedicated development team. Both teams are very skilled. So having this additional complexity was acceptable in the name of getting the exact design correct. We had a tight timeline, like I mentioned, to turn this project around. So it was not really possible to decouple the entire site. However, by decoupling parts of the site, we've achieved our desired outcomes, while also ensuring that as time allows, we can come back and decouple the parts of the site that we want to in the future. So now we understand the spectrum of the approaches and the questions we should be asking. And we've seen them in action. So let's talk about what not to do. Some of the common pitfalls to avoid. You know, one of those pitfalls that we've seen is where clients try to decouple too much. So we had a Fortune 500 client of ours that had built a platform that combined both CMS and commerce. And Drupal was used in a coupled fashion, while the commerce platform was completely decoupled. And as we talked about earlier, this makes it easy to mix the commerce content with the marketing content, which is real plus in the system. The challenge, though, when you're decoupling the commerce implementation is that you need to implement all of the pieces for for commerce. So while the product category and product detail pages were pretty easy to implement, there are some challenges when it came to the shopping cart flow and the payment functionality. These require tight communication with various other platforms and cause a variety of issues. So if you're doing something with this, you really need to think through these integrations. So they need to be well planned out and executed. So how would you solve this problem? Well, we we saw the problem by helping them couple the shopping cart and payment functionalities back to the commerce platform. So the way it worked was Drupal was the glass Intel the user was ready to check out and once the user is ready to check out. Then you can move it over to the commerce platform. Now, this takes advantage of already built and well tested functionality for the shopping cart and payments. Right. And it also allows you to take advantage of other features of the commerce platform as well. And some of these were requirements that we knew were, you know, nice to have some things that soon needed to be added. So kind of the lesson here is that the more you decouple the more you need to custom solution or build for. So, in short, for this example based on their current and future plans, this architecture adjustment right size 30 coupling. Another pitfall we see is where the project does not have the correct stakeholders involved from the beginning. You know, here we had a client that asks us to do a discovery with the main question being, you know, what should the architecture of the system be what should their approach be. And the initiative was driven almost exclusively by the it team. And as we dug into the requirements and he started doing some stakeholder interviews came more and more clear that the marketing team was not being consulted. So the primary drivers and considerations were all it focused. Things like, should they be using the couple versus another approach should they be using microservices. So how about the content publishing flow how will that affect them and how you know what were their role be as content is published. And some of the things that marketing would be concerned about things like content workflow personalization and journey orchestration were largely ignored. So, as you approach the project like this, you really need to pull in many different points of view it marketing legal analytics and more are needed to understand what you need to build. Just a website need to take into consideration a wide variety of wants and needs to make sure that the architecture you choose to support supports those things now and in the future. Looking at a small slice of requirements for one group may lead you to choosing a couple of approach. But when all the groups are considered and all the features and functionality and requirements are considered a headless solution, maybe the place you want to be in the next 12 to 18 months. And the last pitfall worth mentioning here is failing to plan for the future. So we had a client that brought us in to assess the platform, specifically the client was looking to expand the Drupal site beyond just being a website client was looking to start using Drupal and content to really engage their customers using personalization or other channels. So, one of the possibilities based on the platform and the content that was already built was our question. It was a powerful tool, and you can build anything you can imagine with it, and you can build that anything in many many different ways. The way you choose to build Drupal you the way you choose to you build using Drupal and how you build that content out will really dictate how much flexibility there is in the system to accommodate those changes in the future. In this case unfortunately we had to tell the client that the platform was not going to support their needs without heavy refactoring. We needed to have multiple content types added and entities added, so that the content could be easily be used in many channels. The piece of it's needed to be adjusted so that they would accommodate personal personalized content. You know, with a bit of planning in a different approach, all this work would have been avoided. You know it's vital in these replatform projects that the architecture and approach allow the platform to be flexible in the future. The last few years have told us it's that we don't know what will come in the next few years. But we can build with a flexible architecture that allows us to adapt in the future. So, in summary, Drupal is a powerful flexible tool. We can do lots and lots of different things. We have a spectrum of approaches that we can use from couples to fully coupled. The approach that we use will be informed by many questions and points of view focused on the business problem to solve the organization's digital maturity and skill sets and the project's requirements. So we hope you've learned a little bit from us today. That concludes the presentation. Thank you for attending our webinar. If you have any questions, please feel free to reach out or visit our website at bountyus.com.