 Mori is a technical account manager for Acquia based in the UK. He is also a coordinator of the Drupal security team, or a coordinator. There's a few aren't there. He's the admin, or one of the admins of the Japan Drupal groups on GDO. He's a module contributor and core translator. He translates core strings into Japanese, if not other languages as well maybe. Yeah, shut that. Yeah, God please. And he works with customers who operate internationally with over 20 offices around the world. So, as you can see, he'll have the experience that he needs to be able to talk about this topic. While Mori is, I'd say, a techo, really, fundamentally, or historically have been, today's talk is not going to be overly technical. It's classed as an intermediate level. Anyway, without further ado, I'd like you to welcome, please, Mori Sugimoto. And we'll just swap over microphones here. So, talk amongst yourself for 10 seconds. Uh-oh. You hold that. Hello? Hello? Sorry. Okay. Right. Okay. So, sorry for the delay. My laptop isn't working very well with the projector. So, okay, so let me start. So, just to give you a quick introduction about myself. Well, you already know my name. My name is Mori Sugimoto. My screen name is Dr. Mori. I've been using Drupal for the last six years. And I'm based in the UK, although I'm originally from Japan. And I work for Acquia and very quickly about Acquia. So, we provide expert 24-7 Drupal support. We provide optimized Drupal hosting. So, it's a platform as a service. So, you basically bring in your code and we look after the rest. And we also, through trainings and professional services, we foster Drupal adoption. And also, we are hiring. And we are especially interested in hiring client advisors if you're interested. Please let me know. We have many other posts available as well. Okay. So, can I quickly ask about yourself? So, are any of you developers or project managers and businesses interested in using Drupal or have been using Drupal already? Okay. Thank you. And, okay, well, if you're a developer, you're probably pretty experienced with Drupal. So, people who own business, what's your experience with Drupal? Like, have you been using Drupal? Yeah. Okay. Cool. So, good to know. Yeah. So, since there are some developers, I might be adding some technical details to the talk. But just so you know, just to make it very clear, it's about Drupal adoption for multinational organizations. And it's not about multilingual Drupal. Some people thought my talk is about multilingual, but it's not. So, if you're not... If you're here to learn about multilingual Drupal, unfortunately, you're not going to learn much about it. Okay. So, I'll be quickly going over about the benefits of adopting Drupal. And also, in a context of multinational organization, it makes it quite a lot more complex. So, there would be peculiar challenges related to this kind of use case. So, I'd be discussing about these challenges as well as solutions to that. So, first of all, benefits of using or adopting Drupal or disadvantages of not adopting Drupal. So, a typical scenario for multinational organizations is that they have many country... They have businesses around the world. And each country office has their own website, which is fine. But if they have these websites on different CMSs and different frameworks, then it becomes a problem. Because the way things are built is quite different. And also, each site needs to be built from scratch. So, you need to... If you've been involved in a web development project, you know how much effort it requires. And if you need to do this for, you know, 20 or 30 country sites, then it's a lot of work and money as well. So, and Drupal can really simplify this. And oh, yeah. And on top of that, if you are using proprietary CMSs, then you'd have to pay for the license as a further cost. So, building each site from scratch on multiple CMSs is quite inefficient. And I'd like to dig down a bit deeper on this. So, the problem of having multiple CMSs is that the reuse ability is quite poor. So, for example, if you want one feature on all the sites, you need to build that feature in different... for different CMSs. So, for example, in the EU, there is now a law that if your site uses cookie, you have to notify the visitors that your site uses cookie. And if you have five websites in the EU and if they're all on a different platform, then you need to develop that simple feature for five of those different CMSs. So, the reuse ability would be quite poor in that kind of scenario. And also, if you want to have the same look and feel for all those sites, all the sites you have, you need to build a theme or a template for each of those CMSs. So, for reuse ability means more development work and more maintenance. And also, if you've been involved in Drupal development, you'd probably know this, but there are a set of best practices and standards that you want to follow. And if you have, let's say, ten different CMSs, it's quite difficult for your developers to adhere to best practices of all those ten different CMSs. So, that can lead to substandard quality and low-maintenability. And also, applying bug fixes and security updates for all those CMSs would be quite cumbersome as well. And if a group of editors are in charge of updating those different sites, you need to train them for different CMSs as well. So, that's another inefficiency. So, the solution to this is to build a Drupal-based platform and then build those countryside on top of that. And Drupal can... The reason why Drupal is so good for this kind of use case is that Drupal allows you to run multiple sites on a single code base. So, even if you have 30, 40 sites, you only need to update the code in one place. So, for example, you have the core and common features and themes in one place. So, if you ever need to apply updates, you only apply that to the one place, and then it gets applied across all the sites. So, that makes the maintenance very simple. And benefits of having such a Drupal-based platform, it's basically a reverse of what I've just talked about. So, high-reusability, if you need a certain feature, you basically build that feature once and then it works on all the sites. And also, the same thing applies for the theme. So, if all of your, let's say you have 20 sites, and if all of the 20 sites need to have the same look and feel, you basically build one theme and you enable that on all the sites. And one of the customers I was working with had a real issue. So, they had multiple websites. They had a site for each country office. And if you look at them side by side, they have different size of logos. They use different color schemes, some of which were actually not allowed to be used. They weren't following those design guidelines and so on. But those sites looked almost like they were for different companies. So, you can avoid that kind of problem quite easily by using this kind of platform. And also, rapid construction of new sites. This is a real strength of this type of platform. So, basically, what Drupal allows you to do is to build this thing called install profile. So, if you run that, you can spin up a site within a matter of seconds. So, you have the platform and you have an install profile to spin up a site. Then, once you build the platform, you can create new sites very easily. You just basically run the strip and then populate the content and do a quick UAT and you can launch the site. So, it's very efficient compared to what you saw going through all the phases of the development. And like I mentioned, because you can apply update in one place for all the sites, the maintenance will be much easier. There are some challenges which I will talk about later. And also, hosting requirements will be simple. If you have multiple CMSs that runs on different technology, for example, you might need to have Ruby or Java, then requirements for servers would be completely different. However, if you have this type of platform, then all you need to have is a stack that can run PHP and MySQL basically. So, it can really simplify hosting requirements. So, this is also another thing that reduces the maintenance overhead. So, in terms of cost efficiency, I can't tell you how much it would actually cost to build a platform because it entirely depends on how complex your solution is. But just to give you an idea, the initial development would involve development of the platform and common theme and features. And you also need to document how things work and you provide trainings. So, let's say you have 20 sites and you spend... For first four sites, it will be initial development and transitional phase. So, you'd be working on a number of common features. But once you have the platform in place, the rest of the 16 sites can be spanned up very quickly like I mentioned. So, it really cuts down on the development cost. So, it really improves the efficiency of not only the development but also maintenance. And it provides you with better return on investment as well. So, it looks all nice and easy, but is it really straightforward? I would say yes for kind of common websites. So, you're talking about common corporate sites. So, you have information about your company, about your products and services and articles and quarterly reports and so on. Then, building those sites on this kind of platform would be technologically quite straightforward. However, because of the complexity, it comes with a number of challenges that are quite peculiar. So, I'd like to cover those. So, challenges... There are challenges in different phases. So, the first one is during the preparation phase and the second one is in the development phase and the third one is in operation and maintenance. So, during preparation phase, consensus within the company is very important because at least the companies and organizations that I've worked with, if they are operating globally, they have quite complex organizational structure and also each country office is quite autonomous. So, they have their own budget for web development. They can do whatever they want, basically. Well, there are budget restraints, but they don't have to... They can make own decisions on their web project. So, it makes it a little bit difficult to get a consensus on all the offices. So, when I worked with them, I had to help them share the image of success among those country offices. And also, there would be restrictions because the platform is shared. You can't do everything that you want to do there. There are some things you can't do or you have to collaborate with other offices. So, it can't be done as quickly as they wish. So, there would be some restrictions. So, they need to understand that. But there are benefits that are definitely worth the trouble. So, they need to understand this before this project can... In order for this project to succeed because you don't want them to drop off in the middle of the project. And you really need their support and understanding to lead the project to success. And also, this is kind of a common issue for any project. But selecting the right vendors is a big challenge because you have multiple offices. You'd be hiring multiple vendors. So, that makes it slightly more challenging than just selecting one right vendor. And the vendors must be highly competent. There's no question about that. They must know well about Drupal. And they need to be able to adhere to best practices. They need to know what they're doing, basically. But for main... So, in this kind of project, you would have two types of vendors. One is the main vendor who would be building and maintaining the platform. So, they have a great responsibility in this kind of project. And they need to be not only competent, but they need to have adequate resources because the project can be quite a big and time effort, I'm saying, intensive. So, they need to have adequate resource to be able to run this kind of project. And they need to be highly capable in managing projects because with this kind of project, you'd be working with an organization which has quite complex organizational structure, as well as you'd be working with local companies and vendors as well. So, they need to be able to manage that well. And as part of that, they need to be able to communicate well and they need to be able to manage customers' expectations well. So, local vendors, they would be, it depends, they need to be good developers, good triple shops, but what they need to do really depends on what the country sites need and how complete the platform is. If the platform can provide all the solutions that country sites need, they'd be doing some minor modifications. So, as long as they are experienced with Drupal and they understand Drupal's best practices and standards, it might be sufficient. They may not be doing any custom development. But they need to be, because the chances are they would be their mother tongue would be not the common language of the company. They need to be able to speak the company's common language fluently. So, if it's Spanish or English, they should be able to communicate well in those languages. So, in order to ensure that the vendors are capable, before signing a contract with them, you'd want to explicitly define a set of acceptance criteria and they must be able to understand that and execute that. So, if they need to be able to, they need to know what Drupal's best practices are in terms of development like security, performance, and so on. And they need to be able to, of course, deliver that. And it really helps to clearly define this before they sign the contract. And also, in terms of project management, it's more difficult to assess their capability. So, you can ask for references and ask for customers who are happy with the way they manage the project and you can ask them and get first-hand opinions and information about those vendors. So, the second challenge is during development phase. So, project management is, well, again, it's a common thing, but because of the complexity, it makes it quite challenging. I myself have come across a project that didn't go very well because of the complexity of the organizational structure and the communication. And also, maintaining quality. Since you would have multiple vendors working on the same code, you really need to think about maintainability. So, I'll go over these one by one. So, because the company is, the company that operates internationally would tend to have quite a complex organizational structure. Communication would be very complex and you would have multiple stakeholders involved from multiple departments involved in the project. So, as a result, there would be conflicting interests and requirements. And the problem I've faced was that within the company, there were two IT departments who were in charge of different parts of the platform. So, they had budget for certain parts of the platform and the other department had budget for some of the country websites and so on. And because they were not communicating with each other, the development shop had a real hard time capturing the requirements and building the right solution for them. So, managing communication is really a key. And in order to resolve that, you should simplify communication. The organization really needs to come up with a way to communicate the requirements to the development shop in a unified way. And also, to do that, you need to clarify responsibilities. And also, it happens quite often in traditional development methodologies such as waterfall, I don't know how common it is now, but I see that I see still being used. But if you stick to traditional development methodologies, you don't review often enough. So, you get a big documentation on requirements and you go off and spend three to six months building the solution. And finally, when you have the customer review it, they tell you that it wasn't what they wanted. So, reviewing frequently is very important. And through better communication and frequent review, providing better transparency can be possible. And also, a customer can't expect developers to understand what they want. They need to collaborate and they need to really be involved and be committed to the project for them to have developers build the right solution for them. So, in one word, basically, this is pretty much possible by doing Agile. So, how many of you use or are aware of Agile project management methodology? Okay, great. And do you use it in your projects? Yeah, yeah, great. Good to hear that. Okay, yeah. And also, you know, Agile, sorry? So, I can't hear you. Well, it depends. I mean, I think it depends on... I mean, personally, I've really... Yeah, yeah, exactly. It's a different mindset, really. And also, you know, the way budgeting is... budgeting works, you know, can be slightly different. So, doing it properly can be quite difficult, but you want to do it properly. And I've seen many projects that, you know, they say, you know, doing Agile, you know, didn't go very well because they weren't applying the methodology properly. It is challenging, but it comes with all the benefits that I just talked about. So, yeah, especially for this kind of complex projects, you want to have good communication going and you want to make sure that you work, you know, customers, the customer and developers work together to build the solutions that they need. So, I think Agile is a great solution for that. So, as for maintaining quality, I can't see the notes, so I'll find out what I've written up. So, the quality consists of different elements. So, I'm going to go through those. I'll try to remember what I've written. So, okay, ensuring scalability. This is slightly technical. Basically, when you build features for the platform, it should be as reusable as possible. So, if you build features that are too specific for certain sites, then you'd need to build, and if another site needs a feature that is almost identical but slightly different, you'll need to build another set of features that works for that site, and then you will end up with 5, 10 different features that are essentially the same but a little bit different. That makes it really difficult to maintain and it also doesn't really scale. So, there is a great presentation about this by Jeff Beeman. He's also an Aquian. He's a senior technical consultant, and he did a presentation on this at Sandcamp. So, if you're interested, you can see his presentation, the URL to that. Okay, and ensuring high maintainability. So, because it's not just the main vendor that would be working on the code, but you would have multiple vendors working on multiple sites that they would all go into the same repository. They all need to adhere to Drupal best practices, make sure they're doing the same thing in the same way. And also, you know, 5, 6 to 12 months down the line, if you need to make changes, you need to be able to know, you know, what code is doing what. So, it needs to be well documented. So, another thing, up until Drupal 7, some configurations are in the database. So, everything needs to be in the repository. There's a module called Features that allows you to do it. And there are Drupal API that also allows you to do this. So, with a combination of these two, you can really move everything, all the configuration into the code. And there's a great presentation on this, because I can't see the note. I can't remember the name of the company, but it's a Belgium slash Italy-based company who did the presentation on this. So, if you're interested, there's a URL at the bottom. And also, because you have multiple vendors working on the same chunk of code, you want to somehow restrict their access to the repository. A popular way to do it, we also use this at Acquia for some of the customers, is to use GitHub and pull requests. Basically, reviewers can accept or reject the request to merge the changes that vendors made. I'm working with a customer who is slightly... who doesn't have very much budget. And reviewing every single commit is too time-consuming and costly. So, what we've decided to do was to simplify that process a little bit by restricting access to directories. So, if one vendor is working on a site for New Zealand office, they'd only have access to the New Zealand... to the directory that contains the code for the New Zealand office. And Git, by default, doesn't give you that kind of granular access control, but Gitolite allows you to do that. So, that makes it a little bit more simpler to manage vendors' access to the repo. And there's this service called GitLab, which is based on Gitolite, and it allows you... it gives you the same... how do I say... it's quite similar to GitHub. So, they have this thing called merge request, which is essentially pull request, and you can manage users and teams in the same way, but it's more powerful. So, for this customer, we use this as well. And, like I mentioned, it's quite important that you make the components as reusable as possible and avoid unnecessary dependencies. So, you would only have one version. If you end up with multiple versions of site because of some dependencies with modules, then you'd end up in maintaining multiple versions of the site or multiple versions of the platform. So, it really degrades the meaning of having a platform. So, you'd want to stick to a single version of the platform. And having automated tests, continuous integration, which is also very important, because you make one change to the platform and that gets applied across all the 2030 sites. So, you want to make sure that those changes that are to common features don't break any sites. And also, if you're building a platform that, which, you know, 2030 sites is going to be based on, you want to have the platform built as nicely as possible. Before letting multiple country sites migrate to the platform, you'd want to do a site audit to make sure that the platform is built in a sound and maintainable fashion. And also, documentation, it's quite important. Well, it's, you know, it's important for any sites, really. Especially because it's shared among different country offices. Having a documentation which all the local vendors can refer to is quite important. So, it's not only about documenting your code, but documenting how features are built, how they should interact with, or how they should be put together, so on. That's quite important. Security is another challenge. So, making sure, you know, that there are, you know, common and easy mistakes that you can make to make your sites vulnerable. For example, enabling PHP filter or things like that. And this kind of check can be done by, you know, scripts. It can be automated. So, you should have that kind of automated checks for this kind of issue. And also, like site audit, doing a security audit for the platform would be quite important as well. And in terms of the performance, it's more or less common sense stuff. So, you know, you want to enable internal, external caching. And this is something that, if you're hosting your site on Acquia Cloud, we do this proactively. So, if a customer turns off their external caching by mistake, we'd get notified immediately because the site is in risk. So, you know, this kind of check can be also done manually. And also, because, well, if you decide to have all those country sites on the same stack, you'd want to perform a load test on all the sites on the stack because doing a load test on a single site wouldn't really make sense because the load that the stack would be experiencing is the sum of the load of all the sites. So, you'd want to perform a load test on the entire platform as a new site launches. So, as I mentioned, there are many, many things that need to be checked, but that can be done automatically. So, we built it. If you have your sites on Acquia Network, you can run this thing called Insight, which basically tells you the health of your site, how well it adheres to the best practices, how well it's set up in terms of SEO, how well it's set up in terms of performance. But you can also do this thing called Instant Insight. So, even if you're not an Acquia customer, you can go to this URL, so, insight.acquia.com slash instantinsight. And you enter a URL of your Drupal site and we do a scan and tell you how well your site is built, basically. It's quite interesting. And I don't know if it's still running, but there's a campaign that if you get a great aid for all the criteria, we'll send you a t-shirt. So, yeah, you can try that out and see how your site would be rated. Okay, so finally, the challenge is during the operation and maintenance phase. So, change, release and deploy management can be quite complex because of the number of sites you have as well as the number of vendors that are involved in the project. And also, because you would have different vendors and, you know, if you're outsourcing, hosting, support can be a little bit complex. So, I'll go through that one by one. So, governance, change management. Because multiple sites share the same code base, you'd really want to be careful about making changes. So, you need to, as you make or as you plan for changes, you'd need to assess and make sure that it would negatively affect some of the sites that you have. And you want to have, preferably, you want to have a formal process, like you'd want to have a change control board and, you know, you apply for the change and you assess the change and approve and things like that. And also, release management. When you make changes to common features, it would affect all the sites. So, you would want to do a regression test if the changes are significant. You'd want to do a regression test for all the sites. But in order to make sure that all the sites are functioning as they should, it can only be done really by the webmasters of the country sites, because no one would know how all those 20 sites should be behaving. Some sites may have some custom features and the people in the central office may not be aware of how it works exactly. So, by scheduling releases, you'd be able to allocate, you know, provide, send out notices and give them enough time to allocate resource for the regression test. And also, because you have multiple vendors involved in the development, you don't want all of them to be able to push code to production when they want. So, you'd need to have quite strict access control and deployment management as well. And for governance, using RACI, so RACI stands for Responsible, Accountable, Consulted and Informed. Having this kind of chart is really useful because you wouldn't be saying, okay, this vendor is responsible for doing this. But you can really describe more precisely which party is responsible for what action and also, even within the company, like I mentioned, companies would have a complex organizational structure. So you'd want to have which department is in charge of what action. And RACI really helps you to clarify. So, the challenge with support is that there would be multiple levels of support. Editors would be asking, you know, how to insert videos to an article, for example. And they may also find some pages that aren't functioning as they should. And there may be some issues with hosting. So, if an editor has a problem, they can, you know, some editorial issues, maybe they can resolve that internally. But some technical issues, for example, some blocks are not displaying. Or if, you know, if they get a white screen of death, who should they contact? Editors shouldn't have to... Editors don't have to know different vendors and they don't have to make decisions on whom to contact. So one way to resolve that is to, for example, build a web form with a decision tree in the back end. So by selecting a few options, you answer a few questions, like whether it's a problem with the website or some questions regarding content creation. And then the web form would send support tickets to respective parties. So it would simplify the communication. And also, if multiple parties are providing support, you want to make sure that it's comprehensive. And each vendor covers, you know, you should make sure each vendor covers what others are not covering. So you can, the support contract would cover all the foreseeable problems. And finally, there are legal requirements in different countries. For example, in the EU, you need to store all the personal information within the EU. So although, for example, Acquia uses some of the data centers in the States, we can't offer those to our European customers. They need to use the Amazon's data center in Ireland. And also, in Germany, there's a law that all the personal information needs to be stored within Germany. So they can't even use this data center in Ireland. So what we did was the site is hosted in the Ireland data center. But when you pull the customer information, that comes from some server that's hosted within Germany and that's displayed within the knife frame. It's pretty, you know, it's a bit silly, but it's a law and you have to adhere to that. And you want to make sure that you build the right solution that adheres to the law. And also, if you have all the 20 sites in one region, for example, if you have all those sites hosted in Ireland, but some of the websites are for, say, like Hong Kong and Singapore, there would be latency issues. So one obvious way to resolve that is by using CDN, like Akamai, for example. You can also distribute hosting as well. But if latency becomes a big issue, you want to certainly pay attention to that. So I think that's all. Thank you very much. And if you have any questions, I think we have five minutes. All right. How many sites is too much in one doc route? I think it's a tricky one. It kind of depends on what your stack is and also how complex your site is. But at Acquia, we have customers who have 80 sites on a single doc route or 120, I think. So, sorry, 160. Well, talk to us. I mean, I guess it depends on what kind of site it is, really. But from what I've seen, I'm pretty sure it's possible. Right. So what's the reason for dividing the two? Well, for latency reasons, you might want to consider geologically placing one set of sites in one region and another set of sites in another region. But if you can combine the two and run it in one geographical location, then I personally don't see an issue in that. Right. OK. Right. Right. So it's kind of a complex access control. I've only been dealt with what I just talked about. So one is GitHub, a pull request, or GitLab, which is basically built on GitLab. So do you want them to be able to push their change all the way across to the production or for continuous integration? OK. Shall we continue the discussion after? Well, listen, look, thank you so much, Mori. Could everyone please show their appreciation for Mori Sugimoto? Just really quickly, it's a coffee break now. The slides, Mori, we're OK to put them on the website, are we? So the slides will become available when all the slides for all the other sessions do. Every session is recorded, so we'll actually have not a transcript recording of the audio plus the slides on the website as well. And remember to fill in your session evaluation as well. So there's a special link that's popped up on the program schedule just recently that you can use to evaluate sessions. And we really appreciate your feedback with that. You can also put comments on the actual session page as well, which Mori's done sessions before and he always takes feedback into consideration to improve his talk as well. So thanks very much for your attention. Next we have coffee and we reconvene at quarter to four. Thank you very much.