 And good morning, everyone. I hope you've been enjoying the presentation so far. And as you just heard, my name's Michael Caddy, and I'm an engineer on the Service New South Wales website team. I'm going to talk to you a bit today about how we're using our Drupal site as a content store for a number of our product teams at Service New South Wales. And I've been at Service New South Wales now for a little bit over two years, and I've only been into the office a handful of times. Is anyone else in a similar situation or has a similar story? A few of us? Okay, that's good. I'm glad I'm not the only one. So to give you a bit of context about Service New South Wales and what we do and the environment that we operate in, I'll just tell you a little bit about us. And Service New South Wales' vision is to provide every person, business, and community with a world-class experience, accessing the services and support that they need from the New South Wales government. We are a one-stop shop for delivering services to customers, businesses, and our partner agencies. And our mission includes rapid product delivery for crisis response and recovery, including payments and economic stimulus. And across government we work with around 70 agencies to deliver approximately 1,300 services on behalf of our partners. And as of now, there are 113 service centres located across the state with 70 of those in regional New South Wales. And Service New South Wales is a single contact point for transport for New South Wales and births, deaths, and marriages transactions. And a transaction, as we call them, government services that can be accessed online over the phone or in person at a service centre. And it's where you go to book a driver's test, get a licence, renew your regio, register a birth, pay your fines. And not to mention everyone's favourite, applying for vouchers. So we had creative kids and active kids and you could also apply for Dine and Discover vouchers during the pandemic. And these transactions alone, they ensure a steady flow of traffic to the website from anywhere between four to seven million site visitors every month. And it wasn't so long ago that in New South Wales you needed to check in and check out of venues to assist with contact tracing and overseas and international visitors, sorry, overseas and interstate visitors. They could also do this via a website. And this slide might bring back a few memories for the New South Wales residents. And all of this means is that Service New South Wales is a recognised brand. It's something that most New South Wales residents are familiar with. And that carries a fair amount of responsibility for us and how we approach our work, what we prioritise and the care factor that we apply to every single line of code. So while some select transactions continue to require a visit to a service centre, many transactions have moved to online or are moving to online services or digital products. So you can do all of those things like renewing your driver's licence without any face-to-face interaction in a lot of cases. And I'm old enough to remember going to being forced to go to the RTA, waiting for what seemed like hours at your seat, waiting for your number to be called up to approach the desk. And thankfully that hasn't been the case for a long time now. And you only need to visit a service centre in some situations. In addition to being known for providing great customer service, Service New South Wales has delivered a reputation for being agile and responsive. And Service New South Wales has played a critical role in disaster response and recovery over the past few years. And for our current team, it started in September 2019 when we had bushfires, which carried through to March 2020 when COVID hit. We then had a mouse plague and when drought ended, floods began. So if we have an alien invasion next, we're going to be well prepared. However, in all seriousness, during COVID, our site traffic increased significantly and it doubled at times. And many residents relied on our website for critical information and support during this period. The digital services team at Service New South Wales has grown significantly over the past few years. And we work in multi-disciplinary teams where engineers or developers sit alongside designers and content designers and product managers. And there's a large number of technologies used across digital services and new applications are mainly written in React on the front end and Java in the back end. And for Service New South Wales, digital transformation is continuous. We're always looking at ways how we can improve. So you might be wondering where Drupal fits into all of this. And Drupal powers www.service.nsw.gov.au. And it serves as a front door for all of the services that are offered, be it online or via digital kiosks in our service centres. The website's also used for frontline staff to assist customers with transactions and for information. And the team's been using Drupal since the Service New South Wales website was launched in 2013, which was on Drupal 7. We've since moved to Drupal 8 and now we're running Drupal 9. The website's part of Service New South Wales's omnichannel approach that gives customers access to services 24-7. And it's critical to the functioning of the agency. It's the glue that holds everything together. And our site consists of various content types that perform specific functions such as content pages, campaigns and guides and many more. And the wide range of products at Service New South Wales, they're not siloed and they don't exist independently. They utilise shared functionality such as proof of identity and authentication through the My Service New South Wales account. They also share common components and many are built using a gel, a gel framework, a global experience language. And Microservices Architecture is baked into the DNA of the organisation. Product teams are very used to creating APIs and calling APIs and that's very much second nature. And all of these apps or products, they need to move quickly in responding to rapidly changing customer and stakeholder needs. And Drupal is the only customer-facing enterprise-grade CMS at Service New South Wales. So as such, other product teams have been encouraged to leverage off the CMS capabilities that Drupal offers, particularly the ability to store content reliably and retrieve it via an API, which I'm hoping this slide here demonstrates. The website team is responsible for running the public website, which is a heavily customised Drupal 9 site. I would describe it as hybrid Drupal, and I also heard the term yesterday partially decoupled. And we're using decoupled elements through the site, such as the store locator, which you can see on this slide. That's an embedded React app that pulls in store entities via JSON API. And the team is multi-disciplinary and in the development team sits alongside a content design team and a product design team. The website carries a heavy content design workload and the content designers work hard to keep the site at a lean 3,900 published pages. And over the past 12 months, the team has averaged 1,830 page edits with 1,070 block edits, so that's every month. And to put that into perspective, that's roughly a change every five minutes. And the team's also archived 507 pages. So considering our site is transactional and barely contains any imagery, that editing effort ensures that our content is kept current, accurate, and up-to-date. So how can Drupal be used to benefit the other product teams in the organisation? And as Service New South Wales expands its functionality, its capability and scalability to deliver new services and content as we saw as seen during the various statewide emergencies, such as bushfires and pandemics, the agency needs to be able to deliver new services quickly. And it's envisaged that having content stored in a CMS, it allows for rapid delivery of content to any device and dramatically reduces the time to market. And for almost all product teams at Service New South Wales, any change requires a deployment. And the lead time for getting these approved via the change approval board, it can be as much as three days, unless it's an emergency change request. Some product teams have fixed release schedules, so out-of-cycle deployments need direct level approval to proceed. And deployments also need to happen after hours, unless it's urgent. So it's often after 10pm or could be midnight for really high volume transactions. So deployments, there's a lot of process involved and they can be resourced and they incur a cost as overtime needs to be involved is incurred. And other product teams might need to be brought in for other rounds of testing if there's shared components or other integration. So for simple changes where it might just be a small text change, this sort of deployment process, it can be overkill. So some typical use cases for using the CMS for other product teams. It might be for text snippets such as terms and conditions block or for error messages. It might be for form control elements or for graphics or icons. And team storing content in Drupal, they get all the benefits of a CMS, such as scheduling content to be published or archived at certain times. They get revisions, so changes can be tracked over time. And often content is entered using a rich text editor. So changes can be made by non-developers outside of release windows. So how we manage all of this content is with the micro content module. And the micro content module is a lightweight contributed module that was developed by Lee Rowlands for one of previous next clients. The code is of high quality, so it's very stable. There are lots of automated tests. So we can have a lot of confidence in using this module. The issue queue is actively monitored by the maintainers, most of whom are here this week at the conference or presenting later today. And micro content allows you to create micro content types or bundles. So you can add your own fields and it allows the creation of custom content models. Micro content is revisionable, so changes can be tracked over time. And micro content entities, they're like nodes in many ways. However they have separate permissions that you can assign to different roles. Micro content is also a good choice for content rendered outside of your main Drupal website as there are no canonical routes. So you can rest easy that when you publish a piece of micro content it's not going to appear accidentally on a website page. And the other big benefit is that micro content appears separately in the administration area of your site. So you can see on this slide here how micro content is petitioned off from your main site's content listing. And this ensures that there's no cross-contamination of regular site content and content used for an external purpose or not being rendered on your Drupal website. So there's no confusion for content editors and the risk of content being accidentally deleted is virtually zero. And as the last screenshot showed you might have seen that the information architecture for our website editors is fairly detailed. Which is fine for our team as they're experienced content designers and they know where everything is. But for other teams, other product teams that only need access to the micro content part of the CMS that view could be a bit overwhelming. So to improve the editor experience of these other teams by simplifying the admin view we've created specific user roles that only have access to certain parts of the CMS. The two new roles we've created are an API editor role and an API publisher role. And editors can only make changes whilst publishers can make changes as well as publish those changes that editors make as well as they make on their own. And we're using a layered permissions approach for these roles which makes them easier to manage as permissions aren't doubled up. So the API editor role contains the lion's share of permissions and that includes all the fundamentals like access to the administration pages access to the administration theme, access to the administration toolbar as well as all the micro content permissions such as access to the micro content dashboard and create micro content, edit micro content. Whereas the publisher role only has maybe a dozen or so permissions which relate to workflow transitions mainly. So this role is deliberately kept lightweight so it's easier to manage. And so here's a view the website team members see with the master publisher role as we call it where you can see how detailed our information architecture is. And this shows the scale and the volume of the types of content that we're managing at Service New South Wales. And just suppose that here's the view that API editors see when they log into the CMS in the administration area which you can see is a lot more streamlined. In addition to specific user roles we're also using a custom workflow and the workbench access module to further restrict what external team users or non-website team uses see what they see and what they can do in the CMS. So you can see here we have a separate workflow for micro content and a separate workflow gives us the flexibility to change workflow states and transitions without impacting the workflow that the site's main content is using so the main content editorial workflow. And it's also another control mechanism to preventing outside team users doing anything with the site's main content as the roles that those users are assigned they only have access to this micro content workflow and they only have transition permissions on that micro content workflow. We're also using the workbench access module to ensure different teams can only access their own content and not content from another team. So workbench access allows you to assign content to sections based on other taxonomies or menus and we're using a taxonomy called API project and this is a shared field that we've added to all of the micro content types as an entity reference field and this ensures that users that belong to team A can only see and edit content belonging to team A and users that belong to team B can only see and edit content that belongs or is marked as belonging to team B. Really important to write quality tests for any of your micro content and workflow configuration just so when you're introducing new features you're not causing any regression so you're alerted when any of your unit tests are failing through a continuous integration tool. We're really keen observers of a test-driven development approach so this is South Wales. And how are the teams fetching their content out of the CMS and they're using JSON API queries and we offer guidance to the other teams about how to best craft these queries as they can end up fairly complicated. They can also return a lot of stuff that might not be needed and so the use of filters is really important and we've created a number of computed fields in addition computed fields to make it easier for these other teams to traverse the API response as some of the entity reference fields can be nested a few levels deep in the API response. So computed fields are convenience fields that we've added to the entity code so a little bit more work on our part but they do help with overall performance. We're also using collections so collection is a micro content type we've created to group micro content items together so they can be retrieved in a single API call so we're not making separate calls to the API. And we also have to be mindful of caching with cloud CDNs such as CloudFront and also with the Drupal cache so have to ensure that we've got lots of test coverage to cover those scenarios. Now quickly to some real-world examples and the first example I've got is for the Service New South Wales for Business team which supports businesses for all stages of their journey and up here on the screen is the Booker call with the business concierge form and this is a React application and everything you can see that I've highlighted with boxes and arrows, they're micro content items that are being pulled in via JSON API including the drop-down items that appear... I don't know if you can see them but the help topics drop-down item, that's all micro content. So the React app then uses its logic to render those items into the correct location in the layout. This here is the collection data entry form where related content or related micro content items they're being grouped together and you can see here they're using entity reference field so it's a multi-cardinality entity reference field. And so here on the screen is the help topics drop-down list which you can see is just a very simple micro content text type and if the Service for New South Wales business team discover they need a new help topic they can do it very quickly without the need to go through that full development and deployment life cycle and it can be done by non-developers and that new feature can be up and live within minutes. The second example I've got is the new Savings Finder application which is another React app and this is a new build of an existing application that has an improved customer experience but this application is not live yet so you won't be able to browse to it and the Savings Finder helps customers find savings that they might not be aware of through a simple multi-step questionnaire and all of the form fields that I've highlighted on this slide with the boxes and arrows again they're coming from Drupal as micro content items and to reduce the load on the API we've similarly grouped these items together in a collection to group customer micro content types together and at the end of the process of the Savings Finder process you're presented with a list of service offerings that you might be eligible for such as vouchers or rebates and again I've tried to highlight on the slide what items are coming from micro content and that includes the icons that appear adjacent to the headings in those offering boxes as the Savings Finder application it was a specific use case we needed to develop custom micro content types to fit the required content model including this question type that I've got up on the screen now and that included a answer options field that was an entity reference to an answer option paragraph type and this is one of those examples where we needed to develop a computed field to surface the data attributes of that field cleanly in the API response just so it makes it a lot easier for the other team that's calling that API to traverse the response we also did a similar thing for the service category icon as well so what's next for us we have a few teams lining up to start using the CMS in this way such as the mobile app team and other grant related products we're continuing to monitor and review our approach just to ensure that the architecture and the solution is scalable and robust as the services that we add grow and so far we've had a few wins and the word is spreading and so far the results have been very positive just quickly, well I've got an audience so I'll be a bit cheeky and just mention that we're recruiting Drupal engineers at the moment so feel free to come and have a chat to me during one of the breaks you'll be helping deliver groundbreaking and innovative services to improve the lives of our 8 plus million customers quick reminder of the code sprint that's happening tomorrow and that brings me to the end