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.
Know the Kind of Multisite Architecture You Need
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:
- A clone: This is when all sites managed by the organizations are expected to have the same look and feel, with only minor variations from one site to another. So the layout, the components in use, the content types, the features and functionalities are the same across sites, while only some elements of branding are different for each site. This is usually the case with multi-regional or multilingual sites, where the base website just needs to be replicated as is in different languages with no other changes.
- Feature Flexible: This is a little more complex than the clones because, beyond a base template, there is a requirement for different features on different sites. This requires a deeper level of change management as well as communication for contributors working on the platform.
- Snowflake: These kinds of sites have modifications unique for each of them. They may have entirely different theming and backend development. This often leads to these sites needing their own unique site architecture that may change frequently. A snowflake will most likely be the main organization’s website, where the major value of the digital business, such as e-commerce or customer support, will be housed.
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.
Build Out the Features Matrix
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:
- The required customizations from each site/stakeholder
- The list of required integrations across different sites
- The set of shared and unique features and widgets that need to be built and can be reused across sites
- The kind of access and permissions that need to be provided to the teams managing individual sites
Plan the Information Architecture
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:
- Create a list of categorizations and classifications currently used by the various websites
- Perform an audit to consolidate most of that infrastructure. Evaluate what can be standardized and document it to help bring consistency in how individual brand teams work in terms of website updates, content publishing, and creating a unique experience on their site.
- Create a spreadsheet of all content types, taxonomies and metadata that you need to support and map them to centralized structures if they are to be reused.
Think Through User Access
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:
- Individual website teams and specific roles within them, like a marketer, editor etc, can have access to create new pages or new websites by pulling together different modules and components
- These stakeholders can also be the ones who can add or delete different functionalities or modules to their websites
- You also need to ensure that users/authors on one site do not have permission to edit or publish content of a different website
- No individual website team can have access to change or modify any component on the base platform
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.
Plan Your Multisite Architecture Roll-Out
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:
- Plan the maximum amount of your project timeline for creating the base site. The success of your multisite architecture depends on how this is designed
- Map out effective processes for staging and syncing across different websites. This could be editorial workflows or deployment workflows for different features, wherein new content or new updates are centrally managed in a staging environment, and then synchronized across different sites
- Create processes that give quick access to different website editorial teams so they can start adding content to sites. This is specifically when spinning out new sites, as site-building and content creation can run in parallel to speed up the time to market.
- Create a roadmap for consistently training individual website teams on how to correctly operate within the multisite architecture, the benefits they can leverage, and the possible inefficient processes that they should avoid
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.
