Conscia

Thanks Thomas Mulreid for bringing up this great topic about the importance of Interoperability in the MACH / composable architecture. The MACH Alliance has put together a reference architecture that includes the 'Data orchestration Layer' as the way to ensure separation of concerns, interoperability as well as accelerating the path to a #composable architecture for enterprise brands. Conscia's orchestration product, #DXO, was built from the ground up for exactly this reason. It's great to see all the stars aligning in this space!

This week we’re taking a closer look at this recipe on ‘Orchestrating multiple personalization strategies simultaneously’. Put simply, we have three sources of recommendations and we’re going to split the traffic to test which source gets the most clicks. This recipe draws on manually curated, rule-based, and AI-powered content. In a time where we’re learning how to use AI, we need strategies that allow us to test it out and compare it to the tried and true methods. Clay Hobson wrote a piece the other day where they described this scenario, where you can A/B test content and technologies alongside personalized content with Conscia’s #DXO. Being able to configure this kind of #orchestration, grow it and adjust it, in hours versus weeks or months of code-writing. They called it #MACH speed. See how it’s done in this recipe. Watch my commentary. Fair warning, it’s a long video. I had a lot to say. But that doesn’t mean the recipe is any harder than the others. You can find the link to the recipe and Clay’s “galaxy brain” post in the comments below. Clay Hobson Sana Remekie Bart Omlo #DXO #Personalization #Orchestration #Composable #MACH #DigitalTransformation

In the MACH Reference Architecture, Data #Orchestration sits below the #Composition layer.  Why is that? First, let’s define the two terms.  🎨 Composition is the visual presentation and layout of the experience in a specific frontend i.e web vs. mobile vs. kiosks, etc.  In some scenarios, the look and feel, layout and presentation of data is pre-determined via design systems and templates, while in others, you may want to provide a WYSIWYG site/page/visual builder to non-technical teams.  Many of the headless, hybrid and visual CMSs and DXCs offer this capability.  🔀 Orchestration (or #DXO), on the other hand, involves the following: - Connecting to various domain level APIs - Canonicalizing the domain specific data - Stitching data from various domain services for an experience (like stitching inventory data, product information and related content for the product detail experience) - Determining what data/content should be seen by the customer (eg. personalization as well as privileges to see data). - Shaping and filtering the data for the needs of each of the frontends - Caching the data dynamically for optimal performance - this is especially useful when you have to make multiple calls to backend services. - Responding to any client request based on its context Embedding data orchestration into the composition layer is an anti-pattern.  Here is why: ✖ Each frontend managing its own point to point connections becomes unmanageable as the number of domain services and backends increase. ✖ It can create fragmentation in customer experience as experience logic is no longer centralized ✖Frontend is something that lives on infrastructure that you are responsible for scaling and optimizing performance, whereas an orchestration platform, if MACH Certified, should be SaaS. So, logic in the SDKs is not SaaS. ✖ Business logic in the frontend layer is not maintainable as it adds to the ‘glue code’ which is not manageable by business teams. ✖To avoid performance impact due to over-fetching, you want to shape/filter the data before it reaches the frontend, not after it’s already been fetched. ✖Data access privileges are typically frontend/channel agnostic and you should be determining who can see what data before it reaches the frontend. ✖Chaining API calls in the frontend requires multiple round trips to the backend, which is obviously not great for performance. Composition should happen once the data is ready for the frontend to consume. Agree?  #composable #DXO Conscia MACH Alliance Maria Robinson Bart Omlo Manny Mattos Katarina French Janus Boye Rafaela Ellensburg Carrie Hane Adam Peter Nielsen Nabil Orfali Adam Böhm Andrew Sharp Jacob Pat, MBA Clay Hobson Andriy Samilyak Dom Selvon

"Who flips the coin?” Some interesting opportunities emerge when you go beyond a “glue code” direct integration #composable architecture and embrace #orchestration. Here’s one. I was workshopping a technology approach with an architect, and the topic shifted to A/B testing. In a strict build scenario, the answer to this has always been somewhat tepid. You can write something in the BFF and update it with code changes? Or stick an integration into the CMS and treat it like localization with variants of content? Of course, then you’d need another solution for monitoring. Do flags count as A/B testing? But the approach Conscia follows is so much more robust than that. Let’s say your site is live with Conscia and you want to run a simple test, like comparing two videos on the homepage. You can have a Picker component “flip the coin” and split traffic between them (50:50, 90:10 - whatever you like). That might be ten minutes of work, and no code changes. Or you want to test a new solution. For instance, see how a Cloudinary-served video compares against your legacy CMS? Great, replace one “Get Video” component with the Cloudinary connector. That might be an hour if you’re taking your time, and no code changes. Want to scale up experimentation? Have that picker enrich the context that’s passed back to the frontend depending on the path taken. Now your event and tracking solution can key in on the test underway. One one-line change would capture the new context, and then it’s ten minutes’ work to start visualizing the test outcomes. Or rather than a coin flip, we want to use a personalized content recommendation from Segment? Change a couple lines of configuration in Conscia. Now you're using the same everything-else to serve tailored content instead. Same backend integrations, same frontend code, all new capabilities. But where it goes "galaxy brain" is when you do all those at once. A/B tests of content and of technologies, alongside personalized content, empowering marketing dashboards? You've turned an MVP site build into an experience-maximizing engine... With almost no code changed. This is multiple sprints’ worth of work in the glue code world, and you’re done by lunch. Crawl, walk, run… #MACH speed.

As our CEO, Sana Remekie, said recently - 'Personalization in a composable stack is not a single vendor offering'. This is especially true in a complex, enterprise technology landscape where content, customer data and customer's real-time context maybe sourced from a whole bunch of different applications, systems and APIs. For less sophisticated engineering teams, it maybe sufficient to simply tag your content in your CMS and retrieve the right content for a specific customer segment with if/then statements in your frontend code. But, if you're an enterprise brand, you know that personalization doesn't happen in isolation in a single CMS, CDP, Commerce Engine or even a personalization engine. In this recipe, Maria Robinson showcases the necessity for #orchestration in delivering a personalized experience. See the comments below for a link to the recipe documentation. #dxo #personalization #orchestration #composable #mach #digitaltransformation

As Sana Remekie wrote recently, #personalization happens at the intersection of Content, Customer Data and Context in a #composable stack. Personalization doesn’t happen in isolation in any one application. It’s a coordinated effort, which requires #orchestration. We have an ‘Orchestration Recipe’ that demonstrates this very thing, where we take context and customer data and serve up content specific for this segment in this situation. It’s a common use case – A known customer is browsing a website and they see a personalized announcement banner. A different customer, in a different location, on a different device, with a different history will see something different. Each audience will see content targeted directly to them. Any kind of context can be taken into account. Any information that can be passed through from the experience or accessed via API. Does weather affect your buyers’ purchases? Do major sporting events sell more wares? Does the time of day coincide with certain types of conversions? Let’s use the information. Any kind of content can be served up based on the information at hand. Hero banners, promotions, products, blogs. Conscia’s #DXO handles the data connections, dependencies, and experience logic. Developers and content managers can handle their pieces without stepping on each other’s toes or getting stuck in someone else’s backlog. Take a look at this Orchestration Recipe and watch me walk through it and provide commentary. This recipe is a starting point for personalization and sets the groundwork for more complex use cases. Next up: ‘Orchestrating multiple personalization strategies simultaneously': Manually Curated, Rule-based, AI-Powered. You can find the link to the recipe in the comments below. Bart Omlo Clay Hobson Sana Remekie

Both federation and #orchestration platforms can act as an #abstraction layer in a #composable stack, which is essential to decouple your frontend from your backends.  They can even stitch data from multiple backend APIs, reshape data for consumption for various consumers (or experiences) and enhance the performance of your experiences.  But….they’re not the same thing! It's up to vendors to help their buyers understand the difference, and so, I'm taking a stab at that here. Here are some key differences between the two: 1️⃣ API/Data Orchestration accesses data straight from its source while data federation layers require you to push your data into them using their ingest APIs.  Challenge: This means that you must own the process of data synchronization and the ETL pipeline to get the data in the format required. ---------- 2️⃣ API orchestration accesses the data and business logic straight from the source and is able to unlock the full set of capabilities native to your backend systems.  Data federation treats backends as dumb data sources.  Challenge: You can sync data, not business logic.  For instance, how would you sync the image transformation/optimization logic in Cloudinary?  ---------- 3️⃣ API Orchestration allows you to chain API calls in a certain sequence based on dependencies between them whereas federation layers don’t offer any such capability. Challenge: There is no way to personalize content based on customer data if they sit in two different systems as it would require chaining the API call to a CDP/CRM to get customer information followed by a call to the CMS to get relevant content. Personalization requires orchestration of APIs, not federation. ---------- 4️⃣ API Orchestration offers both read/write capabilities whereas data flows in one direction in API federation i.e from data source to the federation layer to the frontend.  Challenge: A federation layer is not able to ‘abstract’ out a checkout process from the frontend as it requires both read/write capabilities, which is not offered by federation platforms. ---------- I'm not saying that there aren't use cases out there where federation is needed. Even Conscia itself offers a module called the DX Graph, an API-first data layer, that does data federation, but I believe that is only necessary when the data is unavailable via APIs. For all other use cases, you need to either build or buy an API orchestration layer. I'm curious to hear thoughts and objections from my network as I may be missing something in my analysis. Jason Cottrell Tomas Antvorskov Krag Janus Boye Rafaela Ellensburg Bart Omlo Carrie Hane Adam Peter Nielsen Nabil Orfali Everett Zufelt Adam Böhm Andrew Sharp Manny Mattos Katarina French Jacob Pat, MBA Clay Hobson Maria Robinson Andriy Samilyak #DXO

At MACH 3, there was a huge interest around the topic of 'MACH vs Monolith' and how brands are looking to create innovative customer experiences without having to do a re-platform. So, we decided to host a webinar where we'll talk about our perspective on this. Most enterprise organizations have one or more monolithic platforms including DXPs, Commerce platforms, ERPs, CRMs etc as well as home grown and legacy systems in their technology ecosystem. It would be naive to think that you can get rid of them and build your 100% pure #MACH tech stack. These platforms have evolved over the years through customization based on your specific needs and it's not really possible to replace them easily with something else. The pragmatic way to go about your digital transformation is to think about how you can add #composable technologies to your existing tech stack without a complete rip and replace. In this meetup, we'll talk about how this is achievable through a layer of abstraction and orchestration so that you can employ the strangler pattern to decompose the monolith, one piece at a time. MACH Alliance Bart Omlo Maria Robinson Clay Hobson

In my first hours exploring Conscia and the way they discuss their Digital Experience Orchestration software, I sketched out a chart to crystallize my thinking. I knew I was on the right track when today on a partner call, their solutions head jumped on the screen share and went to start drawing the exact same thing! Here’s some of my learnings, and a thought technology that might help you cut the Gordian knot on who #DXO is for - diagram below. For #DXO, like a lot of technologies that execute #MACH principles, there’s a potentially-polarizing build versus buy. Let’s rule out “do without” right away; every modern experience is going to need to converge data from a variety of services. Each integration for each experience requires upfront effort to build and an ongoing effort to host, extend, and maintain. The dev-hours commitment both initially and post-launch scale up based on the cross-product of the number of experiences managed, the number of countries, locales and regions supported, and the amount of services integrated. For each, a little bit of custom code is written, either directly in the web Javascript or in a dedicated BFF; but there will be code, and this code is always service- and use-case-specific. If anything needs to be updated, or new capabilities brought online, or a service exchanged for a new entrant then we're stuck writing feature request tickets and waiting for resources to come available days or even weeks later to make it happen. By contrast, licensing Conscia is a known resource allocation; adding a new integration takes hours, not weeks; and the maintenance effort of each integration is a fraction of what maintaining a codebase requires. So for a scaled brand, with complexity in their customer facing experiences (present or near-future), Conscia is tailor-made to efficiently manage world-class composable web experiences. Obviously the ratio of dev hours per dollar differs across firms (onshore vs nearshore vs offshore, etc), but all that does is adjust the tipping point rather than change the equation fundamentally. In the emerging composable consensus the need to integrate technologies to experiences is table stakes. For leading enterprise brands, though, the “secret sauce” that they want to bring to the table probably isn’t around building and maintaining infrastructure. Instead, it feels like a no-brainer for brands with sophisticated experiences and a variety of tools and services, touchpoints, and locales (either now or on the roadmap) to configure a best-in-need tool dedicated to the task, rather than building (and supporting, and patching, and re-building) a good-enough coded solution. And I haven’t even touched on personalization or the “daily driver” experience! More to come as I dive in deeper.

Here we go! Looking forward to two great days at #MACHTHREE. Excited to be in #NYC with our CEO Sana Remekie and our new colleague Clay Hobson. Welcome on board! Conscia MACH Alliance