The Vision for the Future of a Composable Sitecore Stack
Vasiliy Fomichev
In Architecture Posted December 02, 2021
In this post, we will continue unpacking Sitecore’s Composable Architecture promise and will do some educated speculation at defining what the future might look like. Why is this important? Two reasons:
- Sitecore’s message around the Composable Architecture was loud and clear; however, there was no clear vision given to the audience around what that would look like. We heard standard descriptions and some, perhaps misleading labels like “best of breed” coming from various angles; however, nothing that drew a clear picture for those considering Sitecore products or their current clients for what they can expect in terms of value. Yes, Sitecore covered the converging UI, the unified portal for managing products, the SSO, etc. however, those ate table stakes, not something companies can get excited about and look forward to on the marketing and business sides.
- Since there was no clear vision, there was no complete roadmap to get to that and, therefore, no timeline. The timelines we saw in the content and commerce roadmap sessions were helpful in terms of seeing the next few steps; however, there is still a big gap between what’s on that roadmap and what the end product should ideally look like to make it worth for brands to buy into the Composable vision. At this stage, there is a lot of unknown, and with an added number of systems to work with, things seem like they would get more confusing and complicated, which is not what Sitecore clients and prospects want.
So what can we call a realized composable story? To me, it’s the point at which the composable architecture’s ROI bypasses the one of the DXP for the similar set of functionality. There will certainly be some homework for procurement teams in brands considering the new composable architecture.
In the first post, we looked at the earliest timeline for when we should expect a meaningful composable story coming to life (the realized story); we looked at what the “better together” realization will likely look like, and examined the new acquisitions in the context of the composable goal. Here we will continue with the vision around the middleware that would connect the systems in the backend and provide a single mechanism for communicating with the stack. We will review what composable and integrated stacks look like in reality, and finally, where I hope Sitecore will take their integrations with other products to make them genuinely composable.
Sitecore Composable “Middleware Layer”
This is perhaps one of the most important elements in the new composable story and what will deliver the “better together” idea – its competitive advantage, a structural moat that nobody else can replicate, because nobody else has backend access to these platforms. This middle layer could be a series of layers, integrations, and backend connections in reality, so for the sake of simplicity, I will refer to it as simply the “middle layer”. This middle layer will be Sitecore’s playground, where they can do as they wish and tie their products together in many different ways. Like no other integration, this layer can deliver new functionality that’s hard or simply impossible to replicate via the public APIs and make the Sitecore products properly integrated. The point here is not to limit the public APIs, but to expand the backend layer to be smarter, more secure, and perform much faster than public APIs. This layer may even serve as the foundation for some public APIs.
Sitecore Integrated Composable Stack
Here are some use cases where this layer will be irreplaceable –
- Mass data access for various reasons, like reporting, or search engine crawling. The crawling use case is especially compelling, because, our search needs to be able to not only crawl the front-facing user experience, which is the case with many “composable” search engines, but also the backend data structures to understand content relationships and taxonomies that may exist behind the scenes.
- Performance gain by connecting the systems at lower levels in their logical architecture to speed up processes like data synchronization between systems. An example here can be a large catalog sync job between the Content Hub PCM and Sitecore Commerce. Sitecore Commerce, or OrderCloud, comes with cataloging capabilities; however, product content usually originates in and gets pulled from another system, in our case, this is done in Content Hub. There are two ways to get Sitecore Commerce to show products from Sitecore Content Hub in its catalog – create a data provider that would plug directly into Content Hub PCM’s content and pull data straight from the database, or a product synchronization layer that would update Sitecore Commerce catalog, when an update is published in Content Hub, for instance. Both use cases would ideally be supported at lower layers for security and performance reasons. For instance, data exchange at the SQL level is much more efficient than at any other higher layer in the stack, and that becomes important when we talk about the enterprise-level use cases with complex dependencies and massive amounts of updates, where data manipulation can get pretty involved and time-consuming.
- Security – there will be massive sensitive data exchange between the systems in Sitecore’s composable architecture, for instance, PII between Sitecore CDP, Personalize, and Send. Additionally, there will be cases when Sitecore’s platforms need to communicate with on-premise systems for various reasons, and here again, we would need an express route, or a VPN, in the case with Azure. Let’s add the fact that at least one of the new Sitecore acquisitions is on AWS, there is additional complexity in ensuring security, and with privacy regulation tightening, all Sitecore systems need to align around the privacy settings in any one of them. All of these use cases will require not only the middle layer, but also the right infrastructure to be put in place to support the continuously growing security and privacy requirements.
- Smart system awareness – this is perhaps the most interesting use case, because it is where Sitecore has a chance to significantly impact prospects’ willingness to pay by “wowing” everyone with its creativity. Think IoT-type system awareness, where platforms discover each other on the network and activate additional functionality. Here is what this can look like – imagine that you are already using the Sitecore CDP, Personalize, and XM, then signed up for Sitecore Send. As the product is added to your stack and activated, it becomes aware of the other Sitecore products. It activates additional functionality within Send that allows expanding marketing automation based on decision models existing in Personalize and using contact data directly from the CDP! Let’s go back to our example with Content Hub PCM and Sitecore Commerce integration – imagine you activate Sitecore Commerce, and it sees Content Hub with the PCM and a catalog already present, so it asks you whether you would like to bring that catalog into the platform and with a few clicks, that data is now seen inside the OrderCloud dashboard and accessible through their APIs. This is the layer that will make the “better together” story come true. Yes, it is possible to create a set of public APIs and enable this type of system information exchange through that; however, there will be sacrifices in lowered performance, security, and potentially stability.
- Development experience – this has been the differentiator for Sitecore from the early days – being exceptionally developer-friendly. Look at the platform now – not only do we have headless capabilities, but we have several options: JSS, .Net Core SDK, SSG – pick your language! This flexibility had served Sitecore well, and it’s part of the reason for such a tight technology community that exists around it; developers are made feel appreciated. My hope is that Sitecore will continue this trend with unifying the API layers behind a single “edge” and syntax for easier, and therefore, faster development. One of the main concerns around the composable stack is the potentially large number of API calls that solutions will have to make. For instance, to render a page for a known visitor, we will need to make a call to the XM to get the content, to the CDP to get contact info, then another call or two to Personalize to get recommendations. What if we could streamline this by making a single GraphQL query and a microservices backend? Now, that would be efficient! Yet again, something like this will require a middle layer.
As you can see, a true integrated composable ecosystem requires a lot of smart architecting behind the scenes to make it easy to use – plug and unplug Sitecore products easily from its own ecosystem. Sitecore is currently at the start line – they have individual products that don’t talk to each other yet, so one of Sitecore’s top priorities will be to get them to work well together, to create an integrated competitive advantage – the stickiness between the products. Sitecore will have to get good at this – it would have to be the best, in fact, in order to compensate for the product immaturity, when competing against Adobe or other stacks. Complexity reduction will be at the core of the integrated story – because Sitecore will need to ensure that their products are not only easy to setup, use, but also build on, and for that the systems will need to be integrated. Envision logging into a single Sitecore portal, creating SaaS ecosystems consisting of smart, stack-aware platforms that do not require you to install connectors or modules – they simply plug right into each other. Data exchange is seamless, and the need for integration work between Sitecore products will be gone, because the products will be fully integrated. This ecosystem will have a backbone with a sophisticated middle layer that will allow secure and performant global data exchange by default. Every system would be aware of its peers and activate new capabilities automatically based on data available and features configured across the platforms. Now, this is the integrated product vision I can look forward to!
The Integrated Composable DXP Reality vs. Vision
While the integrated story is attractive and is what will allow Sitecore to build a structural moat around its ecosystem, we have to ensure that the stack remains properly composable. Let’s take a look at what that will mean. From the symposium, we know about the idea behind the flexibility advantage of composable architectures that will allow us to create our own stacks with the tools that fit our needs best. A composable architecture, in theory, will let us easily replace any system with another alternative without affecting our entire MarTech stack. This sounds remarkable! With monolith platforms, we were locked into the entire thing, and finally, we’ll be free to make our own decisions around what platforms we want to use for each facet of digital marketing. We get freedom, flexibility, agility, sustainability, and all the other good things that come as a result.
Sitecore Integrated Composable Roadmap (see previous post for the 2-year minimum roadmap)
There is one large problem – this vision can only be achieved in-depth within a centralized and controlled MarTech stack, where you are only using products that are fully integrated. Think Sitecore Composable DXP, Adobe, Salesforce, etc., because this type of “pluggability” requires all systems to have the same types of plugs. Think about the electrical outlets around the world – there are so many different shapes and sizes. Although all of these plugs and outlets (system integration APIs) transfer the same type of electricity (data and information), you cannot take a device with a US-based plug and pug it into a European outlet (the ability to simply plug and unplug our MarTech tools), but it works like a charm within the US (a centralized controlled ecosystem). In order for us to use our US-based plugs in Europe, we need an adapter, a small device that plugs into the European socket and allows the US-based plug to fit right in.
The reality is that all MarTech tools come with their own “plugs”, and in addition, they speak their own languages – KPIs, metrics, etc. Although realizing a truly composable story will be achievable inside controlled ecosystems, it will create a massive market for the “adapters,” the integrations required not only to stitch the APIs together, but also help translate the domain language from one system to another to enable seamless data exchange, and that is a long shot. For these types of integrations to exist, tools will need to agree on a common “composable interface standard” that will allow creating stable reusable integrations, and that will likely take a long time to get to. In the meantime, whether we like it or not, because we have an increased number of systems to work with, when we talk about mixed composable architectures, the ones using tools from different stacks will get the short end of the stick and will have to build or purchase a whole bag of these adapters that would make or break the success of their composable story.
Scaling Composable Integrations
There is one direction in which the industry is moving in that can help ease the added stress of the increased integration requirements – low code / no code. There is plenty written on it. If you are not familiar, I encourage you to invest your time in learning about it, because it has a high potential of becoming the standard for new integrations across digital. This will be time well spent. To give a simple example – after learning the tools like Azure Logic Apps and WebMethods.io your development teams will be able to create more robust, stable, performant integrations in a small fraction of time it would have taken them to build those the “legacy” way.
Low code and no-code systems allow creating integrations in minutes, using a user-friendly non-technical interface, allowing even business users to implement them. If you can create a flow chart – you’ll be able to integrate systems together. It’s that simple! This type of accessibility means that we can scale the work of integrating platforms beyond technologists.
Sitecore Integrated Composable Roadmap. Credit: Cuelogic.
To summarize, low code / no-code integration applications allow us to create integrations faster and empower business users to do it themselves – another step towards marketing autonomy and self-service. One other benefit is that these platforms can serve as foundations for creating that composable interface standard. These platforms allow creating “plugs” and “outlets”, i.e. connectors for the systems to use for working with their data, and if every platform created these types of connectors for their systems, it would make it relatively easy to stitch them together even for a non-technical user. These low code and no-code integrations may start as rudimentary data exchanges and evolve from there. Additionally, having these connectors exist in a centralized platform, let’s say Logic Apps, or in a vendor-specific similar platform, will allow to speed up the alignment of the connector interfaces and help move us closer towards better quality composable integrations allowing more sophisticated capabilities.
Conclusion
The composable stack’s promise is excellent; however, as you can now see, there are many things that need to fall into place for us to realize this vision. We are likely at least two years away from realizing the Sitecore composable story and about three to five years away from being able to relatively easily plug and unplug our martech tools in our composable stacks realizing the business benefits of the integrated composable architectures. Up until then, don’t ditch your trusted monoliths just yet, unless you have a mature software engineering team that will be able to stitch the products together for you while the vendors figure it out on their end. If you do decide to pioneer the composable space, prepare to scrap your own integrations eventually in favor of the formal ones by the vendors. The ROI calculation here will be different for everyone, so as always, your mileage may vary. I’m personally excited to see how Sitecore will tackle the Composable implementation, it has amazing potential, and just like with anything that is complex – the devil will be in the details.
