 Okay, we'll make a start. So welcome along to our presentation, Cheesing Drupal, insights from Irish multinational. So a bit about myself, my name is Alan Burke. I'm with AnarTech, we're one of the sponsors here with the main Irish Drupal development company in our own minds in any case. I've been doing Drupal for far too long. This is about 10 years at DrupalCon. I was at DrupalCon in Brussels and I've been at almost every European DrupalCon. Been involved in various core things over the years, primarily at the front end and some testing. In terms of AnarTech, we're a full-service Drupal agency doing lots of work for various organizations in Ireland, little bit of stuff in the UK and beyond as well. So that's my backstory here with Drupal and Ashlyn. Yeah, sure. So, hey everyone, I'm Ashlyn. I work as a technical associate within the digital media team in Gambia. My role is quite broad. So I work with the build of sites from a dev and PM perspective. This all depends on the resource and scale of the project itself. I would also work a lot with Gambia's current sites across platforms, just every day maintaining content uploads, et cetera. And because of this, I was highly involved in choosing a platform within Gambia just to standardize. And just to give some context, digital media almost sits like an agency within Gambia. So the business would come to us for sites, campaigns, social analytics, you name it. Sometimes we may even actually have to compete against external agencies. And that is because the vast size of our organization. But we are constantly trying to improve and set standards and processes. So our main goal within digital media is to create a set of standard platforms and processes to work with and maintain digital excellence. So just to give a quick overview of who Gambia are, Gambia are a global performance nutrition group. We employ over 6,000 people across 32 countries. We distribute and sell products across 130 countries. So we have four main sectors. Number one being Gambia Performance Nutrition. So Gambia Performance Nutrition is the number one global brand performance nutrition. It's a portfolio made up of BSN, Optum Nutrition, Isopure, Neutromino, TinkTin, ABB. You may have heard of some of these protein brands before. Although the product makeup is quite similar, each brand has a specific target market. We then move on to Gambia Nutritionals. We'd be talking quite a bit about this business sector as it is one of our recent go lives within Drupalate. So it's quite a complex business unit. It's made up of three business units which are mandated this year. So we have customized solutions, ingredients, technologies along with many of our cheese businesses. So the main thing with Gambia Nutritionals is that it is a source of raw ingredient from dairy, non-dairy nutritional and functional ingredients. So as you can imagine, there is a lot of content around all those different products and ingredients. It's a B2B business. So customers and businesses would reach out to Gambia Nutritionals if they were thinking to develop a new product and needed the ingredients and innovation to do so. We then have some joint ventures. That's our third section. So we have trees to treat joint ventures and associates. We have two cheese companies and Gambia Ingredients Ireland which is also another Drupal site. One of the first sites we went live with last year, again, in the B2B space. And lastly, we have dairy Ireland. So this compromises of two business units. In here, we have branded consumer products from a dairy perspective such as Avonmore you may have heard of and also in the Irish agricultural space. So the inputs such as animal feed and agriculture. So that's just a very, very quick overview of what we do. You can see it's quite complex. As you can imagine, we have numerous sites in there. So I'm going to give an overview of the talk itself. So, maybe I won't first for a second, sorry. Just the talk itself. So what I'm going to talk about is why Gambia came to Drupal. So this was interesting from our perspective as Anurtec because we, I suppose, to our, is this the one? Felicia. So to our, I don't know, detriment, we only became involved in this project at the very, very end. And in reality, we would have liked to be involved in the very, very start. So that led us to ask, why was that? How come Gambia, a global multinational based here in Ireland, weren't talking to the main Irish Drupal company? So we wanted to find out a bit about that. So this presentation is about that process, what Gambia went through and their process in choosing Drupal. And it led us to understand why it was that we weren't knocking on our door. So like, relatively speaking, we're a small company. There's 15 of us. Gambia are a massive multinational. Thousands and thousands of people buying and selling business units day by day, almost. So the context there is that we're very much a small fry in those eyes, in their eyes. But still, we were still perplexed by this. So this talk explains why that came to be. And so we'll start off with, so we have a backstory about Gambia and their business and what they do. But I want to talk about the situation that was in place in Gambia before Drupal. Actually mentioned that the digital media team within Gambia is a semi-autonomous business unit. So they have to fight for projects from various other Gambia divisions so that they don't win them all. They've got to compete against external agencies. It hasn't happened yet, but in theory we could be competing with the digital media team on a project where a business unit might come to us and say, hey, can you build us a project and that kind of stuff. However, before the digital media team came into existence, what happened was all the individual business units, they're relatively autonomous within the context of global multinationals. The individual business units, and in particular the marketing departments within those business units, had a lot of autonomy. They could go and do whatever they pleased. They didn't have to worry about IT in terms of, hey, IT, we need another website. They just went off and got it done themselves. A lot of them are marketing sites, but there's a couple of sites out there with an intriguing amount of functionality in terms of relationships with suppliers. There is a certain amount of B2C stuff, but not a whole pile. Predominantly B2C marketing, and that's the context in which a lot of these, at least this phase we're talking about, takes place. So those independent units, they went off to whatever agency they were dealing with for the last 10 years, got some website bills, and it did its job, and it's up there and it's running. But then the digital media team was formed, and their role within Glombias, they should be the first point of contact for all of these websites. So what should happen is that all these websites should be supported, maintained, developed, improved, patched, whatever you might say, by that digital media team. And they should be the first point of contact for Glombias business units. And as you said, as I actually said, that doesn't always happen. Sometimes they go to external agencies. But what the digital media team found was, suddenly they were being landed with an absolute smorgasbord as the word I used, of technologies to support. So when they started doing, maybe not as far as I noted, but they had to look around and they go, okay, what have we got here? So they had WordPress of various hues in terms of customization, age, and how well it was kept up to date. That was a common platform for various marketing sites. But then at the other level, there was various things like Sitecore. It was in play. Hybris is an SAP product to use for e-commerce stuff. So that was in use, and it's still in use. SAP is a very big part of how Glombias run their business internally, so Hybris was the natural extension of that. Obviously they would have evaluated Adobe for various products, and we'll talk about Adobe a little bit more later on in the presentation as well. So then you had various custom platforms. I talked about some of the services where they do semi-complex websites for partner relationship. So some of those were built with custom platforms using who knows. They're just sitting there, working away, doing their job on a day-to-day basis with somebody somewhere praying that they don't fall down. Then they've got, obviously they're gonna have some static sites as well. I don't know if you guys have any Duma, because I know Duma got evaluated later on. But so you're left with this vast array of technologies that the digital media team was then expected to support. So this that led to a problem. It's not that it's impossible to support every single platform on the planet, but it's not realistic. And it's not realistic within the budgets and working as a competitive business unit. So the business unit had to decide, okay, how are we gonna handle this? So the decision was, we need to standardize on some platform, some CMS that will help us run a wide variety of different websites across the globe. So that's the situation they were in. And they're still in this hybrid situation whereby an independent business unit can still come to them and say, hey, look, here's this WordPress site we did six months ago. Can you guys just make sure it lives? And that's an awkward position for them to be in. But that's currently where things are. They're not in a position to dictate and go, hey, yeah, you can go independent and go to your own agencies, but you've got to use Drupal. And that's something that might change over time, but that hasn't happened just yet. So, yeah, so too much cheese. So this was the problem. There's far too much stuff that they needed to deal with. Just make sure to cover them all. Oh yeah, so the other issues that they had to deal with were hosting. So, and this I found a little bit interesting because within the context of these websites, the application and the hosting platform were very much considered a single entity or at least considered that, if you're going to look after this website, you're looking after the hosting as well. It's not something that you can say, oh well, we look after the application, we look after the website, and somebody else looks after the hosting. So again, when they did their audit, so to speak, it wasn't a formal audit, so I don't like using that word, but they did the review of everything that was there. They found that there was hosting with things like rack space, various independent hosting vendors. Within Ireland they were using a company called Black Knight. So again, a wide variety and a wide range of supportive platforms that they had to deal with and different hosting companies that they had to deal with. So this led to a situation where if there was ever a problem with a website, most of the problem was finding out, well, okay, what is it actually built with? Where is it hosted? Who's our contact? How do we get in touch with them? So this wasn't a viable business process, certainly not in the long run. So something had to be done. So I've talked about, make sure I got it all here yet. So what the overriding target of this process for Glombie was to come up with a single neck to ring. Somebody whose job it was to say, hey, this website is not working or hey, we need to get some work done on this website. Who's the person we can talk to? So that was the process. That's the, so I guess the backstory to how this process needed to be conducted. So move on. Sure, so as Alan said, we were working with numerous different platforms. We needed to gain some sort of control and create a standard for our current sites and most importantly for future bills and just to have that standard in place and a process to display to the business. So as part of this, we had to review all current platforms and a few other platforms that the businesses may have heard from other businesses, et cetera. So just to name a few, which some we do still currently use. So Adobe, Joomla, Sitecore, Magento, Hybris, Hybris as Alan said as well. We still use within Glombie, but more for the complex side of things where we're displaying information from SAP, for example. So as part of this, literally, we went back to basics, creating comparison tables, going back to the business, showing what each platform could do, along with demos in some cases. Then we created a list of requirements. Okay, so for a multinational company, what did we require as a standard platform for a CMS capability? And also, we needed to ensure that it would be evolving with Glombie. So as you can see, Glombie is quite a large organization. Sites are being built left, right and center. So we need some control over that. Sites are constantly being requested as they were previously, as they are now. So we jumped on board. So one, we needed a scalable platform that, again, was ever evolving. We had to future-proof it some way. We had to see that it would evolve with Glombie as well. Again, just little things like multilingual and just moving forward constantly. Also, very importantly, it had to be intuitive. So we were tired of dealing with all numerous agencies and having such restricted access and to make such a small amend, having to raise a change request to do something so simple. We needed more control here. We needed some intuitive CMS where it could be handled over to the business if they needed to make a small content amend, switch out an image. We wanted that to be an easy process and also within our own team digital media to have the capability to carry out certain requests. And Drupal gave that intuitiveness and simplicity. I thought Drupal was a very transparent area. So it's a scalable, intuitive. It also, as Alan mentioned as well, we were looking towards the hosting. So we want to implement a tree tier environment, so a dev, a quiz, and a production. So lots of our previous CMS platforms, it was very unclear how it all worked. It was very blurred of how the hosting and the site worked. Where did you make a change? You'd have to make a change on test first and then move it to prod. There was no process there. We really needed a clear structure path there. So throughout the review, Drupal did match all of those qualifications plus more. And as I said, it seemed a lot more simplistic and clear on what to do, just in terms of modules and configuration. Also the ability to create further modules if there was something complex required. The CMS was of particular interest, especially from the business, just for the ease of content demands, et cetera. And also that multilingual capability, which was also very easy to maintain in the back end. It could easily be handed over to the business with minimal training. But however, Drupal did match everything, but what it lacked was visibility. So in a corporate world where decisions are actually signed off, no one had heard of Drupal. People thought it was something like WordPress. Is it even enterprise-y who uses it? Will we not just use something we already have? We can manipulate current platforms, et cetera. It was extremely, extremely hard just to get the visibility and credibility out there, even though it was so obvious it could do all these amazing things. The business were even happy with it. They could see, they could make amends clearly. They understood the process. So we then dug a bit further and we looked into the hosting. So Acrea came up, which essentially bubble-wrapped Drupal itself. So Acrea did implement that build test deploy approach. It had that corporate feel. Maybe it was just down to marketing, but it did have that corporate feel which just signed off Drupal. That's really what the selling point was. It bubble-wrapped all of Drupal as well. Acrea was also very intuitive, like Drupal, very transparent of what was going on. So a lot of us working on the digital media team and even within Glambia, not all of us would be that technical. So it was very easy to see how things worked and we were able to understand the process and end of how it would work. Acrea, just in terms of creating the environment itself, uploading an SSL cert, it all just took a number of minutes and we could do that all internally, which is a very, very simplistic approach. So that really did speak volumes and it signed off the process for Drupal, which we have created as a standard. So I'm going to take a slight segue to the presentation itself and talk about Acrea and Drupal. So I don't know if anyone's here from Acrea in the room. I was at an Acrea partner day yesterday and I mentioned this talk as like an accidental sales pitch for Acrea. And it wasn't meant like that and to be honest with you, the lessons that you can take away from this can be applied to various other large supporting platforms. But the point I'm trying to make here is that from a Glambia perspective, there is no differentiation between Acrea and Drupal. There is just, there one thing, like we had very interesting conversations early on our engagement with the Glambia where we're here for, oh yeah, we were speaking to Drupal yesterday and they said, I was like, who? Who are you talking to? And no, we're talking to Drupal. And they said, yeah, this is no problem. You can just, you know, upload the SSL certain and eventually over time become to learn that as far as Glambia are concerned, there is no differentiation between Acrea and Drupal. So it's part of their research process and it's part of basically how they do business. They will not buy Drupal on its own. They will only deal with a large corporate vendor. And this is probably the biggest take home point from this entire presentation. So this is something, you know, it took us as a small Drupal company and as far as we're concerned, we're the face of Drupal in Ireland. This was a bit of a wake-up call to go, well, hang on. Yeah, you're the face of Drupal in Ireland. You've got, you know, core maintainers, security team members, et cetera, et cetera. But from a Glambia bear perspective, that does not matter. They do not care. They wanna deal with a large corporate entity that are gonna be around in 10 years time that are backed, that are financially viable, stable, huge, that deal with big companies. And yeah, this was a bit of a wake-up call for us. So, yeah, it's the idea that it's all about dealing with a vendor, not just a product. Like, we've got a really good product. You know, as in AnarTech, we sell Drupal, we do a really good job of it, but we're not a big vendor. And what's interesting is that for this phase of the product, Acre did a really good job. The scale that Acre are at was just what the business needed as a sort of a, okay, yeah, there's a big company behind this. They're dealing with bigger projects. They know what they're doing. They give a sense of scale, a sense of permanence, importance that Glombia needed in order to get Drupal over the line. But what's interesting when you look later on down the line is that Acre themselves, and by extension, the Drupal community, have a job to do in terms of still reaching the corporate boardroom level within a lot of agencies. Because, well, I won't give away the rest of my slides, actually, so we'll talk about that later on. Okay, so, yeah, how did Drupal nearly lose out? So, let me make sure I've got all this right here. Yeah, so, yeah, the difference is that when it came to making a decision, one of the questions I asked was, why aren't we just using Cycor? Or why aren't we just using Adobe? I don't get it. Why are we taking this product, this platform, Acre, that I've never heard of that, yeah, okay, that they're dealing with NBC or whatever like that. But, you know, the guy down the road in the other large multinational food companies, they're not using this. So why are we switching over to it? And this genuinely was a big problem. So, you know, this I guess is a takeaway for a lot of different people, but certainly within the people who are pitching to enterprise level clients, this is far bigger a deal than I thought, that the role that emotion plays in making a decision, I mean, you know, psychology and majors know all about this kind of stuff. But for us, it was still like, well, you know, a lot of people here in the room come from a development background, or at least I did. And, you know, everything was evaluated based on the capabilities of the product and what it can do, or the hosting platform and what it can do. But that isn't enough at a top level boardroom. They're going on gutter and emotion. And if you can't play to that, if you can't reassure people that they're making the right decision. So, you know, the line that no one ever got fired for buying IBM was thrown around for years. And, you know, that's kind of inertia still exists within a boardroom level. But what Drupal had in terms of its secret sauce, it is a very good platform, and it's just as good as the other platforms that are available. And this can't be underestimated, in terms of, say, the likes of, I don't know, WordPress, Joomla, you know, Drupal at a corporate level, still seen as a more reliable platform to deal with these kind of, deal with problems that multi-nations are playing, working with on a daily basis. But I actually mentioned the idea that Acria came in and bubble wrapped Drupal. This essentially was what the difference was in winning over Drupal as a platform. Yeah, like I said, I'm not an opener for us, but the idea that they can deal with a single vendor that looks after their hosting, looks after their staging and QA environments, and looks after the Git repository hosting, for example. So all these little things that are bundled in as part of that platform, this is very appealing from a corporate level perspective. And it was definitely a huge part of the decision-making process used. It was like a key thing to see as, well, that's what Drupal's got that the other ones don't have. What Drupal 8, we're using it a lot and we intend to make even more useable, but there's a couple of things within Drupal 8 that the other platforms haven't quite caught up with yet, or at least not as well, is certainly configuration management, Drupal is doing a much better job of now. I won't say it was part of this evaluation because it wasn't, but it's something that's the kind of thing that a corporate level vendor is gonna look for. Configuration management, content staging, again, not part of this particular decision-level process, but that's a huge thing. We were asked for content staging as long ago as, ooh, six years ago? My business partner's in the room, which you might not remember. Yeah, six years ago, and like, you know, meetings that go, yeah, we look into that and you run away and find out what the hell does content staging mean? So you find out what it means and then you find out, yeah, it can be done, but it's really, really tricky and really, really complicated and does your budget stretch that far to spending the sort of time on it? No, okay, that's parked. We'll look at it in a later phase. But that's something that's cropping up more and more again and at a corporate level perspective, to have that ability to have not just the configuration, not just the functionality on a staging version, but to have the content stage ready to go for a big media launch, click the switch, we're going live with a new platform, a new set of content. That's very appealing to a large corporate. So we've been looking at projects like the Deploy Module and, what's the one with the Dixon? Pfizer in the UK are doing a lot of work on this. So basically, this is something they really need as well. Again, another large multinational with thousands and thousands of sites, but the ability to push content like that is seen as a big deal for them. So they've been working very hard on that and there's been various additions to Drupal. And so there was just a module called Deploy. Now there's like a suite of five or six modules that work together, things like multi version and things like that. So that's something we see as being very important that we're trying to get to grips with it, get stuck in with that kind of work so that when requests come up the next time from a corporate line going, hey, what about content? And they're doing, yeah, no problem. Here's how we do it. So that's where we're moving to. And that's the kind of thing, if you want to pitch these things, this is the kind of stuff that people are looking for. And the point is that Drupal can do it and can do it really, really well, especially in the newest version. So after a lot of research, numerous meetings, comparison tables, having plenty of meetings with Acquia and Alan and his team, it took about three months all in all to select Drupal and Acquia as a platform to go with within Glambia. So at that point we had made two decisions. We were going to have Drupal and Acquia as our standard CMS platform, but also stick with hybrids just for a more complex side of things. In the house, for example, we have a site called Glambia Connect which displays all milk data from SAP. So we would stick with hybrids for that sector. Okay, so within three months, that's not a long time. We already had two sites in the backlog within digital media, which we knew were going to be built on Drupal. And at this point, what we were saying to the businesses, this is the only option, this is the standard, we have set in place and this is the way. Which was much appreciated by the business and there was no conflict or queries about switching platforms. Once we provided everything that was there and it was signed off as well by corporate. So the first site we went live with Drupal was about this time last year, Glambia Ingredients Ireland and we built that on Drupal 7. So that is a B2B space just to give a small bit of context. Glambia Ingredients Ireland is Ireland's largest dairy provider. So it processes about 2 billion litres of milk annually. That's converted into numerous dairy products for the sports performance nutrition sector and also clinical. It ranges from milk to butter to cheese, again, and also to nutrition products. So Glambia Ingredients Ireland had little to no online presence previously. The business really wanted a content rich site and also have that corporate feel. As well, the business wanted the capability to amend and edit content, simple things like switch out images, which wasn't so simple in the past. Drupal was able to handle all of these capabilities. As well, they wanted to future proof the site as we know that this site is going to grow just into further markets, such as China, et cetera. So we knew that Drupal could cater for this in the future when we get to it. That was the first site. The second site, which we were actually building pretty much in parallel, was also built on Drupal 7, called Foodscapes Nutrition. This is a company based in the US. It was a new business unit that just set up recently last year. Basically, it is a lunchtime school program for primary schools within the US. The main objective of this site really was just to have a point of reference for the primary schools themselves. The site was to display a relatively small portfolio of products, lunches, and recipes. Now, this site was particularly interesting as we worked very closely with Anartek, who actually trained us in end to end, just with the build and configuration of the site. So that was absolutely excellent, because also as a team, we got to see how Drupal was configured, how to download, upload modules, et cetera, even just from the environment perspective, using Git version control. It was very clear, the standards and processes, even from a coding perspective, that had to be set in place. So that has been a huge learning curve and also makes it easier to go back and explain to the business, say, for example, if a change request comes in, we have a rough idea of what's feasible or not, and then we work together to resolve. So that was a very, very exciting opportunity. Then our most recent go live is Glambia Nutritionals. That was built this year, it went live about July, and was built on Drupal 8. So as I was talking earlier, just in the back story of Glambia Nutritionals, it is a very, very complex business unit. As I said, it's compromised of three business units, which actually joined together around the time of go live. So there was an enormous amount of content that had to be displayed, along with numerous different business units and points of contacts that would all require certain permissions on the site to edit and amend their areas. So role permission was a big thing here. Again, I think the main challenge with this site was that it would have to be a content-rich site, but it was more offline. So there was so much content, we needed to find a way to display that in an intuitive way. Again, with Drupal, one of our key points within a CMS was that we wanted a flexible platform. We don't want all of our future Glambia sites to look the same and have the same template, but Drupal allows us to have that flexibility. So say, for example, within this site, we have numerous product solutions and categories. Each category solution would have a detailed page. We didn't want all these pages to look the same because the content would have varied such a huge amount. So within this, Drupal gave us the capability to have different content types on different pages. So say, for example, we'd use the accordion, we'd use the list approach, the tabbing approach. And again, we could add and subtract this as we went along. And say, for example, this week, if a new product got added and a new tab needed to be amended, a new accordion, it is very, very straightforward to add in. So Drupal really did give us a lot of flexibility here just to have a nicely designed and intuitive site for the business. We have a nice little mega menu dropdown with some icons. It was a pretty intuitive site. So the business were extremely happy. Again, with three new business units joining together, the role permission was very, very important. So the business are extremely happy that they still have their ownership of their content and they can change things as they go. Then just the next course, so Future Plans for Drupal, even though we just went to... I don't say a few bits about the long-being ingredients. I'll just add to that. So it's been an extremely successful project. There's a couple of reasons why. So the first one is it was built in Drupal 8, so it gave us a much better platform to work with in terms of meeting some of the requirements of Glombia. But a few of the other things that we'd learned then over the course of the year as to how Glombia functions as a business, we were able to put that into practice in terms of developing that site. So learning how roles and roles, permissions, segmented sections of the site that different people could edit, these kind of requirements as we've learned, as we worked with them on the third large project. So learning these things over the course of the year meant that we could put solutions in place now rather than stuff that we'd say added on at various points in time as various change requests came through. So that was a really good project from our perspective as well. Things that we'd learned both about Glombia and how it does things, or large corporates and how they do things, how Drupal 8 will let us do better things. These things came together to produce a really, really good site and one we're very proud of and is up for an award tomorrow night at the Irish Web Awards. And I think it's been nominated for a few different things, but Irish Web Awards on tomorrow night, so we're hopeful we'll come away with something from that. So yeah, we're very happy with that. And I think it also lets us, from an analytics perspective, it puts us in a very good place now. An extremely successful project built on a modern CMS platform that we can use as the inside sales point for various other projects within the organization. And as well, just to note, this is the first time that the business actually have control to amend their content. So usually our platforms are so bespoke that they'd have to hand it over to us to make a change or they'd just ask us to take care of it. But now the business can actually go in and make the changes themselves. I think with Drupal, they do feel a lot more included with the process. We do have a process to explain to them end to end of how it works, even from the dev testing and production environment when we were in the middle of UAT. They were very much so involved and are extremely happy to be involved in just simply things like the updating process, which wasn't done before. So then the next course, just the future of Drupal within Glambia. So even though Glambia Nutritionals has just gone live, we are already kicking off into phase two. So it is an international B2B site. So for phase two, which we are currently scoping out offline, we will have to incorporate that internationalization, which is going to be quite big. So we'll have a multilingual capability, geolocation, and also we'll need to have some sort of product switch on it. Because not all products are going to be available in certain regions. So that's a pretty big project, which we are fleshing out at the moment. Then also, which we are looking into extremely closely for our future B2C and B2B projects is the recent Drupal to Hybris integration. So this is extremely attractive. So as I said, we do use Hybris just for the more complex sites at the moment that are feeding in from our main system SAP. But with that Drupal to Hybris integration, what we are thinking as a company is that we could use Drupal as the presentation layer. Again, given that flexibility, as we don't have to stick to a number of templates, et cetera. So just for moving forward again, for fear of all our sites looking the same and just adhering to business requirements as closely as possible, this is proving very attractive, which we are looking into a lot and doing a lot of research into at the moment. Yeah, so this is very interesting again from a Drupal community perspective. So when I first talked to Glombia about maybe 18 months ago, when they were evaluating Drupal, it was very much, oh no, this is just for brochure wear sites. You know, we've got SAP, we've got Hybris, that's what we're gonna use for the complex sites, for the e-commerce sites. It wasn't even considered. And you know, this took me back a bit because we would see Drupal's expertise as being in the complex site spaces and we would be surprised that it would be even competitive within the brochure wear sites. But then, you know, we dig a bit deeper and it turns out that behind the scenes, even the brochure wear sites within the corporate context have an awful lot of functionality they require. So, you know, Drupal has proven it's worth. It's a reliable platform, a couple of successes within the company. You know, perhaps at one level we'd like to build a couple of more projects at this level, so complex corporate marketing sites so we can learn more and more about the business, get a bit more traction within the site, but it's been so successful that it's now been evaluated at a, you know, the truth is a level above the digital media team are now deciding, hey, are we gonna go with Drupal? Or are we gonna go with Sitecore or Adobe? And this is a big corporate level decision that they will be dealing with large vendors in terms of multi-year contracts and all this kind of stuff. So this, you know, this is not a game that AnarTech can play. You know, we don't have 1.5 million in the marketing budget or 7 million or whatever the hell it is that Adobe have in the marketing budget. You know, we can't fly people over to Wisconsin to meet the various executives in Glombia, USA, Cheese Division. You know, we're just not at that scale. So we're, but at the same point and the point I'm trying to make is Drupal is competing at this level and Drupal shops at our level can be involved in those processes as well if you choose the right partners. So from our perspective, you know, we can't scale up to be a massive 500 company, 500 person company overnight, but what we can use is if we have appropriate partners for appropriate projects, we can get involved in those projects as well. So it's a very complex scenario from our perspective, because we are working with Glombia on a close base. We're not their only vendor available for them to get websites built out. Like I was actually mentioned, they will go directly to other agencies. They still get WordPress sites spun up because the independent business units will go to them or even if they don't have the capability in-house, they're gonna do it as well. But we're working closely that the term is an in-house business partner. So we're trying to work with them to develop new projects because the digital media team is almost like an agency. They see requirements, they see needs for different units to have different problem solved or sites updated. So they're working with us, hey, do you think we could solve something for these guys? What would you recommend? Have you got some ideas? And we'll work with them to put together, they're not quite joint proposals, but they're in the same area. But then at the corporate level, it's different. You know, we're just not at that level just yet. So what we're trying to do is get involved with Acquia and support them as much as we can in terms of that particular pitch for the next level product. So this is a bit of a catch when you do for us because we're not Acquia's only partner. They could choose to go off to another company if they do in that large long-term project to provide corporate level stuff. But I mean, our take on it was this, that basically it's better Drupal than Adobe, number one. So it was worth helping out Acquia for just that because if it is one, if it's another big Irish brand choosing Drupal, we will eventually benefit from it one way or the other. But the other way to look at it is that ultimately Acquia does get other partners to work on them in various projects. And we'd like to think that if we're able to help seal a deal like that, that we're gonna get some of that work as well. So that's our approach on it. We're happy that it's, well, that process is ongoing. It's gonna take quite a while for Glombia to make that decision and even the fruits of it in terms of the first sites being rolled out. That's a bit of a way, but we're quite hopeful. But hopefully in the meantime, we can get more and more sites built and demonstrate more success with Drupal as a platform within the Glombia site itself. So that pretty much wraps up the talking part of the presentation. The standard slides they want us to talk about is this contribution sprints on Friday at various places. So basically the point that, and how somebody's been involved in these sprints, there is room for everybody at these sprints regardless of your level or knowledge of Drupal. If there is anything at all that has annoyed you about Drupal and you can explain the problem to somebody, that's a huge contribution in and of itself. So something as simple as, I really, really hated the first time you installed Drupal that standard landing page that's there and suddenly disappears as soon as you add an item of content, that I don't get. So even be able to explain something small like that is a huge contribution, there's room for everybody. And at the very bottom, I'd like to invite you all on to Trivianite on Thursday night. I'll be the emcee for Trivianite. The Quizmaster is in there in the fourth row. Stella put together all the questions. So that's a lot of fun, very informal light. So come along and say hello to us and have a bit of fun on the Thursday night. It's in, for those of you who are from Dublin, it's gonna be in the mansion house. So it's a fantastic venue. And if nothing else is worth going along to have a look at the venue itself. Yeah, next things, we do need you guys to evaluate this session. So, good, bad or indifferent, let us know what you thought. Is this something that you would like to see more of? Is there stuff you felt was lacking from this presentation? Obviously, I'd prefer you've maybe told us that face to face. And yeah, that's pretty much it. So thanks very much for your time. We're gonna take questions. There is a microphone here in the middle. So if you just wanna stand up in the microphone cause they're gonna record the audio and play it back. So that's why we want people at the microphone. Thank you for everything. And just a real quick one, that award-winning Drupal 8 site that you mentioned, was this Glanbia Nutritionals? Glanbia Nutritionals. Okay, so that was, what award did it win? Oh, it didn't win the award, it's been nominated. Oh, it's been nominated, okay, that's great. The awards are tomorrow night, yeah. Okay, that's great news, thank you. Maybe it'll be an award-winning website for about 30 hours in the morning. It's good progress in either case, thanks. Any other questions? JP cycled all the way here. He surprised any breath left. That's why I'm walking funny, I haven't recovered yet. So I'm aware that Anatek were a very early doctor of Drupal 8, so that put you in a good position to use that as a platform for this. And I guess that you were quite early to it with this. Yeah, we were. Was there a lot of customizations and was that, do you see that as being a risk score? Okay, so there's two different sort of questions here. So if the first question is, did our early use of Drupal 8 help us for this particular project? I'm gonna be honest, say probably not. As a project, who else, maybe is that fair? I look at hat to help and so what. We've been using Drupal 8 for a couple of years now. We've had our own website on Drupal 8 since, I don't know, it's a two year, Amsterdam, so almost two years now. We've had people who have been involved in developing Drupal 8 for quite a long time now. So when it came to switching over to that project, it wasn't something new to them. I was like, oh, okay, great. I finally get to build a website with this thing. So there was a level of enthusiasm and I guess the few kinks that were there at the time and they were already A, familiar with them and B, knew how to deal with them. So yeah, maybe I'm being unfair. Maybe it was a bit of an advantage to be able to go with a website on Drupal 8 that early because we had knowledge of the platform, maybe not for real websites, short of our own website. But yeah, definitely, I guess it would have helped, yeah. I guess Contrib was quite sparse, quite early on as well. So the, you know. Okay, well, I mean, okay. So we're definitely in a good space there, at least within an Irish context. We've plenty of people on board who, when it comes to a module that isn't ready, we can jump in and write the patches, write the upgrade path or whatever it takes. So that didn't scare us and still doesn't scare us in terms of projects with Drupal 8 because we've got some pitches at the moment where we, I don't know, have we pitched Drupal 7 but certainly it's been approached to us to say, hey, we want you to build this on Drupal 7 and we're already, and I genuinely mean, we're already scared of the thought of building a site on Drupal 7 because for us, we've moved on. You know, warts and all Drupal 8 is far and away better as a platform. And I would encourage anyone who's still sort of sticking with the happy, safe space of a Drupal 7 site that they know and set out, they can spin up sites really quickly. That's gonna, that'll work for a certain amount of time, but you know, the learning curve that is there, you'll have to overcome eventually. And I genuinely think that once you get there, you're in a much better space because like even, I'll give you a good example of where that was a huge thing for us. So within the Columbia project, they're talking about, okay, we want our websites now, you know, can Drupal talk to hybrids? And going, okay, yeah, of course they can. And now we know that because we've got a much better API layer, we've got RESTful services within core, all these things are available that we can start using straight away. So like, without having like, you know, a hybrid module you can drag and drop and off you go, we just know that in terms of writing some custom code or a custom service that interacts with those things, we just know that that's something that's gonna be much more available out of the box without going, okay, do we use the services module or the RESTWS module or the RESTful API module? We just know, we know that we can do it with Drupal core if we add on our own custom module stuff. And look, the nature of these projects is this custom code involved anyway. Like Ashene talked about the way that the independent business units are very independent. They want their own look and feel. This isn't quite the same as I mentioned Pfizer and people like that where they've got a corporate look or Johnson and Johnson downstairs, they're another example where there's a corporate look that has to be adhered to across the whole platform and then the whole family. This is quite different. These guys, like they're competing with each other. Ashene mentioned three or four protein brands. They're competing, you know, there's a lot of overlap and competition there. You know, they're in different spaces, but there's a lot of overlap and they'll compete viciously. So if you're told, oh, your website's gonna look the same as this one, that's just not gonna fly. That's interesting. Yeah, it's a different space. Different corporates will handle these things differently and that's currently how it's going and the way things go with the corporate world, it might change over time. They might decide to go, you know what? Let's bring all these people in-house. Let's come up with a single nutrition brand and get rid of the other ones. Our standardize on a single one. These are decisions that people who look at spreadsheets and cash flow predictions and that kind of stuff, they can make better decisions that than I ever would. Cool, oh, cheers. Thanks to you. Oh, the boss. So I don't really have a question. I just wanted to answer a point that you had, JP. In terms of custom development in that site, there wasn't a huge amount. There is one custom module that we're going to contribute back to the community for the decision tree that's on the homepage. I just haven't had time with Drupal to do that yet. Yeah, so yeah, there's the decision tree engine which is pretty nifty and it was built in such a way that A, it can be contributed back as a computer module. It's just the engine behind it works really well and B, we're already planned to use it in the next site that we're going live with. So that functionality has, you know, it's been seen within the business unit, or sorry, by another business you're going, hey, that looks really cool. Could we use it for something on our site? Yeah, we can do that. My question is about the design part. Did you provide the design or there was another vendor? So the digital media team, yeah, do you want to talk about that? We have two UX and we also have a graphic designer within the digital media team. So we worked very closely with Anatec on the designs just to ensure, because we were under tight deadlines with this project, so we worked on the design internally, but in sprints with Anatec, because if something was a bit too complex under the deadline, we just amended it slightly. Yeah, that was my second question, if there was no collaboration, but that's good. Yeah, so the design process has just been fantastic from our perspective, because this has not been a, here's the design, throw them over the wall, go build it. It has not been a process whatsoever. From the wireframe stage, from the user requirement stage, we've been involved. So while we haven't actually been producing the visuals ourselves, we've been heavily involved to make sure that a lot of times, a design can go two different ways. One of them is going to be a very long way and very complex to implement. One's going to be trivial, and we can just steer things in the right direction, because I mean, I don't know, maybe all businesses are the same, but the deadlines are challenging and have been challenging to deal with, but we've got there, but only because of the cooperation that we've had. I don't think that if we, I mean, short of doing the whole design process ourselves in-house, could we have met those? Because if we had to deal with another agency who were very fixed on their design approach, it wouldn't have worked, but because we've had this cooperation, this in-house business partnering that we've had in place, it has worked, and we've got the fruits to show for it. You're very lucky. Yeah, we are, and we genuine, and we say it all the time, we know we're lucky, we know that, because look, we've got other projects where that isn't the case, where stuff is thrown over the wall, and we're going, well, what does this do? We've never seen this before. Have you any clue how this should work, and then it goes back to something like, well, I don't know, I've never seen that, and it's just, it's an entirely different process, and we'd much prefer the collaborative approach. It's definitely, I mean, I think it'll be something we can, in terms of future projects, it's going to work, because we can show the timelines. We can show this is how this went live that fast, and it's only because it was a collaboration. If we had to go, okay, here the designs are done, and here's our spec, and now it's over, it just wouldn't have worked. We had a lot of, certainly for non-being nutritionals, there's a lot of the functionality of that site, and a lot of the content of that site was written before the designs were finalized, because we knew that we could work with them in terms of finalizing the designs and making sure that they were quick to finish off and get that site live. It was like I did last time. But we always knew there was going to be a phase two, so we were able to take certain elements and go, look, is that a feasible thing for phase two? And they go, oh yeah, no problem. We don't need that now at all. And on this kind of thing, it wasn't the case of, well, here's the shopping list, get everything on it. It was a very collaborative approach, and we're very happy with it. The content as well, we do that in parallel. So it was the first time that we actually, oh yeah, sorry. So just to know, like, I know with some of our other sites that we went live with initially, I think content is always the hardest piece at the very end just to get it across the deadline. So this was the first project that we actually managed to get all that in parallel, just to get to that deadline. So again, as Alan said, it's completely collaboration. Once everyone's on the same page and knows what has to be done and works together, it can be done pretty fast. Thanks very much. I work for a regulator, so our content is unique. And we've really struggled with dev agencies to get them to fully understand what we do and the sort of environment we work in. I was wondering if you've got any tips about how you talk a lot about collaboration, about how to get, working with agencies and how to get them to understand the sort of pressures that we have and also what has worked well in your collaboration and what hasn't worked well, what you might have done differently. Sure. I think a lot of the time, the business, especially if a business unit is dealing with say two different agencies, which they generally are in terms of development, design and content. For some reason, the business seemed to be afraid to bring all those people into one room and to have those daily calls and daily meetings. Instead, they tend to assign one person in the business to communicate between all three, but it really is necessary to have everyone in the room. Again, like with Alan and our tech, like we operate very closely. We did have our daily calls, weekly calls, all in the one room. I think that is the main thing. You really just have to bring everyone together. Mike, Mike, sorry. I'll get told out of it. Did you actually get your agency embedded in your office? So essentially, our digital media team is like an agency, similar to Anatech as an agency. I don't know if I want to refer to Anatech as an agency. So that was two of us dealing together very closely and then we'd work say with the point of contacts for sign off within the business and we'd have everything communicated back. But I think because, I think we were lucky because we were designed and then we just emangulate the dev and the design together, we were able to have that collaboration. Yeah. We weren't all in the same room. No, we're not in the same room. But it wasn't really possible because a lot of the business units they're based in the States. So we were in the US for a majority of this project, but we did have regular touch points and made sure that we both understood exactly what point we were at in the project. So I think that's the main thing. But when we were in meetings with Alan, for example, we'd have our designers in that meeting as well. We were just lucky that they were also on our team. So I think sometimes if that isn't the case, then it tends to get a bit complex. The same with the content was also within our team. So they could also jump into meetings if they felt something wasn't working. I think the big thing is a bit of give and take. What we found was that we would, there might be 10 things presented to us that might be challenging. And we just go through them all. Half of them could be approached in slightly different way to make it easy. Another three or four could be put off to a later date. But the final two and the business, no, no, we really need that. And then to get, because there was a bit of give and take from the business, we can go, okay, fair enough, we'll make sure that gets done. And that was huge, because oftentimes it doesn't work like that. It's like, no, no, that's it. The deadline doesn't change. But they're the list of things we need. The phased approach was huge as well. Because oftentimes, certainly with marketing projects like this, people are very afraid of a phased approach because they feel that, oh, well, I won't get the budget next year, or I'll be onto something else next year. But there was a very committed decision that this is a living, breathing website. It's going to evolve, it's going to change, it's going to grow legs, because the business unit itself is actually mentioned with three different units coming together. So there's going to be this initial phase of, well, okay, bumping shoulders and knocking heads together, try to work out with their best approaches at a business level. But eventually that's going to come together and it's going to filter down into direction on the website and other marketing materials as well. So we knew that we weren't going to nail it all on day one, because the business hasn't got it nailed on day one. They're going to evolve and the website's got to evolve with it. So in terms of dealing with regulatory agencies, yeah. Like, I mean, I know some of the stuff we talked about there would be interest to you guys in terms of like content staging is a big thing. Yeah, no, it's huge for us. So, yeah, I mean, just to understand, like as much as possible, like I talked about how we did a better job in this project because we were a year working with the business and we knew a bit more about how they worked. I think that's a big thing. If you're working with an agency for a longer time and it's a good relationship, certain things that are pressures to you that might seem like incidentals to an agency, eventually you learn, oh wait, that really is a big deal and we better put a lot of effort into that. And something else that we think is a big deal that can be left until later or they don't care. Like, you know, like for your perspective, I'd imagine that the ability to get content live at a certain date and a certain time with a certain wording trumps everything. Yeah, it does. And actually for us it's been a real difference from working on the project to exiting the project and moving into BAU and we focus too much on the project and not on to actually working in a live environment on the BAU and that was been a big lesson learned for us and for our agency. Yeah, so I guess that's the thing to learn there is whatever makes you ticker, whatever your real pain point is, to try and get that across over and over again and then to understand that if the agency is able to solve that problem, that maybe cut them some slack on some other stuff, I don't know. Because it is give and take and if you can do it like that, yeah, we've definitely come across the content staging and the revisioning stuff for regulatory stuff and government stuff. Yeah, and we get it. Thank you. Any other questions? Okay, we'll wrap it up with that. We'll stand downstairs, booth 901 I think it is. Downstairs on the corner as you go in the door. So if you have any other questions about the project or anything else, just come up and say hello. We won't bite. So yeah, we'll see you all at trivia night or I've another talk tomorrow about Ireland.ee. So if you want to come along and hear more about that, that'd be great too. So thanks very much for your time. Thank you.