Introduction
One of the beautiful parts of Sitecore is that it doesn’t force you into a particular implementation pattern. You can build websites as small and simple as you like, or as large and complex as you need. You can have a single website driven by the CMS, or dozens hosted out of the same installation. You can extend the CMS in multiple ways, and employ different strategies for managing your content. Unfortunately, this flexibility can lead to difficult decisions- especially if you don’t have the experience to fall back on what you’ve done in the past. When we at Brainjocks, now Perficient, are tasked with a project that requires large-scale multi-tenancy for an enterprise, we usually think about a pattern that we’ve pioneered in the past: the Enterprise Accelerator.
If you’re struggling with a large multi-site implementation in Sitecore, this series is for you. Enterprise Accelerators are the approach we use when it comes to handling multi-site implementations effectively and efficiently. I’ve been working in this realm for the past three years across multiple implementations, and during that time we’ve established lots of patterns that really empower this concept. Over the next few posts, I’ll share them with you.
What is an Enterprise Layer?
At the core, what we’re attempting to do is find the commonalities among all of the brand sites in a multi-site implementation and capture them in a generic component layer. Sitecore supports multi-tenancy natively, so this naturally fits the architectural model of a multi-tenant CMS implementation. This could include anything from integration points, to how you store and present products, or how search is implemented, how you handle errors, and more. If we combine this architecture with accelerator techniques, we can churn out websites at a rapid pace.
If you’re using an accelerator for your website (which I highly recommend), this becomes incredibly powerful. Think of it as an accelerator specific to your business needs, not just specific to making generic websites. Need to integrate with Bazaar Voice and allow for product reviews across a dozen websites? Looking to read jobs out of Career Builder and present them to prospective candidates across different recruiting websites? What if you need to integrate with Salesforce for lead tracking? Want to be able to handle SEO in the same way across all of your brands? What about security and authentication standardization? No problem, let’s build it in the common enterprise layer.
A Practical Example
To give you an example, let’s assume that we’re working at a multi-national corporation that specializes in placing candidates into jobs. In this example, recruiting is our enterprise’s bread and butter (yours may be Products, News, or any number of concepts). We have multiple brand sites, and each specializes in a different area (legal recruiting, information technology recruiting, healthcare recruiting, etc). Each brand site has its own theme and marketing agenda, its own content authors, and its own business stakeholders. One of the many things that they have in common is their need to display a list of relevant jobs to prospective candidates.
In Brand Alpha, a single job tile may look like this:
However, our Brand Bravo design team thinks that jobs should look like this, and Brand Bravo’s marketing team loves it:
And finally, Brand Charlie really wants their jobs to look like this:
In this case, we have three websites with drastically different themes across the same data points. All jobs have a title, they have a location, they have a reference ID, they have a description, and so on. On each website, we show a portion of these data points but not all of them. On some sites the title is a link, and others have a read more button. Some display a logo for the company, while others do not. This is a perfect candidate for an Enterprise Layer to provide this concept in a generic way so that each website doesn’t have to re-invent the wheel when it comes to “how-do-we-handle-jobs”. The best part is that if you pull this off correctly, your enterprise accelerator can support hundreds of possible tile designs, and your content authors will be able to switch content in and out for each website easily, utilizing a common component layer.
Why do you call it an Enterprise Accelerator?
The Enterprise Layer is only half of the secret sauce. Anyone can make a single solution house multiple websites. That’s not what we want to do. What we want to do is pick an accelerator (e.g., SXA, SCORE, etc) and create extensions to it. These extensions should be housed in their own solution (separated from the tenant website solutions), and should install on top of our accelerator of choice. Additionally, when we start a new website, we don’t want to start with what our accelerator gives us by default. We don’t want to start with a blank SXA or SCORE site, that’s just too much work. Instead, we want to enhance our accelerator’s website scaffolding to also include our custom extensions, components, page types, settings, site structure, and more. Scaffolding is the formula and instructions by which a new site is created.
Scaffolding should provide you with a few things (a bit subject to opinion, but this is how I handle it):
- A solution for each website, which is pre-configured to align with how your organization builds websites. For example: sass compilation, unit test frameworks, script bundling, and other features that you normally set up manually on each and every project. Creating a new solution should not be a multi-hour or multi-day exercise. Instead, we can use the power of automation to generate a new solution in around 15 minutes… but more on that later.
- A content tree for each website, which is pre-configured to align with how your enterprise layer and Sitecore accelerator organize the content tree. Templates, placeholder settings, content items, script modules- anything that you create for each of your websites should just come automatically by your enterprise scaffolding. Again, we take the process from a error-prone, multi-day ordeal down to a button click and 15 minute wait… but more on this later too!
- And of course, because each of our tenant website solutions follow the same structure, we can have consistency amongst our continuous integration builds. Each solution follows the same pattern, each CI build looks the same, and we simply point each CI build to a different repository accordingly.
What goes in my Enterprise Accelerator?
This is one of the most important architectural decisions you can make if you follow this path. I’ve worked on multiple enterprise layers, and each had a different philosophy. Firstly, you must inventory and identify the integration points and concepts utilized across your enterprise. From there, you can start to determine how frequently elements are used. For instance, if you find that roughly 75% of your websites all feature a Brightcove video, then it may be worthwhile to build out Brightcove integration as part of your enterprise layer. If only 2 of your 20 websites display a Google Maps component, then it may not be worthwhile to build in your enterprise layer (remember, each tenant site has its own solution, so they can each bring their own components to the table). Identifying what to build and prioritizing these elements in a backlog is critical, and will require an architectural vision.
So why do I need an Enterprise Accelerator?
Time to market. Reduced maintenance costs. Consistency for content authors. These are a few of the benefits that you can see when you follow this technique. You can have great success with this concept. On one of my recent projects we:
- Took six sites to production within a year.
- Built websites ranging from 100 pages in a single language to 1000 pages in 10 languages.
- Were able to take a website from zero to production in a week, and deploy weekly updates until the website was finished.
- Provide continuous updates across multiple web properties weekly.
Granted, this wasn’t an over-night transformation, and enterprise layers are not a silver bullet. However, when utilized correctly they can bring you tremendous amounts of success for your investment. Over the next few posts, I’ll explore some common scenarios and how you can piece together an effective enterprise layer by blending known Sitecore techniques together.
