AXS + AEM: Bridging Engineering and the Business

Context

Even with a strong design system, a major gap remained. AXS primarily served developers. Business users, marketing, content teams, relied on AEM. Engineers built reusable components; business users couldn’t easily leverage them. The result: slower content delivery, inconsistent experiences, and continued reliance on engineering for execution that should have been self-service.

The front-end platform needed to connect to the business content ecosystem. Not as integration trivia, but as the next stage of the platform’s value.

My role

I played a key role in defining and implementing the AXS → AEM integration. Designed the technical model, influenced how components are delivered inside AEM, and positioned AXS as a business enablement platform rather than just a developer system.

What I did

Established the integration model.

• AXS UI library deployed into AEM.
• AEM templates consume AXS web components directly.

The rule: AXS owns the components. AEM declares them in templates. AEM stays thin; the design system stays the source of truth. Consistency across every touchpoint by construction, not by review.

Enabled business users to leverage engineering assets. AXS components integrated into AEM so marketers and content creators use pre-built components without needing custom engineering. The phrase that came out of the rollout: put the design system at the fingertips of the business.

Delivered consistent experiences across channels. The same AXS components power applications, marketing pages, and content experiences. One visual layer. Cross-channel consistency without a separate effort to enforce it.

Scaled content delivery through platformization. Business teams build pages from reusable components and deliver content faster, without engineering bottlenecks.

Connected the design → engineering → content flow. AXS component library + Figma design system + AEM templates aligned to a single mental model. No re-interpretation between stages. No duplicate implementations of the same component for different audiences.

Resistance

AEM architecture complexity. AEM has its own component model and rendering constraints. Integrating a modern design system into AEM is non-trivial and required a clean abstraction strategy.

Organizational boundaries. Traditional model: engineering builds, marketing requests. Moving to marketing self-service via AXS required trust, new workflows, and behavior change on multiple sides.

Competing approaches. Other groups explored different AEM component architectures. Without a clear shared direction, the experience would have fragmented across Vanguard.

How I handled it

Simplified the integration model into a single principle, AXS owns components, AEM consumes them, and eliminated the ambiguity that usually kills cross-system integrations. Framed the work in business outcomes (speed to market, consistency, scalability) rather than technical elegance. Drove alignment through practical implementation, demos, walkthroughs, socialization, not just architecture diagrams.

Outcome

• Business enablement at scale. Marketing and content teams use AXS components directly in AEM. Engineering dependency reduced for content work.
• Faster content delivery. Reusable components → faster page creation. No more custom builds for templated content.
• Cross-channel consistency. Same components across apps, AEM pages, and digital experiences. One visual layer, by construction.
• Stronger ROI from AXS. No longer a developer tool, a business platform with measurable impact.
• Foundation for future innovation. This integration is what makes personalization at scale, AI-driven content generation, and dynamic component-driven experiences possible.

Why it matters

This is where the work transcends engineering. Converting a design system into a business capability is what separates a library from a platform.

• From engineering efficiency → to enterprise enablement.
• Non-engineers can ship on-brand digital experiences.
• The organization moves faster without scaling engineering cost linearly.

The arc continues: the same component primitives that supported multi-framework apps in Chapter 3 now serve marketing and content. That compounding is the whole point of building framework-agnostic from the start.