A multisite architecture gives global businesses two key advantages - speed to launch new ventures, and a way to keep costs low even as they enhance the digital experience for their customers. So they have multiple websites that showcase different products, or talk to different regions, or kickstart specific marketing campaigns - all being managed centrally, on a single codebase, but with enough flexibility to customize individual sites as required.
While that is the final result of a multisite architecture, a lot of its success depends upon how it was conceptualized and built. While the idea remains simple, a multisite setup for any business needs to be carefully calibrated to their requirements. And that is why it’s important to understand how to start thinking about multisite architecture.
Here we take a look at some of the basic questions you need to answer and evaluate, and the aspects you need to plan, in order to create an effective multisite architecture.
The first decision that a business needs to make before adopting a multisite architecture is evaluating and finalizing the type of setup that will suit them the best. There are three types of multisite architecture sites:
In order to decide the kind of multisite you need, you have to first evaluate the reason for wanting to build a multisite solution in the first place. While delivering a project like this, we usually bring to the table the different brands' teams within the organization to reach common ground on how the different sites relate to each other and then make this decision.
The next key requirement for a multisite architecture is to understand the features matrix.
A majority of multisite implementations work on the principle of having a base platform that has all the modules that can be shared by the different sites.
The goal is to build this platform in a manner that requires individual sites to do as little customization as possible. And hence, mapping out a features matrix becomes crucial.
The features matrix is a list of the features different websites want and comparing that across the board. Again, this is something that should be done with all brand teams present in the same room, to get the most accurate information around their individual requirements. It looks something like this:
Once this is in place, you can take a look at the complete set of features that need to be built. For example, in the image, we have a list of ten features, where Site 1 needs all of them while the other sites need some of them but not all. When you have a similar matrix for all the features, you get a sense of what your base platform should look like, what features you should build out.
This matrix also gives you a view of how many websites want a particular feature and prioritize building them accordingly. Key features that a majority of sites need to get built first, and then you move on to building the ones that are required by fewer sites.
This exercise can also be extended to map not just features but the whole range of shared resources required across sites. That will give you a consolidated view of:
With different websites now coming under the same umbrella, it becomes important to understand the hierarchy and information architecture at play. You want the multisite setup to bring in more consistency and standardization across the sites and for that you need to understand the existing structure of relationships, and how to preserve them within the new setup.
A few useful steps here could be:
While multisite architecture is all about simplifying processes and empowering individual website teams to deliver brand-consistent experiences, there is also an element of governance that has to be built into the system. And that is where user access and permissions come into play.
The key here is to define who can access what, and who can make changes to which elements. A few points to consider here are:
While these are some simple examples, your multisite architecture can have a much granular level of access controls depending upon how your website teams operate. What’s crucial is to think through the kind of access that needs to be shared with different users, and how that is enabled within your architecture.
On an effective multisite project,
Effort for building all sites = Effort for building the first website + (Effort for building next site * Number of sites)
So the bulk of the work is involved in building the first or the base site. The site infrastructure has to be set up in a manner that it can be reused quickly by other sites. All new sites need is to replicate the base site, set up the right URL and permissions, and then begin to add or remove any modules they want in order to customize and launch it.
So in terms of planning you multisite architecture setup and deployment, here are a few things that you will need to keep in mind:
And those are some of the basic steps to approaching a multisite architecture. While the process appears simple enough and organizations understand why these are necessary, actually executing this process might get a little complicated. So even as in-house teams can evaluate their requirements or bring independent website teams together to map out feature requirements, they are usually not adept at making the right technical decisions based on that information. Sometimes they might miss asking the right questions, leading to an expensive architecture overhaul that doesn’t meet their needs.
This is where it becomes important to have an experienced technology partner that can guide the initial discovery phase, help make the right choices, and then execute a multisite architecture project.
Srijan teams have worked with several global enterprises to deliver multisite architecture with the Drupal multisite solution. We understand the business and technological nuances involved in a large-scale multisite setup and have the expertise to help you successfully navigate the discovery, development and deployment phases of the project.
Looking to consolidate your digital presence with a multisite architecture? Let’s start the conversation on how Srijan can help.