Summary
Confirmed integrations (11 total, some marked for discussion):
Integration usage patterns:
ATDW technical details:
Mapbox technical details:
Five websites to migrate:
Content and components:
Component consolidation opportunity:
Platform history:
Recent improvements:
Current challenges:
Notes
Transcript
This will be the wider team's onboarding. So we've got everyone from the TA Digital team here today, except for Celinda. Unfortunately she's sick. You will meet her sometime over the week. And then for the TA team, you are meeting the horizontal team. So this will be our migration partner. for the CMS project. Um, If you guys want, you can do a quick... Would Brianne just introduce yourself to everyone?
I'm going to be honest, Ryan. But my name's George. I work for Horizontal. I'm their managing director. I'm Meg, I do delivery at Op-End Horizontal. Nice to meet you all.
I'm Ed. I hope you can hear me through Meg's computer.
I work in digital strategy at Horizontal.
Yeah, hi, I'm Srikul. I'm a front-end developer at Horizontal. Go ahead.
I am a senior technology leader at Horizontal. over multiple Yeah, sorry, we couldn't see on the screen, you're audible. Okay.
I'm a product designer with Horizontal and I'll be taking care of the design system and standardization for Tourism Australia. Thank you.
I'm Erin. I'm the digital content delivery manager. I'm Ryan. I'm the Digital Program and Technology Manager. I am Nick, I'm the senior tech lead. Ben, I do most of the queuing.
Lily, it's from us of the team.
And I'm Lauren, front-end developer.
I'm Brooke. I'm the Digital Project Manager.
I'm Serena, the Analytics Manager, Oh, we're so smooth until then. Bye.
Marco, I'm the data manager. Bob?
I'm Bob, I'm the China Digital Manager.
I'm Larissa Orris, Head of Digital Experiences. Atieh.
The team that you've got in the room today is what we're classing as the kind of core project team for this. There are a number of different stakeholders that we are going to bring through the process. This team will be the consistent team that you'll see regularly through the whole journey, really, discovery to QA.
Yeah, sure. So this type sorry this this image is showing up like it generally what kind of. different layers of the current ecosystem we have. So we have communication, content features, data analytics and the core platforms. We do grid out some of the components on this image that it's not in the current migration scope, for example, the VO. For example, like communication, we use Dynamics as an idea.
For the content features, we have a transfer effect for the translation, CrowRiff for getting the social medias on the page, Suikotite in charge of the accessibility, ATW is providing the tourism warehouse data, for like a different, for example, restaurants, attractions, different dynamic contents, and feed into the website. Mapbox is doing the maps for us, and data analytics is like, we have Adobe Analytics, We have customization, like we used to have targets and for the customers for the personalization. And we use data collection as the tech management. And we use One Trust as the cookie constant. We also have GA Google Analytics with us as well.
Core platform, as you know, that is definitely Adobe CMS. And we also have the AMS for now, that's Saba. We are doing a migration. We are migrated to share IMC at this moment. CDM we use Akamai for GoPro and Tencent, this is also in migration, this is for China CDM. This one is just a more general like a display for all the different platforms, how they interact with each other. So same concepts as the previous one is we split out into communication, content features, Uh, kind of features to localize the data analytics analyzed.
Yeah, so the only thing that we've needed to really localize in the China market with the current infrastructure is the video because Brightco doesn't really play nicely behind the firewall. And that's why we've got Youku, though I think gems would like to move away from Youku if we could.
And it's mostly because we've got the Akamai, well, we had Akamai as that global delivery CDN and that helped a lot. Now, with the CDN changes in China now, Akamai no longer play in that market. they're not allowed to. So they partnered with different partners. We partnered between Akamai and Tencent. And we're already seeing a little bit difference in terms of the latency that's going to come out of there.
So we're hoping with this migration to the Azure and Cloudflare with Data Weavers that it's going to help us Brightcove is the only thing that we've had to localize through this whole journey with all the APIs. Everything else has functioned as expected to this point. Thank you. We used to, just a bit of background for that. The stack used to have different author instances, one in global, one in China.
Over the last couple of years, Nick and the team have worked on consolidating that. So all of the author points are coming out of the global publishers. And we're pushing that through to China. So nothing's altered behind the firewall, but only pushing content through. But because of the nature of some of our connections, we do rely on a lot of real-time connections to and through the firewall, and it still hasn't really interrupted anything.
And I guess it's partly because of our ICP compliance.
I think the only one thing that's gone down in a couple of years is We had one of the libraries get blocked, if you remember. And so we ended up just hosting that library in our network and it's fine. Yeah, I think it's something like that. It is being hosted on a third party JavaScript city. So overall, the point here is we're trying to treat Google and China as a whole community. entity, so no Ideally, there's no like a different tools or platforms being used like in a, differently from global and China, they should be using a unified one.
CMS? No. So Target was what we were using for personalization. And over the last couple of years, whilst we've been resetting and really heading towards the point that we are now with your team and Sitecore for the future, we kind of pared back a lot of that personalization and A-B testing to the point of basically zero activities. So we've actually just decommissioned Adobe Target a couple of weeks ago.
Now, the intention, obviously, is then to have that feature set back in Sitecore when we move in. But at the moment, there's no consideration. And there was no features that had been turned off because they didn't work in China at this point. Thank you. All right, so we move on to this slide. This is all about all the integration points. So we list out all possible integration points and we mark some of them as the orange flag that you can see, which they are just like open like open discussion, like it could be, we are happy to see this is to happen.
It hasn't to be decided right now. So first one is definitely the CMS platform, so that is what our central CMS platform. With them, I'm powering all the multi-site digital ecosystem. Second is the Adobe Analytics capture all the granular page level events and user behavior data. for advanced analytics. ATW is that one I mentioned before is the primary database for tourism products and the services they provide us some of the useful or contentful dynamic contents to enrich the the web pages.
Brightcove is one that we use as a primary video hosting platform. So all our videos are actually managed in Brightcove and we just refer back from CMS. to that library to fish for the videos. ChromeRiff is the platform that we use to the social user generated content. We integrate that one by APIs and pulling all the beautiful images from the, like say for example, Instagram or Facebook or Twitter, like even before X right now, those kinds of images onto our page.
MailGaun is the one that we currently use for AM to send out the notifications. For example, if we have done some internal audits like page movement rollouts. and some workflow improvements. This one will be used to send out email for approval or notification. Shira IMC is the current one that are moving onto our AMS system. Currently we have some scheduled batch work happening every day. And this is because of the current AI/MS system has its drawback on the APIs.
So essentially like we mark here as the, with the orange, the orange flag is essentially we want those jobs to be like a real-time APS. If real-time APA can be replaced, that will be the best result for us. Mapbox is the one that we use for the map and we're fitting the coordinates and the interest points and then Mapbox will be interactive and display those places for us full-time. OneFast is the one that's the platform that we use to manage all the cookie Constant?
Also, it's mandatory for European countries to meet the criteria for the GDPR. Sugar Tides, that is the one that we use for governance. More likely we get the inputs or insights from this tool to some of the statistics like accessibility. SEO and other like say content quality insights from there, then we can just fix our pages. Transparefect, this is one that we use for translation. currently we use like a app inside AEM and we submit all the the translation request to the platform and gets the translated content back and import into AEM.
Youku, this is the one that we are using for China video, but then because Their API is out of date and the whole platform is actually going down. So we are trying to replace it with some other video platforms in China from market or even we can consider just using the local video or down video to replace this one.
I had another couple of questions on that slide if it was okay. I'll try and be brief because I don't want to eat up too much time with all my silly questions. But is it right to say, I think with the exception of the LMS, all these integrations are definitely on the consumer site. But I wonder if the LMS is ASP specific, right? So all these integrations, these other 10, are on the main site. Go on.
Yeah, sorry. The ASP, funny enough, the ASP connects into the consumer side, not to confuse things, just because it's presented on the consumer side, not the ASP side. It's weird, but...
So the two that aren't used globally would be ATDW and the Mapbox, which are more consumer focused. And CrowdRiff is a little bit more consumer focused also. The rest of them are... used across all sites. Thank you.
What a timey question you've asked that, Ed, because it's a continuous conversation. No, there's not at this point. In terms of the migration, there won't be either, but that's a different discussion. But no, we're only pulling in the feed from ATDW. The partnership that we've got with them and the relationship is just to use the content in their database. We have got though, they've got quite a legacy infrastructure as it stands, and they struggled to take our APIs in real time.
use a bit of a pseudo cache system that stores into a database from our side so that we're not always calling ATDW servers real time. That's something that we'd like to mimic across as well. We pop that in there in the scope. But no, we don't. There's no content that we would sync into ATDW. It's purely only pull and retrieve from their database.
High level analytics will be kind of essentially unchanged for you, that's right? Yeah, at this point, yeah, correct. Yeah. Understood. Okay.
There are a few different collection methods through the site as as a legacy and evolution has come around. And. If the opportunity arises to single eyes that collection point and the JSON that's going through to AA, of course we take it. we have got some documentation that we could share but we didn't at this point not to overwhelm because it's we see it kind of not in the original scope. Sorry, just rolled up onto my head on the previous slide.
Okay, so for migration scope, we will be migrating the five websites that currently sit in the CMS, the largest being Australia.com. Then we'll have ASP, Tourism Australia, BEA and Signature Experiences. With that, all the digital assets will also be coming across. So we retain all our campaign assets in the DAM. And we would like to keep The author building blocks that we currently got, but consolidated a bit more. So we have put it out there that we do have page templates, 13 used, but there's variations to them depending on which website you're on. Then we've got our components.
We've called out 83 core components. As you go through, you will find that there is additional components. There can be sub components to make that core component work. And then there's other ones. deprecate or streamline, consolidate as we go through. And then we have our content and experience fragments too. So authors use this to bring extra detail to create those maps. While we use Mapbox, we also have fragments in the backend that we populate with our data and we have experience fragments that pull content onto the page.
So we did do an analysis internally on this as part of the contract revision. We didn't give it out to you because we wanted to see what came out of this. We thought it was a better exercise to kind of let you see and then come back as well. So we saw the component review that you sent over the other day, Megan and team. Thank you for that. We can chat about this around the next steps. What we did was, we've got five footers, for example, and they've got 99% identical features within that, but they can go over time.
So we classified that as one footer that we need to migrate and how we do that inter-cycle is up to debate. There's lots of components that are classed as doxed in. They're not necessarily components. They're aspects of the templates themselves. So they're built into those templates. And similarly with the templates, we've got kind of like the core five or six, but they're reused or they've been built over time and split into the different sites. So we're super keen to work with you on what is that exercise on how we group them?
How do we make it a little bit more easier to view rather than filter by instance type, we can filter by component and the aspects like, Content and experience fragments is a really good example. There's quite a few components that leverage content fragments because the idea was to create these reusable fragments that could be used across different components. They're just kind of blocks that are brought in.
So we're really keen to work with you and land on what that final piece is and where we can optimize as well. We felt 83 plus 10, I think we had in the contract, 93 seemed about right, but we can work through that. Ideologically, would you prefer to find a way to... reduce that number or you know, you want to stay exactly, you know, as you are. I mean, what are you, what are you, logically, what are you looking for from us in terms of working together? So we need the functionality that drives the site, right? So we need that to remain, so we need it to be frictionless for the team, particularly all of us because we rely so heavily on our regional team.
In terms of the makeup and that structure, five footers, one footer, you know, we've got a couple of components that are split now. If they become one, we're very open for that optimization, but definitely not wedded to trying to across the same frictions or same set up for the sake of it. So functional and visual parity, but if we can find ways to rationalize that and reduce tech and design debt. That's exactly what we'd love to do. That's why there's five footers. I keep bringing that one up because it's easy, but there's a lot of that there, right?
That we've just built on and on and on over the years. So if there's a streamlined way of doing that, we'll take the opportunity to review that. We will see him for sure. That'd be great.
Can I ask about the history of that in terms of like when Mikkel who sits next to me was looking through some of the code I was seeing kind of like, you know, he was looking at some differences between what fields we've got in the source code versus on Confluence. And it just seems that you were kind of alluding to it, we've built and built and built on things. Has this been kind of like a mix of internal and external teams working on this?
Yeah, absolutely. Look, first thing is we've been on this system, we've been with Adobe for more than a decade, right? So there's been different internal teams and there's been different external teams. You'll see some things in there. We've got, some code bits in our repository that are just straight lift and shift code packages from externals that they built it on a different, they might've built it in Contentful for real. I can't sit in Contentful, so we just packaged that up and just dropped it in because that was the path of least resistance.
Definitely lots of different people, lots of different methodologies, but over the last couple of years, particularly since Nick has come in, we have been working as a team to streamline and have that kind of more common, The brand ID gave us an opportunity to do it because we did a big brand refresh last year where we changed topography, fonts, corners, everything. So we were able to create what I think we call it B2.
You'll see B1 and B2 all over the place. But definitely a lot of different methodologies for how we've built over the years, different teams.
I think it's also a case of like legacy needs as well. So as like we've improved the way that we build components, there's been fields in templates that become redundant because we don't need that anymore. But we just haven't taken the opportunity to...
remove those fields. So I think if that is something that we could do.
It's like the dam as well. We never do a turnip in the dam, right? Yeah. Because we just don't, we haven't, to be honest with you, we don't at the time, we're quite a small team. We've been churning out a lot for years. And a couple of years ago, our main focus was really to reset back on the basics. Three, four years ago, our core web vitals were terrible. You know, our SEO has always been okay. We've partnered, but our core web vitals was bad. The documentation was lacking.
It wasn't there. So this team that you've got now, done a really great job to rebuild that. You know, we've got better scoring call-by-voters, we've got better documentation. All that documentation that you've been given for this project wasn't there two years ago. So the team have done a really good job of understanding. And to be honest, there's a lot in the code that, you know, we're probably going to be learning and reviewing with you at the same time because there's things in there we haven't touched for quite a while or we never built in the first place.
Australia.com, just really quickly, biggest website, has over 14,000 pages live, 16 different locales, and it's got eight English, nine languages currently going on. It is our consumer-facing website.
It does have a big language structure. So Blue Box, our global master, where we build everything globally to roll out. Purple Boxes are for our regional masters and then they roll out to orange and green would be our live. So they're our live sites in the green just for now. We do have multiple websites. layouts across Australia.com so they're all in here available for you guys to have a look at just calling out home page has things like the navigation and the footer component are only authorable in there our guides utilize the map and we link into our sub-article pages from there we then have listicles that are our utilization of experience fragments and then our itineraries have interactive maps as well that utilize the content fragments that you'll see in the back end available in the DAM.
We also have our marketplaces on Australia.com which is where our main regional teams author. They're responsible for all their regional campaigns making sure that any deals and offers they're running they create the content fragments for those areas. Then we have our other interactive layouts across the website. You'll see we'll have that are built off fragments. And then we do have things like Google Web Stories and our interactive stories that have HTML scripts in the page properties to pull them onto the website.
Can I just jump in there quickly, Brooke? So these ones are probably, other than the map and the events calendar, they're probably more deprecated at this point. We haven't really invested recently in...
doing a lot in this space. So just wanted to flag that.
Yes, the map, no, the map would be other than the map is what I said, other than the map and events, other things, this like this trip Tinder and these other things that we've got here were kind of tests and learn, something that we'd obviously look at at a later point, but it's not something that is a a lot of investment at this point in time ofA couple of these templates that you see here, they're really just a blank container that we can drop.
So the whale experience in the bottom left, they're actually just empty containers that we just drop custom code into and it just loads in our wrapper. But the top left in particular is a complex structure. I didn't scope maybe for review. Let's ask a clarifying question. You mentioned a moment ago that last year you went through a bit of a brand refresh. Is that TA-wide or are you just thinking about Australia.com?
I'm brand for Australia.com. So for all of the different sites, we wouldn't expect or you wouldn't be anticipating any significant brand change in the next year? There may be one more color palette that might be introduced.
It'd be color palette for the luxury. So we did a brand refresh last year across consumer, which was changing the logo, the typeface, fonts and colours. And then we need to apply that to some of our other kind of marketing personas around luxury and business events. So that will come, but then there's a debate of when does that need to come? Obviously, we are saying not till after migration, but...
So a couple of years ago, we also started embarking on trying to introduce a bit more tokenization in the code, right? And you'll see that, but it's really lacking on that. But we do have better tokenization in there. The topography, the colors, all the fonts, they're all following the same framework and same structure. So if there is any brand updates in this year, it would be replacing the font, replacing the color.
Yeah, so ATW basically... The idea is just simply calling the ATW API to grab the data and display the data on the page. We did put a special solution there, which is just to a little bit sync for their data to our own database. It's because previously their framework wasn't stable enough to support that kind of big volume, we request this through the API. So sometimes they just, you know, they just fell offline and this just like a service variable for us. So we had a discussion with them and they suggest some of the top visited pages we can do early-bid sync.
For example, the ATW contextual cards, like a single card products, we sync those into our database. So the mechanism right now is being changed, like the flow has been changed, the data will be fetched from our own database. If there's no data, there will be a real time API call to their end. We also trigger a weekly based update for the database. And also we have a HW carousel, which is the same, but then that, the storage key for that, the carousel products is a bit different.
So we can reach to that details later, but basically it's, based on the API code to grab the data and plus the assistance with the data sync. Mapbox is pretty simple actually. We actually have this Mapbox in a different repository and it's just being integrated to the main websites via the script integration. And how we do that is how we fit in the data is basically two ways. So in the common fragments, we have some of the destination that will have coordinates. So we take out those coordinates and are feeding into the Mapbox API.
So then the map, we control that through the API to zoom into one places or we display the POI icons on the page. Also, we can do the search via the APIs. And we also can just say on the page we can dynamically input the coordinates. So different ways of manipulate the Mapbox APIs to control the map. What happened, please?
Yes, the ATDW does feed into ZMapps, yeah. It uses the same database.
Yeah, it's more like a front-end. We didn't use middleware to control that. So it's basically our own JavaScripts to... as a bridge to join this BTW data and the Mapbox APIs. marketplace this is the the one that brook has mentioned before that how we um build up a stream line to flow the all the offers from the kdps then into the review process and then after the promo and the offers will be displayed on the website.
So we do a lot of market, they're called marketplaces on the site where we put deals and offers from key distribution partners. Some of the different business unit works on those relationships. And it's always been quite a manual process to get the information from the KDP, to take that information, to author it into the website, and then to publish everything up. So this year what we did, we automated a few steps. There's a third party submission form.
It's not in the CMS. We're using a software called JotForm at the minute. We're just using our out of box form. That form is filled in by either the KDP or it's also filled in by one of our business units. That flows through to the MondayYeah. That flows through to monday.com, which is our key project management tool. And then that monday.com feeds through their API into the CMS, in which we've created a custom dashboard. That custom dashboard can be used by the authors to publish these offers through the website as needed. We did it this way because of restrictions on what we could do.
We're open to discussions on this one, but it is a key workflow that we do need to replicate into the new system. The phase two of this was to actually merge a couple of the dashboards, We can go through, I think this deserves its own session, to be honest. I think it's, there's quite a few things here. It's unconscious that we've got 15 minutes and we're about... a third through the slides. So we can come back to this one, but it's what we're trying to replicate really at an MVP level is the connection into monday.com and being able to pull those offers from monday.com into the CMS and then give the authors that final approval process to publish them into the website. As it stands, those deals and offers go into content fragments. That's where they're stored in the CMS.
Sorry, Brooke. I was actually going to say, because we've obviously still got a fair bit in the deck. I don't want to put pressure on everyone because there's still a fair bit, but Because we've gone through the main sites now, kind of talking what they are, I wonder, Brooke, if it's worth We've got the tech immersion and we've got the content author immersion where we're going to deep dive more into the platforms and the author workflows.
So we can use these 10 minutes for a bit of a Q&A if you want. And then we can then reserve the platforms and the author workflows to those respective discovery workshops that we've got next week. Awesome.
So that is our lion's share of traffic, 21 million come to Oz.com and there's like a few handful to the other sites. So from that, but now the world is different, right? It's just content everywhere. And to a consumer, they don't care what URL it is. obviously the answer straight away and that is where our strategy is moving to but it still needs to be anchored in in those sites and oz.com is kind of the home where we have the authority you have it's been around for 20 something years it's baiting authority has all those signals that are That that we have.
But as you said, obviously... I've got a little session on Friday. We can go through a little bit more on the... strategy side as well. Any other questions? I just have one last question.
Wow, that is a lovely question, Randall. Wow. That's a tough question because I'd kind of frame it in a more generalistic way is that I would find that we have a lot of a lot of niggles through the process from dev to authoring. We spend 30% of our delivery time in maintenance because of that, whether that's patching or bug fixing or whatever. And so through that whole journey from the ease of developing to the ease of authoring, we're all really keen to optimize McCall.
I think we are ready for that kind of clean slate as it be. to So I'm hoping that you can help us get there. 30% of your dev time is on tech debt, basically. Basically, yeah. Because we've got a small team, but we've got a large, we've seen, we've got a lot of integrations. We've decommissioned actually 30% of our stack or more, 40% of our stack over the last couple of years. So we've been in a big optimization phase, but we had 30 plus platforms integrated to deliver websites, EDMs, and LMS.
Okay, great. Yes, I think we'll leave it there. I'll stop recording and I will put this in confluence and I guess we'll have a great kickoff with everyone tomorrow for Discovery.