Site Factory
Multisite Governance & Delivery Issues
An interview with Will Eisner, Senior Director, Product at Acquia. Will's primary focus is on Acquia Cloud Site Factory, which helps organizations create and manage many sites, from a dozen to thousands.
Also sitting in on the interview, via conference line, was Sonya Kovacic, a Junior Product Manager at Acquia who also works on Site Factory. Sonya's comments are featured in Part 3 and Part 5 of this series.
The interview was conducted by DC Denison, Senior Editor, Technology, at Acquia, who is represented by the letter Q.
For typical technical site teams and managers, when they're trying out a new technology like Drupal they will start by running a couple sites using the new technology and when it goes well, they start to think, This is something that we like. Then they decide that they want to build more and more sites, more and more things with the new technology.
Yes. We have plenty of organizations who come to us and they're in a situation where they have dozens or even hundreds of different sites running on different versions of Drupal, different Drupal code bases. Then, of course, they've also mixed in other non-Drupal platforms that they might have, other content management systems and legacy platforms, or just other technologies that other groups prefer.
When we talk to these organizations they're in a situation where they've benefitted from having a lot of creative agility. Different teams in the organization have been able to spin up sites and create cool, exciting content, which is why they picked these new platforms. But they are now in a situation that's becoming unmanageable, and very difficult to scale.
Well, let's say a very important security update comes out. Imagine, for example, the Drupal Association announces a high priority security patch. All of a sudden, now this site team is basically in a panic mode, where they have hundreds of Drupal code bases running. They do not know where the code bases are necessarily, and they don't necessarily even have access to them.
Now they have to go through a panicked process of testing all these different sites: test each one separately, test the upgrade, then install it separately in each of these sites.
This isn't a theoretical thing. This is something that happened last year when an important Drupal security update occurred. We had real organizations that we work with talking about working day and night for a couple of days just patching and testing literally hundreds of code bases throughout the organization.
Sure. You could imagine a company that has a particular system that they're using for marketing automation integration, or something like that. Let's say they want to upgrade to a new version of that internal system. They need to have a corresponding upgrade to the Drupal module that talks to that system.
Now they have the same problem, right? They've got to update all these different sites they don't have control over. So having this kind of site sprawl is a real pain.
What happens, unfortunately, is that some organizations react to this situation by instituting a very locked down kind of solution...
Yes. Basically, they say, Okay. You're going to be able to change this logo, and you can turn on this feature, and you can change this, and so on. But most of the time, that's not a good alternative. Sure, it's great for governance to have one code base that you can just update once, but then you get into a situation where the people who are driving the goals of the business by being creative are handcuffed. Basically they can't do their jobs and they aren't happy. Our customers, and the prospects who come to us, they are digital platform owners who aware of this. So we're often talking to digital teams that are trying to figure out, How can I scale all these sites and digital experiences in my company in a way that maintains the ability for the creative people to do their thing? Because they know that if they try to lock it down, it's not going to work.
Right. They have to have something better than that, but they also just can't let it be the Wild West.
Here's one other example: when you have a Drupal code base, that's an application. There might be a continuous integration workflow that you use to make updates to that, right? If you're working with an outside agency to build that site, you'll inherit whatever continuous integration workflow they used. So we encounter organizations that have different tool sets that they use for different Drupal sites.
The customers we work with are not trying to differentiate their businesses based on creating tools for managing lots of sites. They're differentiating based on the products that they make and the digital experience that they present.
They want to deliver a mix that gives their team flexibility to be creative in how they deliver content, but they also need a maintainable and manageable infrastructure. That's the balance that they're trying to strike and it's a difficult one. There are different ways that you can try to do that.
Next: the Site Factory approach to managing multiple sites.
Site Factory