Good morning everyone. On behalf of Kerasov Technology Corporation, I would like to welcome you to our AQUIA and OOMF webinar, Small State Big Dreams, Howard Island, a reimagined and modernized digital presence. At this time, I'd like to introduce our speaker for today's webinars. Jack Hartman, Head of Delivery for OOMF. Jack is the Head of Delivery at OOMF. On a daily basis, he's collaborating with OOMF's internal team to solve unique problems and deliver quality digital platform experiences to our clients. Ben Hamlin, Senior Back and Engineer at OOMF. Ben is busy writing custom code, developing site architecture, testing website functionality, reviewing code, or evaluating and contributing to Drupal projects. Kara Hall is Drupal Cloud Senior Product Marketing Manager at AQUIA. Kara has a focus on AQUIA site factory and AQUIA personalization. She has a passion for innovative marketing solutions in the digital experience space and finding ways to help marketers and developers work together efficiently. Jack, Ben, and Kara, the floor is yours. Thank you, Blake. I'm going to go ahead and share screen. Okay. So again, everybody, my name is Kara Hall from AQUIA. I'm a Senior Product Marketing Manager. Thank you so much for joining us today as we cover little state, big design dreams, how Rhode Island refreshed their digital presence. Just to give a quick overview of everything we're going to be covering for our agenda today, I'm going to give a brief introduction into the current environment or common issue that many people see. And then we'll dive into the case study and the state of Rhode Island, and I'll pass it off to the OOMF team then. And then finally, we will close with some panel discussion with Q&A, mostly focused on answering those questions that you can submit throughout their presentation at any time. So diving into the current environment. So we know that it can be challenging to manage hundreds to thousands of sites. And then when you add in the factor that some of these sites are multilingual or regional sites, both with unique information, it can become even harder to manage all of those large number of sites. This often leads to a challenge that many state and local governments face when delivering their digital experience, that challenge being site sprawl. With all of these sites to manage and often small teams to manage them, it becomes very easy for the number of sites to continue to grow and reach an unmanageable level with information across all of them being different or unique. This is a challenge that the state of Rhode Island face as well. So now I'll pass it off to Jack, who will walk you through how the state of Rhode Island overcame this challenge with the case study. All right, thanks so much, Kara. Hi folks. Thanks for everyone who attended today. My name is Jack Cartman. I'm the head of delivery of at OOMF and served as the project manager on this particular engagement with the state. What I'm going to be walking you through is the first half of the AQUI Engage Award winning case study for the state of Rhode Island. I'll aim to cover a brief overview of the situation, the challenges, some of those proposed solutions, and some of the contributing success factors. Then I'm going to pass it off to my colleague, Ben Hamlin, Drupal Engineer and League Architect for the project. We'll dive into a little bit more detail around the implementation. All right, next slide, please, Kara. Thank you. All right, so let's talk first about the background of the situation that we were facing. As Kara alluded to upfront, site sprawl is a big issue for many multi-site platforms regardless of whether you're in state government, higher ed, etc. And the state of Rhode Island was really no different. The status quo for them, if we take a look at it, was really a bunch of state agency sites, 99 of them to be exact, spread across a number of different sites that really led to a lot of inconsistency and a lot of key areas. First one being technology stack. So in taking a look at the landscape, there were some sites that were built using ASP, there were some sites that were built using PHP, and a lot of this inconsistency contributed to high levels of inefficiency in maintenance practices, standardization of the state's web practices, and increased level of costs. The next thing that was a key contributor was varying levels of proactive maintenance. Some sites had been kept up to date, other sites may have been more neglected, and it just caused the potential for further vulnerabilities. Visual aesthetic was really key. Many of the sites across the state's presence lacked consistent look and feel. You can imagine there are 99 of them. There's a lot of different visual aesthetics that we're competing with. And as a result, it was hard for folks to understand sometimes whether or not they were actually on, sorry, set a poll pop up, whether or not they were actually on a government website, or whether they had been redirected perhaps somewhere else. And then finally for state content admins, content flexibility was really key but unfortunately also inconsistent. Content admin permissions and contact creation really varied from site to site based upon how they were built. And as a user, a Rhode Island resident, it was difficult for a user to sometimes find the information that you were looking for. So we faced a couple of challenges and those challenges are that we, one, we needed to rectify the issue by bringing all 99 state agencies in under a single platform umbrella. Two, we needed to establish a scalable design language that could work for all of the agency's websites. And then three, we needed to establish a centralized publishing and notification system that was suitable for the entire network, let alone an individual agency. So needed to be scalable. Next slide. And then the pandemic head. So we have all of these challenges. We have all of these things that we're facing in our situation and COVID-19 happened. So as I'm sure many of you have experienced, it really impacted a lot of operations on a number of different levels. And this shook things up for us a little bit. And it moved the goalpost forward from a delivery standpoint. We had a plan in place for when we were going to roll this out, but this created a heightened level of urgency to get a COVID-19 information portal launched as soon as possible. So when we talk about the need for better, faster, more efficient communication, there's immediate need to reach many more Rhode Islanders, given the critical information that needed to be disseminated by the Rhode Island government. Via increased level of translated languages or accessibility options. Next slide. The good thing is though that this was a challenge that we were facing, but despite this unexpected and sort of ever changing nature of the pandemic. The original solution didn't really need to change at all, because we had a high level of confidence or an original approach. The first being the services selected from Acquia. So first and foremost, given the sprawl nature and what Kara was alluding to earlier, Site Factory seemed like a natural fit for this. We could bring all the sites into a single Site Factory platform. It allowed the states and its many agencies to deploy new sites quickly with confidence and have a single hub management administration. The next was EDCDN and this was a service that we had been considering and I think was kind of deemed an absolute necessity following COVID-19, because things were changing at a moment's notice. We were delivering critical, very important information to Rhode Island residents over the duration of this pandemic. Once we have the COVID-19 information portal up and any option or idea of latency in delivery of this critical information was just a non-starter. So Acquia EDCDN provided a good solution there. And then finally, edge security. The very nature of Rhode Island being a government body makes them a target to those looking to spread information, cause harm, you name it. Security was a really critical component of this to ensure that our Rhode Island constituents were able to trust the information that we were communicating. Alright, next slide please. So the second half of that solution was creating a universal design system built specifically for the state of Rhode Island using Pattern Lab. And this really spoke to helping ensure that there was a consistent look and feel and consistent presence across the entirety of their 99 agency sites. So the users had a general sense of where they were, who they were getting the information from. And we named it Kohog. So if many of you or some of you aren't from the New England area, it was our little nod. One, because we were working on the state of Rhode Island, but I think too, if you don't know Kohog, some of you may have heard it from Family Guide, but it's a little hard shell indigenous clan. And they're really tasty and I highly recommend if you're ever in the area. But anyway, so what kind of comprised this design system? Well, five key components, I would say the first one being color themes so site authors currently can go in, they can choose from five color themes that supports light and dark mode viewing. Each theme rigorously tested to conform with WCAG AA. And in some cases, depending on the sites themselves, AAA standards, and each theme was based upon a palette of 27 colors and 12 transparent colors. So a lot of options available, but stuck within, I would say, a consistent look and feel across all of them. User preference site visitors can toggle between light and dark mode as I alluded to, or use their own system preferences with adjusting font sizes, line height, word spacing, default language. There are a lot of different ways that people can digest and personalize this content to ensure that they can read the information appropriately. Mobile first, a lot of our users were coming on mobile devices. Each design that we did for Kohog. Treats the mobile experience as a first class counterpart to desktop so oftentimes there can be a drop off between the quality of information being able to be delivered or the experience from desktop to mobile. We started with mobile first to ensure that that quality was consistent across pretty much any device that you're going to access the sites from. Fourth being accessibility. Every design pattern is super accessible for screen readers, mobile devices, color contrast keyboard nav navigation semantic labeling and all text enforcement. They all contribute to highly highly accessible site, regardless of whether you have the largest sites or the smallest agency sites. We also added extra labels and help text to have been added to create context to actions while also following best practices of use of aria attributes. And then performance aware. As I spoke to earlier, they need to get this information of folks quickly. Each page is given a performance budget so design components are built as lightly as possible. They use the least amount of code and relying the smallest visual asset file size as possible. All right, next slide please. So, we've got this great new solution in place for the state. And we're going to Ben's going to speak a little bit more about how we actually got there and how we actually build it but now that we have it we're going to fast forward a little bit. How are we going to be successful. Well, we needed to start with a partnership approach with the state, and that was the biggest factor I think, as far as ensuring that we got this done the right way, the right time. So, clearly defined MVP must have for any project. The accelerated timeline made that even more critical, and there's little margin for error before the launch the COVID-19 information portal. A dedicated engineering team needed to immerse ourselves in the world of Rhode Island's agencies truly understand the scenario from the largest agency down to the smallest. So we knew that we were building a platform in an infrastructure that was going to support any agency size. A commitment to a phase delivery approach. That wasn't going to happen overnight. 99s a lot of sites for us to be able to transfer in a short period of time so we knew that we needed to face this out needed to have a prioritized site rollout plan. What is the most critical information that needs to be basically disseminated as quickly as possible. And we knew that happened to be the COVID-19 information portal. There are many voices to be heard in any size government and I would say yes, even in the little state of Rhode Island. So, while everyone's voice is certainly equal in say we're dealing with 99 different agencies as well as other governing bodies within the government who have a hand in this process. So someone really need to be the primary decision maker for the state to ensure that we were able to make decisions move quickly. And we are really fortunate to have Robert Martin, who is the web development manager at the state of Rhode Island and a few other select advisory team members on their side to help be a really strong partner in pushing things through and making sure that we were maintaining momentum. Communication cadence. The same teams needed to be in lockstep. As I said, we are all experienced a lot of new information being disseminated to us. Things were changing on a daily basis. It was crucial that we were able to adapt pivot and ensure that this new platform will be able to support the information that we'd be communicating to our constituents so talking multiple, multiple times a week over the duration of this engagement. And then the final thing I would say is a really responsive and supportive aquia team, which we had the team team from aquia was a fantastic partner throughout the duration and build and continues to support our ongoing maintenance of the application. All right, next slide please. So, where do we net out. Well, we had some really good immediate results and this is an ongoing evolution of the experience there still I think we've got over 70 sites migrated so far there's still many more to come, but so far we've seen some really positive results coming out of this so immediately paid speed 300% improvements in page load times compared to the legacy systems site deployments new site deployments are achieving 96 to 99% lighthouse accessibility scores and performance scores consistent above 90%. This is huge. And one click deploys one click deployment, allowing us to launch in minutes. It's been really great. Okay, so next slide please care. Thank you. This is great system in place. How do we not repeat past mistakes. We don't want to go back to where we were before. And how do we avoid falling back into old habits. The first thing is ongoing performance maintenance, ongoing performance maintenance, and with aquia site factory, it makes it really easy because instead of having to worry about doing ongoing maintenance for the sites, the maintenance that we're doing for the umbrella site factory environment is able to disseminate those updates and proactive updates I should say across the entire network of sites. Isolated feature development, we want to make sure that anything we're developing is not having an impact on a broader part of site audience and we're testing thoroughly before anything rolls out. This is the balance of agency autonomy and guardrails. One of the really nice things about that design system. And what this was built upon is it allows a lot of these agency content admins to have the autonomy to run the agency sites the way that they need to update the content the way that they need to, but we have a level of confidence at an umbrella level that it's going to adhere to both our design standards, as well as our practice standards. It also goes hand in hand with the pointed training of key state content teams and is team members who provide a lot of support beyond some of the regular maintenance that we do over the course of of a monthly basis here at home. And then regular consultation from the equity team site factory, as well as equity services are constantly being upgraded new features are being added. And there's work being done on them, having a regular cadence with them ensures that we're one step ahead of any changes that are made. It can understand the impacts that it might have to the actual platform. So, without further ado, I'm going to pass it over to Ben Hamlin, who's going to walk you through a little bit more how we put this platform together. Awesome. Thanks, Jack. Appreciate that. Thanks Cara. Thanks everyone for joining this morning. I'm pretty excited to share kind of the under the hood here of how we, how we got this site out. So I wanted to start at a high level and just talk about what this life cycle looked like. I did want to know with with Jack's mention of the cohog that none were harmed during the development of this, this ecosystem so I just want to make sure everyone was was clear on that. So I want to highlight the phases that that we that we went through to execute this project. The first is discovery. And then we're going to talk about migration specifically since this was such a key element of of what was extended to the state and enabling them to to migrate sites in that phased fashion that Jack mentioned. We'll talk a little bit about launch, not as much as we typically do. We're still in maintenance, which I think is one of the most important phases. We're still in the maintenance phase. We continue to be here we go two years out. And of course that phase is typically the longest of any project and this is no exception. And what I want to focus on as we go through these. I want to focus on some of the key timing and the ordering of deliverables that enabled us to execute. So with the most efficiency, given the escalated timeline that was introduced back in the summer, when COVID first really reared, and we knew that we had to expedite this work. I want to highlight the technical approaches that we took for maintaining this distribution. It's different than a typical Drupal maintenance project, given that we are dealing with the volume of sites and the ecosystem that site factory provides. And then I also want to focus around the decisions that were made that allowed us to extend some level of independence to not only the state itself, but also to the individual agencies. Next slide please. Discovery started actually really early with this project. If I recall anecdotally I think that this was kind of, this was an idea that had been floating around in a few folks heads for a number of years. And the thought of solving this, this sprawl problem with a Drupal distribution had kind of been fermenting for quite some time. The discovery phase, you know, was was fairly extended. But as we got closer to development, the key elements of discovery that started to happen. I really wanted to highlight here. I think this is really relevant for folks. You know, to be frank, those of you who are evaluating a new build a new approach are kind of in your own discovery phase right now and this is part of that. The key elements and the key milestones here for our discovery phase was that we began interviews and content modeling workshops with key stakeholders. As you can imagine, across this large sampling of agencies, we needed to find common ground for for what the content types in this Drupal nine build we're going to be. So we needed to find that commonality. We also needed to talk about flexible content. We wanted to extend the most flexible page editing system that we could knowing all of the use cases that we had to cover across all of these these content needs of the of these agencies. Of course, we had to identify a core feature set. You know, some examples include site search ability to execute translations, and as well as content moderation. We needed again to align on what those features are going to be. So, you know, over the course of discovery as we got closer to development, what these efforts produced was a final content model. A final site architecture, as well as a build approach with with how the development team was going to be able to execute on these features. So this is really key here this last point, the early sign off that we received on these items. It allowed for the initial site configuration to commence very early in the project lifecycle slide please. Thanks. So I'm going to talk about design and configuration in parallel. And that's because that's how these phases were executed. That happened in a traditional software development cycle. But it did here. And again, I want to highlight the fact that we had a content model that was approved that we could design towards and also build towards. And the beauty of that, that content model is that we can execute on some basic site configuration, while the designs are being finalized and being approved. And the development team doesn't even need to be aware of the designs, since we know what we're building. So the design itself. So we're using a custom Drupal distribution. But it stood up alongside of an atomic design system. And Jack mentioned earlier that's pattern lab. The pattern lab has a twig template renderer which essentially essentially generates the template files that we use in a Drupal system. And it's interesting to note that actually, since we began the project the pattern lab, twig template renderer is actually not being maintained anymore. However, we are able to migrate to alternatives such as storybook. There's other design systems that exist that would allow us to migrate away from pattern lab without having to impact the primary Drupal distribution. So the fact that we chose pattern lab in a non Drupal system to execute these designs in this was important. This allowed the designers and the UX team to work outside of Drupal. And again in parallel with the development team. So those tracks could continue at the same time. Designs were approved. And once designs were approved the component markup was actually developed and tested. So all the accessibility all the performance tests and QA that we needed to perform on these designs. Again done outside of Drupal at the same time that we were developing kind of the framework for the Drupal distribution itself. The final result of this phase from the design standpoint, produce twig templates that were Drupal theme ready. Another important note, the components from the design system that were generated. Again they're not Drupal specific they can actually be used and applied in some other web framework. So they can be used outside of Drupal, including standalone, and they can be used to demo just the themes themselves. So while this is all happening. I wanted to talk about the configuration that was happening from the development team side. And we're starting to develop a custom Drupal installation profile that includes your standard custom modules developing the custom theme, as well as custom features which I'll get to a little more in a little bit. We started implementing the shared content types that had been derived from the content model, as well as the flexible content components that were identified. And we implemented those using a combination of paragraphs and layout builder. We started executing on shared site configuration so some examples of these are SEO elements such as meta tags, URL aliases, XML site maps. We started working on the menu system. We started working on custom theme settings to allow for the selection of those different color palettes that Jack mentioned earlier. And other core Drupal elements such as user roles. So we call out here for this, for this build, and how it differs from a traditional Drupal build. We can't rely on Drupal 9's config management system, the way that we came with a single site. So in order to execute updates and other shared configuration updates as we're maintaining this system, we have to use a combination of Drupal features as well as update hooks. And again, what that allows us to do is maintain the core site configuration, search, user roles, etc., while also allowing autonomy for the individual sites. So for example, some sites could introduce a custom view or implement a feed from an RSS, from an RSS source, and we don't want to clobber those things when we're applying security updates and general maintenance. So that was the strategy we used. So we're not using a standard config import and export as you would in a single site. All right, we can go to the next slide please. Ah, so development. All right, this is my slide. This is where I'm most comfortable. So I'm just going to go through some of the key components that we integrated for the suite of sites. And of course, there's a lot going on here, but the first call it is the actual integration of the design components with the custom theme. Once the designs were finalized, we were unblocked from that standpoint. And that's when we really started to be able to marry the Drupal theme and the pattern lab work that had been done and start to see that work come together. We implemented an SSO single sign on solution as integrated with the state's Azure instance. So this allowed the state team to continue their access access management control outside of Drupal, essentially maintaining the status quo that existed. Users are assigned to one or more sites in the network. And then the roles for those users can vary across sites. So the actual role assignment is still managed within Drupal by that particular site admin is administrator. But again, it allows the authentication piece to live outside of Drupal and be managed by the state in one place since they're, you know, authenticating other sources besides this distribution. We had to do some custom development within Site Factory itself. Site Factory provides a series of hooks and other automatic code execution that facilitates the maintenance and the upgrades of this group of sites all at once. So we've talked about the dashboard and single, single click site creation. We also have the ability to stage sites down one or more from production to do testing and QA. Again, we're writing update hooks and we're using feature imports to allow for global site configuration to be updated while the existing site config anything that's unique that's been introduced is unaffected. We also developed an automated backup script and that executes prior to every deployment that we do on this and this environment so that we ensure we have database and file backups in case we need them. And that was done using the Acquia Cloud API. Another key feature of all these sites is global site search. So that was integrated with Acquia Solar Search on top of Site Factory. It's using Acquia Connector and Acquia Search. And each site connects automatically as soon as it's spun up to its own unique solar index. So right out of the box, as soon as you spin up a site, you've got enabled solar search and it's all pre-configured and ready to start indexing content. Translations. We provided two translation options here. Drupal Core, so multilingual out of the box with Drupal. It's more of a manual effort, as I'm sure some of you are aware. But we're not restricting languages, whatever languages need to be added and enabled can be done. I've seen example of that on the COVID site. I think it has the most enabled languages of all the sites that have been deployed. And those new enabled languages automatically show up. There's no additional development that has to happen. The site administrators just have to enable the languages. The second option for translations was a simple Google translate integration. It's more of an automated but still configurable option to allow the site admins to control which languages are available. Content moderation workflows. So, you know, almost all of the agencies had some sort of requirement for content moderation. So we simply established a standard editor publisher set of roles. All the default content types are opted in when the site is spun up. Key here, we're not forcing this on agencies, right? It's not a requirement for a smaller agency that only have a few folks writing content. They can bypass that system easily just by assigning the publisher role to all their content editors and then essentially the workflow is moved. This also provides a content moderation dashboard and email notifications for those users. The content syndication API, this was alluded to a few times about the need to disseminate information across this vast network of sites quickly, efficiently. And so we developed the custom content syndication API to fulfill this need. We leveraged Drupal's core JSON API as well as the QAPI and developed some custom modules for publisher and recipients. And that facilitated two-way content syndication for all the sites on this network. And it's, you know, the basic use case post a notification to the main hub site. And that notification is queued up and delivered to all of the sites that have subscribed. That's running on Cron. So it's not immediate, but it can be initiated immediately if the need did arise. And then with the edge layer CDN in front of everything, the ability to clear caches across all these domains, you know, in the scenario where we did need to publish that content immediately. And we can't talk about a Drupal build without talking about the web forms module. It's still in contra, but boy, I don't think that's going to last. Maybe I'm wrong. So we did include web forms in this build for obvious reasons, provides web forms by default. We use the web form node module to automatically create pages for each new form that was that's built within a site. And then we provided integration with the web form encrypt module. Again, that's an opt-in. It's not a requirement, but web form encrypt is available for those sites that want it or that perhaps need it as well. All right. Time check here. Good. All right. Next slide, please. All right, migrations. We needed migrations to be usable by non-developers. We needed them to be repeatable because that first pass isn't always exactly what you were looking at, looking for. We developed a well-documented process that includes training and post-migration quality assurance using some automated tools to ensure pages were brought in, ensure that redirects were brought in. So that was a really key part of this process. This enabled the content teams to execute migrations independently without developer support. The process under the hood, it's essentially it's scraping sites. It's scraping HTML and files from the source site using a combination of Drupal core and contributed migration modules along with some custom code. And again, this is really key. This is source site technology agnostic. This scraping process, as long as the pages can be loaded, this migration process will work. And again, it creates automatic redirects during the migration process for both pages and files. And then in an individual migration instance, the completed migration is handed off to the state agency and they can perform final approval and any additional content entry or massaging that they need. And next slide, please, Kara. All right. We built this thing. And now we're going to launch sites. Typically, this is a big day for the dev team. But within this ecosystem, we're not really needed. And dozens of sites have launched on this platform unbeknownst to us. And that's the way we would like it. Using Acre Cloud Edge, of course, DNS control, the state, it's at the state's discretion when they launch these sites and when they go live to the general public. And then we'll talk maintenance. Again, we're still in the maintenance phase. These things are still happening and continue to ongoing Drupal core and contributed updates. When we first launched, I believe we're on Drupal 9.0. And we're up to 9.5. We're starting to plan what this year looks like with a migration to Drupal 10. Of course, as with any maintenance days, we're adding features, executing bug fixes, as well as platform updates. Recently a PHP update. And Acre updated their MariaDB instances. So kind of those standard things that are happening with any Drupal maintenance phase. Again, just to drive this home, all of these updates are executed within one Drupal profile, one distribution, one code base. Update hooks and feature reverts are triggered during each deployment. And that ensures that the configuration that we're relying on is maintained. Right now, statistically, we're averaging two deployments a month. So here's here's my big bullet. This is my big closing slide. There's over 100 sites on this platform now we talked about the 99 but there's a lot of demo sites, there's documentation sites, there's training, etc. So there's over 100 sites. They're all updated simultaneously. And that deployment window takes two to four hours. So our average maintenance two to four hours 26 times a year over with over 100 sites is where we net it out. Thanks. I'm going to pass it back to Kara so that she can discuss some other benefits of Acre products that were used by the state. Awesome. Thank you, Ben. So, as he said, awkward solutions offered a variety of benefits to the state of Rhode Island. I'm going to start. Oh, better hit next slide. Sorry about that. There we go. I'm going to start with awkward site factory, explain a little bit about it, and then dive into the benefits of edge security and edge CDN. So again, some of the benefits that awkward site factory provides is that you can launch websites faster. You can quickly create those sites with a single click and then get them launched faster than ever before. There's also governance. You can assign user based roles and permissions so that teams have to access only their responsibility so you're not overextending permissions to anybody throughout the team. And then last but certainly not least of the benefits that I'm going to cover today is that reduction in maintenance costs with one central dashboard to view monitor and manage everything in one place that maintenance really becomes less so you can save money there and those maintenance costs. So then diving into edge security, the main benefit that our edge security offers is minimizing the risk of security incidents. You can see threads ahead of time. You can protect your sites and prevent attacks and more with the variety of solutions that edge security offers. And then last but not least we have our edge CDN. It has create you can create operational efficiencies you can route content through the best available pass speed up app delivery and ensure availability and even more with creating those operational efficiencies and then monitor website effect effectiveness with this you can cut low times up to 50% for static and dynamic content and much much more when it comes to the websites effectiveness and you can see how well it is performing on the back end with it. So with that those are the benefits that the awkward solutions can provide a little bit of more of a high level and then Jack and Ben both covered the benefits that are provided in a very more specific case study with the state of Rhode Island and it's always great to hear about those. I'll pass it off to you to kick off Q&A. Thank you, Jack, Ben and Cara. So we do have a few minutes left and would like to take this time to answer any outstanding questions. All right. So we have our first question here with 99 agencies platforms. How did you get design system buying across all stakeholders. I can take a first pass at that. I think Jack can chime in too. I think the two things I wanted to call up from a development perspective were the flexible component options. There were a couple of dozen I'd say around, you know, 20 to 30 components options, everything from inline image galleries to press release snippets news articles. I mean, there was, you know, a really vast options that for the content administrators. And so that flexibility really allowed us to cover a lot of the content use cases that had come up in discovery. So I think that's a that's a really big piece of that. Yeah, I would I would say the latter on top of what Ben said. Another piece of that was design is always a very, very subjective discussion. A lot of people have a lot of different preferences when it comes to what their design tastes are. So I think what made this really effective was keeping it very simple, but professional clean really helped buy in across across the board. I think some of those. You know, I spoke about it earlier but the idea of a design budget. Design budget kind of limits the amount of what we can do. And actually creates a really nice challenge for us to create a really phenomenal experience within that budget, but not overdo it with a lot of more. We call them like bloat assets that can be added to design with photography and animations and other things that well night and while might provide I think some nice visual appeal is not necessarily contributing to the function and features of the website. Yeah, and just one other thing to call out there and Jack mentioned at the beginning of his slides that the key partnerships that we developed with the agency. I know that personally as lead developer. You know, I wasn't in a lot of design conversations I didn't need to be the state and the project leads really took ownership of those conversations. They really made those amongst themselves, which is always ideal from the development side that that we can come come to a come to a final decision and see something that is ready to act upon. Instead of being iterated upon. I have another question in the Q amp a pod does also build components template, etc, and site studio or only and twig dash pattern lab or storybook. I know, although I myself am not currently working on this. We have a group of engineers that are working on an internal initiative to develop a component library. They're working in both react as well as in twig. And I know storybook has been has been surfaced a lot recently, at least in two separate projects that I've been working on. So I think the short answer Tyler to your question is yes, we do. And that is actively happening. Julia is it okay if I ask her a question. Absolutely take it away. Awesome. Kara, I have a question for you. What are some of the trends you're seeing with clients in the non government and public sector space that are doing their homework but are coming over to state and local gov. Yeah, I think one trend that I'm seeing today was actually shown in the case study of state of Rhode Island and this is a trend for everybody. Organizations are looking to streamline their site creation and the management of that and it's just a really big trend. We have lots of case studies on a variety of organizations across a number of different industries on our aquia case study resource page. And it just shows within those case studies that organizations want to quickly create new sites while allowing their teams to work on siloed from each other. So again, and at aquia we had a lot of our engage winners that were also highlighted doing this same type of transformation of being able to put all their sites in one place manage them from one place quickly spin them up and then giving their team the time to do the work that they need to without you know always relying on the developers to go in and spin up new sites. So, you're looking to see more stories that maybe aren't for state and local gov or maybe you want to read more about higher ed or retail we have a lot of this same trend in those case studies. Yeah, I've got another one for you as, as we were talking about plans for this year and getting prepared to migrate to Drupal 10. One of the, one of the thoughts that popped up was interested to know if there's anything. Anything in the pipeline for for site factory itself as an actual environment as we look at Drupal 10 and some of the new features that come out if something that we should be considering for for maintenance this year. In terms of updates to site factory for D 10 there are some things in the roadmap can't share those yet so we do have some things coming for site factory. But in terms of D 10 and working with aquia products you know all the aquia products were compatible with D 10 before D 10 launched back in December. And D 10 has lots of new innovations that people can take advantage of. There's a new front end theme all of arrow, and then there's also a new admin theme claro so admins can have a new theme to work in their starter kit theme generators. There's a streamlined core as some of those modules have been moved or depreciated and moved out of the core so D 10 has a lot of new aspects so if you haven't tried the new version of Drupal I would highly recommend testing it out or you know building one side on it or migrating one side and that's the good news about D 9 to D 10 the migration is super easy you can do it in five very simple steps. We have lots of resources on our website website outlined around if you want to read more about Drupal 10 in general and just find out more about those items that are outlined or if you want to read more on what that migration can look like. We also have blogs available on that and as well as support, if you want help with your D 9 to D 10 migration we're always happy to lend a hand. As I'm sure you guys are at oomph right. Yeah, I'm looking forward to, I'm looking forward to those the new features, the yet to be disclosed features. Thanks, appreciate it. I have a question for Jack or Ben if either of you want to answer. What additional trends are you guys seeing that might be relative to travel or transportation right now. Yeah, it's a good question. And I think it's within the travel and transportation space I think what I'm going to talk about is maybe a little bit expanded beyond that and can be in government higher ed etc it's kind of across the board but I think, you know one of the things that wasn't necessarily the impetus for this trends trajectory, but more I think it gave it a shot in the arm was when the pandemic hit the need to communicate to a much broader audience more quickly than I think we, we would have done in the past and I think that it goes back to one of the things I talked about earlier which was both an increased in height and level of translation needed, as well as an increased level of accessibility options. And as I said, the pandemic didn't start this trend, this has been a trend for a long time, but I think it really increased the need for it. And I think about, if I working back to maybe some of the projects and engagements that we've done in the past. There was always that kind of phase rollout approach where it was, let's get an English version of the site up and then let's maybe do a trickle campaign of next translation will be Spanish than something else than something else than something else and having these things right off the bat. It really broadens, and obviously it needs to be based upon data in your user base and all that other jazz but I think having more of those options available upfront makes you a much more sought after entity and platform right out of the gate versus a slow rollout of, basically opening the door to it to a broader audience group. Yeah. Absolutely. I think we're getting close on time. So I think Julia will pass it back to you. Awesome. Thanks team. All right. So thank you, Jack, Dan and Cara for your presentation. I would also like to thank all of you for joining us today. We hope that you found this webinar was informative and helpful to you and your organization. Thank you again for attending and have a great day.


Are you ready to embark on an epic adventure of a wish that an alien spaceship would just come down and scoop you away from this honestly disappointing planet? Victory's greater than death is the story of a girl named Tina who is secretly an alien, and she and her best friends have to leave Earth and go out into the galaxy. With romance and epic battles and people asking for consent before they touch each other and people getting each other's pronouns right, and did I mention romance and epic battles? And stopping fascism with your best friends.


This April, the Marine Corps and the DOD observe Sexual Assault Awareness and Prevention Month with the theme, Eliminate Sexual Assault. Know your part, do your part. When I look at our SAPRA program in operation across the Marine Corps, I'm pleased to recognize the excellence of our military and civilian personnel who all have a part in preventing and responding to sexual assault. Our commanders, our SARCs, UVAs and victim advocates, our medical providers and counselors, our investigative agencies, our victims' legal counsel and judge advocates, all of these Marines and civilians serve their role honorably and with dedication. But the SAPRA program doesn't end with them. You also have a part in eliminating sexual assault. First, Marines have the moral compass and courage to do the right thing. We do not take advantage of each other or precarious situations. If we see suspicious or criminal behavior, we report it. Second, Marines step up and step in when they see a situation that could lead to a sexual assault. We look out for each other. We don't look away if someone needs help or if something feels not quite right. Third, Marines always remain faithful to each other and our core values. We do not tolerate retaliation of any kind. If a Marine has come forward to report a sexual assault, we continue to treat that person with the dignity and respect that all Marines deserve. On this last day of April, sexual assault awareness and prevention month is coming to an end. But our duty to prevent and respond to this crime lasts all year long. We've made much progress, but we still have much to do. All Marines must do their part. Only together can we win this battle against sexual assault. Semper Fidelis.


Yeah, so I was saying I'm the one between the end of the event and the beer And I'm as as you probably very tired by the event because there have been a lot of sessions. So My goal here is to make a point around the redfish standard and how many of you have heard about redfish using it Okay, great. So my name is Bruno Konek. I'm working for a hardware manufacturer company Which I will not necessarily name here because I'm on my own for the travel. So you will guess during the slide I've been involved in various open source projects in the last 25 years And I'm interested in redfish around the Python project that we have been doing in a small team of people First I would like to just to remind some definitions around what what we are dealing with so Everybody's aware of what a rest API is Yes, okay An API is clear It could be it could not be just rest. It could be politics. It could be X window It could be whatever library defines an interface between two environments Cheson is clear for everybody as well, I guess Stricted format great Oh data Okay, so this is something Microsoft have come with as a protocol to enable the Creation and consumption of first API. I'm not a huge specialist of all data But it's used in combination with the rest of the other three protocols to create redfish so redfish is another not an industry standard which is Providing specifications schema and a set of tools these days To help you with regards to server where machine management, I would say It started on the server side and the goal is to if you are familiar with the notion of BMC so an on-board Chip on the on your machine, which allows you to do which is completely separated from your operating system your pattern environment which gives you access through Syria through a Network port to another operating system running there and giving you information and Ways to manage your server out of band So this is what the BMC is doing and having a lot of startups in the past to try to help you manage at scale fleet of servers and Typically you use to to have something called a smash for example Which was a command line interface tool created by the DMTF the same guy who are creating redfish and redfish is Is there because smash did not really succeed with aware of smash in the room Okay one Was used smash in the room, okay, so that's why So it was pretty complex. It was really not standardized across vendors So it was really difficult to to deal with and you have you had to learn a new a new interface each time You were changing from hardware manufacturer, which was not really nice So that's not one of the goal for a fish redfish is really there to help different manufacturers to agree on hardware representation of your machine and An API Sustaining that hardware representation so that you can have access to the same Hardware components in different manufacturer of servers the same way So it's using as we were mentioning earlier, it's a restful API It's based on on jason and it's also using OData for some representation The goal is to have a much better hardware support that what was provided before so the ancestor I would say Fred fish was IPMI Which had a certain number of drawbacks? Especially it was not really secure. It was pretty cumbersome to use and it did not provide a lot of Hardware information on complex hardware setup complex hardware setup could be Blade system with chassis where you want to have address Do you want to address multiple servers inside a single enclosure having a single management interface or? Multinode platforms so one manufacturer and I know of which is HPE has a machine called moonshot in which you have Cartridges which can have embedded Management board as well as a chassis management board and each cartridge can have multiple CPUs multiple systems on it. So The rate fish standard was created to support all type of hardware design Not just a standard server to processors RAM memory disk Nick etc etc The goal is really to be able to have a model which is suitable for more complex platform And you may know that some manufacturers are working on memory-centric type of computing these days And we will have in a couple of years. We will have machines which will be made of pool of memory somewhere Pool of compute in other places CPUs Different type of CPUs and very high speed interconnect between the CPUs and the memories and and the disks if there are disks or Yeah, pull of large very large full of memories And so the right fish standard should be able to support those new type of design of Systems that will happen in the coming years. So it really has been architected that way Of course when you gather I Don't know ten different hardware manufacturers around the table and you say to them, okay Let's talk and make a standard It's pretty difficult to each one wants to have the best support for his own hardware many hardware servers hardware platforms, so the standard evolved slowly because They really agreed on a subset Which was pretty small at the start of certain a certain number of features that you have in a machine and everybody was in agreement on How those features should be described and should be accessed and as time passes They were adding more and more features so that more complex architecture were recognized and In common between different manufacturers. However, you always have some So so the marketing departments in in our Company calls that added value and sometimes you can call that crap, but it depends on the on your point of view But anyway A lot of hardware manufacturer have some features that are not standardized because it's something which differentiates them from another Hardware manufacturer, but they still want to be able to access to it So the best example in history is probably SNMP SNMP was working like that You had the standard me and you had public information with the OIDs and you were able to access To to certain number of information completely in a standard way from one manufacturer to another But for example our fans in our servers were accessed in what we call a private me So we had a sub number under which all the tree was our property our Yeah, IP and was described and you give access to the people to the information with that information For the fan was different from a server from Dell a server from Lenovo server from someone else Huawei or whatever so Really redfish had to propose the same type of mechanism and they created the notion of OEM schema to be able for manufacturer to store Some information that all their own information that they are not in agreement to standardize yet either because not all the manufacturer has the same Feature and so the other don't want to expose in a standard something they don't have because that would them at a disadvantage Or because it's something that the other don't have have not developed or not interested in and you want to keep it on your side So hopefully after the first time there will be a redfish Redfish page because I was supposed to make that slide based on Wikipedia as the previous page because I think it's a very good source of Information but there is no Wikipedia page for redfish yet So I've written what I had in mind on one template and I will propose that When I'm in the train back to to my country and hopefully next week We will have a redfish page which will explain a bit what I explained to you here So the standard is not completely new it's four years old standard Which has been published originally So mostly what you had were the JSON and the OData schemas to describe the resources Which are available and a very light mock-up was was made to a little developer to test redfish even if they didn't had access to A hardware supported redfish implementation Because when we started the standard was there But there were very few hardware manufacturers who had added that feature in their BMC Nowadays, it's very different. There are a lot of Manufacturer who were which are providing support for the redfish with minimum firmware version depending on the manufacturers I Put here some of the major one In terms of numbers of server souls Feel free to so I also put that in the wiki page wiki pay their page Feel free to add when if you're dealing with the manufacturer, you know that it's supporting redfish Feel free to add to the information So you have mock-ups you have real hardware you can play with it that's pretty interesting a lot of Documentation has been published as well as when paper facts, etc on this URL So the dmtf.org website under the standards are standards area So I have a redfish and three point in which you will find all this information and you can download all that so latest version is 2018.3 which has been published in 2019. Don't ask me why it's not on 19.1. I don't know That's the way it is So I have been I think seven or eight revision of the standard still Since the beginning You have released notes which each time described what has been Changed between the latest version of the standard and the newer version of the standard Since the 1.0 version originally It's mostly addition so has not been any big change in the way the standard has been has been designed Compared to 0.99 where it was a bit different Okay, so what can you do with redfish? So typically you can do what you do with a PMI historically So you can have a lot of information about server health temperature fans identification asset info information typically an inventory on On the hardware platform as much as your BMC is able to provide to you There are about something like 400 items that you can get and Among those 400 items 25% or items you can modify through redfish as well because you have the you use the The rest API interface so you can get information, but you can also post information to the redfish API and have Configuration items modified on the fly You also have actions that you can pass on the server around power management around the boot order around some thresholds for the power around alerting and logs and You can also deal with the BMC itself with its network settings and the user accounts For authentication on on the system through the BMC So DMTF is providing quite a large set of tools to to deal with As examples, I would say on how to deal with the redfish interface so that we can take that software as a reference point and Include that either in your program and programming environments. So mostly what they are providing is C bindings and Python bindings There are some CLI tools and there are More and more tools available. Not all of them are working for all of the redfish implementation So I don't take Parts here, but I'm trying to make some of those tools work on my HPE reference hardware And as souls have been developed by they'll sometimes there are some differences in the way you interact with redfish And especially the setup the access to the sash redfish that v1 interface is a bit different But globally once you have passed that hurdle the rest is working really really fine So you have the possibility to do simulators you can for example if you have a real hardware server You can capture the redfish implementation of that server and put it in a simulator and then run it as a software Appliance, so it's pretty interesting if you want to do tests without having access to the hardware Which is also nice when we were speaking about kernel CI and the possibility to do automatic testing That's one of the feature which is pretty interesting What else so Personally with a group of people we started the python right fish initiative I have another slide on that a couple of years ago. I've been ill last year, so I've not been able to work on it I hopefully I will restart that This year the oven stack guy didn't want to wait till we fix some of the issues He identified so they created another python library called sushi There is also another python library in the end on the redfish DMTF So everybody is in love with pythons these days. I'm missing my pearl bindings That's why there is a comma here and I need to do something for that But there is no reason but it's just rest API so it's easy to do bindings in other languages That's such as go or or pearl whatever language you like The only major application which has yet Already a redfish driver as probably the open sack ironic bad metal deployment project I don't know of any other tool which has integrated a redfish support to do to medic inventory or Automatic deployment for example based on the type of systems that you could have you can have a lot of ideas Using this type of tools. I will we're going to it So the data model looks like this one, but I won't pass too much time on it What I will do is more go on to directly the The life one There with me once again So I will just explore the mock-up for a simple rack mounted server. So this is on the DMTF directly the DMTF website. They are Not on swing very quickly So they provide a certain number of of mock-up for a simple rack mounted servers or OCP machines they have blade systems Okay Interesting and so when you explore the the data model it looks like that So you have your entry points which are so these are the old data stuff I don't know why we are in need. I need to discuss with the guy because I don't really understand why we are in need of that instead of just plain jason and You can have fields Directly and you can have of course collections Available so Here we have a single system, but you can have the notion of chassis So for example if you go on the on the blade here You would have more stuff you have the manager which corresponds to the BMC So for example, if you look at the manager, you have just one BMC on the server And if you go on the on the BMC, so this is this one is not a real Physical server is just a fact one To show what type of fields you can get And and you will see that you have for example the nick itself of the BMC that you can query and Finally when you have passed the tree enough you can find the MAC addresses for example of the BMC So if you want to do the GP configuration so not for the BMC because you need to have access to the big see first So that's not really the most useful part But if you go on the on the system side, of course, and you have just one system You will find exactly the same type of information For is a for the embedded mix inside the system. So for example, you see you have a TPM 1.2 Component inside that servers you have a certain number of information on the on the naming on the asset number on the BIOS version which can Help you derive an upgrade strategy if you have a fleet of servers and you want all the server to have the same firmware version that's the type of stuff you can do with it and Again, you can pass the BIOS processors memory Internet interfaces so here I have two nicks in my server and again. I have my MAC addresses IP addresses here in that case So the MAC address a hardware MAC address so you can have a Effect MAC address you can have a physical one and you can override the physical one by another one if you want so Here is the way to to pass the information and all that is accessible through the rest API. So here's it's just a nice looking Visualization system for it. Okay, let me just go back so For those of you who are a fan of of pythons there is a source a work we've done around python redfish with a couple of people initially around the open stack we use a python request tortilla to map in fact the Data model of redfish in in memory and being able to pass it very very easily Our goal and that's still a work in progress. We have a markup for that, but that's it would require a bit more development The interest for me of redfish is really around Activities so I'm part of solution center. We host 400 servers. We do models for different type of customers and we are Rebuilding the data center all the time we move servers We move parts in the servers because we have to build something which correspond to the customer request and the idea is to say Okay, how can we automate the management of those changes in relationship with our CMDB? So we have a CMDB but each time you change a RAM from one server to another your CMDB is wrong except if you do Manually the operation inside the CMDB, which is very time-consuming a stupid job so The idea is to really use while it's not stupid for some people doing it But it's it's you can use your time in a better way and drink beer that starts them for example But so the idea is really to say okay if I could claim a higher hardware platform So that this part of the inventory is always up to date and pushed into my CMDB that would be great So what we want to do is have a data model of four hours servers in the data center Which are looking like the redfish one because you don't want to reinvent anything And we want to map that data model to the CMDB data model we have and the CMDB We are using is an open-source one called itop and so the data model of item is a parameter So you can change the data model the way you want so we can very easily map the two data model and each time We modify something on the hardware side pull information through which redfish call into the CMDB and the CMDB is Working by Raising information which I've changed but keeping all the rest of the information which have not changed So it's pretty easy to use and that would allow us really to Improve the the times that the people pass on maintaining that CMDB and just maintain the information that only humans can maintain Not machines so that's one of the Area where redfish could be very useful in my opinion another area could be on the deployment So if there are redhead people in the room for anaconda for example on rail You could have a look at redfish to try to grab hardware information from the redfish schema and detect automatically a certain number of hardware informations that leads to Device names or hardware setups that could be easier to do Using redfish directly in a portable way in the interesting part is that you do the redfish call and whatever the nature of The server you get then normally you should have something which drives a decision which could be the same for all manufacturers So that's really the type of ideas you can have around that So if you want it's on pit if you want to look at it It's that's one version available. You can also look at the DMTF stuff as well I'm working on the mock-up to automate the test of our our client with regards to the DMTF mock-up so that it works correctly Any question? Yes, you're first Oh, sorry, CMDB is a configuration management database So this is a place where you are managing your assets in your in your IT infrastructure Which could be not just computers. It could be Copiers it could be phones. It could be buildings. It could be whatever you want in the CMDB We have you can also manage for example service level agreements providers Point of contact, etc And you can have a measure of impact for example Imagine you unplug a power cord in your data center because you need to do electrical maintenance on an area You can say okay. There's CMDB. Tell me if I unplug that.  So what will be the services at the end which are touched if I remove a plug on my on my wall So that's the type of service a good CMDB is able to to give to you and the more the CMDB is up to date The more precious it is for managing your environment and the more automation you can put in it The best is because if that information is correct. It's coming directly from the hardware You had one question. Yes. What about security? It means are very problematic if they put on public public The problem is you cannot you cannot expect You are expecting your client somebody who is bought that's not to put Okay, so with regards to security Customer should never put a BMC on the internet. That's clear Change customer I mean Now teach to your customer teach to your customers is really really a bad idea It will not improve with IoT devices which are also sometimes on the internet and all sort of BMC somewhere I understand the Redfish protocol is HTTPS So you need another authentication mechanism to be able to log on to the system So it's as secure as your authentication schema is So so from as you mentioned is is an update for example of that a version of BMC firmware and and that's true And and that's I mean the BMC is should be managed like a standard system So people should pass their updates on a regular base. They should automate that if possible They should I mean that's part of the CI environment for managing It's as an operating system. You are upgrading your operating system. You have a workflow You have a approval for a grade you have tests, etc You should do exactly the same for management of the BMC's on your servers because that's as critical as the rest Even if it's not on the internet Yeah, so comment is that There are problems with the Software implementation on BMC so the software stack use on BMC the fact that it becomes obsolete And the fact that it could be shared with as an first sneak of the server the access to the BMC I would say Make test with your hardware manufacturer before buying this hardware and Includes test on the BMC as part of your evaluation of the platform. There are good providers that don't do that anymore That may use to do that in the past, but don't do that anymore But I agree. It's I mean redfish has not a goal to solve those security issues per se It's a it's a way to do secure management because it's Inscripted and it has an authentication mechanism compared to IPMI which was really poor or SNMP Which has also a certain number of other problems. So it does not solve the The hangar in the world, but it sells some of the problem