Conscia

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 topic. We now have 120 attendees registered and there is room for more :) 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 data orchestration layer (#DXO) so that you can build modern experiences on top of your existing technology investments without a re-platforming effort. Here is the link to the webinar if you have not already registered: https://lnkd.in/gZqqX2Vk Brian Browning Janus Boye Rafaela Ellensburg Bart Omlo Carrie Hane Adam Peter Nielsen Andriy Samilyak Nabil Orfali Everett Zufelt Adam Böhm Andrew Sharp Manny Mattos Katarina French Jacob Pat, MBA Clay Hobson Maria Robinson Jason P. Rebecca Wyatt Marc Relford Dirk Jan van der Pol Natalija Pavić Chris Marino

New episode of Martalks! A double feature, with Sana Remekie of Conscia. talking #dataorchestration alongside integration partner and returning Martalks guest Jason Cottrell of Orium. In this clip, everyone (including Jason's kids, apparently) agrees on the importance of the accellerators, which the most advanced #systemintegrators now use to execute the highly detailed integration and data mapping that takes place between connected platforms. Sana here lists EPAM Systems, Valtech and Royal Cyber Inc. alongside Orium, as a select few, #composable-native integrators which 'share the same vision of the architecture' needed to help brands truly take command of the data across their martech stacks. Jason helpfully defines accelerators as pre-written integrations, requiring major investment and extensive user-testing to be client read. "Any integrator worth their salt in the composable space," says Jason, "should be coming to the table with that. A big thank-you to our guests for sharing their wisdom and experience. You can hear the full conversation via the link in the comments.

In the #composable ecosystem, you come across several vendors who claim to have custom connectors to a large set of CMSs, commerce engines, promotion engines, CDPs, and everything under the sun!  If you add up the number of connectors and marketplaces available by these vendors, you end up with 10s of thousands of connectors across the ecosystem.  That is not maintainable. I believe that if you offer an opinionated custom connector to a specific set of vendor APIs, you are bound to create another monolith. A-PI and H-eadless are two of the four core elements of #MACH and they form the backbone of interoperability.  So, what are these custom connectors doing, exactly?  Here is a wild guess: - They’re assuming that the API response has a certain schema - They’re transforming the API response to a proprietary schema - They’re not offering complete coverage of the full set of APIs offered by vendors and are catering to a very specific set of use cases. So, glue code is hiding in these connectors somewhere! Conscia’s #DXO gives you a low/no-code framework to connect to ANY Rest or GraphQL endpoint.  The DXO makes no assumptions about the schema of the response from any vendor.  It just exposes what is, and gives you the ability to shape it based on your requirements.  This allows you to decouple your systems horizontally and vertically. Interoperability is table stakes with the DXO. We don’t build connectors.  We create Recipes.  See the link in the comments below for DXO recipes that shows how we connect to anything and everything.  For those of you concerned with defining and enforcing industry standards, we shouldn’t be expecting vendors to conform to an industry wide schema to ensure interoperability.  Practically speaking, that will never happen.  What you need is an orchestration / translation / abstraction layer that takes care of interoperability between systems. So, the next time you hear a DXO, DXC, FEaaS, CMS or Commerce vendor tell you that we connect to a specific list of vendors, ask these questions: - What if the vendor updates their APIs - will you continue to support us? - We have our own internal microservices that we need to connect to the overall composable stack.  Do you need to build a custom connector for us?  Who will maintain it? Jason Cottrell Tomas Antvorskov Krag Brian Browning Janus Boye Rafaela Ellensburg Bart Omlo Carrie Hane Adam Peter Nielsen Andriy Samilyak Nabil Orfali Everett Zufelt Adam Böhm Andrew Sharp Manny Mattos Katarina French Jacob Pat, MBA Clay Hobson Maria Robinson Jason P. Rebecca Wyatt Marc Relford Dirk Jan van der Pol Natalija Pavić

Exploring Conscia’s #DXO platform has been a blast as I’ve built out my first recipe, inspired by "Chef Maria Robinson". A few big lessons for me over the last week of rolling up my sleeves and getting my hands dirty: 1. Start with a clear vision. If you jump in “from the middle” and just start plugging away, you’re going to subject yourself to rework and false starts. Thankfully this is a few hours’ work redone rather than weeks or months in a build-heavy #composable project, but it’s so important to craft out the goal, the services that will empower it, and the flow of data in between. 2. Right beats fast. It’s also worth building out your #orchestration components the right way, leaning on their reusability and modularity - that way, you can easily spin off “cousins” by duplicating and making small adjustments, rather than having to start from scratch because the thesis of a connection is hard-coded into it. 3. Sculpt the calls in Postman, then map them to Conscia. Conscia has great specialized connectors to simplify accessing services like commercetools. Until you’ve got their API spec memorized, though, starting from the Postman collection lets you tailor exactly the interaction you want to see. Then, it’s just a question of modelling that call in Conscia! This might take a newcomer a few tries, but now my next recipe’s going to take half as long to execute. 4. Learn from those who came before. Same as anything in software, having a relevant, running example is a huge shortcut. You could figure it all out by trial and error, but if you have a relevant and complete starting point you can save yourself a lot of laps from service to frontend to debug console and back. There aren’t many graphQL examples in our knowledge base, so thanks to Harshil Maniar for helping me to add another! I’m so proud to be contributing back, both to streamline future deployments and to add to the showcase of impressive capabilities clients can wield in their first hours with the platform. Can’t wait to show you what I've got cooking up!

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