Potential future for Sitecore XM

When I joined Sitecore in 2009 as a QA and met the first Sitecore Product Manager, I have no doubts about what I want to do - to create a product. I think this is the most exciting - to form a future. It took me 6 years to become a Product Manager

Now, I am no longer a part of the Sitecore family, but I am still a creator and want to form a future. So, in this article, I would like to share what the potential future for Sitecore XM would look l like if I would continue forming it.

Talking to many developers, architects and MVPs, I quickly realized the strongest side of a Sitecore XM - extensibility. This is something that was integrated during the Sitecore DNA formation by founders. And I honestly think it was a masterpiece. Even now, I think it is not that outdated as someone may say, but obviously, requires some "refreshing" and "tuning".

Due to a huge number of customers, unfortunately, we are not able to make huge changes in one release, thus, we have to design a technical roadmap which we would stick took from release to release. I become a PM at the time we were releasing the Sitecore 8.0 and it quickly becomes obvious we have serious problems with architecture which I wanted to solve. I have started with Abstractions. Why? Because I need a testing foundation for huge changes. Without code abstractions, we were not able to write native units and were using various tools which allowed you to test pretty much any bad-designed code. We used TypeMock, this one allowed us to test pretty much everything. Thus, there was no motivation for developers to do things right. So, we removed the tools and did huge refactoring. Devs can recall Database Abstractions, Configuration Abstraction, Job Abtsration etc. During that process, we refactored more than 30% of the entire foundation, removed code duplications, brought a lot of optimizations and increased the code coverage by more than 45%. Quality boosted immediately, the one can report the release notes with more than 250 fixed issues (FocusedImprovements initiative).

The next step - configuration. With 8.0+ series, Sitecore extremely blasted in a number of instances which is needed for Sitecore to work. While I am not fond of what we did (introducing the Reporting and Processing roles based on Sitecore Foundation), the problem requires a solution, thus, the Rules-based configuration emerged (a brilliant solution from one of the former Sitecore employees :). Needles to say, it was a blast. The ability to configure any instance in one line changed how Sitecore solutions are developed and deployed. The purpose of the configuration was not only to simplify but to divide as well. While we talk a lot about best practices in Sitecore, I decided that we need to hard-implement our best practices, not allowing customers to make a bad solution. So, we divided the configuration by layers and saying the Sitecore configs should never be modified. As a side project, I have had composed the entire configs into the resource file and provided a simple tool for configuration. You would be able to change any setting, and the relevant patch would be created automatically in the Solution (include) layer. Haven't had time to finalize this as there was a plan and we need to stick to it. It was 2017 and exactly at that time, one of the Senior Architect at EPAM told me that WDP is crap and we need to investigate Containers/Docker. Haven't got enough support inside of the org for this idea, unfortunately, like that time XM and XP was one package. Was not able to do much with that setup

Next step - minimizing deployment footprint. It was clearly seen, there is something wrong in how we position XM to be a sub-product, but physically, it was the same XP with a setting. This is clearly not what customers/devs would expect, especially from the feature side: you are not expecting having all the XP stuff and slowing down your solution, your deployment, your development and hosting costs. Thus, I heavily pushed for dividing XM and XP. Said -> done, with partial success. Devs were happy to see a cold start of 10 sec instead of 40, but the lack of Personalization didn't allow to gain momentum for XM.

The next 2 were dedicated to polishing up the XM and attempts to build SaaS:). Removed Core DB from CD, bringing personalization to XM, finally building containers, ReadOnly Database replication etc.

Sitecore XM 10.1 hit the middle of the road map with a huge promise - solve the upgradability issue and finally dividing Sitecore product from Sitecore solution. Now I was able to seriously refactor and improve the foundation.

So, what I have had in mind for XM:

• Developers to deliver the IA as a resource. With Items as Resources, it would be cool to release a Nuget that will allow developers to pack their IA items as a resource
• Async Initialize pipeline. The idea is to make dependencies between Processors through the configuration and run independent Processors async in parallel. The POC that was designed by one of the most bright minds I have ever worked with (Yes, Dmitry K, it is you:) shown, we can potentially reach XM cold start below 3 sec. vanilla and 10 sec with SXA
• External DataProvider. The idea is simple - to introduce extensions and abstractions to natively use any 3d party data as Datasources in Sitecore Pages (UI). Without Syncs, without importing, just connect and use. Any CaaS, CRM, CMP etc.
• Distributed Cache. In 10.1 we introduced partial Cache cleaning that Devs can configure. We quickly realized that our caching layer is dead. Too many small caches for nothing, can't be scaled. SXA double the amount. So the idea was to rewrite the entire cache layer using modern distributed approaches (Redis Cache as an example). This would make significantly boos the HA/DR capabilities of the product + autoscaling.
• Native integration with Google Analytics. This is kind of a no-brainer
• Removing all SPEAK apps from XM. Yep, it would be cool to fully replace those with Horizon OOB. This would potentially kill a need for the Core DB entirely and move us toward pure CQRS (not sure about that, as with Items-As-Resources, we may not need a Publishing anymore, it would be a deployment process, where you deploy the latest resources to CD - e.g. Publishing in seconds as Resource would be like 100 MB for mid-size solutions and Media in Azure Blobs/DAM). All UI customization would happen in Authoring (Horizon) with native approaches (JS, ShadowDom etc.). the "UI free" CM would operate using GQL endpoints. Customers would be able to easely add additional endpoints and be able to add pipelines for CM and CD
• Obsoleting ASP.Net Forms, moving parts to .net Standard. This would be the final version of XM running the Net Framework. The assumption was that any customer that was using MVC would be able to upgrade to such a version, others would be looking for a new world
• NextGen XM would be a pure NetCore 5. Running Linux Containers with support of the Sitecore Pipelines and configuration, native Core.MVC and Horizon as the main editing experience. There would be no CD->replaced by Rendering Host, self-written .Net Core app or just Headless with Edge. Tracking/Personalization would be executed either on RH or Edge. You would be able to request onPrem copy of such a product or having it as SaaS/CaaS. Medial from Sitecore DAM (if you wish)
• SXA partial integration. SXA now is a product-in-product. It would be cool to drag some of the concepts to be OOB in XM (such as SiteManagement) and leave pure customizable web components for SXA. So, the customer that is having XM is loaded with best practices and if he wants to boost the Site creation, he can get the SXA components for free. Partners would be able to develop their own set of components and be able to pitch them without the risk of being broken by the next XM/SXA release. Components, as native as possible (Angular/React etc.)

Anything I have missed that would be great for the Sitecore XM?