The power of modular development

A modern digital platform doesn't just get built and then sit serving content pages for years without any changes or updates. Any system where you aren't continuously updating it to meet the needs of the business quickly becomes a legacy system, and other uncontrolled "micro-sites" will start popping up in other places (and all the FXM in the world can't make up for that!).

The counterpoint to this however is that constant uncontrolled change to any system can result in a big ball of mud.  When your digital platform is a key organisational asset this might get even worse when you have multiple development teams on multiple releases or across multiple vendors all working on the system at once.  Even when delivering in a single stream using Agile principles your solution can get messy without a clear underlying architecture "skeleton" to which you can add meat.

Sitecore's support for modular page composition through placeholders and modules provides a very good platform for building modular, componentised solutions.    Sitecore's Helix architecture provides a good starting point for thinking about this in it's section on Modules, however we have found a few other concepts and practices are helpful when delivering larger projects.

Feature level of modularity

I have seen several Sitecore implementation projects get into trouble by trying to deliver on a user story by user story basis.  Designing user experience for a story independent of other related functionality can lead to an anti-pattern that I can "UX micro-optimisation".  UX can get micro-optimised when each individual interaction is designed and refined in isolation of the overall system.  Even when real user testing is done and the feedback used (after all the road to hell is paved with good intentions), if an interaction is not consistent with the way the rest of a system works the overall impact can be a degradation of user experience.  In addition the fact that a slightly different pattern or approach is used in each place can multiply the implementation effort and cost of a solution.

The approach I favour I like to call "feature modules".  In this approach we consider a functional area of the solution as a whole, and do a level of design to establish the key patterns for how that functional area works.  An example of a feature module could be something like "events" or "media gallery" or even "search".  A good feature module exhibits those key call signs of good architecture - high cohesion and low coupling.  That is all functions in the feature module tend to be closely related to each other, but have few dependencies with other feature modules.  These feature modules become the "epics" of our implementation, and we do at least a high level MVP UX design for each one as the corner-stone of our solution.

Furthermore as we deliver across feature modules we try to create core UX patterns that can be reused - things such as consistent approaches to calls to action, listings and search.  Getting these laid down in a way that prevents too much rework means thinking about the order of design and delivery of your feature modules so that perhaps you consider those likely to have similar patterns at the design phase before progressing any into development.  This might seem heretical to some agile practitioners, but to my mind the real aim of agile is to reduce waste by not building things you don't need - and building something without considering another related piece of functionality you know you need to build seems to me a definite path to waste!  The key here is to understand what the MVP is of each of the features that you need to deliver.

Once a feature module has been developed, the renderings it contains can be used in appropriate placeholders across the site and mixed-and-matched where appropriate to create a website greater than the sum of it's parts.

Supporting multiple development streams

If you have ever worked on a large code-base you will know that the key things that will start to trip you up after a while are changes that require you to touch code across multiple parts of the solution, or having multiple changes occurring in different parts (or even worse, the same part) or the code by different teams or developers trying to achieve different things.  Having to then deploy a monolithic artifact and hope that there wasn't an unexpected side effect (or spend weeks in regression testing) is not much fun at all!  Automated regression testing suites can help here, but aren't a substitute for good architecture!

One of the key advantages to this modular architecture is that is separates functional areas together into cohesive solutions that are likely to change together at a separate rate to other parts of the system.  We like to have each feature module implemented in it's own self contained solution that builds into it's own deployment artifact.  This results in a module that can be deployed independently, with full confidence about what parts of the site are and aren't being changed.  This is a very similar pattern to that used in Micro-service design where each micro-service is independent of others to reduce side effects of changes rippling beyond the micro-service boundary.  Both these concepts also align quite neatly to the Bounded Context concept in Domain Driven Design.

With a few fairly simple conventions it is also quite easy to create architectural guidance that will let different streams -- or even different vendors -- create and update feature modules separately with minimal risk to the solution.  The key factors to consider are:

• Always use Sitecore patch files based on the module name to inject configuration for your feature module
• Have a consistent approach based around module name for website folder for things such as views
• A similar folder naming structure should be used for Sitecore items for templates, renderings and other Sitecore items. 
• Use a module naming conventions as a part of your module namespaces and assembly naming.

With these standards in place, you can create a build artifact containing website files (config files, assemblies, views) and Sitecore items (we have recently made the jump from TDS to Unicorn for managing these) and easily deploy it independently into your solution.

Conclusion

I hope this has given some high level patterns that you can use as you are planning and designing your Sitecore implementation. Taking these patterns in conjunction with the Microservice pattern (with microservices aligned with and supporting feature modules where functional business logic needs to be delivered) will help ensure you are building not just for your current project/release horizon, but will have a solution that can be easily enhanced and updated over a number of years by multiple parties, and without getting dragged into a morass of regression testing and side-effects!

These concepts are also underpin our approach to delivering Sitecore digital platforms based on frameworks to support multi-instance rollouts with a shared code base.  This is a pattern with application to deployments for very large multi-national organisations, which I will aim to address in a future post.