 here at Drupal South to spend some time with us. My name is Aaron Nicholl. I'm a product manager and the lead for Drupal managed services at Deloitte Digital in Australia. And I'm joined today by my friend and colleague, Chris Hopper, who's our lead technical developer on Drupal within Deloitte Digital. So firstly, before we get underway, I just want to say this is not the talk that you were expecting. But I don't want you to leave the room yet. So in the original one that went around, we were saying we're going to talk about web components. I will get on to that a little bit at the end because there is some interesting stuff that we're doing in that space. But I actually wanted to take the time to talk about the journey that we've been on with Drupal delivery and support. And it's been a journey over a number of years. And I think it'll be quite interesting to see some of the things we've been doing and the benefits that we've seen from those. And so we'll explore that today. So I just start with a little bit of an overview of Deloitte Digital. So this is just a bit of a graphic of where we sit. Deloitte Digital is obviously part of Deloitte, which is a global consulting firm. We sit within a consulting arm that has many other divisions around human capital, strategy, technology, cyber risk, actuaries, and consultants. And we're obviously the fun part, where the one's not wearing the suits around the office and then getting in the elevators with everyone else that wears suits. So it's a fun place to be. Obviously, we have offices around Australia. We're based in Melbourne. And that's where the managed services team lives for us. But we obviously have people in Sydney, New Zealand, Adelaide, and all sorts of places around Australia and the world. As an organization, we sit across the entire spectrum. And I think there's just a few examples of some of the other people that we maybe I would say compete against, but people in the industry that we work alongside. So I mean, up in the top corner, advertising agencies. So we even have an in-house advertising agency with some doing television commercials and so forth. But we go all the way through into build and run for digital solutions. And then within that, the team that I work with is focused on open source and obviously particularly Drupal. And we look after assets and managed services. So we'll get into what that means a little bit here. So I think a lot of people probably think of a normal digital project. There's obviously a phase up front for delivery, for the build, the project. And then there's usually the separation between the build and the run. So the managed services team on the end. And I've certainly experienced that. Plenty of places in the past, and I'm sure everyone else has experienced that, that often what you end up with as a managed service, the thing that you'll be supporting, is often something you don't really know about until it sort of lands in your lap and then you're left with something you need to support that maybe you don't really have a good sense of. And so what we do as a managed service team is try and flip that on its head a little bit. And so we're involved at the very early stages of a project. And even before the project starts, trying to build a stable platform. And then working with the project teams throughout to support high quality application development and then maintain the stability and evolve those platforms over time. And then look to the future. And we'll get to that a little bit towards the end. So just to frame this discussion. So I want to talk a little bit about the interface. So in previous times, obviously we had interactions with companies that were face to face, retail stores. We were either calling people up over the phone. There was many different touch points. And increasingly those touch points have all started to converge into digital interfaces. And these are just a few examples. But we're obviously familiar with a lot of digital interfaces in our lives. And increasingly that is what is handling that exchange between a customer and a company. And I guess because we've all been accustomed to these great experiences, we've had a very high expectation set for what great looks like. And that's no different for us as individuals or if we're inside a company and we're trying to actually achieve some kind of digital transformation of our own. And so when we work with companies, what we tend to find is that the expectation they set for what they're trying to achieve digitally is what they're used to in their own lives. So that level of experience that they're used to in their own lives. And a challenge with that is that sitting behind all of these experiences that we're used to is very complex, sophisticated technology, services, applications and tools. And often teams of potentially hundreds of people working on these things. And so we need to do a lot with a little. So what that generally means is that we end up with phased projects. And we'd all be familiar with these. We sort of segment out the delivery of what we're trying to achieve with the ultimate goal that if we go through all the phases, that eventually we'll get this amazing transformative things. But what we typically see is phase one is sort of setting those foundations. Phase two allows us to go and expand beyond that. And phase three is probably where we really want to get to. And this is practical. And it's sort of necessary that we do this. But the problem is that a lot changes over time. So between phase one and three, the world might change, digital technology changes, even the organizations that we work with will change and people will come and go. And so often maybe what was set out for that phase three, by the time we actually get to that, things have changed so much that achieving that original ambition, maybe it doesn't make sense anymore or it just doesn't happen. And so what we have been trying to do for quite some time is trying to accelerate that transformation. So how do we bring forward some of those things that we would expect from the later stages, those phases two and three? How do we bring that forward into phase one? And where we've really been trying to do that most is by looking at the acceleration that we can get in the early stages of a project. And obviously we're focused on Drupal. And so we've been spending a number of years now to look at what we can do to accelerate Drupal and try and get it out into those projects and start to accelerate what we do there. Now for our Drupal team, that means a few things. The first is it means curation. So for us we really need to curate a platform that we are comfortable with that does what we feel is necessary for an enterprise digital experience. We need to align our teams so that we're all delivering to that level of experience that we're looking for that we're all following the same practices and principles. And then we need to be consistent in how we develop and how we pull development back into the platform. So it's sort of a looping cycle for us. And so as I said, this has been something we've been on a journey for a number of years. And to tell you more about it, I'd like to invite Christopher to share some of the journey we've been on. And then I'll come back to talk about where we're going next. Thank you. No worries. Thank you. What we've been describing is trying to reach that nirvana that you all want to get to where we're all like running a nice platform where it's not monolithic, but it's lean that we can reduce reuse, reduce duplication, but do more reuse of things and provide some governance around the stuff that we're doing. So what we found at Deloitte, when we started down this path was we built this monolithic profile that had everything in it for the kitchen sink that we thought that projects and clients would want so that we could duplicate that into new projects as they came along and not have to redo those things again. But it ended up being quite large and we wanted to get it a lot leaner. And we wanted to remove the duplication so copying this, what we had was a big Drupal install profile that was being copied across from one place into the next. So it had originally been built around a local government type context and we wanted to take it forward into other industries and projects that we had. So we wanted to do that without duplication and we wanted to have some sort of governance around the modules and things that were being chosen because as we all know, developers come into projects or have their favorite sort of tool that they're working with, new things come along all the time. We wanted to sort of try and keep things stable and be able to provide a platform where if you went and worked on one project and went and worked on another, you'd have the same sort of tools there that you would have a similar sort of tool chain to work with but also content creation tools and all of the rest of it. So what we decided to do was move away from this monolithic duplicated install profile that we had and try to package up all of these features into packages using the tools that we have in open source. We know that as Drupal devs, there's a huge community out there who are contributing packages, modules that we all pull from day to day. Why don't we use that same architecture and infrastructure and the work that we're doing with each other just within this teams? So abstract away a lot of the client specific parts of our packages into configuration and then start to consume those and combine those in ways that make sense for different clients so that we may have some things that we've built in local government that make sense. We can take some of those that might make sense in a water utility and leave the things that are local government to one side but just bring the things that make sense in the new project. So how do we move away from that monolithic sort of thing to a lean, easily consumed, combined sort of architecture and then share and contribute with each other? So if you fix something in one place, how do you get those fixes and those improvements shared with everybody? So again, we've got that architecture built in to what we're using with the Drupal platform. So just finding a way to make use of those tools and share and contribute amongst each other. So how we started out with this was we created instead of a huge project that would be copied from one project to the next, we moved to a sort of a model that you're probably all quite familiar with which is like a Drupal Composer template. We used the Drupal Composer Drupal project as a base for this template. And then taking the packages where we'd packaged up features into little packages, we just stuck them in as Git repos as registries or repositories where each individual package had a line that pointed off to a Git repository. And then we went out into the community and saw some other tools. So we didn't want to be stuck on an island unto ourselves. We wanted to be able to pull from the best of things that were going out there in the world. So we ended up settling on using Acquia Bolt or BLT to provide a lot of the tool chains and stuff that would accelerate the setting up of projects but also testing and coding standards and just local VMs that you want to set up, recipes for integrations with SAML and so forth. And the Acquia Lightning profile we used to provide a lot of the base for workflows and content creation and creating like common things like landing pages and so forth and layouts. And we found that they were doing a similar thing to us in terms of packaging their features up into little packages. So that kind of aligned with what we were doing and that allowed us to then take those and configure them in the ways that made sense for our clients and our customers and for each other. So when we did all of that, what we found was that first of all, our developers seemed to get a sense of, I don't know, they were a lot happier, right? So everybody seemed to feel like they were contributing to the success of everybody else because often in project teams, you have project teams that are not always co-located. Also in the support of production systems, those aren't always the same people building new features but now everyone was happier. They felt like they were all on the same page working to a common goal. All of our service delivery managers and so forth, all of our clients seemed a lot happier. They were getting things a lot faster. They were getting things that were where we'd fixed something for one person. We were able to bring that fixed to another. So there was less duplication. There was a lot quicker to get to the end product that we wanted to get to with a lot less cost and a lot less effort. But we also ran into some issues. So we're all used to being package consumers rather than publishers. So we found that sometimes when we updated something, it broke somewhere else, which would make people quite frustrated. So you add a new feature into this package that we built and then when I pull the update into my other project over here, it suddenly, it breaks everything. So now there's this interdependency that was making people a little bit confused about how to move forward. So that introduced a little bit of upset amongst the teams and we wanted to sort of work out, how do we keep all the good things and move forward and sort of get rid of all of the sort of the interdependency issues that we were having. So we continued to evolve and we moved away from having individual repositories stuck into a project template because we didn't have discoverability of our packages when we did that. So we moved to having our own SATIS package registry, which is essentially a registry of all the things that we'd built and they were all versioned and they were all in there. So now you could discover all of the packages. So if somebody created a new one and was popped in there, it was easy to discover and pull into a new project. The packages had metadata around them, who was the author? What was the version that it was on? It was easy to distribute to one another. You could link off to an issue queue. So each of the packages had like a JIRA issue queue. They had some documentation around them. Then we brought in some more testing. So with a lot of our projects to that point, we did have testing in place, but we were using things like Jenkins and we were using a tool out there called Probo at the time. So a lot of our clients have sort of requirements around data sovereignty. So we weren't able to utilize things like CircleCI where the testing maybe happens in the US. So we went out and looked around for something that would give us the power of a CircleCI or Travis or the other tools that were being used in open source, but would still meet the requirements of our clients to have data sovereignty. So we went with our build kite, which was here in Melbourne and we built a test and release pipeline around that. So we were able to use the same familiar YAML pipelines that you would be familiar with using things like CircleCI, but have these testing pipelines run on our own infrastructure here in Australia. And as well as putting that into projects, we were then writing tests and pipelines around all of the packages. So now they were starting to get a bit more rigor around them. We could control some of the quality and we would make sure that we were all building to the same standards. So we made sure that our packages followed the Drupal coding standards, started to have some functional tests, and it really improved the stability of the system overall and allowed us to focus more on some of the other governance things, like if we take care of making sure that everyone's building to the same standard and we know that everything is at a similar level, then we can more quickly do pull request reviews and merge feature changes in together and start looking at how we do versioning. So previously, we weren't really following a semantic versioning in some of these things, so people would introduce a feature that would maybe break in another site. So now we all together got together and discussed semantic versioning and how we were going to implement that through the packages. So patch version changes would be bug fixes that were easily adopted by all the projects. New features would get a minor version update and that would flag to everyone that if you install this, you might get a new feature, it might have some different configuration and major version changes, which might be a complete rewrite. Like let's say Drupal Core's just taken the media package into Drupal Core and you have to redo your media feature so you might give that a major version change to indicate that it's not safe to pull this in unless you do some restructuring around how you've implemented the media stuff associated with the package. So then we were able to also look at the module choices. Now that we've got a Sardis repository, we can build packages that are just collections of other modules and choose versions which are stable that work with the platforms that we're on and it really made things a lot better. Some of the benefits that we found then was that all of our teams started to move together. So as you probably know, Drupal's like this moving target. So as the latest version comes out, some of the older versions lose security coverage. So you're always wanting to stay within that security coverage window which is the first two sort of minor versions as they're moving along. So this allowed us to move together and fix in one place but have those fixes rolled out everywhere. So as I was mentioning earlier, things like when media went into core and everyone had to do changes to adjust maybe some of the content schemas that they were using for media and some other things, we were able to do that in one place and have all of those fixes then easily adopted into all the other places where that same media package was now used. It allowed us to keep up with... There's been a lot of changes in the multilingual. Media, layout builder, you've probably all been through some of the pain with this over the last few years. But now we've come up with a way of being able to move with that a lot more quickly, a lot more easily. And as I said, share those improvements between multiple teams. That led us to focus on keeping things simple and stable. So where sometimes you would go to a particular project install and there might be two modules installed in a project that do kind of similar things, we would keep things simple and sort of settle on one approach and make sure that we were using the most stable versions, using Drip or Core features where possible. I know sometimes there's always that sort of... There's a module for that sort of mentality out there where a client will come to you with a particular problem and you can think of a quickly grab a module just to do all of that stuff really quickly. But we would always try and implement things using the stuff that was in Drip or Core first where possible. And that allowed us to keep up with that moving target of Drip or. And it led to a more secure and stable platform. And we felt that as a team, we were all helping each other following these common principles, these open-source principles and practices that we see out there in the world that we're always pulling from but not always contributing back to. It led to faster onboarding of new people or moving people between projects because I know that clients sometimes have changing needs and budgets and you might need to move people between different client installations. We found that it was really great because now people knew that they'd have the same tooling and access to the same stuff as they moved around. So we got a lot of improvement there. There was also more accountability now that we had this register of packages. Everybody was accountable for making sure that things worked with each other and flagging those changes between each other. People chose to become maintainers of some of these packages. And the skills that we were building internally allowed us to then start contributing more to open-source. So going into the Drip or Core issue queues or module issue queues and starting to solve problems there that we were having and effectively contributing back to those projects. So it's not always easy if you don't have those skills to work out how to get a patch back into a module or to understand what semantic versioning is in different packages that are outside the Drupal ecosystem. So those skills were really transferable and helped us to start contributing back a bit more. And it started to inspire confidence. So we got confidence with each other. I know our service delivery manager's got a lot more confidence. Our clients got a lot more confidence. So as we're continually doing Drupal updates, things are a lot more stable. We're starting to see those benefits sort of roll through to everybody. Things are more predictable. We were able to estimate our updates better. There was a time Aaron can attest to where we'd get a Drupal update that we'd have to apply to a client project. And it was like, how long is this going to take? We don't even know. We don't know what this is going to break until we install it and start looking around. So this allowed us to start becoming a lot more rigorous around that and being able to predict how long these updates would take. And then we started telling other technology streams within Deloitte about what we were doing because within Deloitte there are teams running working sort of almost exclusively say on single page apps written in React or other teams working on Sitecore implementations or Adobe Experience Manager. And they're running into the same issues. They want to be able to share things with each other. But they were actually really interested in what we were doing. We were just following some of the architectures and practices in Drupal and fitting them to ourselves. But we were finding quite surprisingly to me that they were really interested in what we were doing and wanting to adopt some of that themselves. So everything from testing pipelines to semantic versioning to packaging things up into smaller installable packages. We were showing the way in other parts of the organization. I think at this point I'll hand over to Aaron again and talk about how that allowed us to move into some things that we're thinking about doing in the future. Thank you. So I think just to recap on that, I think the work that we're talking about here, like this is years of work, right? And this happens so it's the labor of love, right? It's happening throughout projects and often it's just trying to hack away bit by bit at what are the things that cause inefficiencies for it. And I know seeing it firsthand and having worked on other platforms that what we've got set up now I think is and I'd hope other people are setting up similar things. It just really makes it so much easier to predict and to manage these solutions. And I'm really excited about where we're heading next. So a little bit of a sneak peek. I guess now that we've got those foundations in place and we're doing this repeatedly, it's actually allowing us to think a little bit more further forward and start to look at, okay, so I've got this really stable sort of platform. We've got tooling on top of it. We've got our processes set up. What are the things that are still challenging from a digital experience standpoint? And one of the things and we sort of go back to that interface, right? It's actually creating the experience to themselves. It's sort of, a lot of it is underneath the surface but it's that experience layer that is causing I guess the most time and effort that is involved there in sort of creating something great. And so what we're starting to work on and this is not just within our team, of course, we're a very small team within Deloitte but within the broader Deloitte digital team is start to look at, is there a way for us to create a design system that sort of scales out so can adopt client branding as sort of like a white label set of components that can be tied into systems like Drupal but also other systems like Adobe and Sitecore and then become the basis for experiences but actually pulling upon all of the things we've talked about here. So how do we version these things? How do we make sure they're packaged up and they're consumable out to projects? How do we make sure that they're governed and maintained and updated and so that they can sort of come from a centrally managed team be tied into many different systems and an ecosystem of services and then pushed out to clients, pushed out to projects and deliver those experiences. So we're looking at this using web components and that's sort of where I'm going to come back to what I said the topic was going to be originally but we're looking at web components as a fairly new way of working for component-based design but it's something I know our front-end development team is really chomping at the bit to get in and start to really have some impact in. So we've already started down this path. It's not easy. I can definitely say it's a journey for us. And the biggest challenge is governing this kind of initiative but I think that's where drawing upon the open-source community, drawing upon the work that we've been doing in Drupal is actually forming the basis of the way that the whole organization is sort of looking at this and going, okay, that seems like a really good way to do this and so we're seeing a lot of traction there. So I mean this is my world. It's Chris's world. We're sort of sucked up into this at the moment but it's a lot to go through and it's probably a separate talk altogether but certainly happy to have discussions, answer questions, talk about some of the stuff we've been doing. So I'll leave you with that. Do come and speak to us. I'm really happy we've got some other members of the team here so it's a good opportunity for us to all have some engagement and talk about some of the stuff that we've been working on and also for us to learn from whatever are not in the community has been working on as well. Thank you. Sorry. I just have a question about the maintainability of your packages. So as you mentioned, you package your functions, modules and all that and you also have versions and things is compatible to certain versions and people become maintainers. So working as an agency, you always have cases where say your maintainer would go and work on a project full-time on the client side hence whatever need to be maintained or upgraded for that particular package might lag behind. So in your experience, how maintainable this model is and do you have any, do you bump into any roadblock or any tips on how things are going? Absolutely we have. So just like you said, originally we chose people or we asked people to nominate. Would they like to maintain certain packages that they'd built and they said, yeah, I'd love to do that. But like you said, they have like competing responsibilities to go and work on a project, right? So what we found over time was that meant that some of these things did start to lag behind but once we put the testing layers on top of it what that allowed us to do was continually start installing these into say newer versions of Drupal and making sure that they worked because all of our clients have to keep up to date as Drupal starts releasing new versions so that we can stay in that security coverage window. So they may not get new features but it was our responsibility of our team predominantly in service delivery for the production sites to make sure that all of these packages would work with the latest versions of Drupal. So even though a maintainer may have gone off on a project and they may not be available we would still need to keep it up to date. So because we had this foundation in place we were able to sort of flag whether an update required major schema changes. We'd give it a minor version bump or whether it was just some bug fixes and we could write some update hooks to keep on top of that and change the config schemas and we just bumped that by a patch version. And then all of the packages basically got kept up to date. So we don't keep any packages that aren't actually being used. So all of them are being used in different projects. So some may not get new features a lot but they all get kept in that sort of that window. But yes, it's definitely a problem we ran into. And I'll probably add that I think one of the things that makes a big difference is because the team we've got this managed services team because we're the kind of custodians of the client platform but we're also the custodians of our I guess our whole platform that we're delivering to projects. And so ultimately we have accountability and we own that responsibility. And so we're always looking for ways to update what we've been working on. And so we'll very quickly identify if something's out of date or it needs to be fixed and we'll fix it and make sure that that change goes back out to the other projects. So it's sort of think of it like our own platform I guess in that sense. So one of my questions I've got and I see a question over here is that an organization like Deloitte is big on performance measuring performance and having a lot of accountability around the time that's spent on something. So did you have to introduce like did you have to come up with a way to show performance or did you get anything applied to you and sense like, okay, we realize this dude's going to be working on something and it's not for a project. We're not going to hassle him and it's not going to be a person with a clipboard saying here's your schedule you should be working for this client on this project and stuff to name. So how did that work out? I don't know if I should answer that question. You should answer that question. So I guess the way that we've been able to do it we're a very close-knit team. So we all sort of co-located we're based in Melbourne and because we're working across multiple clients and we're juggling a lot of things and we're helping out projects. I guess that gives me an opportunity to work with the team to I guess give a bit of cloud cover. So that where there's opportunities where there's slack time where we're not working on anything we're sort of managing okay, we know these are the things that we want to be working on and there's always going to be some time even if you're really busy there's always going to be some time where you've just got a little bit of time you can put into this or a little bit of time you can put into that and so it's really just taking those opportunities and going, okay, let's take advantage of that and then I'm just going to try and protect you I guess so that no one's going to try and steal you and take your time away and so it's a balancing act and like you say, it's a big organization there's a lot of focus on people being the main product I guess that you're putting into markets a chargeable time we have to make money right? Exactly, exactly you think that the sport for what you're doing is the sign of maturity in sort of the big four and stuff? Yeah, I think it is and I think even some of the work that we're doing at the moment around looking at the future and where we're going these actually aren't projects that we're just looking at as a side thing these are actually projects where we're investing money from within the organization and dedicating resources to these things so I think that's a sign of maturity and to me it's a sign of consultancy thinking is there an opportunity for us to act more like a product company and actually deliver things that have real value out into the market? Yeah I'm keen to understand how the package is a structure particularly we're talking about dependencies and dependencies and how the versions are managed in that sense so say if you have a helper package and there's another dependency consuming that how you manage the change between those things? Sure, yeah maybe it's a... Sure, yeah so we don't have a lot of like I know in a lot of projects you'll have like a module that's a helper module has all this stuff chucked in it and it's used all over the place and you don't always have a sort of a keen idea of exactly where all the dependencies are in this so in the things that we packaged up they were very targeted pieces of functionality that mostly in the beginning involved packaging up some configurations that you would get on an install and a bunch of other modules that you'd pull in at specific versions and pulling that together to provide a feature then they started to expand to include more custom code in them but they're all very much targeted at specific use cases so there might be something for news we've got one around media there's one around hero banners and stuff we had one around providing specific types of forms that a lot of our clients use there's like I mean how many are there now there's like Henry do you have any idea there's like 20 or something now 25 and there are interdependencies so we built and we do have a profile and the profile requires some of those 20 so there's a security package that might pull in a bunch of security related modules to set all sorts of things from you know password standards or other things that clients typically ask for we haven't had a lot of early on we did have problems with dependencies and breaking backward changes but you have to start what you end up doing is starting to think more like a package publisher and less as a consumer so as a package publisher you don't want to dictate the you know the exact patch version of a particular package that can be used you want to stick to this package will work with all of these minor version or up sometimes it'll be you know this major version or this major version or not so you have to start thinking more the way a module maintainer would or a package maintainer would about your dependency versions and dependency management and it is a completely different mindset and it took a while for us to all get into that mindset of how semantic versioning actually works under the hood and how to do that so we showed them the results of their poor decisions yeah we said okay so I pulled your update in and look what happened you're gonna help me fix this up and now we're going to understand how do we flag in future that this is a change that you want to make so that we don't just automatically get that so we looked at different ways you know using in composers sometimes using the hat or the tilde gives you a completely different version constraint so we all learned those sort of things to work out how could we set up a project with version constraints that made sense how could we flag that a change was going to have breaking changes as opposed to just fixes and it was a process it took a few months but that's how we did it because we're all working together on the project teams so we have very close relationships with all the people that are out on projects delivering even if they're in Sydney or New Zealand or wherever they happen to be based they're sort of looking to us for guidance because they know that we're helping them get set up and we're providing the platform for them and that means that we often get involved in decisions that could potentially cause issues down the track right are we thinking about doing this let's actually not go down that path and sometimes those decisions you have to sort of debate them out you have to sort of discuss through why you want to do it that way but ultimately it's in the interest of creating something that we can share and we can get benefit from across everything that we don't have all these just projects that are islands under themselves that require a whole bunch of effort and a whole bunch of I guess reorienting like as a managed services team if you're picking up a different project and it's set up in a completely different way then you're trying to context switch all the time and things aren't the same that obviously slows you down as well so that's a big benefit for us it's as much about saying yes as saying no also sometimes project teams do things that are really good and you'll pull that into a package you'll get them to do it in a way that's shareable so that we can share that elsewhere sorry really really really really good so primarily Deloitte there are occasions where we'll have other contractors working with us but again it's still an opportunity for us to then shape the project and work with them so but yeah primarily internal teams that we're working with alright I'm going to wrap it up right on time now thank you very much to Harlan Deloitte