A Multisite Drastically Reduces the Technological Debt in an Organisation

When it comes to building and maintaining many websites, companies often struggle. With various requirements, technologies, agencies and standards, they often end up with a massive technological debt which eventually has to be paid by rebuilding the websites from scratch. The accumulation of debt then typically starts all over again.

To break the endless cycle, companies can use a multisite approach, which brings standardisation and reduces the amount of debt carried.

The need for many websites

With the web taking over more and more of the communication with the company’s audiences, the need for multiple websites is growing.

• Where once companies could have one global website they now have to be able to address each market separately.
• Where they could list all brands on one website, they now have to create a separate website per each brand to be able to communicate with each niche better.
• Sometimes, even on the level of a single brand, a few websites may be required:
  • one for the global audience,
  • and another for example for a particular section of customers who are a small fraction in terms of numbers but large in terms of turnover,
  • and then another for an event or a conference that the brand holds every year.

The need to build multiple websites grows. So do the problems with maintaining all the websites that get created. Let’s examine various approaches companies take and what are the outcomes.

A “free to build” approach to web development

The most common approach these days to web development is allowing each cost centre or profit centre to build the websites it needs and in the way, it wants to do that. Deeper in the organisation, in a profit centre, if a department (typically marketing, but there can be other ones as well), decides it needs an additional website, it is let free to build what it wants and how it wants it.

This approach seems great in theory - those closest to the business know best what they need - but it starts to stumble really quickly.

Each website is completely different

To build a website each team sets its own plans, decides what it wants, creates specification, finds and hires an agency and then builds the website with it. The technology powering each website will therefore depend more on the skillsets of the team or even more likely on the skillsets of the chosen agency:

• some will be open-source, some will be proprietary,
• some will be hosted in house, some will be hosted by the agency and some will be hosted in a completely different setup with a 3rd party hosting provider.

Apart from the technologies, each website will look different and will achieve similar requirements in different ways: eg. a store locator of one brand might be a map where you can zoom in and a different brand might ask users to filter by city.

Maintaining each website separately is very expensive

The cost of building each website separately is quite high and quickly outpaces a multisite approach (possibly already at website 3 or 4), but the biggest hurdles start when maintaining is required.

If each website is built differently and by different teams, maintenance is also done by separate teams with skill sets in the particular technology. This is a massive cost.

Let’s calculate:

If a company has 50 websites and a website requires around 20 hours a month of maintenance (this is super low for a bigger website), it has to pay for 1000 hours of maintenance every month!!! This number only increases if active development has to be done (features added, campaigns launched etc).

How do companies manage this? They typically don’t... 

The “less important” websites are typically built once and then never maintained. They are just left there not updated what raises the question whether it made sense to build them in the first place. Those that need upkeep are maintained on an ad-hoc basis.

As time goes on, the uncared for websites became outdated. The agency that built them is long gone since there was no budget for a support contract. The technology gets outdated. Security exploits are identified. Eventually, the website looks old and something has to be done about it because it is bad for the brand. But no one knows how to handle the legacy code base and each agency recommends rebuilding.

If the website is not rebuilt on time, it is typically hacked. As more and more known exploits are found, eventually one or more automated bots find a security hole. The website becomes part of a botnet or starts mining bitcoin or redirects to websites with malware. It is then taken down and… yes - rebuilt.

Only the main websites are cared for in a typical company. Still though - each by a separate team. If the company has 10 of these (eg. 1 brand in 10 countries) it will have to pay 10 retainers to 10 separate agencies just to maintain. If any website wants to add a new feature, it has to scope it, get an estimate and pay for it. If all websites want the same thing - the cost has to be incurred 10 times.

The above is repeated in each profit centre and department of the company, every single time separately, creating a massive cost and a plethora of technologies and approaches to handle.

A “guidance” approach to web development

Obviously, many companies realized that the freedom to build approach is not optimal and they are trying to mitigate. One of the most common ways to do that is to use guidance or policy.

Headquarters will publish guidance on “how we build websites” and will expect everyone to follow. The policy will typically include information about technologies used and some recommendations on implementation on the technological side. Eg. the company might require all websites to be built on Drupal and hosted in AWS.

The guidance more and more often includes design requirements and it must be said here, many companies have created really great tools to allow all teams to use a standard approach to the visuals. A list of various design systems is really impressive.

Guidance is better but only goes halfway

The policy approach is better. It reduces the technological debt a company carries. If the policy is followed, the company uses only a few technologies and even though separate teams and agencies typically build the websites, some economies can be achieved:

1. Even though it is difficult, the company can arbitrage a little by comparing costs between teams and agencies. It can also compare the quality of the output.
2. Some re-use of code might be possible when one team builds something and shares it with others. This will not always be possible though, because despite using the same technology, the websites might still differ substantially in their architecture.
3. All agencies the company works with have experience in the same technology, so at least in theory, one agency could take over another agency's work. In practice, though this is fairly difficult because separate teams mostly do not communicate, even though they do the same thing.

Using a policy or guidance is a step in the right direction, it is however not enough to manage technical debt effectively. As we have seen, doing Drupal consulting for many clients, companies still have many teams build things completely separately and re-use or economies of scale are limited. Costs of maintenance typically also do not go down very much.

Multisite (one codebase) approach

The final and the most successful way of managing many websites is a multisite approach.

A multisite means building many websites on the same codebase. The idea is that most of the websites the company builds are typically quite similar (eg. a website of the same brand but for multiple countries). If we build a website once, we can re-use what we built on all these websites, perhaps just adding a few customisations here and there. We wrote a separate article which details how Drupal multisite works.

Building a Drupal multisite requires a bit more planning and discipline than building one website but the investment is quickly recouped.

1. If we have one boilerplate, we can launch multiple websites quickly. No more need for multiple teams, planning processes etc. and a separate agency for each website. Money saved repeating this process multiple times, can be spent on maintenance, improvements or other activities to make the multisite better overall.
2. There is just one codebase that has to be taken care of. Thanks to this, keeping it up to date and secure is much easier and cheaper. One small team can maintain code for hundreds of websites. Because it uses a budget that would otherwise have to be shared between many separate websites, it can do a much more focused and better job at delivering high-quality solutions.
3. Feature reuse is the standard. If something is improved or fixed for one website - all websites can get the benefit.
4. If for some reason, the codebase became outdated and would have to be migrated to something new, the project will be bigger but we can migrate one website after another using one team and delivering an improved version to websites.

Overall, building just one codebase on a multi-site, drastically reduces the amount of code, the number of people involved and maintenance requirements. It ensures that all websites in the organisation are secure and up to date and that there is someone who maintains them, knows how they work and can lend a hand to all teams that use them.

Additionally, what we receive from a multisite is the standardisation of approaches. A store locator can work in the same way in all countries. We can spend time working out the best solutions and then deploy them to hundreds of websites.

Summary

If you are planning on building a multisite but are not sure where to start or if this is the right approach for your project, check out our Drupal multisite offer and contact us to talk about your requirements.