Episode Transcript
[00:00:00] Speaker A: Foreign.
[00:00:10] Speaker B: Welcome to Arbray Digital Experiences. This is episode 16. Today we're going to talk about Edge delivery services and a brand new player on the scene which is the document authoring interface, which is a early access technology from Adobe that we've been developing on and working with and have a customer that's launching on shortly. We want to tell you all about it and what it means to the AEM world.
I've got with me today. This is Bray Sachar, he's the CEO and Principal architect at Arbore Digital. How's it going with you here today? Tad Reeves, Principal Architect at Arbori Digital and we're going to talk about this. So Bryce, before we get going, once you set the stage, tell me a little bit about your history and your background. Sure.
[00:00:53] Speaker A: I mean so I've, you know I've computer science, I've been in computers all my whole life, but in the content management space for oh man, pushing in probably 15 years now, all over the place, you know, documentum, SharePoint, it's a lot of the open source stuff but really focused in the Adobe Experience Manager or previously CQ space for a big chunk of that and had sort of seen it grow, grow up from its infancy, you know in, in probably 0809 time frame and to the 6, 5 that we have now run a lot of on prem gear have, have done a lot of cloud transitions whether self hosted or Adobe managed and obviously you know we're in the weeds with a lot of AEM as a cloud service that. So yeah, actually looking forward to learning more about Edge delivery with Tad here actually that you have probably some of the most experience in the industry.
[00:01:56] Speaker B: Yeah, it's been so. It's funny. So Bryce and I first worked together at a big application service provider that doing AEM support and we're supporting AEM in every flavor and every way that you could possibly host it or miss host it. We saw every mistake you could possibly make and worst practice that you could make as well as some really amazing implementations.
And I feel like in seeing all of that, AEM has had a really amazing run in terms of what it's done. But there's been a lot of new tech that's come along which, which folks have been trying to figure out how to apply to this space. Where, where does that new tech fit in the content management space? And how can you, how can you solve some of the problems that have been kind of with, with people in the experience manager world all along one.
[00:02:56] Speaker A: Of them really the content management system world yes. Or you know, digital experiences as well. And real quick, just so my background, I come from a lot of like development teams as well, doing a lot of application implementations, probably more focused on the OSGI layer and back end, what you'd call. But obviously, you know, like what you were saying is we were supporting a lot of the architectures and infrastructures and the actual server builds out, build outs and then, then, you know, transitioning into a lot of the cloud architectures as well. So I think we come at it from a lot of those areas where knowing that, you know, it's important to know the, the application itself and what's running on there, but also, you know, knowing the gear that it's actually running on and all of those, the networking and the security and the, and the performance that, that you, you get or you don't get depending on the architecture choices you make.
[00:03:49] Speaker B: That's true. And, and, and having, and coming from that background, I guess you end up with a much more, I mean some people would say cynical and I guess some people would say critical eye toward the gear that makes it go. And obviously I have like my own affinity for blinking lights and stuff like that. I still miss working in a data center because there's something really endearing about working on the physical machines that run everything. And whenever something's all in the cloud and you ever see it again, it's always a little bit like, do I really trust that thing that I've never seen?
[00:04:19] Speaker A: Like, I already built a new desktop myself actually, which.
[00:04:24] Speaker B: I love it. So, so with this though, I want, I want to just dive into, into this thing because that, because I, I got steeped in this first. I was sampling it before Adobe Summit last year, coming around pretty hot on Adobe Summit 25, but I was, I was sampling it a bit and then ended up really kind of immersed in it at Summit. Ended up talking to a really, a bunch of really amazing Adobe engineers and got kind of got on the, on the trail of a couple of amazing projects really. Some of them are already released in the form of what Edge Delivery Services is now, and some of them are not yet out to the general public.
But one of them ended up forming into a pretty major customer implementation that we're on the tail end of right now. And it has been the most fun I've had in this space in my career because of how there's so many problems that I've, I've like, gosh, well, you know, there's just no good solution for this in the AEM world. There's been times where I've been like I really wish this part was better, but it's just not. One of those is like development time is something that I've always been kind of like I really wish that it was. It was easier and faster to develop an AEM site and. But unfortunately there's people like you and me that end up involved all the time and but have to be involved in perpetuity throughout an AM project, even after it's launched, even after it's live. You have to have a high end, high paid architect on all the time. All the time. Maybe multiples especially troubleshooting.
[00:05:58] Speaker A: The more complex it gets the, and the, the more things are. Can break.
[00:06:03] Speaker B: Yep, exactly. So things like that. But think things that just you know, making it fast, making it performant, making it, making it able to be run on. With, with. With the team that you have more content flexibility. There's been a bunch of things where I want, you know, I, I want more and there's got to be an answer out there and, and one of these answers kind of presented itself. So. So I'm going to talk about. We're talking about Da. This is the Artist formerly known as Dark Alley. This is now document authoring. Got a chance to present on it at Adapt to, which is amazing. I still am grateful for that opportunity. But then I want to go into this in much more detail as to what it is, how it fits into the ecosystem and so forth. But first, before I even kind of get into that, I, I feel like we need to define what edge delivery is because if you define that well, then you can define where it fits in the overall ecosystem and how it would plug into an enterprise architecture and whether or not it would even like. I really want anybody listening to this to be able to start thinking about is this, is this something that would make sense for any one of my web properties, for any one of my content management workloads, whether it's internal or external, where it's your main site or microsite or something like that.
[00:07:16] Speaker A: And you almost gotta start with the name changes of it all too because that's was to me one of the most confusing things is all the, the, the different code names and.
[00:07:26] Speaker B: Yeah.
[00:07:27] Speaker A: And then when as it. As those would change throughout the years like you. You'd wonder is that the same thing? Is this new?
[00:07:33] Speaker B: What's. What.
[00:07:33] Speaker A: What are the differences? Where's the nuances there?
[00:07:36] Speaker B: Yeah. Well, let's start there. Okay, so there is a project that a consortium of engineers started working on a few years back at Adobe and this project was called Project Helix. And the whole idea was basically, and one of the engineers explained it to me as. So he was one of the original folks at Day software that created cq, which eventually morphed into aem. And he's like, well, if I was going to make this, I was going to do this sort of innovation that. Because CQ was seriously, let's not make no mistake, CQ was seriously innovative at its time. And there's a reason why it became so popular. There's a reason why that's the tech that Adobe picked up as their marquee content management solution.
[00:08:19] Speaker A: Yep.
[00:08:20] Speaker B: So it is seriously powerful and there's a reason why our whole careers have been around this tech. It's because it's really quite something. But if you're going to go and make it newly using today's tech and solve today's problems with it, what would you make? And so that was what, that was what came out of this and that the whole idea was this Helix solution, instead of being all wrapped around the Java content repository, which is really kind of the source of everything previously and every piece of technology in AEM came out of that. This was centered around the whole idea of first you're going to make something extraordinarily fast, you're going to make it fast to develop on and you're going to make it flexible in terms of what kind of documents go into this thing, what, what are the sources of the data that then goes and drives the website. Yeah, so the cons.
Yes, exactly. Or sometimes the lack thereof.
And whether you want to use simple docs or if you want to use something more complicated to be able to drive it, either way.
So the solution ended up being a thing where you could have. It has built in cicd. So that's one of the things that's always been a challenge. So you and me are CI CD DevOps people at heart.
[00:09:37] Speaker A: I'm in the middle of working for right now, actually.
[00:09:40] Speaker B: Yep, we still do it, but it's one of the hardest things to get right because the requirements are always changing and, and even just, even basic DevOps takes a fair amount of skill to get right understanding of the entire system. Not just of how to deploy something, but the whole workflow. So getting that right is hard.
And so this is built in from the ground up so that when you, any team who's running on this gets a pipeline, they get a mechanism that's all git based, it's all versioned it's safe. It's a way for things to get deployed easily and quickly so that there's a pipeline right off the bat. There's development, best practice that's easy to slide into with almost no training.
It's super high capacity. That's another thing that's always been a challenge. Designing AEM for high capacity has been a challenge, especially since licensing is always tied to it.
[00:10:38] Speaker A: Yeah.
[00:10:39] Speaker B: And so you go, I can only afford this much, but I have a popular website. Great.
And then you start making content trade offs because.
[00:10:48] Speaker A: Well, and actually that's where some of our architectures and the architects would come in to solve some of those problems too. Because you can scale certain tiers, such as the dispatcher tier, different caching layers that, but it, by doing that, it makes it more complex in certain areas too.
[00:11:02] Speaker B: Yep. Or, or paints you into a corner in some cases too. Because you said I want to, I want to super cache this. And you're like, we have to super cache this or else we're going to kill our application tier. And then you're like, then now again you're kind of painted yourself into a corner with just with your licensing or what.
[00:11:17] Speaker A: What a lot of people miss is, is the cache hit ratio too. You can have as many cache servers as you want, but if you're bypassing the cache, they're all dead.
[00:11:26] Speaker B: Yeah, and then you do that, do the famous, you know, take yourself out with an email promotion and yeah, everybody's doing it.
[00:11:33] Speaker A: Famous one for me was a Bruce Springsteen concert, I think it was at MSG and they sent it out to 20 million people and they got a lot of responses immediately.
[00:11:45] Speaker B: A lot of responses and not a lot of successful responses. No, but, but so, so you have this, so you have the CSG built in. You have a high capacity, high delivery speed because it's all built around the fact that a modern website has to, has to just have basically as close as you can ever get to a perfect Lighthouse score. You, you want that because if you have less than that, then you're setting site up for lack of success, you're setting yourself up for failure. So to have that all built in, make it easy to migrate to, easy to hang on to, and then you can still plug it into other things. So those seem like basically an inbuilt paradox. Like, like with it, with, with regular aem, it's almost a paradox. You almost like it. Well, you, you could, you could pick two or three of those things, but not all of those things. But it's it's so Edge Delivery is that that was what it was designed for. So that was. So it was Helix at first. Ended up kind of melding in with some other things that ended up with a temporary name change to Franklin for a little while. Same product, same thing. And then afterwards, then it ended up basically getting rolled into the AEM ecosystem and being a part of the AEM ecosystem, which is where it got its final name. Which is hopefully its final name. Yeah. Which is, which is AEM Edge Delivery Services or AEM as a cloud service, sites with Edge Delivery Service or something like that as its official name, which nobody's ever going to say it's Edge Delivery Service.
I still call it Helix because that's a cooler name.
So. But the thing is, is that Edge Delivery is not a cms. And that is one confusion that I think a lot of people, because AEM is like an experience management server and framework and thing that you can plug stuff into, but at heart it's a cms.
Edge Delivery is not a CMS because it in and of itself doesn't manage your content. It provides a way of plugging content in. And a lot of people have been employing this so far, using SharePoint as their document source, where you author documents in SharePoint and then you publish them through Edge Delivery Service. And it's. And it's. Without doing it yourself. It's tough to explain why writing, using documents to author a web page is so cool. And I was so skeptical at first. I was like, you can't tell me. I mean, I've used Microsoft front page in 1997.
You can't tell me it's a good idea.
But it's game changing. It's so fast.
And for our launch customer that we're doing this with the number of times they were like, they're used to a page, especially really complicated page with lots of components and nested components and like you go and you load it and it takes forever to load up. And this stuff is just so fast to work with. So.
[00:14:40] Speaker A: And the fact that, so all these content management systems, they were, you know, developing their own wysiwyg, right?
[00:14:46] Speaker B: Yes.
[00:14:46] Speaker A: And so every one wasn't bespoke. And it was up to the engineers of the product to develop that, to add new features or whatnot. Whereas there's, you know, they sort of offload that in some of these cases.
And it's in a tool that the, you know, marketing teams and the business teams are more comfortable with. So the training curve is a lot.
[00:15:07] Speaker B: Less as well that, that's actually the biggest part too is, is that, is that everybody anywhere knows how to use a word processor. And for structured data, like if you say you've got key value pairs or you know, you know, different pieces of structured data, everybody knows how to use a spreadsheet. And so it's such a natural way to store and update that data that it just takes no training, it takes all the. Because one of the things that we get into too is, is that these kind of domain experts of, of people who know how to author in the content management system, who know the ins and outs of how to author in a. And it's like it's, it's its own super speciality, then you almost should have a content author architect, you know, for each company because it usually is domain knowledge just for the company too of like how do we put our weird stuff together?
[00:15:55] Speaker A: Yeah.
[00:15:55] Speaker B: And then once you know that you want to democratize that out to everybody, but then in effect there's only like five people who actually know how to author it. Well, great.
So. So, so Edge Delivery is this framework for being able to plug documents in and get them quickly. It's got this whole CICD pipeline for being able to basically style the components that you put in there. In AEM world they're called components and in Edge Delivery World they're called blocks. These pieces of things like you take like a tab or a carousel or a hero or a footer or any one of these, one of these things that's supposed to do something. In AM World you call those components here, you call them blocks. There's a system in Edge Delivery for how to style them and give them behavior and in. And this is the major difference between Edge Delivery and AEM is that an AEM you need to learn, you need to be a total IT polyglot in order to get one of these projects out the door.
[00:16:57] Speaker A: JSP or HTL or sitely or even more HTML.
[00:17:03] Speaker B: Yep. And then, and then. Yes. And plus your obviously your front end which would depending on whatever front end framework that you use. Plus you need to understand how AEM does client libraries.
[00:17:13] Speaker A: The client library for sure was always. Because you own a lot of teams.
[00:17:18] Speaker B: That's right. Plus then you need to. Then then there's the whole backend which is obviously hardcore Java. And then the way that you control your caching and your security framework is all the dispatcher, which is its own weird configuration file, which I think there's only one person in Switzerland who really knows where that came from. Who could really define it, right? So it's like, so there's all these different things you have to know. Whereas with edge delivery you need to know commodity CSS and commodity JavaScript. That's it.
And it's really, really easy to get people up to speed with edge delivery, which is the other nice thing about this.
So, okay, so with edge delivery you've got a couple different ways that you get content in. You get, you can get it in with SharePoint, author, your docs in Word and your structured data in Excel, which is fine. You can do the same thing with Google Docs and Google Sheets, which my first experiments with this, that's what I did. Very, very easy to get up and running. And so if you go to like AM Live and you do the, do the developer quick start and you just go, oh, this is really easy. You can have anybody with any kind of an IT background could have one of those up and running and in a matter of like an hour.
[00:18:32] Speaker A: You want to touch on what AEM Live is?
[00:18:34] Speaker B: So AEM Live is the, so there's the site that has all of the edge delivery, all the Helix related documentation is all on AEM Live.
A little confusing that AEM Live only has the Helix related stuff and not the regular old AEM stuff, but that's how it is. So if you want to, if you want to get up to speed on how to do an edge delivery site and that all the docs are there, so just AM Live and you can rock and roll. That's the other big difference here is that for once we're just letting people just get in and just start going and seeing if you like it and if you like it and you want to roll it out to your, to your company, then cool, then you can contact sales and start getting it licensed. But with, with traditional aem, somebody says, hey, I want to learn aem. You'd be like, I'm sorry to hear that.
[00:19:21] Speaker A: Do you, I mean, well, you'd have to learn. Okay, now first, I mean, and they had the double click, right? And that worked decently well. But you have to install your author, okay. And now you have to install your publisher. Do you really want to see what it looks like in the wild now install dispatcher all on your local machine. Unless someone stood up a whole server infrastructure for you and get in didn't give you the keys to demo around.
[00:19:43] Speaker B: You know, but even then you have to be at a company that has a license in order to do that. If you're an outside developer and Even if you know Java, even if you were like a JBoss guy and you.
[00:19:53] Speaker A: Came in, I'm sure it's widely known. But the. So I did a training on AEM in 2008, maybe it was 2007.
I think it was that. So that was definitely before, you know, Adobe acquired Day. And that training license is still valid for the problem.
[00:20:12] Speaker B: Yeah, yeah. But, yeah, like here.
Yeah.
People ask is there a legal way for me to do? I go, you know, I could help you, but I shouldn't. So, but, but it's, it's nice to be able to, to have something that somebody can just get involved and just, just do it. But so you've got this. So doing stuff with SharePoint is cool. So last year also Adobe rolled out this whole mechanism. They called it Project Crosswalk at first. But what it is, is. So AM's got a new feature called the Universal Editor. It's yet to be an editor that can. It's a separate service. It's not part of the AEM author itself. It's a separate service that kind of runs on the side and you can go and edit other, you know, traditional AEM stuff with it. It's going to store so you can actually edit and publish Edge Delivery documents. But it's stored in the jcr. It's stored in A M itself. And so, and so that's just, that's. That's another way to deploy it. So, so if you get yourself up to April of last year, you're basically at my understanding of where AAM was and where Edge Delivery was. And I'm like, okay, good. Well, I was about to do an implementation for a customer and we're going to go from 6.5 to AM as a cloud service.
And that's where some of these. There are some limitations that in some cases they've been solved, but in other cases they really haven't been solved on the edge delivery front.
One of those is that. So as cool as it is to publish with SharePoint or with Google Docs, there are big kid content management problems that you don't solve with that, that you then need to come up with a weird janky solution yourself to solve. One of those is translation and rollup because AEM has a, has whatever. It's a mechanism. People have different opinions about how good this mechanism is, but it's very powerful what it can do in terms of being able to roll out translations to a whole bunch of locales.
[00:22:20] Speaker A: So if you've got, we'll get into that why I'm excited. But I remember we had a conversation two years ago at Summit and I specifically asked that and in full disclosure, I actually wrote the 1.0 machine translation API in AEM 6.0. So I was actually on working with Adobe team and wrote that API. So I have a lot of history in that. And I was asking, so how do people do translations in this? And the answer at the time two years ago was well, you know, just use Google Translate. You know, people have their own translation engine that just, just send it to and just copy and paste the content in. So it wasn't native at all. And they weren't trying to solve for that and essentially had, had sort of offloaded that to any other system. You know, roll your own type deal. Right. And obviously that's beginning to change, which is I think fantastic.
[00:23:09] Speaker B: It is. And so, but that was that. That's one of the. So if you're a SharePoint and let's just say you've got 10 languages that you're rolling out to, and your 10 languages have, maybe you have a difference between Canadian French and, and, and Metropolitan French and you've got, so you've got a couple of different locales and languages that you need to be able to roll out any content to. And you will be able to control things like, oh, local edits and things like that. You're, you're writing your own whole bespoke workflow outside and on top of SharePoint to manage documents flying all over the place, which it's not like. And if you're coming, if you're somebody like me who's like trying to implement a content management solution, that feels like a disaster.
[00:23:53] Speaker A: Yeah. Because it's not just the content management system at that point, it's a business process system and it's dealing with people and you can't automate a lot of it as seamlessly as you'd like to in the technologist.
[00:24:09] Speaker B: You can't then also take work that you did with one customer and say, hey, I already made something that handles this and handle it with the next customer. Because it's, it's as gonna be as bespoke as the permission structure and everything as that customer. So that's a problem. There's other problems when it comes to that. Like SharePoint is meant to be a document management solution, not a content management solution. So whenever you do something like, hey, I just made this little footer change to 500 documents and now republish them, SharePoint doesn't love that, of moving and flying all these documents around and sometimes you can just run into really big and hard limits with the Microsoft Graph API in terms of how you know it'll crush it. Other things like what if I wanted a side by side preview, you know, because AEM forever has had some manner of WYSIWYG that you could go and do and do editing on. Right. So if you wanted some manner of being able to see what you're working on while you're working on it without having to publish it.
[00:25:12] Speaker A: Yep.
[00:25:13] Speaker B: Didn't really have an option for that either. So.
So there's a bunch, there's a bunch of. So. Oh, another. So here's another thing. So if you're, if you're storing. So if you've got a document, a page that you make for a web page and you're going to have. It's got graphics all over it. Right. So in Microsoft Word. So if you're going to store that in a word, you put a graphic in there and you. And you publish it. Edge Delivery would take care of that. However, if you, that graphic that you have is now living inside of that document. A Word doc. And anybody who knows about Word docs is know that a doc. A docx file is just a dot zip file, a bunch of XML and PNGs and other random stuff in it. It's just a zip. So what your system then has to do if, let's just say you make one change and you're trying to roll it out, you're having to go and unzip hundreds and hundreds and hundreds of files and explode them and take graphics out and plug them back in. There's no way to make any of that fast. Right.
Never mind. So one of Adobe's cooler products for a long time has been AEM Assets. It's a genuinely cool product. Yep. And it has it, it serves a neat. And Adobe's strength has always been in their graphics tech. And with Photoshop APIs and all that kind of stuff, you can do really powerful stuff with assets. You want all your stuff in one place.
[00:26:31] Speaker A: A lot of integration, there's a lot of AI focus going into that direction, a lot of governance around it. You know, there's, there's features to be able to handle multiple agencies connecting into your assets, repository and, and limiting what access they can give or what they can see. You know, making sure branding's on point. So they, I mean it's a very mature product at this point with a lot of fantastic features.
[00:26:57] Speaker B: Absolutely. And if you take a product like that and let's just say you said governance. So let's just say you've got. Let's just say you have a clothing brand, you get a sponsor, you get some celeb to take a picture, right? Okay, good. So now that celebs picture with your clothing on is all over your website, now that celeb does something dumb and you have to have that celeb off the website. Right. Now, if everything is living inside of documents, how are you going to switch one image and say, good, now this person no longer appears. I updated the image. Yeah. That image lives inside all of the different documents. You're going to have to then now go and try to. There's no way to centrally.
[00:27:34] Speaker A: It's a copy everywhere instead of just a reference.
[00:27:36] Speaker B: Essentially. It's exactly, exactly. So that's where you go. Okay, that would, that'd be really nice if you could really leverage this asset management system that any company that's done an asset management, like a dam migration, you're like, you've put a lot of work into taxonomy and search and making sure everybody's using it. Finding all weird rabbit holes that everybody stored all their images and oh yeah, Jim's got a server under his desk that he keeps some of those like, nope, they're all in AEM now. You torpedo that if you don't, if you're, if your CMS doesn't use the central assets. Yeah. So these were questions that I had that I'm like, okay. People are like, hey, why don't you go with Edge Delivery? I'm like, I just don't know how to make it work with all these because I had a customer with requirements like that. I'm like, I want centralized assets, I need rollout.
I love the idea of Edge Delivery, but I'm kind of checkmated. And so this is kind of where this new tech comes in and everybody's going to be seeing more of it. Right now. It's an early access technology, which is document authoring. Again, this is this thing that was formerly known for a while as Dark Alley. It may get another name, but a job. I never worked for Adobe, so we'll see.
[00:28:56] Speaker A: But this is only the second name. And they averaged four names per tool, I think.
[00:29:01] Speaker B: Yeah, they're only halfway there.
[00:29:02] Speaker A: Everyone always forgets Wem. You remember wem?
[00:29:06] Speaker B: Yes, I do. Actually.
[00:29:07] Speaker A: Between CQ and aem, it was Web Experience Manager and that lived for maybe a year, never got traction, didn't even.
[00:29:14] Speaker B: Live for a whole year because I.
[00:29:16] Speaker A: Was seeking my whole Year. But that's like erased from the history books at this point.
[00:29:22] Speaker B: That's right. That's right. It's not even there. I think we, I think we made some reference to it on our blog and I think that's the only place where it still exists. It's been, it's been 1984, you know, Ministry of Truth already already got to it. But.
So this, so this DA product, it's not a product yet. I can't refer to it as a product until it's a product. So it's tech. It's a tech right now, but it's still awesome. So it, so what it is, is it's for. Specifically for Edge Delivery. It is a, it's a. It's a product that's actually built on Helix. It's built on Edge Delivery and it's for rolling out documents and managing documents for edge delivery services.
It does documentary management, does editor collab, does a bunch of different stuff that has to do with keeping everything together, but keeps it on one isolated thing that's isolated to a Edge Delivery project. So you basically authenticate it and get it going with your git project and then everything's living in that context and it's extraordinarily fast. And it's been, it's really been a joy to use, I gotta say. It's really been something else. And it's allowed me as an architect to then go and focus on some of the, some of the other, you know, pieces of plugging in that I've wanted to focus on for a long time with things like this. But, but yeah, I. So I guess I could just kind of go into a little bit of what it, what it, what it is and what it does.
I mean, the first thing that it's gotta do is gotta manage documents and, and so it's a, it's got its whole tree interface and you know, probably, probably could have had screenshots and stuff going around, but we're a podcast. We're just going to have to like, you know, conjure it up in your mind. But, but it's. But it's so, but so manages the whole tree docs as a part of this. It makes calls out to Helix or, you know, Edge Delivery to be able to get things like publication status and stuff like that. So you can easily go and scroll through your docs and see, see whether or not they've been published out or not. So it's, it's a very, it's an aem, like kind of an experience for people who are used to being able in one place to see like an aem, you know you have the little orange and green, whether it's been, it's in the middle of being published or it's. Yep. So this is very similar. It's like you, if it's, if it's been previewed you can see it and who published it and so forth.
Um, one of the other things that it does really nicely is versioning. So it's got inbuilt versioning.
[00:31:55] Speaker A: Yep.
[00:31:55] Speaker B: So with SharePoint you have. The only way you can really do versioning is with word track changes.
So you, you have. That's kind of like versioning but if somebody goes and clobbers that one document then your version's gone. So yeah, this is inbuilt versioning so you can see who, who made a modification and all that kind of stuff. Basically in perpetuity. It's got infinite version storage and as.
[00:32:23] Speaker A: Part of the test was that. So you said infinite version storage, someone's going to put that to the test.
[00:32:29] Speaker B: That's right, that's right. You said infinite.
I'm on my 150,000th version and it's starting to sell.
[00:32:35] Speaker A: Like when I dug into the segment store and they're like well it'll iterate up forever. And I was like. And I found that's not the case. It actually dies at big N where Java has the limitation of integers but you know, effectively infinity.
[00:32:54] Speaker B: Something may eventually get there. I don't know. We've seen some big AEM implementations.
[00:32:58] Speaker A: If you have any versions, I mean you have a different problem.
[00:33:01] Speaker B: That's right, that's right.
But one of the nice things about the versioning as it's done in DA is it allows you to quick revert to any one of those versions. So it's got in the user interface you can just quickly just go and just roll back to a previous version.
[00:33:17] Speaker A: Yes. Which is really nice. I've used really frees up a lot of anxiety from some of the non technical authors because once they see that oh, it's really that easy to go back if I make this change and you know, I don't. It gives them the confidence to edit documents and make changes and make breaking changes at times just to see what would happen knowing that they can go back.
[00:33:43] Speaker B: Well, I think that, that, so that anxiety point is also. It also comes down to things like access control and who do you want making changes because so DA does have access control. It has actually fine grained access control that's built into it. So you can say only for these things. I want people to go and make updates to this documentary. And it's all controlled within Adobe Admin console.
But if you're trying to make a choice as to whether or not you're going to let somebody into you're fancy new cms, you want to know that if they, if they muff it up, that. Can you, can you back that out? Yeah. Do you have a quick path to be able to, to, to retrieve what it was like before you let them in there?
[00:34:20] Speaker A: Yeah.
[00:34:21] Speaker B: So that part's really nice. Um, the other part of it that's really cool. That word unfortunately does tend to muff up is collaboration. Like anybody who's worked on a PowerPoint PRE in a, in a teams meeting knows that even whatever we are, what are we 10 years into collaborative editing in Word and it still doesn't get it right. Yeah. So this has collaborative editing. It's pretty robust collaborative editing. In fact, at Adapt to, I gave the edit link out. I, I was up on stage with 200 people in the audience and I gave a link out to everybody. I'm like, all right, everybody in here, everybody try to edit right now.
[00:34:58] Speaker A: Now there is some Adobe engineers that are pretty nervous about that, but it's.
[00:35:02] Speaker B: The guy who actually wrote the collab was in the audience and I'm like, okay, I'm going to sweat tell everybody in there. But he actually was cool as a cucumber, actually. And so because I'm like, are you cool with this? I mean, I'm going to get everybody. He's like, it's cool, it'll work.
So. And it did actually. I mean, the UI wasn't made for 200 edit icons all the way across the top. So the unliter. That was a little bit weird, but. But yeah, no, it. So the collaborative editing works really great. Collab works inside of sheets, also versioning works inside of sheets. So you can do that. So the.
So yeah, the collab. Okay, so now onto things that really handled my problems here that I had as of Adobe Summit last year, so built in AEM assets integration.
So da. Yes, it's big. So one of the things that AAM that the Adobe folks rolled out last year was this thing called the Assets Micro front end. And it was basically an interface for AAM as a cloud service to allow an upload front end to be able to be integrated into other UIs. Like, let's just say you were silly and you wanted to put AEM assets into WordPress or something like that. So you could do that if you really wanted to. So but in this case they use that whole assets mfe, the micro front end to be able to go and upload assets directly into da. So that allows us to have all of our assets in one place. It's really nice. So all of the, any of the anxiety that was had about do we have to redo our taxonomy on this? And so forth from a previous AEM65 migration. That was the easiest assets migration I've ever done. Yeah, fine. There were a couple little weird hiccups with some things, but it, but biy barge it was so easy. So just got it all up into the cloud service from 6.5, plugged it in, plugged in the users and for the most part it was good to go.
[00:37:01] Speaker A: And how do you connect those two? It's just sort of the connection strings to your AMS cloud service.
Dam.
[00:37:07] Speaker B: Right? Yes. Yeah, the URL.
Yeah, there was like a environment variable that you had to do in your cloud service setup. So you basically said this environment variable to say, hey, I'm talking to da and then DA is saying where's, where's the author that I'm talking to? And it's talking back. And then since you're already talking with AM authors and they have an Adobe account, you're just signing in with this Adobe account. So either that, that, that Adobe account either has access to your author or doesn't. Right. So since you already set up your authentication for your author, you're done.
[00:37:43] Speaker A: Thanks to the truth of the assets. Then is the AEM damage, but you see it in context in the pages.
[00:37:50] Speaker B: That's right.
[00:37:50] Speaker A: But you know, if the same, if you're using the same asset in multiple pages, really you just have to change that asset or revoke it or whatever. On the A, like we were Talking about the SharePoint issue before, you're not doing in every single document, it's not a copy, it's a reference.
[00:38:06] Speaker B: That's right. That's right. So in this case, so the only, this is where, the only place where it, you know, in our implementation that it could have been better possibly is that. So when we pull an asset in from AAM Assets, it comes in with an Assets Publish URL. So it's a front end publishable asset URL. Because like you've published an asset, you have a picture and it comes in and there it is.
It's open to the world at that point. And you say publish when you're publishing that you've got a. It's publishing the full res rendition of that now. The magic then of edge delivery. Edge delivery like you. So in AEM world you had to go and tell it what rendition sizes that you wanted for everything, right? Whereas this basically is doing a lot of that magic itself. And so you, so you give it the full res rendition and edge delivery says, I got it from here. I'll make a little one, I'll make a big one, I'll make a fast loading one. I'll do it progressive so it loads correctly. It does all that stuff for you essentially you can edit it, but it does all that for you.
But at that point it's being served to the end user out of Helix.
So there is still the case that. So if I. So let's just say that same hypothetical example, the celebrity goes off the rails. You need to update the, the image. So you, as soon as the image is updated, the image. So the image you updated in the dam, it's already published, right?
So there's nothing more that you have to do in terms of selecting the image. What you do still in our implementation, what you would have to do is go and republish the pages because the pages are taking whatever the dam had.
So you do still have to republish the pages. The way to get around that is instead of just using regular AM assets, you use dynamic media.
Oh, interesting. Right? Because the dynamic media with open API support basically then you then the whole thing is always coming out of dynamic media because always you're only using a reference ever. And so only the reference would end up in da. The reference ends up out. So you basically as soon as you publish the new image in AM assets and it publishes to dynamic media, every reference gets it. Every place where it's ever used, anywhere, Even if you're on a non AM website, even if it's emails, even if it's anything. So which a lot of brands may want to consider, I think. I think dynamic media is also a very, very cool product. And so unfortunately sometimes when you and I are brought in, licenses are already signed and we were like, oh, you don't have dynamic media. Okay, good. I think you want it. Oh, you don't have. Okay, good. Okay, so we're not dynamic media. All right, fine. We'll go with what we got. So. But, but yeah, that's, that's the only, the only drawback there.
But, but the, the assets part is, is cool. Oh, oh, okay. I've even really told you too much about this. So, so the other Cool thing about the assets integration is that. So, so with, with Edge Delivery Services, you're, you're, you're making these, most of your, this is all commodity JavaScript. Right. So it's all being served. You're, you're not dealing, you don't have a server in this case, that is, that is the one that's serving all this is all right, coming out for.
[00:41:33] Speaker A: The big paradigm shift.
[00:41:34] Speaker B: It's a total, total paradigm shift. It's completely different.
But what if you do want to reference things that are on a server? What do you do?
And, and so we had a use case where you have like documentation. So there's a software product that has documentation and the documentation is referenced out of the, like you can pull it out of the software product too. So it always has to be in one place, like a known place. So we keep it on the dam in PDF files. Right. There's hundreds upon hundreds upon hundreds upon hundreds of PDF files in nine languages.
[00:42:08] Speaker A: Right.
[00:42:09] Speaker B: In a known tree. Right. And all those PDF files get new ones made every time they make a.
[00:42:17] Speaker A: New version of the software when they release the updates.
[00:42:19] Speaker B: Yeah. And so you want to be able to do something like, well, what if I just wanted a component, like a list of all my PDF files, but it's in the dam now what do I do? Now I have a separate system. So how do I do this? So, so it was actually a lot easier than I thought it was going to be. And, and so one of the, one of our developers goes and puts a, exposes it as a servlet on a and says, here's a list of all the PDF files, here's all their metadata. Edge Delivery goes and consumes that. JSON renders it out and it's beautiful. So now you have AEM and Edge Delivery all working in concert because.
And this is for everybody to know too. So, so, so Adobe has one product right now, this Edge Delivery and AM is the same product.
So when you buy one you get both. So let's just say you're like, I just want Edge Delivery. I don't even have any need for a classic like a regular AM server. They're like, you got one. I mean, do you want to use it? No. Okay, fine. Well, it's here so. Or the other way around. You know, there's some people that are still just dabbling with Edge Delivery, but they have all their meat and potatoes on aem. But both of them exist and are available to you. So in this case we just leverage the fact that AEM still remains an insanely powerful server that can do really cool stuff. And you have a built in. You already have a CI CD pipeline for that too. Already built. It's already. It comes with it. So deploying that out was clockwise, I think it was. Yep. Yeah. The whole thing was done in two sprints like that whole integration. So it's just. It's fun that this is very fast to work on other stuff that DA does live preview. It has it built in with all, you know, mobile, tablet, desktop. It's all side by side, especially if you have a widescreen. It's awful nice. So you just make your changes and the previews appear. It's got a bunch of bulk tooling which is really, really handy. So it has insanely fast bulk find and replace. So let's just say you've got something that you want to go like oh, we changed our reference to this footer component which is a new one. Oh but it's on every single page contains a reference to this thing. In old AM land you'd have some. One of our devs, you know, write some crazy groovy script to try to go through and rake through the repository and then you'd have to do that on prod and it was like. And it might break prod when you do it. And yeah it was. It was a whole dance whenever you had to do that. This you literally find a replace. The finder replace is even across like several hundred documents. Takes like two seconds.
It's. It's really, really crazy how fast it is so. But also bulk versioning, like let's say you're going to do something like that and you're like I might break it. So all these pages I'm going to touch, I'm going to take a safety version right now so that I can revert back if I want to and there's. Then you just go bonk. And it just takes a version snapshots it so that you can do your potentially breaking change and if you screwed it up then you can revert it.
[00:45:34] Speaker A: That's pretty neat.
[00:45:35] Speaker B: Okay, it is, it is. Um, so the other thing that also so bulk. Sorry. Besides so translation and rollout. This is the other. This is the other piece that. That was like hey, checkmate. I can't use edge delivery because I've got translation is the other thing too is. Is that. Is that doing multi site manager and universal editor and edge delivery is like a no go. So it's always been a problem and so this has it built in. So there's, there's da. You mean DA does. Yes, DA does.
So this is something that is still, still evolving at this time in terms of what it is and can do and so forth. But translation connectors are being built into.
[00:46:24] Speaker A: It and it's part of this project you're working on. You're able to give real time feedback into that whole engineering cycle, which I've been really impressed with from the Adobe end actually. Just the feedback and the loops and the real live use case that our joint customer is going through and launching on it again really reminds me of that cycle that we went through in the early AEM translation phases. And I think a lot of it sort of is model off of that pattern a bit, but you know, building it again fresh.
It's not with all the crud, essentially.
[00:47:07] Speaker B: Right.
Well, I mean, because in the AEM world that we kind of got used to, it was a lot of this, like you've got engineering and they develop a product and then there was a support org to support it and they weren't the same thing. And so a lot of what was developed over here, like, like you were saying, you know, the, the, the, the limits on versions and stuff like that, like nobody who is engineering it would necessarily know about the limitations until it was somehow surfaced from support. Yeah. And so these, and, and so, and sometimes you know, support, which. Because every single AAM use case is different, every single AAM use it a lot.
[00:47:45] Speaker A: You know, in our previous lives when we were, we were supporting and managing and, and running and architecting some of the largest A M implementations of the world, we were running up against those limits that you couldn't really vet in a sandbox test environment. But now all of a sudden you get to one of the largest auto manufacturers in the world and we're trying to shoehorn all of their users into this and they're basically just uploading pictures of their trucks running through the mud, but at scale and we're hitting those limitations and that is how that feedback loop went in. And obviously in our previous iterations we would be like, no, this doesn't work.
Support would be like, yeah, it does. And we're like, well, have you tried it at 250,000 units?
You've only tested 70 and it breaks it at about 95.
[00:48:39] Speaker B: That's right. Oh yeah, yeah. Getting to work directly with engineering has been so amazing because these guys are, these guys are brilliant. These guys are brilliant people. So. And some of these ideas that I definitely wouldn't have come up with on my Own. It was really nice to be able to have feedback and interaction.
But on the translation side and on the rollout side, this also has a very fast and very flexible rollout built in. So we did not have to come up with our own rollout engine to be able to figure out how to deal with the multiple locales and languages and stuff that we had. So. And then, and then I guess a part of this too. So one of the things in AEM that's always been a thing with AEM is that, is that it's not just the published side that gets customized, it's the author side that gets customized. And if like on any of these deployments that you and I have been on, like almost every single time there's a deployment cycle, there's an author component to that as well of saying, oh, I want a dialogue for this, or I want a different way of entering this data, or when we've got new events, we need to be able to put this and this and this in them. And so there's a lot of customization that you can do on the author side. And so there's been a lot of evolution that's been on this as well. It's basically a kind of a plugin API so that if you have like, okay, like for example, we have events and events need to get entered every so often. So we have to have a common date format to be able to enter events. This is just something silly and stupid. But you need a common date format so people don't say month, day, year, day, month, year, year, month, day, whatever. Right. You just actually put it. One comment. So can we just have a date.
[00:50:13] Speaker A: Picker that like we're dashing slashes versus, you know, periods.
[00:50:18] Speaker B: Yeah, so added it, you know, so added some customization and added a date picker. Another thing too, taxonomy. So with, with edge delivery, you put your metadata on like for the, for the page, you put it in a big block on the bottom of the page. Metadata or block on the page. Or sometimes when you're trying to like, oh, let's just say you have a. Let's just say you have a block, you know, component that goes and pulls, let's say iterates through and finds every article that is tagged industries or it's tagged products or something like that, and displays the top five of them based on the sort order. So you have to have metadata, right? So that metadata has to be consistent. And if you're editing in a block, you're like, well, anybody can type anything. The heck they want into a block. Right. So we're like, well, can't we just do metadata? I mean, AEM manages tags. AEM already does that really well. And we have aem. Right. So can we just pick the metadata out of aem?
And it's like. And that's relatively easy. So, so made a metadata picker for da. And you can pick the metadata out of that. That's something that that is, is, is, is also just part of this customizable UI that you've got there. So, so, so there are the. It's not.
[00:51:43] Speaker A: So the source of the truth of that lives in the, the JCR repository on the.
[00:51:47] Speaker B: Yes.
[00:51:48] Speaker A: Yeah, interesting.
[00:51:49] Speaker B: Yeah. I mean, you could, I mean, you could do it either way. We also conceived of doing it a different way of having the source of truth be in a bunch of spreadsheets or something like that. But aem, AEM is arc. It's already done in terms of, in terms of a hierarchical taxonomy. Do you already want to say, I've got industries and inside industries, I've got these, and inside of those I have these subgroups, you know, so you already have that. It's already built. So why not just use that system? That makes sense that the team already even knows how to use. They're like. Because a cloud service looks just like amc.
[00:52:20] Speaker A: Yeah, they're all coming from aem.
[00:52:22] Speaker B: Right.
[00:52:23] Speaker A: You know, I think a lot of future customers, they're, they're going to be typically, probably AEM shops already. I mean, they'll be definitely net new. But I think there's gonna be a lot of teams that have those skill sets from, you know, the years of running AEM already.
[00:52:39] Speaker B: That's right.
That's where, that's where I go. Okay, good. Well, I mean, there's, and that's where I, I, you know, it's funny because I've been asked like, so is this, is this a replacement for am? Is there a. Is this, is this, is this all in a replacement for am? And it's no.
[00:53:00] Speaker A: The answer right now is no.
[00:53:02] Speaker B: No. But there are a lot of sites that I would have done with AEM before that this solves better.
[00:53:10] Speaker A: Yeah.
[00:53:12] Speaker B: Like, so, for example, this isn't Fedramp. So I can't, can't take a federal website and stick it on this right now. So, so obviously there, you know, if, if you've got, I don't know, financial services, you got something that's really tight or whatever. Pharma may, may maybe not, you know what I mean?
But. Or maybe you Know what I mean? This is something where you'd want to, you'd want to dig into the requirements. A lot of like what really are your requirements? Because sometimes you might say, oh yeah, we've got backend requirements. We could never go with edge delivery. There's too many backend requirements. And then you dig into the backend requirements, you're like, no, it works. I mean you and I were on one where we just, we dug into the backend requirements. You're like, no, no, no, there's no way this is going to work. It has to be regular Am. Dug into them all. We're like, no, yeah, I'd love to.
[00:53:57] Speaker A: Like dig into that a little bit more with you too. Just, just, you know, for my own edification. Just it feels like a lot of EDs is, is consumer focused, is the, is. Is the website look and feel, you know, is really front end heavy. There's obviously, you know, business logic and things that, that are there but that are exposed. But. So where does the, the sort of. What traditionally was the OCI bundle? That, that sort of whole grouping of logic, where does that reside in the, the edge delivery world?
[00:54:36] Speaker B: See, that's where it gets. Yeah, I think that's where it gets. It gets interesting because not there's. There's. For every requirement there's a, there's going to be a solution. Yeah, there's like. So, because for example, you can.
With the fact that Adobe now has a managed CDN that you can read that you can configure. Right. So, so that, so that it's not, it's not a black box.
[00:54:59] Speaker A: And that comes in leaps and bounds too. The ability to tweak that and the rules going into that and how quick you can update.
[00:55:05] Speaker B: Great. Oh, it's funny, it changed the world for me. I don't know. I think I got way more excited than people were expecting because I was like painful.
[00:55:12] Speaker A: Right? Like having to do a whole file manager deployment pipeline just to make a regex rule change. And you're.
[00:55:20] Speaker B: Or. But here's the other problem is that in a lot of companies, like if you take like Akamai. Akamai a lot of times isn't owned by the web marketing people. A lot of times Akamai also runs DNS. And if Akamai also runs DNS, that means it also runs email. That means the CEO's email is going to be taken down. If you muff up an Akamai change, which. Right. It can't just be the website guys.
[00:55:44] Speaker A: That are doing this and there's cybersecurity implications. So a lot of times cyber. Cyberstack runs a lot of that.
[00:55:49] Speaker B: Yes, yes. So a lot of times you don't. So if as a, as a, as a marketing team, a lot of times you don't even have access to just run your own quick deployments into Akamai. Yeah. I asked somebody this one time. They're like, well, can't you just put some of these redirects up at Akamai? They're like, we can't touch that.
Right?
[00:56:07] Speaker A: Yeah, that's opening a ticket and who knows when they're going to get to it.
[00:56:10] Speaker B: Right, Right. Whereas if you're running the cdn, it's in your same cloud manager pipelines as your rest of your stuff. And so the web guys own this then. And those cloud manager pipelines, they, they, they, they take only like three minutes, sometimes two minutes to run through it. So they're, they're, they're fast. So you just say, make a change. Wait, wait, wait, wait. Okay, now it's there. And then, so, so then you can, you can, you can say, oh, well, then I can have some of those redirects. I can make some of this logic and own it myself. So one of those things that I did on this was like, you can say, good. Well, let's say you have a, a servlet endpoint that's here, and this is AEM, so mydomain.com endpoint. And that endpoint is what's pulling up this data, let's just say for the PDFs, that PDF example. Right.
So if you want to obfuscate that, like you don't want people to know that you're, that this endpoint is some other application server. Right. You're just, hi. You're just, you just hide it behind the cdn. So, so in this case, the CDN is doing your routing, goes back to am. The rest of it goes to edge delivery and you can put cache on that too. So you work.
[00:57:22] Speaker A: So a legacy system, right? It doesn't have to be, you know, I think we're getting into that use case with this launch is that there's going to be a legacy system, you know, hosting a bunch of really, again, legacy content.
And that's all getting stitched together at that CDN tier to, to point to that legacy system behind the scenes, seamless to the end user.
[00:57:47] Speaker B: That's right now. So that being said, there, there are occasions where it.
So previously you used your application server to, as the stitching together point as the place where all these connections came from. So if you had like a product information management system that you've got 10,000 SKUs and they all are going to come in and so and they get updated from this weird database on the other side of the country every night and they get pulled into so and so AEM was doing all that and it was the, it was the single point that did all that. I mean it was brittle as a result of that. And anybody who's run any of these knows that that back end connection that goes down, all of a sudden, aem's dead.
[00:58:27] Speaker A: Yeah, right. Right or wrong, you're probably overloading a lot of features onto it that might been best served elsewhere. Yeah, that's right.
[00:58:34] Speaker B: And so that's where. So, so we did that podcast a bit ago with the Stream X guys and Stream X is one of these solutions that basically you could sit that and have that be. Instead of having a heavy Java application server basically being your backend proxy, you can turn a lot of that kind of around on its head and have something that says I have a product information management system over here, it updates whenever it updates. Then I'm going to grab that update and now I'm going to serve it straight out of this super fast machine that's already in the cloud. So I'm not even exposing where my PIN is because right now if I didn't have a piece of. For a better word, it's kind of middleware. Ish. Right.
If you didn't have that, then you're going to have to have a proxy to go and fetch it back there. And you don't want that. Yeah, because otherwise too you're going to then that stitching together point that we're using that osgi, you know, bunch of stuff instead you're just going to move that to the person's browser. And now the person's browser is responsible for making backend connections and saying oh, I've got a timeout. So sorry. Right. But like you don't want, you don't want to make the person's browser do that because then also how do you maintain.
And this is back to our operations hat right. How do you maintain a person's web experience if you're always having to worry about the backend calls that somebody's browser is making?
That part it can be done. There's rum stuff that you can do that. But that's hard to say that what is our people's browsers timing out and that's why they're saying the website doesn't work when really it was this PIM system and it keeps going down and you don't know.
[01:00:24] Speaker A: Yep. So yeah, makes sense.
[01:00:27] Speaker B: Yeah.
But anyway, so I guess that's back to say the good old architect. It depends. Right.
But, but it, I think there's a lot of, I mean if you, if you were to say like, if you take that like you and I went through that big, like we made that big list of all the websites we've ever touched, all the AM websites we've ever touched, I'll bet you if we can mark through, it's a lot, right? Yeah.
Where are we at? I know it's a lot so, because I was up at like we'll get.
[01:01:00] Speaker A: The abacus out later.
[01:01:04] Speaker B: But I bet if we went through that list and said good, so knowing what we know about those guys, which of those could be DA sets and, and I would say, I'd say 85% or more could, could be really good fits.
[01:01:25] Speaker A: And that's the thing too is, is that like we're talking about there's still patterns that are shaking out and there's still things that are being architected and designed that, that this is a new technology really. And so it's gonna be interesting to see how that comes out and that, that will, you know, it's going to get run through the ringer and we'll figure out a lot of those different patterns and how that works and how it all works in concert with other tools as well. And instead of a one size fits all behemoth is, you know, where we're coming from, which works. But it's all right there and can be very brittle and changes, you know, to one site possibly affect there's downstream ramifications. Right now there's going to be, you know, smaller sites or quicker site micro sites or, or whatever use cases.
This is going to be quick, it's going to be easy to develop. They're commoditized, you know, skill sets in the workforce with just CSS and JavaScript really. And the infrastructure is really solved as well too.
And that lets you focus on the more complex things.
[01:02:37] Speaker B: Totally. Yeah, that, that, that and that part's super exciting. But you know, so you and I are both going to be at Adobe Summit and I really, so one of my, oh man, I'm so looking forward to it. And one of the things that so, so I, I, I got elected as a, a champion this year and one of the fun things.
[01:02:58] Speaker A: Nah, I said we're gonna have to get Him a suit of armor so he could.
[01:03:04] Speaker B: But select your champion.
But one of the things, I get to hang out at the Adobe booth a lot over some of this, so I'm hoping somebody, I'm hoping some folks bring some like. Okay, all right, what about this site? Does this site work? I would love to hear some workloads and use cases that folks might say, oh yeah, no, this one, this one needs to be on.
[01:03:31] Speaker A: That'd be really fun. Honestly, I think there's going to be a lot out there that's going to be a challenge and you know, how do you get that square peg into this round hole?
But I think a lot it's going to be, you know, just sort of changing the way you think about it and it will map very easily to this new technology.
[01:03:50] Speaker B: Yes. And I think though that the amount of feedback that we have right now and this really wonderful working relationship that we've got with Adobe. See, previously, you know, when you had a software release cycle based on years, right. Like 6.2636465, when something came out and it had a limitation, you'd say, oh, well, you know, even when cloud service first came, I'm like, oh, but we don't have Splunk, so how am I supposed to recommend this to a client who needs to be able to see their logs? I can't recommend it. Okay, good. Checkmate. We're out.
But now when somebody comes with a requirement, I just, I'm super hopeful right now and I don't think naively that somebody could come up with a requirement and say, I don't think this will work because of this thing. I could say, maybe it won't work because of that thing. Let's forward this along. Let's just see.
Is any of these mad scientists that Adobe has working, would you be interested in solving that thing and come up with a solution that really, that.
[01:04:54] Speaker A: Yeah, it's been a great relationship in that regard. For sure.
[01:04:56] Speaker B: Yeah.
Okay, well, I think that that puts us at, at our, at our limit for the day. But I again, I can't wait to see people at Adobe Summit and, and see.
[01:05:09] Speaker A: Super looking forward to that. That's, I think Adobe Summit this year. There's going to be a lot of stuff. It's going to, you know, for sure be very AI heavy, I'm guessing, but I think there's going to be a lot of other like Undercard technologies, EDS being clearly one of them. And DA on top of that where that, that there's a lot of innovation happening right now and, and it's not getting the, the spotlight. And sometimes that's actually the more exciting things because you can actually have genuine conversations with, with, you know, the partners out there, the, the customers out there running this gear, and obviously the, the engineers and architects that are. That are implementing it and designing it and building it really.
And I don't know, I'm looking forward to that. It's going to be a fun summit, for sure.
[01:05:59] Speaker B: I totally agree. And I think that would definitely be my summarizing opinion on this in that I think that some folks feel that content management is a solved problem and it doesn't need. It doesn't like, it's not. It's not cool anymore because it's solved and we've solved.
[01:06:19] Speaker A: Everything can always get better and especially with new technology. And then you realize what you are actually missing in the first place with, with your solution.
[01:06:30] Speaker B: Indeed.
All right, good. Well, thanks everybody for listening. And once again, I hope I catch you guys at Summit.
[01:06:37] Speaker A: Have a good one.
[01:06:38] Speaker B: All right, see you.
