Modernizing Qantas.com with Edge Delivery Services (EDS)

Transcript

All right, good morning everyone. I hope you found this morning’s session useful and helpful and insightful. There’s obviously a lot to take in, even from people at Adobe for us. For those of you that don’t know me, I’m Glenn. I’m one of the content specialists here at Adobe. I’m fortunate to work across many of our customers in federal, state, higher education and others. So if you sit in any of those, come and chat to me later. I’d love to have a chat to you and see how you’re going. Today I have the pleasure of being joined by Tim Lavelle from Accenture to chat about some of the work that Tim and his team have been doing with Qantas. I don’t know if there’s anyone from Qantas in the room today. I suspect that they might be busy working through their project. We’re fortunate to get some of Tim’s time. But before we dive in, Tim, did you want to give yourself a quick introduction? Yeah, sure. So hey everyone, my name is Tim Lavelle. We’re at Accenture Song. I work under a senior architect in DHP practice. I’ve been working at Adobe for 10 plus 15 years now, I think. When I talk to Adobe folks all the time, Glenn, Joe, and a few others as well, on the product offering and where it’s been and where it’s going as well. Awesome. All right, before we dive in, quick icebreaker. Tell us something about yourself that someone who knows you well might not know.

Okay. I hate these.

Something, I work at Accenture, I’m an architect. But when I talk to people who ask me this question, my degree is actually in graphic design, focusing on color theory and topography. And I’ve come a long way from that state. But when I do my PowerPoints, I’m very critical of how I do things. Exactly. Definitely. I can appreciate that. So I guess the natural question then is, what’s your favorite color? Blue. And what’s your mother’s maiden name? And if you just get a one-time password, can you just read it out loud? That one’s over there. Sorry, sorry. Carry on.

Okay, Tim. So obviously, again, as I mentioned, you’ve been quite busy, obviously working with the Qantas team. Can you tell us a little bit at high level about the project and how it’s going and what’s going on there? Yeah. So we’re doing a lot of Qantas. As you can see it in the screen here, it’s been a complete whole new redesign from their old website, which is about 10 years old. So while we are delivering on Adobe Cloud Service and as Adobe Service is, we’re also doing the new experience design, done a content audit and rewriting content, expiring content, reimagining some of the content as well, the website. We’ve changed the entire IA of the website as well. If you remember, Qantas used to have three navigations. Now it has one. So that was a huge change in the business. We’re doing analytics, unified data layer, we’re doing Adobe services, we’re doing governance, where they’re working in consolidation of assets from three dams into one dam as well. So as you said, the team’s very, very busy. There’s a lot going on. Yeah. And obviously with 10 years worth of development and technology in place, it’s a big project to go through, especially beyond just the technical side of things, but the program management and the change management as well. There’s a lot.

So I guess, Tim, just if you imagine yourself, you’re walking down the halls of mascot and you bump into one of the Qantas executives, how would you describe edge delivery to them in a couple of minutes if you add them? Yeah, look, I think the biggest benefit to a brand like Qantas and many brands out there who use on-prem and are used to the way that you deploy sites is Qantas has gone from a two-week delivery deployment cycle to a two-minute deployment.

And case in point, we launched this homepage about a month ago. And after the launch, we saw a defect. We got it fixed in less than five minutes and deployed it to the site. So no rollbacks, no blue-green, no jar compilation, just a quick deployment. So that was one of the big things for the business. The other area is that, as we all know, with Adobe, the specialists and developers, HTML, Sitely, the Java, quite a bit involved when we were building Adobe websites. We’re with Edge Living Services now. To us, to write our blocks, it’s JavaScript, CSS, and JSON. And we needed to GraphQL APIs. So it’s really opened up the development team to a much wider market out there than trying to find these developers who know how to write HTML, use Sitely, develop your servlets. It’s a big change, a big shift. And components like many brands deploy React code, React components, to get a better development model and workflow. With Edge services, it’s a very similar workflow now. And it’s much easier to deploy and develop. So by having a fast deployment time, better innovation, lower cost in managing that, and then having to build a huge pool of developers out there to write my new code makes it much easier for a brand to pick up Edge services versus going with traditional AM on cloud service. Those are two big key things. Among universal editor, the cloud service ultimately success quite a few things. But those are the two biggest things that I talk to a lot of brands about. And they actually keen to know more about that as well. Awesome. Just a quick question for the audience. Just a show of hands. Who is currently using or has used Edge Delivery Services? Who has experience with core components and traditional AM development? I’m guessing everyone of you raising their hands.

Awesome. We’re obviously going to be chatting a bit about this because I think it’s a really exciting thing to be working through. And again, we’ll talk about some of the results as well.

It is a big decision, I think, to choose, especially if you’re coming from an install base where you’ve got core components, you’ve been working on the technology potentially for, in Qantas’s case, 10 years. What sort of process did you go through to consider, compare and contrast to use something like Edge Delivery Services as opposed to building it again in core components? Yeah, look, before we did this project, we spent a couple of months in a tech design phase. And at the very beginning of the phase, we were tossing up, we’re going to cloud service. We know it’s going to happen. But do we want traditional AM because we have components, we have Java code, we have configuration already set in place, or do we go to Edge Services? And Edge Services, it is a new building workflow. It is a new code base, which means essentially it’s a Greenfield build. Now, a lot of brands think it’s a bad thing because Greenfield means really high cost, a lot of time to market. It’s going to slow things down. But the opportunity there is if I’ve got 10, sometimes 15 years of legacy code and upgrade on upgrade on upgrade. And as we all know, when we do upgrades, it requires writing new code to use new features, deprecating new features, and you usually just kind of fix what you need and keep it going. So our big thing was, do we bring all the old ways of working, all the old code that we have duct tape, sticky tapes, Grilla glued together to get it working? Or do we throw out old ways of working, which are 10 years old, and you look at modern ways of working, modern development. And yes, it is a new platform and like many brands, Qantas, global presence, a lot of different sites across the world that get used and flights is a big thing for them, obviously. So we have taken all of the leads into a room. And we asked, what’s stopping us from going to edge services? Look around the room, kind of like now, and it was crickets. No one really had a strong answer. It was just like, like anyone else. And you said change, change is such a hard thing to do for anyone. And having that change and going through it is difficult. But having a good partner along with you makes it all easier. I’m not saying Accenture is a good partner, but I am, I’m a bit biased. But having someone who is willing to go in the trenches and get things done and solve problems that come up was a big defining factor for us. But the second defining factor was because of edge services and we talked about deploying code very quickly, we can write really simple code. If a problem does come up, we can fix it very quickly. If we do find something that we can’t do or need to work around, well, it’s JavaScript code. It’s easy. We can fix it. So knowing how edge services work now and deployment in some pipelines, we also said, fine, you know what, let’s just go and design for edge services. And all the leads agreed. And then we went into the next phase of work of tech design, knowing we’re going with edge. And we identified all the niche factors that we needed to consider for and we built TSDs around that, tech solution designs, to make sure we could get things done right. So it was a big shift, not for developers, but for content authors, for the platform team, for the business. And it was a lot of discussions and talking in meetings to get to them and other brands we’ll work with to get them to that point. They feel comfortable. Was there a discussion around, obviously, where does technologists understand the technology and the impact and the benefit of that? And obviously acceleration of the development process is super important. Yeah, I wrote an arc about this actually, because I’ve talked to quite a few brands, CTOs and tech leads. And EDS is great because it’s vanilla JavaScript. Vanilla JavaScript? What? I’m going back 10 years in time, instead of using React or Vue, Angular is kind of on its way out. I’m sorry if anyone here is Angular dev, but it’s usually React now in other areas.

And it’s like, well, I don’t want to write vanilla JavaScript. But vanilla JS today is ESX-compatible. You can have a lot of functionality you have with React today. And we’ve made a decision. Let’s go with vanilla JavaScript because we have a lot of flexibility. Let’s go with vanilla CSS because we don’t need CSS modules. CSS3 has come a long way in how we can write code, we can handle functions, handle how we do areas in CSS itself. So we said, look, for most of the website, it’s quite simple. So let’s keep it simple where we can. And when we need complexity, then let’s use that React or Preact for our development. And we chose Preact as that code base because it’s smaller package files and built for self-contained components versus a full SPA solution. So it really helped change the way that we developed and they developed as well. And we had some even Accenture, you know, HEMAT Guard, senior architect. All ADS is crap. It’s a different word, but I’m going to be PC here. Very early days. Fast forward, we’re having a call with the customer in China and he’s singing his praises. I love ADS, Edge Delivery Services is a great solution. JavaScript is awesome. And this guy, HEMAT Guard, he has code sitting in AEM today. He’s an ex-Adobe engineer. So hardcore Java dev now switched and loves what it is.

I was going to touch on it and you’ve sort of covered a little bit of it, which is excellent. Obviously, and you actually corrected me because I should know these things, but you can always be learning.

The skill set change obviously is a big shift. So if I am an experience manager developer and I’m thinking about the 10, 15 years of experience that I’ve got, and I’ve built that up over time, am I throwing all that experience away by using ADS or am I, can I still leverage that experience that I’ve got in building experiences with AEM? So experience is a process, something that we learned through developing code and deploying sites and integrating workflows. All that same process still exists today.

How I write the code is different for Edge Services and that’s okay. There’s still the need for some Java code and you still can deploy cloud service code to the pipelines for when you need Java code back in. But all that you’ve learned around creating your models, creating your APIs, creating your configurations, creating your pipelines, they carry you over and then you evaluate how does Edge work? How do I apply my background and my experience? How do I develop for, configure for, content launch for and adapt it to the new way of working in experience in Adobe and Edge Services? So it is a shift.

I’m not trying to plug myself, but I did write an article around the mental shift Teams need because it is shifted across the whole business, not just in my code, but how I think about things as well. What is the biggest takeaway from that shift in mindset that you would say, call out for people? I’m going to quote Mark Schultz on this, who I talk to often and we saw him in the earlier session is, just go and build it. He says something a bit different to me, but he said just go and build it. And it’s quite true because there is areas where I cover it later on here, but a lot of unknowns when it comes to the new editor, when it comes to managing my pipelines, when it comes to writing my code. And there’s the fear of the unknown because I haven’t actually got hands on and played with it. Once we started taking Qantas and other brands through the code, the Russell editor, the content fragments, there’s a light bulb moment. It’s like, oh, this is actually quite easy and it’s not so bad after all. So if you are considering it or you have clients who are, to quote Mark Schultz, just go build it. You might have said something like just go and build it. Yeah, it’s not a bit in there as well. You can build it. Awesome. But, okay, Devil’s Advocate. Sounds great.

It’s great in a PowerPoint slide, which is the world I live in these days. I’m no longer hands on, unfortunately.

But just if we boil it down, it’s just really a fancy CDN, isn’t it? A fancy CDN. No.

Just client-side rendering. How hard can it be? It’s been for years, right? Excuse me. And you kind of triggered me to say something here.

There’s a lot of misconceptions. I’ll try to find that. Yeah, okay. Fair enough.

I use the word misconceptions because until you start using it, you don’t quite know what’s going on. But edge services is a common thought of client-side rendering when it’s not. It’s client-side decorating. So everything that developers or producers put into universal editor is rendered on the server side. And we heard Lonny and David talk about agents and semantic code. Engines like clean process, clean semantics. And the great thing about edge services is that it’s been written with agents in mind. When I do my universal editor, I create my blocks, my content model, which is extremely important. Extremely important to get that right and understand how that works.

Everything I put in the editor is rendered server-side.

And then we use JavaScript to add attributes, to add a couple of divs if we want to. And to decorate it, make it look clean. But everything is server-side for SEO, for engines. I bought to go understand that.

So that’s a great thing about it. I love it. CDN is there once it gets generated.

But talking to Cedric two years ago in the UK, the guys have been working with Google for quite a long time on this. And I was quite surprised and shocked at that. They were working with the Google engineers on how do we get nice, fast performance websites. What’s our caching model? It’s a caching process.

So with edge services and the CDNs, they invalidate at the block level, the page level. When I change blocks, that block gets cached, but the whole page. When I load this website, I know where I need to. You have your phases to load things as well to keep a nice, fast performing website. So eager, lazy, and delayed, I think it is.

And that’s something they worked with Google a lot to get that working very, very well. When you understand how that works, you’re like, crap, that’s a great shift in how we deploy and manage our code and the CDNs as well. So yes, there is fastly a lot of code that has Akamai and others, and they can integrate and they can invalidate the API level as well. So you do get that really clean integration. But edge services, how they manage semantics, how they manage CDN, how you manage your editor. And more recently, bring on markup, which is a great new concept where you do have dynamic content from APIs, commerce products, POPs, content fragments. Bring your own model can now render at server side. So you get all the benefits of SEO with dynamic content at the same time. And it’s constantly evolving. The documents, there’s a new section, what’s going on here now? So that answer the question? I think I did. Yeah, I think so. As some of you might know, I’m a… there’s a… Dobby Boomerang, I’ve gone and been and come back. And edge wasn’t a thing before I left and away for a couple of years. It’s like a lifetime in technology and I’m back and it’s been live for years now. And I remember chatting to Mark as well, asking the same sort of question, going, I love it, Mark. I love the PowerPoint slide, but tell me how the magic actually works. And the turning point for me was, right, this isn’t just something we dreamt up in isolation. This is something that we worked with the Google Chrome engineers on figuring out how to optimize delivery to predominantly the number one browser. Which was really impressive. So if we think back a little bit to that conversation that you might have bumped into, again, maybe the CIO, CTO, or even maybe a CEO at Qantas in the hallway. Would it be fair to say if you were to summarize some of the key points at that level, it’s about performance is one thing.

Obviously, I think you made this comment a couple of weeks ago, actually, which I think is a really great way of thinking about it. You’re not working towards green Lighthouse scores. You’re working away from green Lighthouse scores. You’re trying to maintain the green. Now, it’s not always possible. Sometimes there’s things that you have to do that will potentially bring the score down. But it’s the inverse way of working, which is really, I think, incredible as well.

So performance, speed, obviously, SEO, inherent benefits through accessibility and the like, which all adds up to business outcome through organic search and revenue potentially in Qantas’s case, very much so.

Bringing it back to the technical side of things, you mentioned obviously development, velocity, speed. The team’s obviously moving faster now, too, which is great. How fast are you releasing at the moment through the project? Yeah, so we launched the first page back in June this year. I was talking to some of my team at Accenture and we launched the Lighthouse page, the first page. Obviously, about fancy who cares, but for us, we’re lucky to launch the homepage, the biggest new page. So we launched that and then we started launching a bit slower. So every couple of weeks we do a code release or some page releases. We’re now doing code release in one week, page release the next week. Because we’re launching multiple pages, we’re doing translations, we’re rolling things out to multiple countries. They have 36 different websites, six local languages. There’s a lot of rolling out, a lot of managing of these pages.

We will eventually move to everyday deployments. Once we have the platform done, the project finished, all the blocks written, and that’s a big benefit to the product owner at Qantas.com was all F-band. If I can deploy daily, my dreams come true. It’s like, well, yeah, that’s a big dream of any brand, but what comes with that is maturity and CI CD. And the big thing with edge services and what we did at Qantas as well is I can deploy code really quickly. I can deploy great code, awesome, fantastic. Because I can deploy bad code very quickly as well and break stuff. So having edge services now, true test automation has to be in place at the unit level, at the regression level, at the API level. To make sure you do find all these niche areas where something might break, especially in a multi-site environment, making changes can break some different variations somewhere else. So you have to put testing across everything to make sure it works and you are getting what you need out of that. Yeah, yeah, awesome. All right, so we’ve talked a lot about obviously the technical aspect of, as you corrected me this morning, which I should know from my product marketing team, edge delivery services. Not EDS. Mark will say what? I don’t acronym everything at Adobe as we do.

What about the authoring experience? Like what have you found there? It seems to me again, a big shift in that area as well. It is a big shift and we’ll come a bit later, but the big shift is Adobe has gone from Stag templates to Edible templates to now the UMass Oedder. And between the Edible templates and UMass Oedder is a very big shift in how we create content. We’re used to dragging in a component into a layout container or both your own custom call container as well. Dragging multiples in there. For now, UMass Oedder is more of a hierarchy approach. Sections power my full width and then my blocks sit inside there.

And we’ll talk a bit more later on, but nesting becomes a big no-no for these as well. Because it wants to control semantic. Semantic code, nice clean readable code, which is I need nice clean readable blocks. Management of my layout, management of my blocks at the same time. So that new Eddier was a huge shift in quantum because I just spent the year prior getting quantum on the Edible templates. And doing training on layout containers and how to build a three column layout, a four column layout. Record a 90 minute video on how to do these things for the producers. That got so useful now that that’s like, sorry guys, I can’t do anymore. But anyway, what do you mean? We just shifted to this and now it got changed. So there’s a lot of worryness around using the UMass Oedder. How to use blocks, how to configure things. We’re very used to creating these complex authoring UIs. All these tabs everywhere, all these different rules. Often written by developers. What do you mean check this for a null? I don’t understand what that means. So often times you have to do a design for your authoring config. But now it’s very different.

And I was getting a lot of, this is going to be, we can’t do it, it’s going to be horrible. No way, we’re back to the official AM. And then using Mark’s motto, I went and did a 45 minute session with the client. UMass Oedder sections, blocks, how you manage things. And again at the end, lightbulb. Oh, holy crap. This is quite easy. This isn’t bad at all. And the UMass Oedder really helps with getting away from brand drift, layout drift, all these crazy pages. You’ve got a brand, you have a style, stick to that. And I love Edible templates, but we’ve probably all seen it. People do some crazy stuff with these layouts and crazy things. And it’s just because it’s no longer my brand. It’s just a WordPress site with plugins and all these different things.

So it is a shift, but once you go out and use it, you’re like, oh crap, that’s pretty cool. Not bad.

Have you found authors, obviously there’s a big shift in terms of the way in which they’re working. So going from Edible templates to Universal Editor, have you found that they’ve started to embrace that and they can create content faster? Well, they have. They have. And they’ve actually like it, they love it a whole lot more now. Because with UMass Oedder and blocks, you have a single block and a collection block. And with Edible templates, we’re used to, I want to have an article, three articles. I want to change the image to be top bottom. I want to have a hero image. I drop in three articles, like content. I got to change each of my styles for this. Hopefully I have this style system implemented. Where with the collection block, I can update my visual layout for every child in my collection from parent level. So I go configure it once and everything inside of it now adheres to my brand style, my brand variations. But it’s changing everything individually as well. So to them, that was a huge time saver, huge time saver. And then just the ability to have really clean blocks with very clean configuration. And my panel always been the same. The same layout, the same UI, the same place to go and change things. Because no more, you know, this component could be very different in UI versus this component. It keeps it the same, which makes it very easy to learn. Once you do it a few times, it’s repetitive. Now I’d suck in my head. I always know how to do it now. I mean personally I love having 15 components that are the same thing. We just with an image move from left to right to up and down. It’s excellent. I love that.

You mentioned earlier and you’ve touched on it now, so we won’t go into detail on it now. But obviously the point being to the nested Dibs being silent killer. Obviously in the layout and the way things get presented. But also as knock on effects to SEO and now to LLM crawling and so on as well. So yeah, away from. Nesting, as we all know, nesting uses Dibs and Dibs and Dibs. So a layout container and a layout container and a layout container and names and text or a table and a table image text. It just gets out of control. And it makes it really hard for SEO to read, understand. Now for LLMs to go and read and understand, like what the hell am I looking at? Excuse me. What am I looking at? The context. Where nesting was this huge like, oh my God, I can’t nest. My life is over moment to, oh, it’s so much easier to use. So much easier to build. I don’t have all these crazy Dibs everywhere. I’ve got nice clean code even at the server level. And then when we decorate and decorate, not render, we decorate the block. We make sure we don’t enter all kinds of Dibs. We actually take away some of the Adobe Dibs to make it cleaner and easier to work with as well. And that’s where content modeling comes into field grouping, element grouping, field collapsing, etc. Which is a good concept to understand when you get into it as well. Yeah. So we are almost at time. But for anyone in the room that’s considering this process at the moment, they might be working on your own sites. You might be working with a customer, going through a process of deciding, do we go one way or do we go the other? Are there any lessons or thinking that you would advise people to take on board when making that decision? Yeah. The biggest thing is it is a greenfield build. But with that greenfield build comes the ability to start fresh and use a new framework. So I would consider that if you’re ready for that. But also, Edge services is getting all kinds of new features all the time. New features, new functionality, new releases. AI is being given to it as a priority, as I understand here. So just go and do it. And Adobe is moving rapidly to this modern technology, this modern framework. I can’t say a few things now that I do know some stuff that’s happening behind the scenes with Adobe. But they are moving towards modern development versus the old way of working.

And one of the big things with Qantas was let’s just get ourselves ready for the future and feature-proof ourselves. Versus going into traditional and then having to move this in a couple of years time. I don’t know when we’re going to be deprecating them. I can’t say that. But we want to be ready for that anyways. We took it on. And the great thing about it is because we can deploy code very quickly, as part of the Qantas project, they have ultimate success. Which is a great benefit for us because we have seen, with Joe as well, being part of the team, issues with the RTE or the code base. And working with Joe and Adobe, we had fixes in place in a day, sometimes a couple of hours. That’s the core part itself. So it shows how fast things are moving with edge services in the world. Is the deploying cost is quickly enough because of how it’s been built and interconnected at the same time. So just go and f***ing do it, as Mark would say. I think that’s the key takeaway from just summarizing everything that you’ve said. I think, yeah, go do it. Go have a go. I think it’s easier now to experiment with these things through obviously AEM Live and all of the resources that are now available as well, which is excellent.

And obviously the other takeaway I’ve taken from your lessons learnt is really bring the business and the greater organization along for the journey, but do it by showing. Do it by showing. Yeah, awesome. Okay, well thanks again, Tim, for taking time out for having a chat with us. No worries. Tim will be around briefly for the lunch break. So if anyone does have any questions and wants to grab Tim, feel free to do so. Obviously I’ll be around all day too, so happy to have a chat to anyone as well. But yeah, thanks everyone for your time.