[Music] [Mary Alice Orr] Welcome. Good morning. Thank you all for joining to the Skill Exchange AEM Experience Makers Spotlight, where we will be covering Component Mapping for Global Scalability. Now for those of you that don't know or who might be listening on-demand later without the context of this, I just walked into the song Money by Pink Floyd from The Dark Side of the Moon album. Now I chose that as my walk on song for a couple of specific reasons that I'd like to explain a little bit further. So let's count in.

First and foremost, I work at AllianceBernstein, also known as AB. And we work in global financial asset management. So like Pink Floyd in this case, we also care just a little bit about money. Number two, I studied music and music business in college. I live in Music City. And the song Money has a very rich history in its recording. So I'm going to be utilizing my background today to make this session a little more relatable. And number three, it's the morning after Summit Bash for many of you. I'm sure it might be a struggle a little bit this morning. So I'm going to try to keep this fun and light today.

Now I will get into the agenda in just a moment, but let me introduce myself properly. My name is Mary Alice Orr, and I have been working in digital marketing for over a decade. I work at AB as I said earlier. I've been there for five years working on the digital experience client group marketing team focused on managing our platforms for AEM, Marketo, and now Adobe Target.

As Will mentioned, I'm very honored to be an AEM champ this year, as well as an AEM User Group Chair for the Southeast region.

Now for the fun pieces about me, I'm an avid jazz listener and sometimes a mediocre musician. So I try to catch a jazz show in any new city that I visit, like this one here in Denver. You can see in the second photo that I love the great outdoors. I have been to over 75 national parks since I was a child and have garnered an embarrassing amount of junior ranger badges along the way. And lastly, I am a proud dog mom to a menace of society that I like to call a Siberian husky, whom I like to take with me on paddle boarding adventures such as this one.

Now today, we're going to be talking about making components, mapping components, thinking about scalability. There's a lot of ways that you can tackle that problem. And you have to think about doing it for what's right within your organization. So I'm going to be talking about it from the lens of how we have tackled it at AB and some of the challenges and pain points that we have tried to overcome in that instance. So as an example, we are on-premise. We're on Version 6.5 of AEM, but we have migrated upwards of 70 sites over the last 5 years to AEM. So we have seen a lot of things and have tried to learn and grow from them along the way.

I will be talking about four main points today. Number one, what's the status of your AEM instance, and why does that matter to you? Number two, to always consider scalability or it might bite you later. Number three, think outside the out of the box components and embrace component customization when needed. And number four, cataloging your component library for future training and usability.

So let's start with this question. What kind of band do you have? And by that, I mean, what's the status of your AEM instance? Are you more of a solo songwriter, meaning you're building your first site on AEM for the first time? So you're thinking about site structure. How are you building your DAM? What kind of components do you need? Are you going to utilize content fragments, experience fragments? Maybe you're more of a duo. You've already done that once. Now you're migrating new sites or building new sites onto your existing codebase. Maybe you're a full-fledged band. You've got multiple sites, multiple codebases, different designs, different needs. Or maybe you're a legendary band.

We're, kind of, in that position ourselves, I would say. And what I mean by that is, maybe the members of your band have changed, have come, and gone, but you've learned a lot of things. And now you have longevity and a legacy ahead of you. So maybe you've built multiple sites. Maybe you've built multiple codebases. But now you're trying to consolidate that down to one source of truth to rule them all...

Which brings me to scalability. So I would challenge to consider scalability early and often, or you might end up recording multiple takes.

So let's talk about the importance of discovery and requirements gathering.

What kind of audience do you have? Are you serving more locally? Are you thinking from a global perspective? So you have to think about EMEA, Americas, APAC. Maybe you have to think about global horizontally. What kind of components do you want to build? Are you going to build atomic individual building blocks, or maybe they're more molecular and, kind of, utilizing atomic elements to build them, maybe you're doing a combination of both? What kind of branding are you utilizing? Do you have an original brand that you're going to be reutilizing? Or are you doing a new design, a redesign, or a brand refresh? With your builds, are you migrating a lot of sites to AEM for the first time or building something completely net new? And lastly, from a functionality perspective, are you creating things that are manually authored, or are you thinking about dynamic rendering from either an API or a service call? These are all questions that you need to be thinking about from a component architecture standpoint when you're thinking about scaling for success.

So once you've, kind of, assessed that, it's time to find your similarities and address your gaps. So if you look at the image here, I've got a few colleagues in the room today. They're very familiar with this image. This is what we call our AB war room. So after we have gone through, kind of, a vetting process with discovery, with people like design, UX, our platform owners, development, our business stakeholders, and have come to somewhat of a consensus of what we want to build and how we want to build it. We start to evaluate where there is overlap. Where are there similar HTML structures with what we want to build? CSS styles. Is there shared functionality or animation that's being utilized? How are we intaking data? Again, are we doing it from an API call, a data warehouse? And are we utilizing existing things that we've already built? Or are we thinking about net new components that we need? Or maybe a variation on something that already exists? Which brings me to learning from your builds. So I'm going to utilize AB as an example for this. We are on our third codebase. And I would think about our first codebase, kind of, like our debut album. We put a lot of effort into what we wanted to say with that first codebase, a lot of discovery, requirements gathering, a lot of thoughtfulness. And we were really, really excited to share it with the world.

But then we got a request to build a new design for our corporate website. And we had a very tight timeline to do it.

So like a software album, there was a lot of pressure to get it right. And because we were on such a tight timeline, we decided to build it in a less reusable way, a little more unique. And it looked great. We were really excited about it. Unfortunately, as soon as everyone saw the new redesign, they all wanted it, which I'm sure is something that most people in this room have dealt with in the past as well. So now we are on our third codebase, which I'm calling our greatest hits volume one because, again, I'm under no illusion that you ever stop building in this business.

But what we have tried to do is marry things that have worked well from the first codebase and the second codebase and negate the things that did not work well, similar to a greatest hits.

Now if we're talking about components, you obviously can utilize core components out of the box within AEM. The problem with that is following the typical formula doesn't always make you a hit record.

So I would challenge to think outside the out of the box components. And I'm going to utilize a hit formula in music to illustrate this a bit. So typically, a hit formula is short. It's usually 3 minutes and 30 seconds long. It's in a simple time signature, usually in, like, 4/4 time, 4 beats per measure. There's usually a lyrical hook or a lead melodic hook. And it's usually in a major key. If we take money from earlier, that was an untraditional hit for Pink Floyd. It was extremely long, 6 minutes and 22 seconds to be exact. It was an extremely complex time signature with 7 beats per measure. The hook was a baseline. It was in a minor key. And it even utilized organic materials like cash registers and jangling coins to set themselves apart. So yes, you can utilize the hit formula and create a core component. It's available to you out of the box. It saves time and effort now and creates consistency of your layout across. And it's 100% shareable, which is great. But from the majority of organizations, it's not going to work probably for you. And so you have to think about customization.

So when you think about a custom component, it has to be built by development. So yes, it's going to take you a little more time on the frontend. But it will save you time and effort later because it's exactly what you needed it to be. It also can create consistency of your brand globally, as well as account for regional nuances. So we'd like to think of this as the 80-20 rule, where 80% is shareable and 20% is unique.

Now once you've decided, kind of, how you want to think about your components, it's time to adjust your levels and master your mix.

So if we think about a chord in music, say a C chord, that can be utilized in a majority of keys. It can be utilized at the front of the song, in the back of the song, as a transition.

And we can try to think of our components, kind of, in the same way. So this is an example of our card component, which we, kind of, call a base component. And when we weren't originally building custom components on AEM, we had variations similar to this. But we built them all individually as individualized components. And that can be challenging for a number of reasons, from technical debt, regression, just overflowing your component library. But it also can be frustrating from a UX perspective of authoring. So let's say I'm new to AEM. I'm working in it for the first couple of times. And I know I need a card. So I'm going to type in card in the search bar, and I get seven different choices. And I pick the one that is the most relevant to me. I author it, preview it. It's wrong, right? Now I've got to start over. And that costs me time and efficiency. And now I'm not sure which one I need to pick. And so we've tried to mitigate that risk a little bit by creating preview screenshots and tooltips within our dialogues so that you can see what it is that you're looking for as a user.

Now on this slide, you'll see examples of our live site on AB, a myriad of pages.

And now you will see an overlap of examples of some of the variations I just spoke of, and they're signified by the colors that they're in. If you look at this one on the right, it looks a little bit different. Some of these cards don't all look the same. So you might be asking, how are they the same variation? I'm going to showcase this variation of our card component, which is our dynamic article card variation to illustrate this a bit further. So we have three different styles for that variation. We have our generic, which we utilize within our article library. We have our large, which is utilized for spotlighting a specific article. And our mini, which we utilize for navigational items. But a lot of the information that is shown here is shared. So as you can see on the left, they share the same category eyebrow, which is distinctive based on the site structure setup that we have that determines what the category is. They have images, a title in the form of some, kind of, heading, usually an h4, a published date, a read time, a linkable author, and a description.

Now sometimes on the mini, the description doesn't show. That's okay. We can negate that with styling.

But what we have tried to do with this is actually not have the author manually enter all of this information. And so within the page properties of the specific article that you're trying to pull from, all of this information gets entered into fields there. And an AEM service pulls that information and then renders these as cards automatically. So as an author, when I'm going to make this card, all I have to do is basically sync to the article path and this displays for me in whatever style of variation that I want. If we had not utilized customization the way that we do, we would not have been able to do this efficiently.

I also want to talk about our hero component. And that preview that I was describing earlier in the dialogue, you can see in the hero example over here with our strategy variation.

We also utilize different templates to, kind of, ensure that some of the components are where they're supposed to be. So we have a myriad of heroes here. We have our generic and our home page. Our generic hero is on our generic template. And our home page hero is baked into our home page template. Now our templates are flexible, so you can remove things wherever you need to. But you're ensured that you're getting the thing that you need out of the gate.

If you look at the top right corner, that was a hero that was designed for our America's audience. But it's technically globally shared. So our Australian audience, which technically lives under APAC, also decided to use that hero. And that's perfectly fine. So as much as we possibly can, we do try to share globally. But if you look at the hero just below it, we utilized that hero for Taiwan, which had a lot of specific requirements around font colors. So for compliance purposes, they had to have things in teals, purples, yellows.

And they requested that we can make those changes within the description. Well, that's our rich text editor field that we utilize across the entire website. So we did not want to enable authors to be able to change colors of text at any point in time that they deemed to do so 'cause that is a design governance nightmare. So we decided to basically only enable that functionality within the site structure of Taiwan. So again, that hero can be globally shared. But it also has specific nuance that we have enabled via customization.

Our bio component, we utilize a custom bio content fragment model that we have built to ingest different fields about a person. And then we can render that information with React either through a bio container component and choose the variation style that you want, or we can render the entire page for you based by just tagging the correct person once that content fragment is authored. All of that is done dynamically within our web development side.

We do this for a couple of reasons. But one of the main ones is, again, we're thinking from a regional perspective. So our EMEA audience is always thinking about GDPR, compliance. That's something they have to think about. Our Americas audience is trying to reach a more personalized realm by showcasing things like quotes, videos, achievements that they have made over their time and their career. And our APAC audience loves animation, gamification, bright colors. So by doing it this way, we can still get all of the base information ingested and then render specific nuances to different regions.

So once you have created your components and, kind of, thinking about your component library, it's time to define your legacy and catalog your anthology.

So for our AB component library, we have tried a myriad of ways of doing this. We've built it on Confluence manually, which is very frustrating. Because any time anything changes on the site, you then have to update that manually in the Confluence, whether that's the dialogue, a screenshot, description of how to use it, any kind of governance rules. And it's painful. So what we decided to do was build live on our QA environment, a site structure that, kind of, showcases the components that we have and provides training materials like tutorials, videos, how to request a new component, how to request a new variation of a component, or, kind of, give guidance to just utilize something we already have maybe you didn't know that existed.

And also include governance from a design perspective or say, I don't want people nesting containers all over the place. That's another thing you can notate in that.

We do this by component cataloging into different component types. We have things like basic, interactive, navigational. And then underneath that, you can look at every single individualized component that we have, view their different variations as best that we can possibly display them because we might not be able to showcase every combination. But we do pretty darn close. And an author can go in and look at that preview and see exactly what that variation is going to look like, as well as look at the editing dialogue and see how it has been authored. So this saves us a lot of time, efficiency, and keeps us from having to do a ton of training on a consistent basis by enabling people to go there and start there first and learn what they need to know.

So I hope you guys have enjoyed this session today. You can think about it like a Spotify playlist, and these are going to be your top tracks to take away. So always evaluate your current state make sure that you know what it is that you have versus where you are going.

Do your due diligence. Don't skip discovery. Don't skip requirements gathering. Future scalability matters. So make sure you're always planning for the future even if you think you have it figured out now.

Customize when needed, and don't feel afraid to break out of the box. Allow for variational growth when it is needed and use that to enable different nuances that you have.

Enable learning and training because you want to make sure that you enable your users to be able to utilize the tools that you have built. Always remember things like regression, something that's always going to exist no matter what. And being as flexible as you possibly can within the guardrails that you have is always helpful.

Lastly, if you live in Tennessee, Georgia, Kentucky, or Alabama, please join our Southeast User Group. You can find the link here, as well as the QR code. We've got some amazing AEM champs who are my friends that are speaking up next. Kelly's going to be awesome. And Wilson is up right after this. So please check out their sessions. They are rock stars. So thank you for listening, and rock on.

[Will Harmon] Thank you so much, Mary Alice. That was so great. We're going to keep it rolling right into our next spotlight session. So please join me in welcoming the Director of Digital Strategy and Services at Sunstar, Kelly Hungerford.

[Kelly Hungerford] Great job. Thanks.

Thanks for being here. You guys are brave. I heard it was an amazing Bash.

Yeah. I see some like very sleepy eyes. So hi. Really, thanks for being here. And thanks to Adobe for giving this platform to exchange skills and really share what we learn along the road. And thanks for everyone for joining. And, Mary Alice, thank you because I learned something there, super interesting. I mean, I love this platform. I love being able to connect and as peers be able to help one another. So today, I'm going to take a higher-level view, where you were so successful in diving deep. I'm going to go up a few levels and talk about our transformation and what's led us to Edge Delivery Services, and our experimentation there. So I'm Californian. I live in Switzerland. A little plug for Switzerland. Visit. It's a beautiful place. Shout out to a peer who's here from Switzerland. Woop-woop. Yeah. There we go. I think he might be the one and only. No. Well, we have there many too. So our partner is here. Super excited. So thank you, Martin, for being here.

I represent a team of 10 at a company called Sunstar. Some of you might know Sunstar. Some of you might not, but you're going to learn more about who Sunstar is. My team couldn't be here, but we're a team of marketing technologists that cover six solutions in house, Adobe Solutions, and our marketing technology stack is primarily based on Adobe. So we'll talk a little bit about that and it's fairly new. We just started with marketing technology in 2018. So that wasn't very long ago.

Today, what we're going to talk about in the next 20 minutes and 30 seconds is an overview of Sunstar's transformation journey, why Sunstar moved from on-prem to the cloud, and how Edge Delivery Services is really helping us transform within our transformation.

For those of you who don't know who Sunstar is, Sunstar is a Japanese company. We're nearing our centennial in 2032. And all of our products across a consumer division and engineering division really aim to help improve quality of life for individuals. We have some colleagues from Adobe in Japan who are here in the back row, and you might know who Sunstar is also. So that's, yeah. It's kind of exciting. Now in the US, you might know of the GUM brand, an oral health brand. That is a Sunstar company. So Sunstar was founded in 1932 and we have a really cool story. So we're a family-owned business and our founder, Kunio Kaneda, was a bicycle enthusiast. And as he rode his bicycle, he realized that when he had a flat tire, he had a problem. So he engineered, packaged, designed, and distributed bicycle repair glue in a tube. 14 years later, he took that same engineering and applied it to powdered dentifrice in a can, which was powdered toothpaste to create Sunstar's, which would launch Sunstar's oral care brand, GUM toothpaste in a tube. Today, GUM is our leading brand. We have some other brands along the bottom of the slide here. If you ride motorcycles, your brakes are probably Sunstar brakes, if you ride an ATV also. If you have pets, you might have one of our QAIS air filter systems. Really amazing. Winning awards. So worthwhile looking into. But the story, the hero of our story today is the GUM brand.

So as I said, we've really only been working with marketing technology across the Western Hemisphere, the last six years. So our flagship brand was the hero of our transformation story, and we launched a four-solution platform. So it was AEM, Target, ACS, and Analytics in 2018 on-prem. By 2019, we had launched 26 sites and 13 languages. And why do I think this is important today? Because we all work for companies that might be a little more traditional than our tech savvy minds would like, and I think this is just a visual reminder and nudge that your company can transform too. Take all of your knowledge in and be passionate about what you do because magic can happen. It's the people that that are making it happen and the technology is supporting. So when you think transformation or initiatives, it might seem like tight timelines, but butterfly effect happens, and you can reach great things. And during COVID, we realized that when we were on-prem, we just weren't getting the flexibility that we needed. We couldn't innovate fast enough for our business users, and this was a problem. So in 2022, we made a radical move to the cloud fast with our partner who's here at comwrap.

It was some heavy lifting, but because we had already upgraded to 6.5 so if you're thinking about going to the cloud, be sure that you're on 6.5. We were able to make that transition relatively easy. I was very nervous. And in Martin's own words, who are here would say, "Kelly, take a chill pill. It's all going to be fine." And it was in the end. True.

We also took the time to integrate commerce into AEM. So if anyone is interested in integrated using Sift connectors, please, please talk to us. So we use commerce for our product catalog. And then in 2023, 2024, we extended our platform across the hemisphere to the Americas. And we also started experimenting with Edge, which is what we'll get to. And as well, we're migrating from ACS to Marketo, so a lot of technology happening with Adobe for very good reasons. So we're excited about that. So back in 2018, this is what the GUM brand looked like in Europe. Very fragmented. So if we talk about customer experience, it was not good. And more importantly, everything was outsourced to an agency. So we initiated a multi-year marketing initiative called ACHIEVE and that was really to revolutionize the way and rebuild the way that we marketed. So we did a full brand refresh to help us get there, and it was very much based on Adobe, these solutions that I mentioned to help power this into the future. By 2019, we had one unified face across Europe. We had 13 languages that were all sharing one instance. So when Mary Alice talks about components, templates, these are all shared. We create once, roll down. We use translation to help us support all of these languages. And by the end of 2024, we'll have 40 sites across the Western Hemisphere using the same codebase, same components, same templates, content localized. So a lot of magic is happening there with the teams. We have over 250 users that are utilizing AEM in the Cloud right now on sites.

I just threw this in there because people often ask what does success look like? And for us, if you look at Sunstar, the little blue line down in 2017, you see we were flat, like, no pulse. The world could not find us. So here is where we launched our first two websites. This is where we launched the next 24. This is our content marketing kicking in. And we often, like all good brands, we're judging ourselves against competitors, we do now volley back and forth between Oral B. Don't know if anyone from Oral B is here, but watch out. We're trading positions all of the time, and this is really important to us. And note, this is just for Sunstar EMEA traffic to global traffic for these other brands. So we hadn't yet extended the platform to the Western Hemisphere. So this is really phenomenal. And I think what's important here is when you're talking to your management about content strategy, content management, you can't build that strategic platform unless your management gives you time to let it grow. It takes a good 18 to 24 months. So feel free to share this slide, send them my way if they have questions. It's a long journey, but it does start to kick in.

So what changed during COVID that made us move to the cloud? Everything. This is our motto and our mission. We live by this every day for our marketers across the hemisphere. And if we can't get easy-to-use tools in their hands so they can create the experiences and communicate with oral care professionals and consumers, we haven't done our job right. And we were code locked. We just couldn't make the changes we needed fast enough during COVID. And it was a problem. All of our investment was going into maintenance. And here it is. This is... If you can see here, like our stack, a good solid one-fourth of it was just keeping the lights on. And my management wasn't increasing my budget because of this. They were just like, "Well, here it is. What are you going to do?" So I said, "Well, we're going to go to the Cloud. That's what we're going to do." And why? Because we wanted to take all of the effort that we were putting into maintaining and releasing. We wanted to shift that back to Adobe. And that's exactly what we did. So for anyone who's not familiar really with cloud services or what you get out of it, I think this is just a great slide that our partner comwrap created to really show where a lot of this effort is going under the waterline. And this was that really that red portion. And this is where we were, I mean, our time and effort was spent there. So when we moved to the cloud, we dropped our operating expenses by 29% right away. And so this was investment that we could reinvest into innovative ideas, products, new features for our business users.

We were able to what took us three and a half days before to deploy, to prepare. We were able to do this now. I don't know maybe it's 20 minutes some days, maybe it's an hour. I mean, radically reducing the time that the teams spend. We also switched partners during this time because our original partner maybe wasn't as comfortable going to the cloud. So we went to a cloud-native partner that could help us realize really better business value.

So where does Edge Delivery Services come into this? If we're so happy on sites, why would we consider Edge? SITES are amazing. I mean, we have everything we need for 250 users. We can scale globally. Well, sometimes you have business cases in house where you have other technologies competing. You have maybe global PR teams. You have scientific affairs that needs a microsite. You have your PR team that has a smaller website or a need coming. And what do they do? They go to Wix. They go to WordPress. Gasp. Sorry. WordPress very often.

There are a lot of different websites or a lot of different platforms that they can use, but this starts to cause problems because as we start talking about the technology that we have in house and how we're trying to leverage this and democratize and really work as one Sunstar and consolidate our costs, we have other departments that are, kind of, working counterproductive to us because they're sinking money into a platform that we can't leverage anything from WordPress. We can, yeah, nothing zero. So this is where we went. This story is about our PR, our Global PR Manager, Elena Alcalde, who couldn't be here. She's on her way to Japan right now. And this is pretty much her. There was nothing that she could touch on her website that didn't break it or didn't cost us development. And the global PR team is really small. There are about three people and they run the whole show themselves. So this was really painful. And all of their money was going under the waterline.

This is a true slide of when we went live. You'll see Franklin here because we were a part of Adobe's VIP program for moving websites to the Edge, and it was called Franklin at the time, which I'm very near and dear to that name. It's very hard for me to say Edge Delivery Services now. Just saying. But these colors, like this map is just representative of the pain that we had. The only thing that we were doing on WordPress was consistently delivering bad experiences. So all of the red is how long it was taking someone to load a page. If you go to sunstar.com now, it should be lightning fast on your phone. And I didn't say much about Sunstar because I encourage you to go there and just check out the speed. So those sites are live on Edge. We have three sites that belong to this group. So when you see dips in here, this is when we're really putting effort into trying, so sinking money into trying to fix it. And then this drop-down at the bottom is the migration itself. So we invested, we migrated, and everything is running down in the green now.

What does this mean in terms of employee experience and employee happiness? And how does this radiate outward to customer experience? If our employees and our team members are not allowed to autonomously create content when they need to, if they have to get a hold of IT or another department, we're doing something wrong. We're failing them.

If you have a low performing CMS, we don't even need to talk about that. You're not going to get anywhere. I mean, site speed delivery is everything if you want to increase engagement on your website, have people management happy. We got to get there. UX and SEO, this is the one area that when budget is tight, it's always cut from business. They don't have the money to invest because all of the money is being invested in maintenance. And small teams. Small teams need really, really agile, and nimble platforms to work with. They just need bare bones and muscles, but they need stellar performance and experience also. They don't want to be the one that has no budget and also has the cruddiest experience in the department.

So before we moved, when we were on WordPress, this is a screenshot we took before migration, before we went live, and we migrated three sites. Sunstar.com our corporate site. Sunstar Engineering, which services our engineering division. And then Sunstar Foundation, which is dedicated to education for oral care professionals.

Oops. Sorry. There we go. So all three websites when migrated, this was a lift-and-shift. There was no additional effort put in.

It was near perfect. And this is just consistently happening through this shift to Edge. So we're removing all of the backend, all of the platform mess, pushing everything out to the CDN, and this is the performance. And again, if you go to sunstar.com it loads fast. You can go to another site, maybe see some differences. But this is lifting, we've seen an increase in traffic. I think, since we launched the first site in November of last year and we finished the other two sites, I think we're seeing a lift a month over month of 10%. We're seeing a longer on page.

We've gone from, I think, a minute and a half on page to two minutes now, two and a half minutes. So we're seeing the engagement increase. And it is only due it can only be due to the lift here.

True numbers speak to our management. We dropped our agency costs by 63%. Overall costs by 83. This doesn't mean that we're not working with the agency anymore. Our partners are happy. Our partner did not want to maintain WordPress. Our partner can now innovate. They're looking into Franklin and seeing our Edge delivery services. Sorry. Seeing how can we improve the site? Like, let's talk about SEO. Let's talk about UX. Let's talk about new designs. How can we create more interactive components now that we've lift-and-shifted? So our agency is actually happier, the one that's been supporting us the whole time on this because their teams can look towards the future and not really maintain this dead platform.

So I just want to talk quickly also about the operation team. So if you work with sites so we have 10-person team in house, not all dedicated to sites, but we do have an agency that supports us. Comwrap, who's here. And we have about two and a half, three people dedicated to two sites, for the Sunstar GUM website.

This was the migration team in-house. Kayo was our UAT. So she made sure that all of the pages were correct because they were in Japanese, a good portion of them. And I unfortunately don't speak Japanese or read Japanese. Dejan was our single point of contact for the Adobe engineers. We did this lift-and-shift with Adobe. And then we had Elena who was the PM. She was the business owner. So it's a pretty lean team. It was about 1,300 pages that were migrated.

If nobody is familiar with Edge Delivery Services, we're using the very classic what came out first. We're built on SharePoint. And as you see it here the... Well, here we have under the website management. This is our structure folder. So if we were in sites, we might have a tree with our different branches. It's housed on SharePoint here. The folders create the navigation. Our permissions are as granular as we need them to be. We use leverage SharePoint permissions. So it can be folder level. It can be document level.

And our languages are managed per a folder in each website.

How we author is per document. So this is how our authoring looks. Now it doesn't need to look like this for everybody. Adobe just announced they've come out with the universal editor. We launched already in December or in October right when Adobe was bringing Edge Delivery Services. So we're using author-based documenting here, author-based Word doc authoring here, we might not stay with that. We might move away because we have different sites that we'd like to bring to Edge. So we might leverage the Universal Editor and maybe use AEM as our backend and just Edge as a frontend. But here, what our team loves, what Elena loves is on the right-hand side, you can see Comments in Word. She can work with her teams just commenting for editorial changes. She's a very small team. She doesn't need to go through compliance, very lean, and she's loving this. Our team in Japan really enjoys this. They don't need to contact us anymore. In fact, we don't hear from any of our end users anymore that she was supporting. It's so easy and self-sufficient.

What else? Adobe has a very nice Sidekick. It's a very simple functionality up at the top. You'll have your assets. So we have this hooked up with our DAM. So we get all of the assets from the DAM. We don't need to copy and paste in there. You have a Preview button or Publish button and then you have your component library, which are called Blocks along the left-hand side. Now there are a lot of ways to these blocks are color-coded. You can ensure that you translate, and you don't translate the name of the block because it's important that it stays named. There's a lot a lot of engineering going into this to really help ensure that you can fit a very simple use case, or you can expand to a larger use case.

And what's nice here also is we are managing all of our metadata and our redirect files here in Excel for this website. So it's very simple. Again, upload Excel. Your redirects are created. So it's a very... Let's say concise and easy way to manage content and let's say web operations for certain use cases or teams within your organization. We are experimenting to see and exploring how far can this go and which other brands that are maybe not using Adobe or maybe investing in other platforms, do we bring them over to sites or do we bring them to EDS? Or do we store all of the content in sites and then we can decide. Do we want to have sites as our classic web pages as our go to? Or do we want to try something more headless here? So this is really it's in progress. While it hit this business need for our PR team, we also see this as a proof of concept just for exploration of where this is going to go and we're really happy to be with Adobe because they're doing all the hard work and all the heavy lifting and I can say that evolution has been quite astounding. We started working with them in May. So this is just continuously evolving at very rapid speed.

Yeah, I mean, I think here also really interesting is we have one person in-house who is frontend developer. He's making all the changes himself. So front we know we're hitting a scale or a skill shortage on the market for technology. Frontend skills are very easy. It's CSS, HTML, JavaScript. This is pretty much the skill base you need to work with EDS. So what's next? So we are experimenting to trialing how would this work with commerce because we use Adobe Commerce in-house.

Can we move additional brands to Edge Delivery Services? It's really just this exploration, content fragments. What if we start creating more content fragments? How can we use this to power microsites? So a lot of exploration about how we can use EDS for really rapid deployment of sites and microsites within the organization to help leverage our investment in Adobe, but bring better value also to our teams.

So final thoughts. I believe customer experience is like beauty. It radiates from the inside out. If you look at anybody's website and it seems cruddy, there's probably chaos happening in-house. It's really important for our teams to have the best tools possible and that's why we invest because we want their experience as an employee working with technology, which is not everybody's cup of tea to be there. Transformation is a survival skill. Always be transforming and equip yourself with the right tools along the journey. There is no fast and cheap. There is no, I mean, we have to invest, and I think this is a message we also need to take back and help educate up to our management. A last call out for Switzerland. I don't work for the tourism board, but I live there. I think Switzerland is the best kept secret. Nobody ever... It's never on anybody's hit list, but this is a great little walk. I can tell you where it is if you're a hiker, but visit Switzerland and we'll see you there. Thank you.

[Music]