Adobe Commerce Headless Architecture

Transcript

So lately, as Daniella had mentioned, you know, there’s been a lot of hype around headless. And in a world where seed personalization, seamless integration are absolutely the norm, traditional CMS and monolithic platforms are really no longer enough to keep up with the inserting, press phrase, rapidly evolving customer expectations. You know, I was recently in Atlanta and I was moderating a panel specifically around perfecting your e-commerce platform. And actually, a majority of that conversation ended up becoming benefits and drawbacks of de-uplink front end and back end. It became a scintillating discussion around adopting headless architecture. And so, as merchants are trying to wrap their heads around headless, we can’t have you lose all your heads over such a powerful tool that can give you that agility, the flexibility necessary to deliver truly exceptional customer experiences. Now, some of the questions that you might be asking prior to this call might be, you know, how do I stay ahead of the curve? What is headless? How do I implement headless? What are the challenges and key considerations? And you might be getting what I call a headache with all of your questions. So don’t worry, we’ll get through all of your questions today. And, you know, first, Matti will kind of introduce the overview of flexible, composable commerce. Next, I’ll kind of introduce the definition or the defining characteristics of headless. Then we’ll look at the different headless deployment types. And then Matti will round it out with key takeaways and we’ll think about the qualifications center at the end. So I know that we’re a bit short on time today, so I’m going to go straight into it and pass it on to Matti, who will talk about personalization at scale. Awesome. Thank you so much. So, as you may know, Adobe Commerce is a powerful platform that enables businesses to deliver personalized experiences at scale. With its flexible architecture and robust set of tools, Adobe Commerce makes it easy to create and manage complex e-commerce workflows while also providing the agility you need to adapt to changing market conditions. So there are three thematic benefits to Adobe Commerce, delivering personalized experiences, ensuring scalability, and customizing to your business and customers’ adapting needs. Today, we’re really focusing on the last point here. Adobe Commerce is a flexible platform that can adapt to your unique business needs, whether you’re looking to customize your store’s look and feel, add new features and functionality, or integrate with other systems and platforms. Adobe Commerce provides the tools and resources you need to make it happen. And today, we’re here to talk about headless commerce. What does it mean? How does that apply to your business? And what are the various advantages that different methods offer your business? All right. So here, we are showcasing just some of the features and functionalities provided with Adobe Commerce, highlighting those built for marketers with point-and-click and workflow-driven UI on the left and those built for IT on the right. Today, again, we’ll be focusing on Adobe Commerce as a flexible and composable platform, specifically as it relates to headless architecture. All right. Before we dive fully into what headless is, let’s take a step back and see how we got here. As a company, we’ve continuously innovated and adapted our products as technology has evolved. It’s important to note that because of the extensibility that our platform is known for, we have always had customers deploying Magento headlessly. And what we’ve been introducing recently is really the optimization of the platform to be fully decoupled and headless-first. Magento started with monolithic architecture, that is, no microservices and coupled front-end and back-end with more of a focus on developers. At that time, there was no cloud offering. In 2016, we introduced our cloud offering. As commerce evolved further, we worked on separating the front-end and back-end architecture of Adobe Commerce as well as optimizing the platform for headless deployment. 2018-2019 is also the time that we launched our PWA studio. Over the last couple of years, we’ve continued the theme of decoupling by separating core commerce services to support a microservices architecture. The marriage of headless architecture, FastGraphQL APIs, and microservices allow unparalleled speed and flexibility when extending Adobe functionality, which leads us to where we are today. All right. Because of this, we often see the inability to personalize content. Typically, leaving content is a one-size-fits-all solution. My apologies. So we’re looking at the challenges of traditional CMS platforms that would motivate a consideration to a headless deployment. We see that limited design flexibility, functionality, and integration options, which traditional CMS platforms are often designed to manage specific types of content, making it difficult to customize or extend. Because of this, we often see the inability to personalize content, typically leaving content as a one-size-fits-all solution, rather than delivering content that is tailored to specific individual user needs. If any of these points are familiar topics that you’ve spent time considering, having conversations about internally, then it could be time to consider headless for your business. All right. And as we move into the key business and digital objectives, we now understand the general challenges experienced by businesses today. We’ve learned that businesses want to improve revenue and increase efficiency by enabling faster time to market for new digital experiences, greater flexibility in delivering personalized content, and easier scaling across multiple channels and devices. Across the industry, we see this to be true, as these are the digital and business objectives captured from industry research, our experience, and several conversations with our clients and prospects. With a better understanding of what businesses hope to achieve with headless, we’re better able to meet their objectives with the following benefits. I won’t run through all of them, but I’ll touch on a few that I feel are important. First of all, one of the great things about headless is that for every head you build, no matter what it is or how you build it, it uses the same APIs and same services so that you have parity across touchpoints. If someone logs into their account on a mobile device or desktop, they will get the same experience across both. This helps you deliver on the promise of an omnichannel experience. Also, in a demanding economy like today’s, like today, flexibility and agility are of utmost importance to keep up with the demands of consumers. This is one of the main driving factors that push headless to the forefront of commerce. With the separation of the front and back end, you gain flexibility to build and customize whatever kind of front end you want. You’re not locked into a front end with your commerce platform provider, and the separation also frees you to customize without back end dependencies. And importantly, for customization work, your development activities are now separated. Headless creates a clear delineation between the skills and activities of the back end developers and the front end developers. And this is important in an ever-changing and demanding market like today’s. This frees both parties to focus on their area of expertise and excelling to provide constant innovation without unnecessary dependencies holding them back. Wonderful. All righty. All right. Thank you, Maddie. Yeah. Awesome. So, I know, you know, instead of getting ahead of ourselves, we want to peel it back, peel back the layers here. So, you know, what is headless? Many of you may still be asking, right? We know some of the challenges, right, of having a tightly coupled CMS, as Maddie explained, right, limited design and flexibility, lack of scalability. There’s also, you know, poor performance issues, potentially limited integration options, and inability to personalize, which ultimately leads to, you know, business impacts, for example, like reducing brand reputation or customer experience, and reducing overall customer loyalty because of that longer page load. And so, again, we know, again, with the benefits, with a headless architecture, there’s so many different ways to actually increase that brand loyalty because we have a flexible, composable architecture, right, and it renders that content immediately in a way that is flexible and with improved performance. And so, in terms of a Stanford professor kind of explaining what headless is, I’ll just put it in their terms. Headless commerce is an innovative approach to e-commerce architecture that decouples the frontend and the backend components of commerce applications. So, this allows businesses like yourself to achieve unprecedented flexibility, agility, and speed to market in their e-commerce operations. And so, headless commerce ultimately makes use of modern web technologies like APIs to deliver that content and that data to a variety of different channels and devices like mobile, social media, etc., ultimately enabling you to personalize and engage customer experience across multiple touchpoints while maintaining a very consistent backend commerce infrastructure. And so, now I’m going to move into the very simplified diagram here. So, if you’re kind of a traditionalist with a non-headless CMS architecture, this diagram is showing, right, your frontend and your backend are coupled, meaning that it’s very difficult to affect change without running that change through the other, which is less efficient, more costly, and advice potential risk. So, this is, again, a very simple diagram demonstrating the coupling of the two. You have the frontend and the backend, right? And what’s not pictured here is a CMS or a search payment, all the other tools in that intimately intertwined toolbox. So, any modifications, again, in the backend will directly impact that frontend. Again, very difficult to make that change and tightly couple. And this means that it tightly couples the content and the presentation layers. So, any changes, again, to the website’s design or functionality will require, again, modification of the underlying code base. And so, with that being said, I’m going to introduce the concept of headless. So, what is headless? Let’s talk about it at the rudimentary level, right, what headless means. Here, we have the frontend or the consumer-facing touchpoints, aka the head, is separated and removed from the backend operational systems via an API. And here we go. And what is an API that you ask? An API is a set of protocols, routines, and tools that enable software applications to communicate with one another, kind of like how pieces of software can talk to one another, much like a waiter in a restaurant who might be taking your order and brings it to the kitchen. And just like how the waiter might need to know about to eat, they tell the kitchen how to prepare it. And an API is essentially a way for the two different computer systems to talk to each other and share information. And so, this no-strings-attached approach divides the consumer-facing concerns from system-facing concerns, allowing for that SIFT implementation of new strategies like subscription services or different stream content. And this headless model, again, reduces the need to dive into the backend, get your hands dirty with every iteration of your ecommerce strategy. And so, as I move into the next slide here, this is an expanded definition of headless. So, we talked about the basics of, right, the traditional versus a headless approach. But there’s actually multiple different hybrid deployments that are possible within the world of headless. And so, here, we introduce the idea of decoupled headless. There are three types of archetypes shown here, like traditional, decoupled, and fully headless. And so, just to really emphasize this point, traditional CMS, as we see on the left-hand side, often described as monolithic, couples the front end. So, the design of a website and its content in the backend, so the interface used to create that content bundled into a single application that is web-first. So, CMS providers kind of like WordPress, Squarespace, Wix are pretty good examples of this traditional model. They require a certain or specific framework or a language with everything that’s tied into that specific application. But what is the difference between decoupled and fully headless? So, let me clarify this point. Decoupled CMS is a backend content repository, still connected front end that delivers content out to channels. While headless, on the right-hand side, it means that the backend is connected to an API and pushes out your content to whatever channels that you want it to be to. So, a decoupled CMS in the middle here, as we see, has a backend where content is prepared for presentation and the front end can be separated from that, and the content can either be pushed out for delivery by an API or an integrated front end. But fully headless, it means that the content and its data are only accessible made by calls from an API, whether it be REST or GraphQL. And headless CMS doesn’t have to come with a front end or presentation that’s built in. And just a quick note here, headless CMS is actually a subset of decoupled CMS. So, the major difference between the two, ultimately, if I had to summarize the slide, is that the presence of an optional front end interface is optional in decoupled CMS, and there’s a complete lack of front end in headless CMS. So, ultimately, what that means is that in both fully headless, decoupled headless, there’s multiple different channels that you can push out content to, whether it be smart devices, mobile apps, generally referring to different ways you can deliver that content. All right. So, now that we have the basics of what is headless, between traditional decoupled fully headless, let’s move into kind of the evolution of headless with Adobe Commerce. All right. So, I know that Maddie kind of gave us a quick history lesson on Adobe Commerce, how it evolved into a headless-first platform, but in simplified terms, you know, how did we evolve over time from traditional decoupled and now fully headless? So, I’ll explain on this slide here, right? We see that Magento prior to Adobe Commerce had a monolithic architecture, really focused more on developers, did not really have a cloud offering. And here, we actually see the storefront APIs. So, you know, any customers who wanted to deploy had to use REST or SOAP APIs, which were not optimized for e-commerce speed specifically. And as we moved towards Adobe Commerce, we maintained that same architecture but introduced our cloud offering, which became a primary delivery mechanism. And you’re able to build, optimize, and deploy, but the content was really centralized, same with the authoring as well. And if you’re familiar with Luma, that’s essentially the front end that we’re talking about where we’re traditional. But as we evolved over time from traditional into hybrid or decoupled approach, right, as Commerce evolved further, we worked on separating the front end to the back end architecture, optimizing for the platform for headless deployment. So, this means that all business logic existed in the back end. And we had a performance GraphQL API layer in place for the purpose to facilitate that fast front end experience, regardless of what head is being leveraged. And so, you’ll see here on this slide, right, AEM drives the user experience and supports Commerce over APIs like GraphQL. And we’ll talk about it more in the second session about the Commerce Integration Framework. But essentially, in a very quick way to summarize, it’s a set of tools of APIs that enables developers to build integrations between the two SysMEM Commerce for unified CX across all touchpoints. And so, now, this enables for decentralized content authoring, flexible build, optimization, and deployment strategy. And so, as we move on into fully headless, right, now, we go into the next new, the next generation of Commerce. And over time, we’ve continued to this theme of decoupling our services, building out our Progressive Web App, our PWA Studio Framework, and our Venia Reference Storefront, expanding the coverage of our GraphQLs. So, here, right, the front end is optional, not necessarily coupled to that Luma Storefront. Now, all the business logic exists within the actual back end code. So, now, all of that information that’s necessary can actually be pulled in from the GraphQL API layer. And now, we have a more flexible build, ability to optimize for decentralized content and authoring as well, and can build with PWA and React, ultimately leads to a modern headless approach. And so, features kind of like product recommendation, some live search powered by Adobe Sensei are delivered kind of like in this microservices-like architecture, part of this composable commerce evolution. And so, really, what we’re trying to show here on the slide is that Adobe Commerce is adapting to you over time, right? Adobe Commerce has been invested from the beginning to really accelerate into the next new e-commerce. So, that’s trying to advance and show that and demonstrate that we, as a platform, are going to evolve and iterate as necessary to, of course, as a company that’s trying to always look into ways of innovating and moving into the next new, we remain agile to really evolve to meet those customer expectations. And so, whether you’re a smaller company or a larger enterprise, Adobe Commerce really just has that power, that versatility to help you succeed in all formats of traditional decoupled headless and continually evolving with its current marketing analytics toolset. So, all right. So, as I move on forwards, so, we’ve talked about decoupled architecture, but if you’re a really visual person like myself, and you really want to understand what this looks like, this is kind of a much more expanded view of traditional coupled architecture. If you’ve ever seen Magento’s reference site, Luma, this is the type of experience that you saw, right? A storefront that’s tightly integrated. So, you see above the Commerce Core services, we see that storefront theme Luma, we see REST APIs that extract and pull the information from your ERPs, your CRM, or DAM, or even pricing, all into the Commerce services. And everything is, again, tied directly to the storefront and ultimately, the channels are predetermined in that way. And so, some of the things to note about legacy storefront, right? Obviously, this approach may work for many merchants today because it has all of the features support that they need, B2B or B2C Commerce. And there’s so many mature ecosystems that exist with traditional storefront architecture, but there are considerations with legacy storefronts, right? It’s not headless. There’s not a separation of layers. There’s a lot of dependencies, potential points of failure when changes are made. It’s not as performant and well-implemented like PWA. And if a merchant doesn’t have the expertise, what in PHP, you’ll have to find those specific resources. All right. So, as we move into, right, the next generation of developing architecture, Adobe Commerce also supports all of your headless needs for your storefront needs. So, as you’ll see here, this orange floating box kind of encompasses the overall core Adobe Commerce services, right? See that there’s REST APIs that, again, pull that information directly from these different services. But you see now this pink box, the GraphQL API layer, right? It uses, ultimately, this headless architecture uses the robust API layer that connects to the product catalog, pricing, or order management, other core commerce functionality with any type of front end. So, giving developers the flexibility to build the experiences that they want to integrate across all touchpoints and using the tools that they prefer. So, ultimately, this is showing that Adobe Commerce, right, delivers that headless commerce architecture, accelerates that time to value, lowers that total cost of ownership while delivering those unique experiences across, like, mobile, desktop, CMS, in-store, custom applications, and drives those businesses. So, this is a overall view of headless architecture. But as we look at a more comprehensive look, the extended view, right, we’re going to look at three types of heads within headless architecture. And so, we’ll go more into detail into session two on the types of deployments, how these are deployed. But as I’m showing here, you see now that generic grey box that was the storefront headless ADEIs or that the delivery mechanisms we now see have been replaced by PWA Studio, AEM, and a custom head. So, PWA Studio is a native progressive web application framework, also comes with Adobe Commerce and enables those mobile desktop experiences. We see AEM, which is the content management system that allows marketers to create and manage and deliver those digital content across multiple channels, often done through…and this is done through the commerce integration framework, a set of tools and services that ultimately allow AEM to integrate with the commerce to create personalized content and campaigns tailored to the different individuals. And then perhaps, if not, these two options that are shown here, maybe some businesses may choose to build a custom headless architecture tailored to very specific needs and requirements. And we won’t be getting into necessarily the custom architecture or the custom build in this session, but happy to talk more details about PWA Studio and AEM and the commerce integration framework in more depth and details in the coming session. So, with that being said, I’m going to hand it off to Maddie, who will now talk more about the next set of business-focused commerce foundation. Maddie, I think you are muted, so let me… Am I unmuted now? Yes, you’re unmuted. Okay, wonderful. Thank you. So, as Jen mentioned, and what we’ve seen and heard, Adobe is committed to delivering a business-focused commerce platform that enables merchants to build and deliver features faster. Facilitates the sharing of data across their technology stack and reduces the cost of maintenance and ownership. Starting with a feature-rich foundation that includes core commerce capabilities, the Adobe Commerce Platform is deployed in the cloud with enterprise-grade security, monitoring, and auto-scaling capabilities. So, with these capabilities, we see that the platform is API-first, facilitating easy integration with other systems when needed, but ships with native admin and customer-facing UIs that can be used out of the box. These UIs are available for admin features, intuitive to use, and uniform across the solution. Storefront experiences can easily be customized when needed or completely replaced with third-party storefronts. So, as we consider those features, we also want to take a look at a few of the benefits and case studies that we’ve worked on with some of our existing clients. So, this is just a quick look at a few customers we’ve helped achieve. Greater efficiency, faster time to market for their site, and improvement in brand, product, and customer experiences using a headless deployment. We’ll cover a few more customer-specific use cases in session two, but I want to walk through one customer use case with you all here. So, Sazerac is a U.S.-based parent company of 400-plus Spirit brands sold worldwide with destination distilleries and Spirit houses that appeal to tourists. When online liquor sales went on an upswing in 2020 during the global pandemic lockdowns, Sazerac’s outdated and disjointed digital presence and infrastructure were not able to keep up with demand. So, Sazerac turned to Adobe to power its digital customer experience in commerce. As part of Adobe Experience Cloud, Adobe Commerce and Adobe Experience Manager have enabled Sazerac to digitally transform web properties during the global pandemic when tourists cannot visit their distilleries and other travel destination sites. So, with a few of our implementations, Sazerac took just six weeks to launch a Sazerac House digital commerce site that complemented the opening of the Sazerac House property in New Orleans. And online sales for all sites doubled in 2020. Other metrics such as traffic, repeat visitors, and basket size increased by 100% or more. So, Sazerac’s new corporate site on Adobe Experience Manager now showcases more brands, including a bigger focus on premium brands. With AEM, they can now activate content efficiently in real time and without relying on external sources. So, just a quick overview of one of our many customer use cases. But here, I’d like to just take a moment to highlight our core differentiators of Headless with Adobe. So, we know that our architecture is built to adapt to technology evolution that preserves flexibility to use whatever front-end solution fits your needs. An architecture that enables agility with integrated content tools that provides day-to-day support for marketing-led content. And built on Open GraphQL standards, leveraging a strong and knowledgeable community of experts with significant contributions from the Adobe Commerce developer community and customer feedback that drives our roadmap innovation. And lastly, we leverage the power of Commerce’s back-end and fully decoupled front-end with our PWA framework to create a site that is special and relevant and tailored to you. And Jen, take it away. Thank you, Maddy. All right. So, as we round out our conversation, you know, and as we conclude this first session today, we’d like to thank our panelists for joining us today. And as we conclude this first session today, we’d like to offer you just a few points to consider as you continue your conversations around Headless. You should first really determine if Headless architecture can really address your specific business needs. You know, we went through all of the different challenges, the key takeaways and the benefits from traditional versus decoupled versus fully Headless architecture. So, determine whether or not that’s really right for your business and understand kind of whether you have the technical expertise or the resources in place and whether or not it would be worthwhile to outsource that expertise. And second, you might need to assess the scalability and the level of support that you might need for maintaining Headless. So, determine whether or not Headless CMS can scale to meet your future business or handle that increased traffic and content and ensure that it integrates with your existing technology stack. And then three, understand your content management capabilities, whether or not Headless can really support your specific content needs. So, you know, multilingual, multi-channel, etc. Fourthly, again, cost is a huge consideration. I remember in the Atlanta e-commerce panel that I had moderated, this was a huge consideration. So, determine whether or not cost of implementing and maintaining Headless CMS, including different fees, development costs and ongoing maintenance would be a consideration. But I remember in that panel discussion, many of those merchants or the panelists who had actually gone towards Headless said that the benefits far outweighed much of the cost, but it is something to consider. And then time to market. So, determine a good time, a season, or perhaps plan out your entire roadmap in terms of implementing Headless. So, that might include the level of customization and testing that you might need, documentation that you ultimately need to consider as well. And lastly, you know, just keep in mind the user experience. We’re trying to create and craft a personalized experience for each individual user. And to really craft that sense of brand loyalty and trust in your brand, it’s really about creating that seamless personalized experience across different channels and devices. So, just keeping all of that in mind, how would Headless resolve or consolidate or reconcile some of those main challenges for your business? These are really the five main challenges or the qualifications to consider before you go into Headless. And I know in the second session, we’ll cover more of the in-depth material for the different types of Headless deployments. This is more of just an introduction to Headless in the world of all things decoupled. Thank you so much, Maddie and Jennifer, for taking the time. And thank you to everyone who was able to join and stay on. If you have any questions that come up, feel free to reach out to your Commerce Account Manager. If you don’t seem to know who your account manager is, feel free to reach out to myself, Daniella M. at Adobe.com. That’s D-A-N-I-E-L-A, the letter M as in Maria, at Adobe.com. And we can definitely get those questions answered for you. Thank you and enjoy the rest of your day.