From AEM Complexity to Operational Visibility

For years, I supported the shopping-banner and airport gate-display systems that power parts of Delta's digital and physical customer experience.

The underlying content infrastructure is complex.

A single shopping banner depends on multiple interconnected AEM configurations, rules, and assets distributed across environments. The shopping experience has numerous placements, each with its own set of conditions governing what appears and when.

Airport gate information display screens introduce another layer of complexity, with content configurations spanning multiple airports, placements, date ranges, and display conditions.

All of this information existed.

What didn't exist was a simple way to see it.

The Problem

One of the most common questions from stakeholders was deceptively simple:

"What banners are live on the site right now?"

Answering that question could require manually examining numerous configuration files and AEM locations, cross-referencing content with its associated rules and conditions, and understanding how the different pieces interact.

The underlying configurations could even be misleading.

Content might appear in a configuration file but not actually be displaying to customers because its associated conditions weren't active. Conversely, the system could consider content technically "live" even though its display conditions specified a date range that had already passed.

So there was an important distinction between:

"Is this content active in AEM?"

and

"Is this content actually showing to the customer?"

There was no report that answered that question.

The same problem existed for the airport gate information display screens. Marketing and airport-experience stakeholders needed to know what content was appearing on screens at different airports, but there was no practical way to inspect the entire system at a glance.

The information was there.

The visibility wasn't.

The Opportunity

I recognized that the underlying AEM configuration data contained enough information to reconstruct the actual state of these systems.

The challenge was turning that raw information into something useful.

Working with Kiro, I built dashboards that pull together the relevant configurations and interpret the relationships between them.

Instead of asking a stakeholder — or a content team member — to navigate AEM and understand its underlying architecture, the dashboard presents the information as a visual operating interface.

What had previously required specialized knowledge and significant manual investigation became something that could be understood at a glance.

Shopping Banners Dashboard

The Shopping Banners Dashboard provides a consolidated view of the banners currently configured across the shopping experience.

It brings together information about:

• Active banners
• Placements
• Rules and conditions
• Images
• Date ranges
• Available and occupied slots
• Production and staging environments

Each banner is represented as a visual card, making it possible to see the actual creative alongside the configuration that controls it.

The dashboard also provides direct links back to the relevant AEM locations.

That distinction is important.

The dashboard isn't simply telling someone:

"Here's a problem."

It can tell the content team:

"Here's the problem — and here's exactly where you need to go to fix it."

Comparing Production and Staging

One of the most valuable capabilities is the ability to compare environments.

Production and staging should generally remain synchronized, but over time, small differences can accumulate as configurations are modified in one environment without being mirrored in the other.

The dashboard makes those differences visible.

A comparison view can identify discrepancies between production and staging and provide direct links to the AEM content that needs to be corrected.

That turns an investigation that previously required manually examining multiple configuration files into a visual diagnostic process.

Find the difference. Identify the source. Click directly to the fix.

Airport Display Viewer

The same approach was applied to Delta's airport gate information display screens.

These screens display different content depending on conditions such as time of day, flight status, airport location, and other factors. Multiple content configurations, placements, and display rules interact to determine what appears on any given screen at any given time.

Understanding what is actually configured requires knowing how those pieces interact.

The Airport Display Viewer reconstructs that information into a visual representation of the system.

Stakeholders can see:

• Which content placements are active
• Which placements are available
• What creative is being displayed
• Which airport or location it applies to
• What rules and conditions govern it
• Relevant date ranges
• Production versus staging differences

For stakeholders responsible for marketing and airport experience, this created visibility they had never had before.

They could finally see the state of an environment they could not realistically inspect themselves.

After all, a stakeholder in Atlanta can't simply walk over to an airport in Seattle to see what a particular gate screen is displaying.

The dashboard provides the next best thing: a reliable operational view of what the system is configured to show.

Designing for More Than Experts

As the dashboards grew, so did their capabilities.

Filtering, sorting, comparison, exporting, reference information, and other functions were added over time.

That introduced another problem: complexity itself can become a usability problem.

A tool designed for the content team could easily become intimidating to someone who only needed to answer a simple question.

I therefore built contextual help into the dashboards, including numbered interface explanations, tooltips, reference information, and links to process documentation.

The existing process guides were also incorporated into the dashboards so that the tools became more than a place to view information.

They became a hub for doing the work.

A content author could learn how a particular part of the system works, inspect its current state, identify something that needs to change, and navigate directly to the appropriate AEM location.

The goal was to make the expertise embedded in the system accessible to people who don't work inside that system every day.

From Dashboard to Operational Hub

That evolution is what I find most significant about the project.

The dashboards began as a way to answer questions that were difficult to answer manually.

They became something much more useful: a shared operational interface for a complex content ecosystem.

They provide stakeholders with self-service visibility.

They give content teams diagnostic capabilities.

They provide direct paths from information to action.

And they incorporate the documentation needed to understand the systems themselves.

The result is a single place where people can see, understand, investigate, and act.

Impact at a Glance

The Result

The dashboards fundamentally changed the visibility available to both the content team and its stakeholders.

Questions that previously required hours of manual investigation can now be answered immediately.

The content team can quickly identify differences between production and staging and navigate directly to the source of a discrepancy.

Stakeholders can independently see what content is currently configured across the website, app, and airport display systems without needing someone on the content team to interpret the underlying AEM structure for them.

And perhaps most importantly, leadership noticed.

Following the development of these dashboards, leadership asked me to explore applying the same approach to a broader Messaging Dashboard that could bring together campaign activity across multiple channels — including airport displays, the website, the app, and homepage experiences.

That work is still being developed, but the request itself represents an important outcome:

The dashboards demonstrated that this kind of operational visibility was valuable enough to become a broader organizational capability.

What This Demonstrates

Operational Visibility

Turning complex, distributed system data into an understandable view of what is actually happening.

Information Architecture

Designing an interface that makes relationships between content, rules, placements, environments, and conditions understandable.

Self-Service Enablement

Giving stakeholders the ability to answer questions independently rather than relying on specialized team members.

Process & Knowledge Management

Embedding process documentation, reference material, and contextual guidance directly into the tools people use to perform their work.

AI-Assisted Development

Using Kiro to rapidly transform raw JSON data into increasingly sophisticated operational functionality, iterating on the tools as new needs emerged.

Operational Excellence

Connecting visibility directly to action — so that identifying a problem also provides a path toward resolving it.

The Bigger Lesson

Complex systems don't necessarily need to become simpler internally to become easier to use.

Sometimes the better solution is to create a better layer of visibility over the complexity that already exists.

The AEM infrastructure supporting these experiences remains intricate. The rules, relationships, environments, playlists, and configurations haven't fundamentally disappeared.

What changed is the team's ability to see them.

By transforming raw system data into an accessible operational interface, the dashboards turned an environment that previously required specialized knowledge and extensive manual investigation into something that can be explored, understood, and acted upon.

The information was always there. The dashboard made it visible.

Tools & Technologies