Supporting global organisations through framework based digital platforms

In my last couple of posts I've talked about when to choose a multi-site versus a multi-instance pattern for deploying Sitecore, and how we approach delivering Sitecore platforms using feature based modular development.

In this post I'm going to take a look at the sorts of issues that arise when large global organisations start to look at rolling out digital platforms, and how some we can leverage some of the points that we've covered in the last couple of posts as a part of our approach to designing a Sitecore based digital platform architecture that addresses them.

Tyrannies of global size

Large organisations hosting a number of different websites are often confronted by some competing forces which lead them to ask about whether they should have multiple sites in a single or multiple Sitecore instances.  These are usually related to the following requirements which address different types of web presence for different parts of a business:

  • We have different sites which are managed by multiple business stakeholders
  • We need to ensure that the sites can be developed separately
  • We don't want our site to be implemented when another site is deploying updates or undergoing maintenance
Although there are ways to manage these in a single instance, these are the requirements that often point to separating instances as a consideration.

However as organisations increase in size and become global, their issues change slightly and become more about country by country versions of a single conceptual site :

  • We want to centralise the delivery and maintenance of our core digital platform and provide it to our offices to provide consistency across our brand whilst reducing overall costs
  • However we know that individual local markets have their own drivers, we need to empower local offices to react to market conditions to maintain flexibility and competitiveness
These requirements are actually quite similar in a lot of ways, however the main difference comes with the ability to provide a core platform that can be used by disparate groups of client sites, and that can be maintained and updated centrally whilst also being extended and controlled locally.  What we really need to deliver this is a framework that can deliver core features whilst allowing controlled extension.

Modular framework architecture

As we discussed in the previous post, we follow a modular pattern for building "feature modules" as the basis for Sitecore platforms.  In this approach we build individual modules containing related renderings, templates and business logic that delivers a specific functional outcome - such as "events" or "media galleries".  

Our framework architecture approach provides a basis for unifying and using feature modules together to produce a core set of features which can be used to deliver sites.  It consists of the following components:

  • Shared framework services - this layer provides underlying ORM and field mapping services for a consistent development approach.  All other layers in the solution use this shared framework.  
  • Base Site - a feature module that contains core components for assembling a site, primarily the main layout and higher-order renderings providing general one, two and three column layouts and common metadata and navigation controls.  This base site depends only on the shared framework, and the code for it is controlled by the central team providing the platform to the organisation.
  • Core feature modules - a number of core feature modules which make up a set of functions provided and supported by the central roll-out team.  These are feature modules supporting key organisational requirements, such as consistent presentation of product information or search features.  A core module can sometimes depend on a certain base site version, for example if it expects a particular wrapping HTML structure for it's rendering to correctly display.
  • Local feature modules - individual local offices in the organisation may need specific functionality to meet local strategic objectives or address local market conditions.  These are developed and maintained locally as separate feature modules but in line with framework architectural conventions and subject to central architectural review.  Importantly, if a core feature module doesn't meet the exact requirements of a core feature module, then a local feature module is developed (possibly off a copy of the core feature) to meet the exact requirement - however local feature modules are not supported centrally.
  • Site configurations - Each site deployed on the framework will have a site configuration which will specify how base site, core and local feature modules are used within that specific site.  This will generally incorporate configuration settings such as <site> node and Sitecore configuration such as the site root item and base IA structure, placeholder settings, insert options, and permissions.  Site configuration will often also include styling information for a particular site including CSS, icons and logos.  However it is important that each feature module includes CSS and JavaScript particular to it and that site level styling overrides this. Site configuration is generally managed by the local team as a part of a rollout to the specific geography, but comprises configuration rather than custom code.  These are similar to "lite" feature modules without rendering code or business logic.

Dependency management

One of the key requirements when the core platform is maintained by a central team is to be able to roll out fixes and enhancements which can then be utilised by local offices.  However it is important that the local offices have control over their own customisations, and ideally when upgrades to the core platform are applied.  In some cases local feature modules may rely on certain core modules of base site features being available to work correctly, and site configurations will also rely on certain renderings and templates being available which may require a particular base site or core/local feature module being available.

This introduces dependency management as a core discipline when implementing a framework based platform.  Each time the is a dependency between two modules (including between a site configuration and a module) that dependency needs to be tracked.  This could be done manually, such as by a wiki page or spreasheet, but where a more dynamic cloud platform is being used it is more likely that these will be tracked in a more automated way.  This could be through a configuration management tool such as Puppet and enforced at install/deploy time, or could be via relationships between  packages in a tool such as NuGet and assembed at build time.  Generally the later in the deployment pipeline different modules are mixed together the better as it supports deployment of the minimum amount of code for an update.

Distributed hosting and content sharing

One of the key advantages of a framework based platform architecture is that is allows a consistent set of features to be delivered and maintained separately even across multiple different instances.  This supports an architecture where global organisations can deploy delivery farms in local data centres to reduce latency, whilst still enjoying the benefits of central control and maintenance.  

It should be noted however that in situations where there is central content that also needs to be shared (e.g. central organisational or product information) this approach shares some of the same challenges as outlined in my previous multi-site vs multi-instance post.  Some of the approaches that I mentioned in that post (such as data providers) would also work in this instance, however given that the source content structures are going to match the locally deployed core feature module code this should be easier, and the data provider could even be developed as a feature module itself to make these patterns easier to use.


Global organisations could achieve significant cost optimisation and greater control of  brand experience through the rollout of a central digital platform.  This could be done whilst still allowing a level of self-determinism and flexibility for local offices to react to their local market conditions through the implementation of a framework approach supporting locally developed modules co-existing with globally controlled core capabilities, however care needs to be taken to establish proper framework architecture and dependency management to ensure maintainability.

As it turns out, the architecture for this sort of organisations is very similar to the framework approach that we use at Deloitte Digital for our Sitecore Platform managed service architecture, which needs to address many of exactly the same issues.


Post a comment