[Music] [Sudip Das] Thanks, everyone, for taking your busy time out and attending this session. Myself Sudip. I'm Director of Technology from Publicis Sapient. [Saurabh Narula] Hi, guys. I'm Saurabh Narula, Senior Director, Engineering at Marriott International.
Today, we will take you guys through the journey of Marriott digital commerce platform using the Adobe tool suite.
So what we'll learn, we will talk about the different solution pattern, integration pattern which Marriott has leveraged to successfully build the web commerce platform, which is providing cross-enablement, enabling the cross-platform teams, providing faster time to market and high-performance web application.
In today's travel and hospitality, user journeys are universals. So user starts from looking for the dream vacation or a room and then further goes into the booking. And not only-- After that, when they are staying in the hotel, that time, they are touching different touchpoint digitally to make their stay experience better. But it does not only stop there. It goes beyond post stay as well. So they share their experiences over the social channels and everything, which influence other users, and they go through the same journey. So if you see, the journey is in a loop.
And what we are seeing, customer expectations are high.
So our digital platform needs to meet this expectation.
As customer expectations are high, so they are looking for seamless personalized experience, and business are getting influenced and they wanted to capitalize this growth. And they wanted to do in an agile fashion end-to-end. But-- Their current state of the platform or their current state of the tool set may not be meeting that expectation. So that's why the enterprises need to do it little differently.
They have to take a different approach, and Marriott has done exactly the same. And Saurabh will take you guys through that journey. Thanks, Sudip. Before we start and I do a deep dive, I want to just make sure-- I want to level set the scale that Marriott has, how many transactions we support. We have huge content repository around 200 gigs, 10 plus million assets that we have in our repository.
So as you can see, the size is huge. We have to support this, we have to continue supporting this and even grow from here. And that's where we started building this new digital platform to enable us to operate at scale and meet the customer demands. So a little bit of history though. Few years ago, we were on a monolith architecture, which was good at the time when it was implemented but does not meet modern customer demands and the performance that modern customer is looking for. That's where Marriott started looking for options and we started exploring AEM that whether AEM can give us that leverage and a faster time to market for content deployment and other scalability aspects. So, we started small. We built around 85,000 pages, which we did for our 8,500 properties across and there were 10 pages. So we built static pages for all those properties and that was just English. So we scaled across all the global languages. That's where we started. Along with that, we did integration with our monolith architecture. We connected AEM to our old monolith architecture to see can we gain efficiencies or what can we do with AEM and the monolith architecture.
What we gained from that? We learned how we can deploy content faster. We learned how do we use Adobe's cloud manager to deploy our code in a multi-tenant way where I don't have to deploy everything in one go. I can do product by product deployments. So we learned all of that. Now along with that, we also saw some of the shortcomings and we started exploring that. We realized that even though we did that, we still haven't unlocked AEM's full potential. We are still trying to put bandages around our monolith architecture with AEM, which was not giving us the scale that we wanted to operate and the agility in which we wanted to deploy. That's where we had an option. Either you continue doing the bandage work and try to make it work with our existing architecture and AEM or take a step back, do an overall of the design and do it right from the start so that we can be ready for the future and we are able to meet customer demands. That's where we, again, did a whole re-all of our architecture.
So, again, we took bold step. We didn't want to go back. We wanted to move forward. That's why we did a whole architecture redesign.
Sudip, you want to take this? So, as Saurabh mentioned, there is a point of time when Marriott decided to re-architect it.
And definitely, it needs a sound engineering pattern. And when we talk about the engineering in the space world, the International Space Station is the pioneer of the engineering.
What is the key enabler for this International Space Station? How it got built? Anybody? So the space shuttle was the enabler for this space station. So space shuttle carried all the equipment and astronauts to the space and they assembled and slowly, progressively built it.
This similar way, our software engineering platform also same, just like you build the digital platform, it needs to be same. So there are three key things you need to notice. Normally, in the engineering world, they did not build that whole International Space Station into the space, rather they progressively built it. And that is a change in the operation model. And, obviously, even before building the space station, they built this spaceship, which is the key enabler for it.
So that is the way we also follow. So in the engineering world, that's why engineering need to influence the operating model, which can make all the team collaboratively work together. It is not only your marketers but also all your partners, like Targets and Analytics, including your developers also. You need to build a foundation which makes it easy for developers to adopt it.
And as we've seen that International Space Station has built progressively, so in the similar way, we need to take a progressive approach. You need to build the platform first, then enable your marketers to control the experience, not only marketing but also your commerce experience. Then followed by, you build your commerce journey. Now once your platform is ready, you can do a rapid innovation. Just like today, now scientists are going into the space station doing their innovation and that is coming to our Earth and benefiting it.
So now if we talk about the foundation, which is the enabler. So for building the foundation, enterprise need to follow few key principles. So one of the principles, obviously, today we want our marketers to control the experience. So you need to have a right tool set, which is like, here in this case, Adobe is the perfect tool set for it. You might be having a tool set and there is different patterns available. You need to add up the right pattern for your solution. Like, if you want your marketer to control both the experiences, static and dynamic, which AEM framework you should choose on? If you wanted to integrate your Adobe platform, which framework you should choose on? There is a different framework. So your integration pattern need to be seamless, which is decoupled and easy to collaborate.
The third important thing, we are talking about both marketing experience as well as commerce experience. In the marketing experience, we want our page more SEO-friendly, and that's why server-side rendering works better. But whereas in your commerce experience where the data getting pulled from the different system, so client-side rendering works better. But we know both of the pattern has some pros and cons.
Now think about if we can use best of both, and that's what the unified platform it is. And this unified platform can be supported with the isomorphic architecture.
Third thing is the scale. The scale, we know digital platform is going and we need to scale it. And scaling it does not mean take your application and deploy into the cloud. You need to build your application, build your framework, which is cloud-enabled. Like a stateless, you need to make your stateless so you can scale your application, different products horizontally. That's another principle.
And it is nothing new that today your organization follows the platform and product model. But the challenge is how you're making the product team enable to work effectively, how they can collaborate, how they can parallel develop and provide the faster time to market. That's where the engineering pattern like micro frontend comes into the picture. So, these are the few patterns which Marriott adopted and built their platform. And that's why Saurabh will be going to take you guys to deep dive. Thanks, Sudip.
So, as Sudip said, right, so we followed few architecture patterns and few principles in order for us to build the whole digital engineering or the digital platform that we wanted to build. We broke it down into different layers. Isomorphic, we wanted to enable client-side as well as server-side rendering for our pages based on the use cases. So we followed isomorphic pattern for that using Next.js. We've created micro frontends and considered every product. And for product, booking journey is a product. Your profile is a product. So we consider those as micro frontends. And we build those micro frontends so that they can independently deploy without waiting for others to be ready. Performance is a very big factor and my boss always says if a page is performant or not. So performance is a very big factor. We wanted to make our pages stateless and wanted to cache as well. So we tried adopting cloud native principles rather than doing custom coding for all of those. Now in all of this, we wanted to ensure our marketeers have the right toolset to enable experiences faster, they can do AB testing and they can do segmentation faster. So we've worked around that and used event-driven data layer model to build those segmentation practices.
So again, going deep dive into cloud native, right, we broke it down the whole web platform into different layers. One big piece is AEM. We used Adobe's AEM Remote SPA, a single page application feature where dynamically, we are able to do a preview of not even just static pages but dynamic pages as well by connecting to backend where an author and a marketer gets the real-time feedback on how the page looks and they can work based on that. So we use that. Then comes the presentation framework. We purposefully made sure we go for the Headless pattern where our page is broken down into smaller components, react components, and we are able to use those as content as service and able to ship it or distribute it to other platforms as well. So, we went on to Headless pattern. And in order to enable isomorphic pattern with the Headless, we created a presentation framework which was built on Next.js, and we were able to do client-side as well as server-side rendering with Next.js. The third important piece which I mentioned, micro frontend. Right? So every product we considered as micro frontends. And every product, they will have their own template. They will have their own components. And those components get independently rendered by using the current world's browser power. You have components, you deploy it and then they can render whether it's a static content or dynamic content. Every react component is responsible for its own rendering. So we strictly followed this pattern to build our whole web digital presentation framework.
Another thing, as I said, performance is always there. We always keep focusing on performance because in current world, a user span or attention span is very, very less. So we want to make sure that when somebody is coming on a page, that person is not losing interest. So performance is a very big consideration for everything that we do. In order to achieve better performance, we wanted to cache our pages at the edge so that it can be rendered faster. And since we are on micro frontend and react Headless pattern, all react components can render on themselves in a stateless fashion. So two things we focused on. One, how can we make our pages stateless? And second, how do we cache it at the edge? And we worked on those principles. One important thing that we realized that the current traditional data layer that you put it on a page, it always blocks the page to render and that's why we're not able to cache it properly.
To overcome that, we used the event-driven data layer model, which again comes with ACDL, Adobe Client Data Layer, where we can attach events to the react components or to the components and then those events can be pushed to the data layer. That helped us in making the page stateless and we are able to cache it at the edge so that when the page loads, every react component gets the data and is also ready to push the data with an event to the data layer. That helped us in caching the whole page.
Moving to the next one, right, marketers, it's very important that we enable marketers to do experience segmentation, to do more experiments on the page so that they can get the right experience for the right consumer.
We keep learning based on the trends and they have to push experiences faster without waiting for longer development cycles before they can deploy anything. So we realized that and we recognize that we need to work on this and one person cannot do everything. So we broke it down into three different personas and profile. One, marketers, who will just define the experiences. Second, merchandisers, who will define the rules for those experiences and segments. Third, the data team or the IT team who will collect the data from data layer and analytics and create the right segment so that those can be pushed. With all these three, we were able to push, our marketers are able to push the experiences faster on a web page. We use ACDL and data layer to push the data. Then we use Target to create rules and segmentation and we are able to push it on page through Target as well. That's what we did to enable our marketeers to have that flexibility and agility to push experiences faster. Along with that, we also realized that everything cannot be done at client-side because sometimes the Orchestrations are super complex and it takes time to do it. So we also worked on doing segmentation and doing that experience orchestration at the server-side as well. Again, one size does not fit all, so we apply both patterns based on the page or what experience we want to enable.
Now we did all of this, and we obviously have to evaluate whatever we are doing. Are they meeting our benchmarks? Or what are the benefits that we are getting out of all the work that we have done by using AEM Remote SPA, by using ACDL, by moving over from traditional data layer to ACDL, event-driven. So what are we getting out of it? So if you can see, these are the numbers. We have onboarded the entire m.com, marriott.com on this new architecture. We are seeing better performance from where we were one year ago. Our performance numbers have become better. Our deployment cycles have become shorter. We no longer wait for too long to deploy anything.
We have given flexibility to our marketeers as well along with this. With this pattern, we are able to enable more channels, not just web. We are able to enable mobile app as well to use the same content fragments that we have built for web because, again, that's why we have used content as service model from AEM.
Now this is all work that we have achieved and we are continuously working on it. But again, technology always is evolving and we have to keep track of the technology. So we are not stopping. We are doing more work. Since we have enabled our framework, now we are focusing on hyper-personalization by giving the right experience to the right consumer by understanding the intent. We are focusing on that. Everybody is working on Gen AI these days, so Marriott is also doing some work. We are focusing on Gen AI in different fields. We are getting content. We are generating more content using Gen AI. And we are able to build components also using GenAI so that we achieve developer efficiency.
We also now realize that once a design is created in a UX visualizer tool, how do we move that into AEM components faster without having too many developers touching it. So that's why Marriott has started adopting to a design to code mindset where something is created, let's suppose in Figma, and we are able to take it as is and break it down into tokens and then push it into components. We constantly are looking at AEM upgrades, whether it's service pack upgrades or whether cloud migration, does that fit us or not. So we're constantly looking at those upgrades and when whatever is applicable, we are applying those, whether it's through GenAI or through regular updates. So that's what we are doing and we've not stopped yet. Handing over. Yeah. Thanks, Saurabh, for giving insightful overview of how Marriott has built the web commerce platform, powering both the marketing and commerce solution. Now, here, if you have seen this journey, this journey is not easy. Correct? There is some point of time where the enterprise need to take a step back rather than reinventing or reworking on the old pattern, you need to come up with the bold decision, take a bold leap to shifting towards building a more strategic approach to build that digital platform. And this journey will not be easy. It was not easy for Saurabh. There would be challenges on prioritization. There would be challenges on skills. There would be challenges with the mindset shift because there is a change in the operation model. But if the enterprise need to stay invested into it and...
Continue to work towards their digital transformation journey because transformation is not one time. It's a continuous process. Thank you. That's all we have. Any question, we should be able to take it.
[Music]
