Let's Not Turn a Composable Stack into a Monolith
Sana Remekie
CEO Conscia, Thought Leader in Composable Architecture, Omnichannel Personalization, Top 10 Influential Women in Tech, Public Speaker
The ultimate goal of having a composable architecture is to give brands freedom to choose what technologies they want to use as they build out their digital experiences on various channels including web, mobile, digital displays, kiosk apps, email, etc.? This means that they should be able to dispose of any technology they wish if it’s not working out for them and replace it ‘easily’ with something else.? No vendor wants their technology to be replaced, but this is the only way brands can avoid getting locked in and adapt to constantly evolving business needs.
I had various conversations this week at Shoptalk with both vendors and brands and the one recurring pattern that I see emerging is that the default point of integration for composable systems of record such as headless CMSs, promotion engines, Media Management, Commerce Engines, etc is the frontend. What this has created is a situation where the frontend is tightly coupled with the backend, in other words glue code.? In this article, I'd like to explain why this puts us in danger of creating a monolith out of a set of composable technologies.
What is Glue Code?
This glue code sits in your frontend framework such as React.js and Vue.js and makes various backend API calls and maps the resulting response to frontend components in a very opinionated way.? This glue code is not reusable on any other channel or even another frontend framework. So, when you want to roll out another website for another brand, you have to rewrite your glue code once again. This may work if you have one brand, one website, a fairly simple set of integrations, but as soon as you want to expand the set of digital products to multiple channels, multiple brands, multiple geographies, and so on, you end up in a very coupled architecture. After all, isn't that exactly the thing that we wanted to move away from when we shifted away from a traditional DXP to a headless and composable architecture?
The Emergence of Digital Experience Composition platforms
The idea behind the DXC was to give visual (WYSIWYG) control to business users over the front end experience, especially when that frontend is built using a javascript framework. However, having a DXC layer in between your frontend and your backend systems needs to ensure that you're not sticking together the frontend and backend in a highly opinionated fashion. Some vendors in the DXC space are creating SDKs for specific frontend frameworks that offer a way to connect to backend systems to pull a very specific set of data such as content records from a CMS or product records from a PIM.
If you look under the hood, these DXCs are providing SDKs that you have to embed into your frontend code and use the available 'Enhancer' functions to accomplish more complex orchestration tasks such as making a call to the CDP and using the user profile returned to get a tailored list of content records.
领英推è
There are a few things that I want to call out that I see wrong with this approach:
- Using functions in the SDK to perform orchestration is no different than writing glue code in your frontend.
- You still own that code and the custom logic that you have 'hard coded', albeit using some helper functions in the SDK
- If the upstream API response changes, you're responsible for making changes to your frontend code to adjust to those changes.
- The nature of an SDK is that it's meant for a specific web framework, which means it's not portable to any other web framework or channel.
Secondly, when a DXC vendor says that they have a Connector to Contentstack or Storyblok or Talon.One etc, it's important to ask what that connector is doing. A connector could do a whole bunch of things, but typically, a connector connects to a backend in a very opinionated way, such as access a specific API to pull a list of content records.? Although, that's a very valid use case, if you are consuming the API response in a 'hard coded' way, you are adding glue between systems and end up risking is a coupled solution.
So, you might ask, what is the solution??
The only way to make a composable tech stack work to create connected experiences is to connect the various sources of data and content.? At Conscia.ai, we believe that the right way to create a connected composable tech stacks is zero-code Orchestration engine that is available as a service in the cloud.? You should not have to write and deploy any code to connect inputs and outputs from backend systems in your frontend.? You should not be using any opinionated connectors to backend APIs.? What you should do instead is ‘configure’ (not code) the orchestration service to suit your use case.? If anything changes down the road, you should be able to re-configure, instead of rip out glue code and rewrite that glue code a different way. Finally, the Orchestration engine should have an embedded 'Decisions or Rules Engine' which gives business and non-technical users an intuitive interface to provide input into the business logic that needs to be executed in real-time based on the context of the customer.
Advantages of this approach are many fold for both brands and agencies/Solution Integrators alike:
- You no longer have to worry about owning the infrastructure to deploy your custom code for orchestration
- You no longer have to worry about a brittle/hardcoded integration breaking and having to support it post launch.
- Developers can focus on more interesting tasks that result in a more differentiated customer experience rather than plumbing.
- You can connect to any backend system (including legacy systems) via an API and there is no need to build a custom connector for each backend.
- You can scale the orchestration layer independently of your frontend.
- You can adapt to market changes more easily and maintain your competitive edge.
- Most importantly, the business user stays in control of the customer experience.
I'm a strong believer in the Composable stack and hence an Ambassador of the MACH Alliance , but I'm also very passionate about building a Composable stack the right way. If you're interested in learning more about the various aspects of composability and how Conscia addresses the challenges of assembling a composable architecture, feel free to read some of my other articles and posts.
Digital Solutions Architect (Commerce & MarTech EMEA) | Composable Commerce Expert
1 å¹´Thank you Sana, great article. It make me recall some of the reasons at the base of Self Contained Systems approach (https://scs-architecture.org/). I would see it more in a perspective of a trade-offs spectrum, I have also written about the drawbacks to push the "ESB" at the front-end (or even 'near-by') level but at the end of the day its about trade-offs. For me one of the goals of composability is to take back control (instead of blindly delegating it to the vendors) and it doesn't come for free as the replaceability of the underlying technologies is often an illusion, I appreciated your '' on 'easily', probably the FE is simply to most 'easy' layer where you can put the wiring logic but, as usual in software design, what is convenient not necessarily is also effective. On the other hand I have seen teams using FE frameworks (such as Vue Storefront) to achieve what they needed quite succesfully, in their context. Moreover, I'm under impression that there are more misunderstandings to "just orchestrating API-s" in order to build a succesful product but this is another related but complex topic to discuss here. I don't know enough Conscia.AI unfortunately but I would see paradigms and solutions as part of a trade-off spectrum.
Leading Web @ dbt Labs + Managing Partner @ Webtech Agency
1 年So much insight in this article. I’ll Likely reread this a few times to take it all in. Thanks for sharing Sana Remekie.
Solution Engineer for Generative AI Applications @ DataStax
1 å¹´Hi Sana, it was nice to meet you at the Amplience booth with Alison at ShopTalk, and I look forward to talking with you again tomorrow. Your article here reminds me a bit of Orchestration vs Choreography Microservices implementation patterns--each with their own trade-offs--advocating for the former. I empathize with brands and the option overload they have to deal with, and I'm all in favor in having the solution community banding together here to offer our best collective wisdom to solve business growth needs or problems. In my experience, I find that each customer ends up with a hybrid of the two approaches. Customers do indeed like to control their code, from what I've seen. Thanks for sparking the discussion!
Strategic Technology Leader | Omnichannel E-commerce Expert
1 年Thanks for this one, Sana. I have a couple of active discussions with brands where this perspective is valuable. My only comment would be that I don’t much like the term glue code. Mostly because the problem with glue code, in my experience, is that it is never just glue code. If a piece of code literally just glues 2 APIs together I’m not sure it’s going to constitute a big issue. The challenge is that little slivers of business logic almost always seep into that code. It’s what you refer to as opinionated glue code. For lack of a better word, I guess “opinionated glue code†will do. There’s still a DXC-sized hole in the market, and we still need to find a better way to explain the value of that proposition in a business context. This article is a good starting point, which speaks to my favourite architectural principle around compsable architectures (compostability).
CEO, Co-founder @ Agility
1 å¹´Great points Sana Remekie! This comes back to the architecture and what solution is build off that in my perspective. I think the current risk in the market is people purchasing a whole bunch of "composable compatible" systems and assuming just because they are using those systems, they will have something that is composable. You need to look closer like you mentioned and understand how you are connecting the systems and how they are architected together. Step 1: pick the best of breed solutions that are composable compatible. Step 2: architect properly (use an expert), meaning make them pluggable (Your no-code orchestration is a great way to do this) Step 3: Build. Step 4: Always go back to the architecture and your goals while expanding over time. Building phase 1 can be fairly easy to do properly but watch our for future phases. People get lazy when it isn't phase 1 and just start tacking things together. This destroys everything they worked so hard to build initially and can easily make something composable act like a monolith. Actually, this if often worse then a monolith because it can become spaghetti! Hire a professional composable architect and use systems likes yours (Conscia.ai) to keep things clean and future proofed!