I85PREP
⌘ K
AEM Sites Architect Master study materials
AEM Sites Architect Master study resources

Editable Template Governance Across 40 Brand Sites

AEM Sites Architect Master · Put your knowledge to work in context.

All case studies

Editable Template Governance Across 40 Brand Sites

A media company maintains 40 brand sites on AEM 6.5 (soon migrating to Cloud Service). Each site was built by a different agency using its own editable templates. Content authors now report: (1) the same 'Hero' component behaves differently across sites because each template defines its own policy; (2) authors can delete structural components like header/footer because policies allow it; (3) a brand refresh requires touching 40 templates by hand. The platform team wants a shared component library with centrally governed policies, but brands insist on layout freedom. There are 120 authors across brands, and the platform team is 4 people. Migration to Cloud Service is in 9 months.

1. Design a template and policy architecture that balances central governance with brand layout freedom.

Read the worked answer

Layered model:

  1. Core component library owned by the platform team: components (Hero, Header, Footer, etc.) with well-defined dialogs and sensible defaults baked into the component, not into per-template policies.
  2. Base template type (e.g., brand/base/page) that defines the structural skeleton and locks structural components (header, footer, breadcrumb) using cq:actions / locked layout so authors cannot delete them. All brand templates inherit from this base.
  3. Brand template types that extend the base and add brand-specific allowed components and policy overrides only where the brand genuinely differs. Policies for shared components (Hero behavior, image renditions) live in a shared policy container referenced by all brands, so a behavior change is one edit.
  4. Layout freedom is granted through the responsive grid and allowed-component lists per brand, not by forking component behavior.

Rule of thumb: behavior is centralized (component + shared policy), composition is delegated (allowed components, layout). This directly fixes symptoms 1 and 3; symptom 2 is fixed by locking structural containers in the base template.

2. How would you migrate 40 divergent template sets to this model without a big-bang rewrite, given a 4-person team and a 9-month Cloud Service deadline?

Read the worked answer

Inventory → classify → converge in waves.

  1. Inventory (weeks 1–3): script an export of every template's policies and allowed components. Cluster the 40 sites into 3–5 archetypes (e.g., 'editorial', 'campaign', 'corporate'). Most divergence is cosmetic; the clustering reveals the true variation surface.
  2. Build the base (weeks 3–8): platform team builds the base template type and shared policy container; validate against the two most complex brands first.
  3. Wave migration (months 2–7): migrate one archetype at a time. Each brand's templates are re-pointed to inherit from the base; brand-specific deltas become explicit policy overrides. Automate policy diffing so reviewers see exactly what changed per brand.
  4. Freeze + guardrails: new templates must extend the base; CI check rejects templates that don't inherit or that redefine shared policies.
  5. Cloud Service alignment: do the convergence before migration so you migrate one architecture, not 40. Use the Cloud Service refactoring tools and the migration window to retire legacy templates.

Sequencing matters: converging templates first halves the migration surface and prevents migrating technical debt.

3. What governance controls keep this from drifting back to 40 divergent template sets?

Read the worked answer
  • Ownership model: platform team owns base template + shared policies; brand teams own only their allowed-component lists and layout. Documented RACI.
  • Template creation gate: a lightweight review (not a committee) before a new brand template type is approved; reject if it can be expressed as a policy override on the base.
  • Automated conformance check in CI: fail builds where a template doesn't inherit from base or where a shared policy is redefined locally.
  • Policy change log: every shared-policy change is versioned and announced; brands can pin temporarily but must re-adopt.
  • Quarterly drift audit: sample templates, report divergence, and retire unused templates (40 sites accumulate dead templates fast).
  • Author guardrails: locked structural components plus author training so 'I can't delete the header' is expected behavior, not a bug report.