Episode Transcript
[00:00:10] Speaker A: Welcome to Arbor Digital Experiences. This is episode six, and I'm here with Joanna de Mont, our new project manager, and we are going to talk about what AEM is. Joanna has just joined Arbery Digital. She's been a project manager for some time, but this is her first AEM project.
And we're going to use this as an opportunity to explain AEM live to somebody who hasn't dealt with AEM before. Joanna, you want to give me a quick rundown of what your experience is and where you're at coming into this?
[00:00:47] Speaker B: Sure. Yeah. This is definitely my first technical project. I've done mostly military contracting, family and personal readiness, working really solely around the military and managing more social services projects. So this is absolutely brand new. I had to look up what AEM meant. I'm still confused. I'm so glad we're having this.
[00:01:11] Speaker A: Awesome. Well, I've. So I've been working in the Am space, so just to start off here. So this product, this Adobe experience manager product was originally a product by a swiss company called Day. Day was purchased by Adobe in 2011 ish. 2012 ish. They started rolling out their first version of it, 2013 ish. It was the first time they were trying to brand it.
It's got a long history. And the problem is with it is that because of the fact that it has targeted mostly big companies, they haven't put a ton of work into the same kind of start from the ground floor developer type thing, like a WordPress or a drupal or something like that has. So the amount of. Great, just here's exactly what it is, and here's exactly how it works. And here's a diagram of how it works and so forth is not really in existence on AM, so much so coming in. It's going to be opaque for most people, and you kind of have to just get into a company and most people learn about Am by actually trying to work with it for the first time.
I'm going to try my hand here at explaining this and we're going to do this live and we're going to see where this goes. Just as an example, in my trying to understand things and then trying to explain things to people, I went and tried to find my own diagrams of how AEM works. I couldn't find them. My previous life before I was in it, actually in college, I went to graphic design school for a while and I thought I was going to be a graphic designer. And then it was very difficult to find a job that would put food on the table doing graphic design, but it was easy to do it with networking, so I just ended up falling into that. And every job has been networking, network infrastructure, Internet, stuff like that. But I still want to do design, but I don't think it's my thing. But anyway, I ended up making a bunch of am diagrams, and now you search am diagram, and it's basically all my diagrams out there right now anyway.
But here we go.
I'm going to start with just the first question here, which is what Adobe experience manager is just kind of go from.
So Adobe experience manager is at its root it is a pretty complex system, or more than just being complex, it's robust in terms of being a system for managing content, tons and tons of content, and whatever that content is and however it needs to be displayed. That is kind of the core problem of any business, is that you take something like a blog. A blog is always displayed in basically the same way. You've got articles that have dates and that have some pictures that have an author, and they're always going to be displayed in much the same way, whereas a corporate website or any corporate Internet entity is going to have their data displayed in a million different ways and for a million different purposes. Sometimes it's authenticated. Sometimes it's not. Sometimes it's for tons and tons and tons of people. Sometimes it's only for a specific audience of people. Sometimes you've got a very expensive product that you need seen only by a few people. Or sometimes you might have a site that might get 30,000 visits an hour, or you're a sports entity, and you might have huge rushes of people that come in and view your things. But in the end, you've got a whole bunch of content, which consists of articles and text and images. It's authored by lots of different people. And the other core problem is that not everybody is the same. Not every person who might view that content is the same. Whereas you take something like a blog and you've just got a latest site, a latest post, a latest thing that you put up. Whereas if you're somebody like, oh, let's say you're Chevrolet, right? And if you go to chevrolet.com, ideally if you have purchased a Chevy or have been browsing about new Chevys or something like that, ideally you would see something different than somebody who's never bought, never browsed, never purchased before. So you have a difference in experience that you need to be able to display to people. You also have things like languages, location.
Those things also play into what experience should a person get what device is that person using? Are they using a mobile device? Are they coming in on a desktop?
Is there a difference between if they have a username and password and if they don't? So there's all these different things that could feed into and further complexify what kind of thing should a person see and be able to do? And I guess that is why you got this word that Adobe went through a bunch of different iterations of trying to figure out what to call this monster that does all these different things. They were going to call it the web experience manager or web content manager and they eventually called it Adobe Experience manager. And to all of us we're like, well, what does that even mean, an experience manager?
But in the end that is what it's doing.
Somehow. You need to be able to programmatically tell it based on your own requirements as a business, what the person is going to see and then manage all the components and guts and images and pictures and videos and pdfs and stuff that would go into what that person would then experience.
[00:07:36] Speaker B: So you're looking at a curated kind of client experience to these large company websites, making sure that it's curated with multiple inputs, things that I would never even have thought.
Very interesting. Yeah, thanks, tad. That was.
[00:07:52] Speaker A: And I gave an example like a Chevrolet, right? Where you're trying to do something that's very image rich, right? So something like a Chevrolet where you take something else. Another one that was a site that I worked on long ago was like Food network, right? So in something like that you're very media rich. You got lots of pictures of, if somebody doesn't want to just read a recipe, they'd want to be able to see what it looks like. They'd want to see somebody preparing the thing and then what is it? Or a story around food or a restaurant experience or something like that, right? So there's all these different things that your cupcake wars or things like that, all these things that go into providing the person what they're there for.
But you could take something completely. So obviously something like that, you'd have all these problems that equipment like this would have to solve of how do you store all those videos? How do you make sure that if the person is greek and they coming to this thing on how to prepare nachos, the nacho video is going to be in English. Is there closed captioning in Greek? How do you then go and send that closed captioning out to a translator and have it come back and then stick onto that video and how does that then get stored?
[00:09:18] Speaker B: Wow. So it's really making these websites global. Anybody in the world could access and would absolutely be able to experience something that is directly related to what they need, right?
[00:09:31] Speaker A: Exactly.
With something like that, though, when you've got a super image heavy site, that's one set of requirements. Let's just say you're something like an insurance company, which is a completely different set of requirements. Right.
So you're a nationwide insurance company. Insurance is weird in that there's different rules in every state.
What offers a person might be able to receive are going to change depending on what state they're in. And then if they're going to sign up what documents and so forth, then they need to need in order to be able to go and acquire your service would be different depending on what state that they're in or what country they're in or whatever. Right. And then, so maintaining all those documents, the PDFs, the disclosures, all those sorts of things, that in and of itself is a pretty monster requirement.
This is where you kind of get into if you're going to say the different types of sites, but then also the different types of work that you would then need to do in order to set up and maintain an Adobe experience manager site. There's not one type of work that you then have to do because if you take something like insurance, right.
One of the things that just diving down the rabbit hole of things, of decomposing that job of making an insurance site work on AEM. So let's just say you're in every state. So in all 50 states, you've got disclosures and agreements and things that you need to be able to sign up for. You've got pdfs that have the person's rules of what happens when you sign up for insurance. So somebody needs to maintain all those documents. So somehow then if you're going to maintain all those documents, a lot of times there's regulations around maintaining those documents, then you're talking about good. So how do you keep track of good? I updated this document. Now it has to go through this, this and this person before it gets approved and goes live. And now it's marked as having gone live and now it's on the website. So that implies a whole workflow that you have to then first conceive of and then implement programmatically. So that when somebody says, oh, there's a new rule that just happened in Mississippi and this document's no longer valid, somebody needs to update this, it needs to get approved and get pushed back onto the site.
So then there's a, so Adobe experience manager in and of itself has a really robust, in addition to storing everything, it has this huge robust functionality which has to do with workflows and being able to say, goodwin, when a PDF comes on, it now has to go through these six people and they all have to click ok. And if they click not ok, then it goes back to here or goes out to Jira or workfront or one of these other workflow management systems or something like that to then come back to then get approved and pushed on and then it can get served. Maybe when you upload a PDF, it then also has to get crunched so that it's web viewable so that the person doesn't download a 75 megabyte pdf whenever they're trying to just okay their insurance policy or something like that. So figuring out and programming and developing those types of workflows is another type of work that goes into running an Adobe experience manager site.
[00:13:14] Speaker B: That's a lot, that's a lot of stuff for a company to manage. Absolutely.
[00:13:20] Speaker A: It is. And that is, I think, one of the reasons why, well, if you take something like again, once again, kind of comparing it to another familiar, like a blog or something that's, or wix or something, that's kind of meant to get you up and running really fast because if, let's say you're a dentist office, right, or you run a little bookshop or something like that, there's a really kind of constrained number of things that you just kind of really quickly need a website to be able to do. I'm in an about us page. I'm going to put my picture right here. I'm going to talk about my services and then I've got some little woocommerce or whatever, some little site that offers my intro package for whatever it is, and then here's a contact page and then we're done, right? So that sort of thing. You could use a piece of commodity software like wix or WordPress or Drupal or something like that and just quickly pound something like that together. And even somebody who wasn't a web developer could pretty much do that really quickly. But let's just say you're something like this. Here's another.
We talk about insurance. So that's one use case for AEM.
Take something else like let's say you're a big shoe company and you've got distributors all over the place. Those distributors have artwork and signage and stuff like that that they are supposed to put in their store that sells your stuff and you have popular stuff.
When you're making all your spring colors and you're in the winter, you don't want that stuff leaking out beforehand or else even your competitors know what your next season stuff is going to look like. So it has to be secured. So keeping track of all those assets and so forth. So securing and externally available on the Internet, but locked down to a specific set of people, that's a completely separate set of requirements that you would need to contract somebody to be able to go and design and architect and what does it need to plug into and all that sort of thing. Is this stuff in stock or not all that sort of thing. That kind of leads into this other thing about AM which makes it kind of a beast and which requires a lot of different specialties in terms of being able to put it together is that am commonly in fact almost all the time in almost every implementation, plugs into something else. Some other business system that's not just the content.
So let's say you are a company that manufactures something. This is like just as another example, there's a company that manufactures tooling and they do tooling for whatever paint or something like that. So they've got whatever, maybe they've got 5000 different skus of different fittings and things that they sell. Some of that's available, some of it's not. Some of it's available in the US, some of it's available outside the US only. Some of it's available for export. So all that stuff is in a big system that they keep some big whatever, maybe it's 20 years old that they keep all of their parts data in.
But that's their source of truth for what things that they offer. And that also maybe has all of their official product images in. Now you want to put this on the website. They don't want to make, to duplicate all that effort and make it redo all their 5000 images that they're already paying somebody to manage. But somehow you want to pull that and have it available on the Internet. So in that case you're going to plug am into that. So that class of thing is you have a product information management system in some cases that is the thing that says here's the picture of it, here's the description, here's its features, here's its dimensions, here's its weight, here's all that kind of stuff. And some of that stuff needs to be on the website, some of it doesn't. So you need to have somebody who can program it and pull that into AEM and then go and display it appropriately on the, it's not.
This is where you go from the requirements of if you're a dental practice in Wisconsin someplace, and then you just got just about us page and a map to your place, those requirements, and then you take something like what you would need for am. This is why these am projects can be huge. They can be very big.
And sometimes you go, well, you look at the eye watering price tag on some of these projects, but then you look at what they consist of and it's pretty big.
[00:18:19] Speaker B: What I heard is you talked about maintaining your brand identity and also your intellectual property, things like that, where that need to be protected. And this does this for you. And what are the people who help program this? What are their jobs? What are they called?
[00:18:35] Speaker A: Okay, that's great. So you've got a couple of different things.
You're implementing an AM site. You've got that going.
Who are the people that you ended up having? So you would have a lot of times, obviously, you've got the business side and the technical side, and those two have to be really in touch. So you've got guys that have to tell you what it is that you're trying to do from a business perspective. And then you have all the technical guys who said, well, this is what's involved in that.
[00:19:09] Speaker B: Tad, the fire department is here.
[00:19:11] Speaker A: The fire department is here.
[00:19:13] Speaker B: Yeah.
[00:19:13] Speaker A: Okay, good.
Okay, sorry, we'll have to pause confirming that intermission graphic. You know what I mean?
[00:19:34] Speaker B: I see this fire truck pull up and I'm like, okay.
[00:19:43] Speaker A: All right, back from intermission. Okay.
All right, that's great. We've never had the fire department show up in the middle of the podcast.
In terms of the people that get involved in this, you've got business people and technical people. You've got usually on the technical side of things, because we're on the technical side of things at Arbery, usually you'd have an architect who is there in charge of the entire project, and they're in charge of really, they're kind of a little bit of the producer of the whole thing, of pulling together all of the disciplines that you're going to need and also kind of designing the system overall. And they need to have enough knowledge of all the different parts of it and everything that's going to go into it to be able to bring the whole thing off. So once you've got that, you then have a series of other people and they can be divided a little bit into, I guess I would say three separate ends, maybe four depending. You have the people who are in charge of providing the content, and a lot of the times those guys are going to have a login into the system, they are going to be usually tagged as authors, and those are the people who are creating all the different content that it's going to go in am. And they're also going to be responsible for things like taxonomy, tagging things in various places, making sure things are arranged in the right way. Sometimes with a very large site or with sites really of almost any size, you have somebody who's wearing a hat, which is an information architect.
And that whole information architecture discipline is one where you're arranging things in such a way that they make sense and they can be displayed. As an example of problems of that nature is, let's just say you have a product.
You want to easily be able to have pictures related to a product, be able to be pulled up. You'd want to be able to have documentation related to a project, a product to be able to pulled up, release notes related to a product, how to's related to a product, all the different things related to a product, to be able to be shown.
That information architecture job is sometimes a long one and sometimes really precedes putting a site together because you really get super cart before the horse if you don't have a lot of that sorted out and you just say, let's build it, and then you realize that you don't have a way of linking all this up or you've been uploading all these assets in random places and you say, good, well, give me every picture that's related to this product and you're like, I have no way of linking all that together, that's a part. So that information architecture hat you've got so separately to that, you're going to have also, how does it look? And so with that, you're going to have visual designers. A lot of times those visual designers come before they provide a visual design to front end developers. Front end developers are responsible for the user experience because these days it's not just what does a site look like, it's what does it do and how do you interact with that site and make it get from the front. When you first acquire the user all the way through to whatever call to action or whatever doing this, that the person is supposed to be able to get done, whether they're downloading a PDF, they're contacting sales, they're buying the product, they're scheduling an in person assessment, whatever it is that the site is supposed to do. Because most of these sites, if they're marketing sites, are not just supposed to show something.
You're trying to actually make the person take action.
So a lot of that is in that whole visual designer, UX designer and front end developer who's doing all that front end development work. Then separately you have this whole job of AEM developer, which that can be a misleadingly large ask because it bleeds into both the front end end of things, of how does it get displayed? How do I display the things that I want displayed? How do I make a component, if I have a component that's supposed to pull up the list of locations that we have and then display a map, and then once it, and it's supposed to grab your location from your gps coordinates and then say, good, well, your nearest location is this. And do you want to schedule a tire rotation at the nearest shop or whatever the thing is that you're supposed to schedule, but then that Am developer commonly needs to both be able to deal with all the front end user facing things, but also talk to back end things and say, good, well, I got to pull the product image out of that information system that's 20 years old. So how do I link that up? So that sort of thing is also going to be coming out of that whole Am developer role. And then assuming you're building all that stuff now, you have to make it work and you have to get it online. And so a lot of times you've got then a whole set of roles, which is infrastructure, operations, monitoring, production support, all the things that go into actually making it available on the Internet and keeping it on the Internet for a long time.
I've been in that role a lot in my life. And a lot of times when people would say, for example, on the food network, right, I was doing that work.
You heard of the Food network? And they're like, yeah. I'm like, yeah, I work on, they're like, oh, you did the videos. I love cupcake wars. I'm like, I love cupcakes too, but I didn't do that. So you know how when you went to the site. Yeah. You know how you didn't see an error message like that? I did that.
That was me. The not error message was me.
You have that sort of thing because if you're serving all this heavy lifting, all this stuff that it has to do as a fire guy back.
Okay, good.
[00:26:21] Speaker B: So what you're saying is that you have these people that are going to help you to make sure that you have a great experience. And I know as a consumer or client possibly, that when I get a 403 message or something like that, it's really frustrating. And I may not go back to that site or use that product because I think they don't have their stuff together. So having an experience manager like this on a global scale would make that experience wonderful for anybody, anywhere. That curated type of experience. And then again, no errors, which sounds like a heavy lift.
[00:26:55] Speaker A: It is a heavy lift. It is a heavy lift. And there's so many ways to get it right, and there's so many ways to get it wrong, and there's so many ways that people obviously, here's the other thing about all this, too.
This is part of what I find really endearing and exciting about this because like I said, it's a ton of work. It's super complicated. It's really weird. It's got weirdnesses all over the place. But at the same time, every single website that is using this, a lot of times AEM represents everything that the company wants to do in the future.
A lot of times they really are pouring their heart and soul into these websites because if the company is going to stay alive, it needs to attract customers and needs to service them. And so it's not just like paying the phone bill kind of a thing. It's not just like, okay, good, we got to keep our email system up or something like that. This is like, if we get this right, we're going to be doing great. And if we don't get this right, then we might as well all go home, sort of a thing. So this gear, a lot of times has every hope of the company attached to it. So this is what makes it fun.
[00:28:16] Speaker B: So I think I've gotten a good understanding of maybe AEM for dummies, maybe this is part one and we dig into those roles in a part two.
But I have learned a lot, and as a project manager, I don't necessarily need to be a tech person. I don't need to understand every single thing that you do. But it is important for me to understand globally what we're trying to do for a company and how to manage those projects with the stakeholders and everything that's involved.
[00:28:51] Speaker A: Yeah, good. Well, then I think a part two and a part three or something like that could dig into the guts of what makes it all go.
[00:29:00] Speaker B: I would love to see what the listeners or the viewers, what do they want to know? Don't be afraid. Legitimately I needed AEM 101. I probably need a 102 and 103. I didn't even know what Aem was, so I appreciate you taking the time to explain that to me.
[00:29:23] Speaker A: All right, well, you're welcome. Well, good. Well, then, we'll finish this off, and until next time.
