If you ever wondered, how to manage Sitecore in a way to have a really solid foundation and at the same time quickly react (or be proactive) in fast-changing business requirement situations, Sitecore can accommodate these needs using a variety of ways.
There is a term coined by McKinsey, called Two-Speed architecture. Although this term is mainly aimed at Enterprise Architecture, some of its principles are applicable to Sitecore installations as well.
With some exceptions, every typical Sitecore implementation suffers many times from a situation, where the budget holder – typically a person with business interests (like marketing, sales etc.) has an expectation and most likely a plan on ROI from the Sitecore implementation, while the solution provider – typically the Implementation partner along with the IT or Systems department of the client company, have the need to build a solid foundation capable of withstanding the tooth of time.
While it is true that proper architecture, design, thinking-through and development are the essential foundation for a solid solution, it is also true that these activities do not come at a fast-pace and ultimately their robustness and deriving cost can potentially outweigh covering the needs of the business stakeholders.
Would it not be nice, if we just had an option, how to build a solid foundation but at the same time provide the required fast-paced business stakeholders with the requested functionalities?
And here we have Sitecore, coming with a few aces up its sleeve.
Tools Available In Sitecore
Classic Sitecore Development
In the classic development approach, Sitecore offers a strict separation of content and presentation in its architecture conception. However, Content and Presentation are bound on the Sitecore side to assemble the final experience (most typically a website). This requires development and deployment for changes of the front-end components which is typically prioritized and approached within the classic Sitecore delivery lifecycle.
Standard Sitecore development is how the vas majority of Sitecore-based websites are conceived.
As classic Sitecore development we understand the development of C#.NET MVC web application that is entirely managed by Sitecore, including content management and presentation rendering (Sitecore renders the web pages).
While this is the most traditional and solid way of building websites on Sitecore, it does come with a few drawbacks:
- The delivery stream is very linear – from design to deployment.
- The solutions require significant coordination when scaling the number of teams working on them.
- The solutions require skilled developers not only in Sitecore, but also in the approach specific to the solution in question.
- Multi-vendor implementations are potentially a problem, especially when a single source-control is to be used and everybody can manage everybody else’s code.
- Total time to production from the requirement conception can span even several sprints (when delivered in an agile way).
All these points are to be considered in a Sitecore project and if they do not present a showstopper, everybody is happy. If they represent a problem however, SXA and JSS can provide just what is necessary.
Sitecore Experience Accelerators (SXA)
SXA is a Sitecore module that allows for quick creation of completely new websites on Sitecore, fully administered by content teams, with zero to little assistance from Sitecore Development teams. SXA achieves this by a set of pre-built components that act as a quasi-wireframing tool to assemble the structure of pages and come with a set of modifications to standard Sitecore pipelines enabling editors to do more from the Sitecore GUI. SXA uses the almighty Sitecore PowerShell Extensions as an underlying layer for governing many of its building tasks.
After building the pages, editors export a CSS and JS standards-based styling file to be modified by any HTML coder with no necessity to have Sitecore knowledge and access. In the meantime, content teams can work on the productive content. After the styling has been finalized by the HTML Coder, it is imported back to Sitecore by the editors and it immediately applied to the created structure.
SXA can live along the traditionally developed websites on Sitecore and it can serve the purpose of creating self-built and managed microsites and campaign sites by editors, without the classic Sitecore Delivery process. It is worth noting, that the editors are wearing the shoes and hats of marketers, web masters, content editors and UX specialists – all at once. For this purpose, I call them rather Technical Content Managers.
SXA uses the same principles of C#.NET MVC web application that is entirely managed by Sitecore, including content management and presentation rendering (Sitecore renders the web pages). SXA components can even be extended and new components can be created by standard Sitecore delivery teams, when necessary to complement a solution with required functionality, missing in the standard set.
SXA allows for reaching Two-Speed architecture in a way that a dedicated Delivery team can work on the functional foundations of the solution and a Technical Content team can work on creating completely new experiences that might or might not be using said functional foundations.
JSS can also live along with any existing Sitecore-based solution and it can serve the purpose of creating fully managed applications.
JSS allows for reaching Two-Speed architecture by using its own completely separated rendering mechanism that relies on Sitecore to get content, but not to render the page. This allows to create the application completely independently on Sitecore and only bind it with Sitecore, when ready.
Image credit: Drivetribe (www.drivetribe.com)