Fast Time to Value with Adobe Experience Manager Sites

Transcript

Okay, let’s get started, shall we? Hi, everyone. Welcome to FastTime to Value with AEM Sites and Digital Foundation. My name is Yuji Nakagawa. I’ve been with Adobe for 12 years, the first 10 as a technical architect for ACS. And so like you, I’ve implemented AEM for a wide variety of customers. As a TA, I’ve always wanted the right balance between best practice and the tailored customization specific to the customer needs. So now this has led me on a journey towards the creation of Digital Foundation Blueprints, a topic that I want to talk to you guys about today. The why we should be doing Digital Foundation is just as important as the how. So I want to take a few minutes to discuss the why. During the creation of Digital Foundation Blueprints, I had an opportunity to speak to quite a few customers and partners and the ACS folks. And there was some feedback, a general theme, that I wanted to share with everyone. And it really talks about the why. So as a developer, I’ve implemented AEM many times before. If it’s not broken, why fix it? So let’s talk about that. I learned AEM maybe in the 5, 6, 1 days. And as a TA, I learned it, I got myself enabled, I did a few projects, I was successful, and that became my go-to routine. And over the course of years, I just did it the way I did it. I didn’t really look at the product innovations. And I just said, you know what? I know what I’m doing. My project’s going to be successful. I don’t know that that type of mentality works in today’s world. And let me tell you why. AEM is evolving quite a bit. And as we move to the cloud, this acceleration would only become much greater. And then there’s other things that get attached to AEM. There’s the Adobe IELTS runtime, there’s a sensei APIs. And so as a developer, my time or your time is better spent thinking about the innovations. And then let’s let the core AEM platform handle the more commoditized activities around deploying a website. Another thing that I heard, is this another development accelerator? And development accelerators are great. I don’t want to sound like I’m knocking them, but this is slightly different. And a development accelerator assumes that your website is going to be bespoke, that you’re building from scratch. I mean, nothing wrong with that, but you’re sort of saying, even from the beginning that customization is needed. What Digital Foundation Blueprint evangelizes is, hey, there’s enough product features with AEM now that you can build a simple website without needing Java development. And that’s the core principle behind Digital Foundation. Given the strong AEM developer community, that’s something and just the way of strong developers are, we know what we’re doing, we don’t really need that much help. So I want to really emphasize this. And there’s nothing wrong with Java developers, but we should try to democratize our deployment of AEM and bring in additional roles to help. And the developers are better spent thinking about the more advanced things. And of course, we’ve heard it’s not for everyone and it won’t be practical for everyone. There’s going to be times when you need to build from scratch and you need to build a highly tailored custom solution. But I think the key is during the initiation of that project, think about the core business objectives. If your business stakeholders want the… And if you hear words like low total cost of ownership or accelerated time to value, then maybe a very simple out of box implementation and then incremental updates is something that might work. And so, yeah, let’s also talk about the definitions of… We throw this around a lot, TTV and Digital Foundation. Let’s talk about the definitions of that. So the standard definition for time to value is the amount of time between a purchase and then the realization of value from that purchase. So within AEM, we typically measure this as the time from the purchase of the license and then the time where you’re getting traffic or your website is live, you’re getting traffic and that’s where you’re starting to realize value from that purchase. Digital Foundation, it’s the idea that you need to build a solid foundation for your digital ecosystem. We’re no longer the days of just a web platform to build your website. AEM is evolving. It’s become the enterprise CMS. And when it’s your enterprise CMS, it’s for your experience platform. And that goes beyond your website now. It goes to social commerce, your customer journey platform. So the Digital Foundation is the idea of building a solid foundation for your digital ecosystem. Now, if you think about Digital Foundation Blueprint, as it fits into your overall implementation, and typically your implementation is linear, you have your provisioning, your discovery, your development, and then your content build out and go live. So pretty much the same routine, but think of it as concatenating it or making it a little parallel in your stream. So parts of your onboarding start going into implementation. You’re starting to pull your content authors and your styling closer to your development or your implementation. And then the adoption or going advanced can happen once you’re live with the website. So if we think about that, if we really want to deliver the 90 days quick to market, you really have to think about bringing in or reassessing your implementation model to better leverage out of box implementation and doing out of box and then customizations. So thank you for letting me talk about the why. So we should start talking about the how, right? And I think a perfect example of how to put Digital Foundation Blueprint into action is a contest that was held for Adobe. I don’t know if some of you may have seen this, but it was called the Digital Foundation Lean Code Contest. And what we did here is we provided a UX and it’s shown there on the right. And we said, hey, can you build us a website leveraging Blueprint and the principles of Blueprint using core components with the least amount of customizations or custom components? And we were very surprised. We weren’t surprised. We were happily, we’re happy to see so many submissions that use zero custom codes, right? All of the submissions used core components and style systems. And they built a very nice website that really reflected the UX that we provided. But this is a good thing, good example to show. And I want to use this as sort of the challenge to everyone here today listening to this presentation. So how can we leverage Digital Foundation Blueprint and put it into action? And so I want to start here. It’s thinking about the values of what Digital Foundation can provide. So if you think about those three pillars, accelerated time to value, or sorry, if you think about there are three pillars in helping you put Digital Foundation Blueprint into action. The first is the business stakeholders, do they want that accelerated time to value? Like, do they want to go live quickly? The second is democratizing your implementation, making use of your content authors and your front end developers sooner so that you can be forward looking longer, further ahead on the advanced features that the customer may need. And the final part is to leverage the automation that was written to help you put in the best practice for your launch and analytics implementation. And if you use Digital Foundation Blueprints, there’s a couple of general tips that I want to share with everyone. The first is everyone’s familiar with Maven Archetypes, but that’s sort of the core means of starting your Blueprint implementation. And it starts with Maven Archetype 25 and anything beyond that. But if you use that Maven Archetype 25+, what you end up getting, there’s a couple of key things that you get with that. And the first is your initial configuration. So if you were starting from scratch, you have to go into the browser tools, browser configurations, and create the configuration folder to support all your cloud service and settings. All of that gets done for you. And then if you’re to start from scratch, you always have to create your base template. That also gets done for you. So now your authors can come in and create all of their page type using the base page template that the archetype created for you. The third thing that it does is it puts in sort of a placeholder for your experience footer, experience fragment based header footer. If you open up that template, if you went into that page template that was created for you, and then you created a new page type, the header footer would be already there for you. You just have to style it. Another important thing that the Maven Archetype does for you is it creates the dispatcher configurations. One of my pet peeves when I was doing TA, it used to always be my sprint one work was fix the dispatcher or fix content sites project name. If you guys are AEM developers, you know this. This gets exposed and you have to hide that. So that’s one thing that gets done for you. That’s no longer something that is part of your development task. And then the last thing is to set up the core components. It sets up the proxy. It’s not difficult work. It’s just all of these things put together. They become a little bit of tedious work. And so they do that for you. The other thing is the next step is to stay current with the core components. And I’m sure you’ve seen it by now, but we have a website that shows all of the core components. And to really, I mean, it’s one thing to know it, but I think to really be able to adopt it, you have to have a means for which you’re going to adopt. And I want to dive into that a little bit right now. If you think about the anatomy of a custom component, now you’ve got your dialog box, your HTML markup, the content logic, the Sling models that are best practice that you have to create, the edit behavior, and then the preview behavior, and of course, all of the documentation and test scripts that you need to write. So that can add up to be quite a bit of overhead to create a core component. And really, you have to ask yourself, and I think that’s the core thing is, can I use a core component instead of a custom component? And the way that I do this is I take a look at that UX that gets provided to me, and I start circling those authorable elements within that UX. And you’re going to start to find a lot of commonalities. When we were piloting the blueprint and we were getting customer provided UXs and we started doing this, you will find that core components really do handle, I would say, like 80, 90% of basic website needs. And there’s always those outliers, and that’s the key. Let’s take this teaser component, for example, and you might get a UX, and then there’s always going to be this title, a description, but there might be something like a date. If you look at the core components and you looked at the authorable elements supported within the teaser, you’ll say, okay, that date’s not there. I think this presents an opportunity when you’re doing your projects to take it back to your stakeholders and say, look, you provided this UX. If we pull out the date or if we move that into a future date, we can go live with a teaser component that’s straight out of the box, and we just need to style it and we’re good to go. And we could potentially add the date if it’s really that important to you at a later date. And this is really more a call to action that there should always be this negotiation. First you check to see, is it a core component? And if it matches, great. If it doesn’t, is it close to a core component and could be? And that’s a really important call out. The last tip is the front end development flow and making sure that it uses a style system. So when you use the Maven archetype, it provides a UI front end module, which is really a web pack project, and it helps you build your AEM client side libraries in a front end developer friendly way. That doesn’t mean you have to use it. Let’s just take my own example. I’m not a web pack person. I’m SaaS. And the way I would do it is I created a folder within my client libs, and within that folder, I made it very SaaS friendly. And that was a space that I gave my front end developers, and they would go do their front end work, and they would do it in SaaS. And then I just wrote a script, and whenever I needed to compile, it would compile my SaaS into CSS, which I pre-created as a client lib, and so it would bring in my front end developer work. That process for the front end is repeatable. You can carry that over from project to project. So it’s very important. And I think making sure that the front end flow is friendly to style systems. And when I say that, I mean our style system uses the bend notation. So we want to be able to incorporate a UI for all the variances of the core component. So we want to make sure that not only is there a friendly flow that’s front end developer friendly, but it hooks well into the style systems. Now, going back to that Lean code example, if we were to go, if we’re going to try to implement that, there’s a few high level steps. And I want to call this out because it may differ a little bit from a traditional flow. But there’s, this is the best way to, I guess, leverage Digital Foundation Blueprint. It’s to make sure you have your content architecture set, and then your front end design, your content authoring, and then personalization and analytics. So let’s dive into that a little further. So let’s start with your content architecture. Now, the Maven Archetypes, it created that base page template for you. And so the next task here is for your content authors. I’m going to go back. I forgot to mention something. So I’ve also put on the owners here, right? So this is, I talked about democratizing your implementation. You’ll notice that I don’t have any tasks for my Java developer. This is because my Java developer is thinking about the more advanced stuff. And then the activities around launching my website, it’s going to be a mixture of my front end developers and my content authors. So coming back to the content architecture, so I’ve got my front end, my content authors. They’ve been given that Maven produced page template, and now they can go through all of their wire UX designs, and they’ll start saying, find the unique patterns needed to support their website. And then for each pattern, list out all the components that that template needs. As a developer, this is nothing new, but the idea here is you can do this within the UI. You don’t need Java development to do this. And so here, I’m just taking one example. On the right was that Lean code contest where clearly you need the homepage. And so we created the homepage template, and then you assign the core components to that homepage template. And you do for all of the templates needed. For the just to tie it off with the Lean code contest ended up needing two or three, I believe. So the next thing you need to do in terms of the content architecture is to do a component mapping. You take all of your UX, and on the left, I’ve highlighted a great example of a component mapping. You start circling the areas of the UX that are provided, and then you start doing that. And then put the label of what the core component is. And just to show you the example from the Lean code contest, there was a section that everyone said, yeah, this is a teaser. And there was three or four variations of the teaser. I’m highlighting two of them for you. And you can see the look and feel is quite different, but you can invoke the different look and feel by invoking the style system and toggling the various display and the content toggle variations to achieve the different look and feel. So that is a very important part of content architecture after you define your templates is to define the component mappings. And then, so after you’ve got your component mappings, your next thing is to get your front-end folks aligned with your content author. So after you’ve got your template and then your component mappings, and that gives you sort of the backlog for your front-end developers, and they know all of the various designs that they need to create. But as they start producing these designs, there needs to be this handoff to the front-end, sorry, to the content authors, because every one of those different components with the variations are going to be hooked into the AEM UI style systems. And this is where the content authors can start taking ownership of the various front-end design variations. And I’ve shown an example on the left. This is the visual of what a design may look like. And you’ve got the hero teaser with, you can toggle on the different sizes of the titles and trigger different displays of it. And then on the right, you will map that as a style system, and the content authors can then use the different variations of the styles together. And so this process is a very important part of democratizing your implementation. And so now that the front-end developers are working closely with the content authors, now the content authors have the task of creating your content taxonomy as well as your asset taxonomy, right? So as taking on the content author persona, I’ve been working with my front-end developers, and I know all of the component styles that they’re going to be producing. And as I get them handed off to me, I register them as a style system. And now I go into my AEM. The first thing that I would do is create my header and footer experience. And that gets tied to all of my page types. I would create as many page types that I would need. Within every page type, I would add my layout container and then associate all of the components and the style systems I need for that. And then that’s sort of my initialization of my system. And now I will go out, go and create my content taxonomy. And to support my website, I would build my asset taxonomy as well. Oops. And then the final thing is the, my favorite final thing is with the Digital Foundation Blueprint license, you get access to automation. So there’s a few steps to invoke this automation. Right now, it’s an email system. I would love for this to have a better way of triggering it, but today it’s a two-step process. You go into your experience cloud and then you add esatadobe.com as a system admin in your experience cloud tenant. And then you send an email request to Adobe and you add your IMS org ID and your org name. And I highlighted some examples to show you exactly where you can find it. And then finally, the name of the analytics report suite that you would like. And what this would do is this triggers automation code and the launch and analytics automation, it’ll do a couple of things for you. It’ll create your, it’ll initialize your launch. And if you don’t have your launch or analytics specialists readily available, this automation will help kickstart it. It’ll get them to a go live state without needing as much of their time. And like the Java developer, your analytics specialist can be spent thinking about the future state of that analytics itself. So the blueprint automation will create the launch property. It’ll create some basic rules as well as the data elements. It’ll also add the analytics core, the target, the experience cloud ID extensions. And then finally it’ll create the environments for you, all of the environment packages for you. But as a short note, the Adobe client data layer, and I think there’s a different session on that. You guys should definitely attend it, came out after our blueprint automation. So that part’s not exactly hooked in yet. So what you have to do is you take your automation code and take the environment link and then embed that into your page template. In the future, that will get done for you. So I’m going to leave it at that. And I think I’m just about with five minutes to go. I want to close it out with a couple of call to actions. First is don’t be like me. Don’t be the TA that says, hey, I’ve implemented many times. I know what I’m doing. So I’m just going to keep doing it the way I’m doing it. The call to action, first and foremost, stay involved with what’s going on with AEM, especially with the move to cloud. The features are going to start coming rapidly. And so stay current and be flexible. Adjust how you’re doing the implementation. Let Adobe handle more of what I call the commoditized work. Just deploying a website is easy now. We’ve been doing it for 10 years. Let Adobe do it. Focus on the sensei, the advanced features, the IO hooks. Those are the things that would be better served with my time as a Java developer. And the second is get your customers live quickly. We are no longer just a website tool. We are an experience platform. And with an experience platform, you’ve got personalization, you’ve got analytics. And the sooner you can get that side of the business engaged, the better it is for everyone. So the sooner you can go live with your website, you can start getting traffic data. You can start building a personalization, your customer journey plan. So get live quickly so that the rest of your team can get engaged quickly. You can democratize the process of your AEM implementation.