An Introduction to Document Authoring (DA) for Edge Delivery Services

There is a new, highly-compelling, early-access technology to manage Edge Delivery Services sites called Document Authoring (a project formerly known as Dark Alley). It is a breath of fresh air for the editing, translation, storage and management of Edge Delivery implementations, and as the lead architect on the first customer project to use this technology, I'd love to take you through it a bit and give my experiences and thoughts. If you're evaluating your next move for a site based off of AEM (or which might migrate to AEM), you DEFINITELY should know about DA.

What is Document Authoring (or DA) for Edge Delivery Services?

Document Authoring or DA (the artist formerly known as "Project Dark Alley") is a blazing-fast, Edge Delivery Services or Helix-native, integrated solution for managing, editing and publishing sites based on Edge Delivery Services.

DA is currently an early-access technology from Adobe, which means that Adobe is presently co-innovating with partners like ourselves and partners who've chosen this path. If at any time along this article you're like, "I'M IN SIGN ME UP" please scroll to the bottom for the Slack/Discord & contact info.

For anyone trying to understand where DA fits in a traditional AEM infrastructure paradigm or a quasi-modern document-based Edge Delivery architecture, let's first get a few terms out of the way:

What is Edge Delivery Services?

Adobe's Edge Delivery Services is a cutting-edge, cloud-based system for website delivery which takes authored documents & images (and some video) and publishes them to the web in a manner optimized for extreme delivery speed. Edge Delivery Services essentially fills the same role in a modern architecture as the traditional AEM “Publisher” and “Dispatcher” server tiers filled, and has advantages such as:

• VERY fast delivery speed - in back-to-back comparison of traditional AEM vs Edge Delivery (which I'll refer to as EDS heretofore to save typing), the EDS pages were 3x-6x faster than they were with on-prem AEM 6.5.
• Global delivery is built-in to the system. (note: China can still be a challenge)
• Virtually unlimited traffic capacity - there’s no set number of servers that are delivering the site, so the system is capable of handling even a Super Bowl Ad sized spike with no issues. The ability for Edge Delivery to swallow ludicrous-sized traffic spikes is already legendary, ask anyone with an EDS site who's run a major TV ad campaign.
• Built-in preview publishing, so that one can preview fully-functional content before it goes live. Not only this, but due to the in-build CI/CD feature set, every BRANCH of code has it's own instantly-provisioned preview environment, for crazy-good flexibility when it comes to squad-level UAT and feature branching.
• Simple “Block” based content development: Edge Delivery services serves pages that are comprised of “Blocks” which are content elements like Tables, Tabs, Accordions or Columns. These are then authored in a simple google-doc-style interface.

Remember: Edge Delivery itself is NOT a CMS

Edge Delivery is a development framework and a delivery pipeline offered as a part of the AEM solution, but it does NOT dictate the solution you use to manage your content, control access to modifications, roll out translations, integrate digital asset management systems, etc. As a result, there are a NUMBER of fully-valid, fully-supported systems for authoring & publishing on Edge Delivery Services, including:

• Document Authoring
• Sharepoint
• Google Docs
• Adobe Experience Manager Universal Editor

There are cases where each of these toolsets could make sense as the tool for the job, and it's important to understand the pros and cons, features and limitations of each one. Note too that not EVERY site is a good fit for Edge Delivery Services, and some may be best for traditional AEM at this point in time.

As another point of clarity in Edge Delivery nomenclature:

• "Document-based" authoring implies that one is dealing with documents as the primary unit of content. Document Authoring uses HTML documents. Sharepoint uses Word docs, Google obviously uses Google Docs. This is as opposed to JCR-based authoring, where the individual documents and their metadata are stored as nodes in the AEM Java Content Repository.
• "Helix" = Edge Delivery Services: This technology has gone through a slew of name changes, starting from its original code name of "Helix" and then later being called "Franklin" as well as "Next-Generation Composability". But right now, if you see a reference to "Helix" it's referring to that Edge Delivery Services block in the diagram below.

Document Authoring & Edge Delivery Architecture Diagram

Before diving into the feature set of Document Authoring, let's first look at an architecture diagram of where DA could sit in an example AEM / Edge Delivery deployment:

In the above architecture, DA plays the part of the CMS and authoring surface, and the integration point for document-management activities such as taxonomy, asset management and translations. It is generally NOT the central integration point for backend or public data-integration in the way that a traditional AEM author might be, however.

In the architecture above, we assume:

• Document Authoring is the surface for web document creation, management, publishing and translations rollout
• Adobe Edge Delivery Services as the publishing tier, which takes documents authored in Document Authoring and delivers them out in ultra-fast, responsive, web-ready format
• Adobe Managed CDN as the content distribution network, web firewall and configurable redirection layer.
• Adobe Experience Manager Assets for web asset management (images, documents and other files delivered by the website)
• Hubspot for web forms and confirmation/transactional emails. (This role could also be filled by AEM Forms, Marketo Forms, or a host of other form management providers)
• Vidyard for video management and delivery
• Smartling for translations

I could (and will) expend considerable time expounding on the flexibility of this setup, and how one could architect one's way around data residency and access requirements for things like product data, PIM systems, legacy systems and the like, but that's a post for another day.

The Document Authoring (DA) Feature Set

The DA feature set includes:

Document Tree Management

Content management for your Edge Delivery site is done from within the DA interface (as opposed to Sharepoint, or within AEM) with documents internally stored and versioned in the cloud. DA's file management and publishing interface allows normal copy/paste/move as you'd expect, and contains inbuilt calls out to Edge Delivery to denote publish/preview status.

Editor for Documents & Sheets

DA includes a document editor & sheet editor for web documents as well as structured data. The editor is no-frills and blazingly fast, including a slash menu for quick functions & formatting, a block library for quick access to blocks (i.e. "Components" in ye-olde AEM speak) that you've created in your project.

The editor plugin framework for adding other UI features custom to your project. Some such plugins that we've put to use are a tag browser for browsing & picking AEM tags from an AEM instance, or a date picker for inputting date formats in an expected format into a event management UI.

Real-Time Collaboration

DA includes robust real-time collaboration, allowing virtually any number of users to simultaneously edit a document. We actually ended up testing this in real time at the AdaptTo() conference where I did a talk introducing Document Authoring. As part of the talk, I ended up inviting all 200+ members of the audience to log into a document simultaneously and start editing & previewing on it, and the collab backend held up just perfectly - which is more than you can say for editing in Office sometimes.

AEM Assets integration

DA includes built-in AEM Assets integration using the AEM Assets Micro Frontend (MFE). This allows organization to continue to use AEM Assets as their central system of record for digital asset management, while also giving authors the freedom to work in a fast, document-based Edge Delivery system.

The implementation on this is A+ and is truly one of DA's killer features.

Built-in Document Versioning

DA has built-in document versioning and audit history. Every edit made to a document by any user is audited with a date & timestamp, and restore-point versioning is done automatically every time a page is published, or ad-hoc at any point where you want to cut a restore point.

Versioning is also available in bulk, and through the API.

Live Preview

DA provides a live preview in the edit window, with multiple screen sizes (mobile, tablet, desktop) available.

Bulk Tooling

It's still an early implementation of this early-access technology, but DA already contains EXTREMELY useful bulk tooling for bulk preview, bulk-publish, bulk-reindex and bulk-versioning.

This, combined with berserk-fast search & replace across whole trees of content, it's very fast & workable to make safe, mass changes across large swaths of content, and to then roll them out.

For example, in a subsection of the site containing around 4000 pages, I had to replace out the name of a fragment we were using for sub-navigation. Instead of having to get a developer to write a groovy script (as one would do in the AEM world) we did search & replace in the DA UI, which completed all in a matter of less than 8 seconds.

Even better, I was able to bulk-version that whole section of the site first, so I had an instant backup version to revert to, should anything go amiss with the search & replace. Again....BREATH OF FRESH AIR.

Translation/Rollout and a "MSM" replacement for Edge Delivery

A huge reason why our launch customer selected DA for their Edge Delivery rollout instead of Sharepoint/Universal Editor is DA's robust localization framework and page-rollout & reintegration functionality. A major challenge with implementing localized Edge Delivery sites with Google Docs or Sharepoint (or even Crosswalk sites with Universal Editor) is the lack of an established framework to replace AEM's multi-site manager (MSM).

Without a translation management system (TMS) connector and MSM functionality to tap into, anyone implementing a localized site on Edge Delivery is forced to design and build their OWN bespoke workflow and document-shuffling disaster to collect documents for translation, ship them off to the TMS (i.e. Smartling or Translations.com etc), to retrieve them back, process local changes and roll them out. Just that functionality alone could represent a massive part of the development work to move to Edge Delivery and negate much of the benefit of how fast EDS is to develop on. DA solves for this by providing a robust and VERY flexible arrangement for shipping off translations and to then diff any local changes when bringing those translations back.

Authoring & Publishing Access Control

DA does contain a robust ACL model for publish & authoring access control. Edge Delivery can be a bit interesting in this regard, as unlike a unified system like AEM where the authoring & publishing is all part of the same system, Edge Delivery is separate. Referring to the diagram above, "Helix" or Edge Delivery has its own preview/publish permission system - and is NOT fine-grained. Meaning, you either can push content into the "aem.page" or "aem.live" buckets or you can't. Fine-grained access control (like only the "bloggers" group can write content to the /blog content tree, but they can't publish it only write - etc), that is up to the authoring surface to implement.

So, DA has support for both the authoring-surface-level access control (fine grained) as well as a mechanism for configuring protected publishing in Helix to lock down which users can preview & publish content to Edge Delivery.

OMG the Raw Speed

The last comment I should make about DA (which could very well be the first) is that DA is without a doubt the fastest CMS I've ever used. If you can find a faster CMS, please let me know.

The document loading time, publishing time, and overall snappiness of the UI is unmatched, stemming of course from the fact that DA is ITSELF an Edge Delivery project. Onboarding authors from the client side who use DA back-to-back with AEM 6.5 are uniformly shocked by how fast it is. The difference is especially stark when dealing with complex pages that in AEM contain nested components, or multiple dialogs that all take time to load out of the JCR.

How to Get Document Authoring

To reiterate, DA is still an early-access technology for Edge Delivery Services.

Edge Delivery Services itself is a part of AEM as a Cloud Service, and as of this point in time is a unified offering with AEM as a Cloud Service. So, if you're considering a move to AEM as a Cloud Service (or if you already have it), DA may be an option for you.

If you're already on an implementation Slack with Adobe, ask them about DA and they'll get you going.

You can also reach out on the Adobe Discord, where there's a dedicated DA channel.

Lastly, please do reach out and contact us either on the site, or just directly on Linkedin or Twitter/X. I'd love to tell you my experiences with this!

Or, come see us at Adobe Summit and we would LOVE to give you a demo!

Like what you heard? Have questions about what’s right for you? We’d love to talk! Contact Us

Podcast Episodes & Blog Posts