AEM Edge Delivery Services - Consider these 5 things

By now, most partners, customers, competitors, and development groups across various communities have heard about AEM Edge Delivery Services. They have probably even heard of the couple of name changes in its evolution: Helix, to Project Franklin, to Next-Gen Composability, and now known as Edge Delivery Services. The concept behind what it does is relatively simple: Enable developers to build performant web sites and authoring ease-of-use, and building out a site and publishing mechanism in...less than a day. Yes, it can be done. So you probably have all sorts of questions, such as "How do I get my site on Edge Delivery Services?", or "What development team do I need to build this for me?", or even "This sounds too good to be true for my site...what's the catch?"

Before diving into any detail, let me say that the technology has been around for a number of years, and has evolved considerably (which is also likely the reason behind some of the name changes.) And I really like where it's heading. At first, the novel idea of authoring in documents and publishing those documents to a fast page seemed pretty cool, from a developer's perspective. Configure a GitHub repository, allow access to a bot, install a browser extension, and you're rockin' and rollin'. But in reality, many organizations, and particularly their marketing teams, have a lot of existing content on pages that do things beyond static pages with a need for basic editing. Integrations with PIMs, or showing targeted and personalized content, or complex forms with many CTAs. Can AEM Edge Delivery Services enable a more mature experience that many organizations demand? Here's what to consider:

1. Traditional AEM development is ideal, if you know traditional AEM

It can take a long time for an organization to get up and running with an AEM implementation. In the spirit of agile, you would start with something small and work your way up to more complex structures. AEM does give some starter content and boilerplates to help you get up and running, but ultimately you still need an implementation team to help with building out your site, positioning for growth, and integrating with other systems. And there can still by many technologies behind that, so you'll need experts in each of those areas. (Think CDN's, HTL development, Core Components, Templates, MSM, Cloud Configurations, Distribution models, to name just a few.)

2. Development Resources will shift

If you were to ask what resources and skills are needed to build out sits in a traditional AEM implementation, you'd have to name the following: Java, HTL, OSGi, JS/CSS, Maven (and all the dependency "fun"), Apache Sling, HTML, XML, .any files (for Dispatcher Configurations), bundles, JSPs (more for legacy systems) and more. Then they also need to be able to architect solutions that involve building out templates (editable or static), components (core components, extending core components, and custom components), ReactJS or AngularJS, JCR and CQ, Workflows development, and more.

Developing in Edge Delivery Services has been more about configurations and developing in Javascript/CSS. The developer should probably also know about working with .yaml and .json files. Any other fundamentals would also be needed, such as development patterns for web development, and how to architect the content itself. Aside from that, it will depend on what is being delivered: API-driven content, based on GraphQL queries to retrieve content from a headless source, for example, will require knowledge of API development.

3. Universal Editor is the new Content Editor

So any organization needs to know all about the UE. From a development perspective, it's a matter of connecting the content source, which can now be AEM (based on their Crosswalk boilerplate, which can be found at https://github.com/adobe-rnd/aem-boilerplate-xwalk ), and then configuring the source and instrumenting pages. The idea behind use of the Universal Editor is to be able to connect to other content sources, thus making the editing experience abstract and decoupled from the content source.

4. Edge Delivery Services is more than just Document-based Editing

We know that Edge Delivery Services has established itself as a great system of editing in Google Docs, SharePoint, Word, Google Sheets, and others. But there has been a misconception that it's the only thing Edge Delivery Services does. Not at all true. It's not only for document-based editing, but it can be used to deliver your site that's sourced in AEM, or GitHub, or other repositories. What it really does is it complements AEM. You can also use Edge Delivery Serivces to serve content from a headless source, such as Adobe Commerce. Or JSON payloads, or .md files, or more.

5. Adobe is investing in Edge Delivery Services. A lot.

Just like AEM, particularly AEM as a Cloud Service, Adobe will be investing in enabling organizations to truly accelerate content time to market. They've already made it easy to build sites, given the focus on the developer persona. They've made editing easier for marketing departments and content authors by meeting them we're they're at, and even taking it a step further with the Universal Editor. They've taken a lot of headaches out from the usual concerns of DevOps, CDN management, and security. And this will all continue to evolve making everyone's life easier.

In summary, it's great to see where Adobe is going with the development of tools, frameworks, and insfrastructure to support a model of agility and effectiveness. The business value here is of the ability to create experiences that are highly performant and reliable, and enabling developers to do so quickly. Given that #AdobeSummit was all about Generative AI this year, I'd love to see more and more integrations that continue to accelerate content velocity, both in creation of content, managing and controlling content, and further enhancing the experiences for developers, organizations, and customers alike.

#Adobe #EdgeDeliveryServices