MOHAMMED BOUDOUN.Let’s connect
AEM PLATFORM ENGINEERING · CLOUD · SEARCH · ENTERPRISE AI

SENIOR AEM DEVELOPER & PLATFORM ENGINEER.

I’m Mohammed Boudoun, an Adobe Experience Manager developer and AEM Platform Engineer focused on migrations, headless content, and dependable delivery from Java code to production — and increasingly on the search and retrieval that turn governed content into grounded AI.

View selected work Contact me
ROLESenior AEM Developer · Platform Engineer
FOCUSAEM · Search · Emerging AI
BASED INFrance ↗
SCROLL TO EXPLORE
01THE APPROACH

I engineer AEM platforms.
Not just components.

My work spans application development, platform architecture, infrastructure, and migrations — Java, Sling, OSGi, and Dispatcher alongside Docker, Kubernetes, CI/CD, Dynamic Media, and production operations. AEM is a distributed platform; I treat it like one.

Architecture firstBuilt for the next upgradeDelivery is part of the architecture
02SELECTED WORK

Migrations. Platforms. Delivery.

Explore all work

Anonymized engineering case studies. Real platform thinking.

MIGRATION / COMPATIBILITY / RELEASECASE 01

AEM 6.4 to 6.5 Migration: Compatibility and Release Validation

An AEM 6.4 to 6.5 migration changes more than the runtime. This representative approach treats custom Java code, OSGi dependencies, repository content and Dispatcher behavior as one compatibility boundary, with evidence required before release.

AEM 6.4AEM 6.5Java
UPGRADE / OSGI / CLOUD READINESSCASE 02

AEM 6.5 LTS Modernization: Java, OSGi and Legacy Code Readiness

An AEM 6.5 LTS proof of concept should answer which customizations can move, which need refactoring and what remains unproven. This representative assessment separates Java and dependency compatibility from OSGi service behavior and production-readiness evidence.

AEM 6.5 LTSJavaOSGi
HEADLESS / CONTENT FRAGMENTS / GRAPHQLCASE 03

Headless AEM: GraphQL and Sling Model Exporter Delivery Boundaries

Headless AEM is a choice of content contract, not simply a switch from HTML to JSON. This representative proof of concept compares Content Fragment GraphQL delivery with Sling Model Exporter and identifies what changes for frontend consumers, caching and editorial preview.

Content FragmentsGraphQLSling Model Exporter
DOCKER / DEVELOPER EXPERIENCECASE 04

Dockerized AEM Development: Reproducible Setup and Configuration

A repeatable development environment needs explicit inputs, not merely a Dockerfile. This representative approach versions supporting services and setup steps, separates configuration from image construction, and makes local AEM development assumptions visible.

DockerAEMDispatcher
03MIGRATION JOURNEY

An upgrade is a
platform transformation.

AEM migrations involve far more than a version number: custom code compatibility, dependencies, deprecated APIs, OSGi, Dispatcher, repository validation, and production readiness. No AEMaaCS production migration is represented here.

  1. STARTING BASELINEAEM 6.4

    A mature enterprise estate with custom components, integrations, and Dispatcher-fronted publish environments.

    • Compatibility audit
    • Custom components
    • Dispatcher baseline
  2. PLATFORM MIGRATIONAEM 6.5

    Dependency upgrades, deprecated-API remediation, Oak index and replication validation, and coordinated deployment.

    • Dependency upgrades
    • Deprecated APIs
    • OSGi bundles
    • Regression testing
  3. MODERNIZATIONAEM 6.5 LTS

    OSGi and SCR annotation modernization, legacy component refactoring, and compatibility validation on a supported runtime.

    • Java compatibility
    • OSGi validation
    • Oak indexes
    • Production readiness
  4. AEMaaCS READINESSCloud-ready

    Externalized configuration, reduced environment-specific assumptions, and headless evaluation with cloud-compatible architecture in mind.

    • Modern OSGi patterns
    • Externalized config
    • Immutable deployment
    • Headless readiness
04ARCHITECTURE

Understand the
whole request.

From the browser through the edge, Dispatcher, and Publish tier down to Sling, OSGi, and the repository. Authoring replicates to Publish; supporting services extend delivery. Every layer has a purpose — and every layer is where a problem can hide.

AEM PLATFORM ENGINEERING
REQUEST FLOWFIG. 01
CLIENTBrowserThe user request enters the platform from the edge.
EDGE CACHECDNCached delivery close to the user, offloading origin traffic.
DISTRIBUTIONLoad BalancerTraffic distribution and health-aware routing across the publish tier.
CACHE & SECURITYApache / DispatcherCaching, invalidation, and request filtering in front of Publish.
DELIVERY TIERAEM PublishThe published experience, served under load from the repository.
RUNTIMESling / OSGiBundles, configuration, and the Sling request lifecycle behind every response.
CONTENT & INTEGRATIONJCR / External ServicesOak repository, search, commerce, and downstream integrations.
AUTHORING → PUBLISHFIG. 02
  1. AUTHORINGAEM Author
  2. AGENTS / QUEUESReplication
  3. DELIVERYAEM Publish
SUPPORTING SERVICES
Dynamic MediaContent FragmentsGraphQLElasticsearchCI/CDMonitoring
+ CODE. INFRASTRUCTURE. DELIVERY.
05PLATFORM ENGINEERING

From AEM code
to production infrastructure.

The profile spans application engineering and the infrastructure around enterprise AEM — containers, orchestration, cloud, delivery pipelines, and the monitoring that keeps a platform reliable.

AEM

Java, Sling, OSGi, and HTL delivering the application layer.

Docker

Reproducible, isolated environments and faster onboarding.

Kubernetes

Orchestrated containers, health checks, and resource management.

Azure

Cloud infrastructure hosting supporting platform services.

CI/CD

Predictable, repeatable, auditable delivery pipelines.

Monitoring

Observability and diagnostics across the running platform.

DELIVERY PIPELINE
  1. Commit
  2. Build
  3. Test
  4. Analyze
  5. Package
  6. Containerize
  7. Deploy
  8. Validate
  9. Monitor
06TECHNICAL EXPERTISE

From code to production.

01

AEM

The product surface, across versions.

  • AEM 6.4
  • AEM 6.5
  • AEM 6.5 LTS
  • AEM Sites
  • AEM Assets
  • Dynamic Media
  • Content Fragments
  • Experience Fragments
  • Dispatcher
02

AEM Engineering

Release-capable application code.

  • Java
  • Sling
  • Sling Models
  • OSGi
  • HTL
  • JCR
  • Servlets
  • Schedulers
  • Workflows
  • GraphQL
  • Sling Model Exporter
03

Cloud & Platform

The infrastructure around AEM.

  • Docker
  • Kubernetes
  • Azure
  • Apache
  • Linux
  • Containerized environments
  • Cloud readiness
  • Observability
04

DevOps

Predictable, repeatable delivery.

  • CI/CD
  • Maven
  • Git
  • Automated deployment
  • Quality gates
  • Release engineering
  • Environment management
  • Platform automation
05

Search & Retrieval

Production search, plus emerging retrieval.

  • Elasticsearch
  • Search APIs
  • Filtering
  • Query optimization
  • Content indexing
  • Semantic search
  • Vector search
  • Hybrid retrieval
  • Retrieval pipelines
06

AI Engineering & Exploration

Proofs of concept and architectural exploration.

  • Generative AI
  • RAG
  • Agentic workflows
  • LLM integration
  • Tool calling
  • AI orchestration
  • Knowledge grounding
  • Prompt engineering
  • Evaluation
  • Guardrails
  • MCP
07SELECTED ENGINEERING EXPERIENCE

EXPERIENCE THAT
COMPOUNDS.

12ENGINEERING
PERSPECTIVES

A selection of complex AEM engineering challenges spanning platform modernization, cloud readiness, migrations, search, delivery automation and production architecture — extending into enterprise search, retrieval and emerging AI architecture.

Anonymized, representative engagements — not an employment chronology or a list of verified client projects.

FULL PLATFORM LIFECYCLE
  1. Java
  2. Sling
  3. OSGi
  4. AEM
  5. Dispatcher
  6. Docker
  7. Kubernetes
  8. CI/CD
  9. Cloud
  10. Production

Connected disciplines. No implied chronology.

/ PLATFORM MODERNIZATION

AEM 6.4 → 6.5 Platform Migration

Modernized a legacy AEM platform through a 6.4 to 6.5 migration, treating application code, repository content and request delivery as one system. Remediated deprecated APIs, updated Maven dependencies and resolved OSGi compatibility issues. Validated content integrity and Dispatcher behavior alongside regression analysis before defining production-readiness criteria.

TECHNICAL CONTRIBUTION

Mapped application dependencies, refactored incompatible integrations and built a validation plan covering bundles, content, rendering and cache behavior.

VALIDATION PATH

  1. AEM 6.4
  2. Compatibility
  3. AEM 6.5
  4. Regression
  5. Release readiness
  • AEM 6.4
  • AEM 6.5
  • Java
  • OSGi
  • Dispatcher
  • Maven
  • Migration

/ LONG-TERM SUPPORT

AEM 6.5 LTS Modernization

Designed an AEM 6.5 LTS Proof of Concept to expose compatibility risks before a production upgrade. Validated the Java runtime and OSGi services, refactored legacy components, and replaced deprecated APIs and SCR annotations with OSGi DS patterns. Assessed Oak indexes and Dispatcher behavior through targeted regression testing.

TECHNICAL CONTRIBUTION

Turned compatibility findings into a modernization backlog with explicit acceptance criteria for maintainability and production readiness.

  • AEM 6.5 LTS
  • Java
  • OSGi DS
  • Oak
  • Dispatcher
  • Maven
  • Modernization

/ HEADLESS AEM

Headless Content Delivery Architecture

Architected reusable Content Fragment models for structured, headless delivery through GraphQL, while evaluating Sling Model Exporter for component-oriented JSON. Compared traditional AEM rendering with decoupled frontends against authoring needs, API performance and AEM Cloud architectural constraints. Designed Dispatcher and CDN caching around query shape, content freshness and invalidation boundaries.

TECHNICAL CONTRIBUTION

Defined content contracts and delivery patterns, separating channel-independent content from page composition instead of forcing every use case into one API.

STRUCTURED CONTENT PATH

  1. Content models
  2. Fragments
  3. GraphQL
  4. Cache boundary
  5. Consumers
  • Content Fragments
  • GraphQL
  • Sling Model Exporter
  • Headless
  • Dispatcher
  • CDN
  • AEM

/ CLOUD READINESS

Legacy AEM to Cloud-Ready Architecture

Refactored a legacy implementation toward AEMaaCS readiness by reducing environment-specific assumptions and externalizing configuration. Adopted modern OSGi patterns, reusable Content Fragments and immutable deployment thinking. Evaluated legacy code, deployment automation and Dispatcher portability against cloud-compatible design constraints.

TECHNICAL CONTRIBUTION

Separated deployable code from runtime configuration and documented compatibility gaps that needed resolution before a cloud migration.

  • AEMaaCS Readiness
  • OSGi
  • Cloud
  • Dispatcher
  • Content Fragments
  • Java
  • Architecture

/ CONTAINERIZATION

Dockerized AEM Engineering Environment

Designed reproducible AEM-related development environments with Docker, isolated dependencies and automated setup. Versioned configuration and supporting services made local assumptions explicit and reduced environment drift. Connected setup scripts to CI/CD so onboarding and validation followed the same engineering conventions.

TECHNICAL CONTRIBUTION

Defined container boundaries, configuration inputs and repeatable Maven workflows for consistent local and pipeline execution.

  • Docker
  • AEM
  • Containers
  • Dev Environment
  • Automation
  • Maven
  • CI/CD

/ CLOUD INFRASTRUCTURE

Container Workloads on Azure & Kubernetes

Implemented migration tasks for complementary application workloads moving toward Azure container environments. Defined Kubernetes Deployments and Services, separated configuration through ConfigMaps and Secrets, and validated health and readiness checks. Diagnosed container lifecycle and runtime issues with application and platform engineers during cloud migration validation.

TECHNICAL CONTRIBUTION

Aligned environment configuration, startup behavior and observability with deployment checks so a running container was not mistaken for a ready application.

  • Kubernetes
  • Azure
  • Docker
  • Containers
  • DevOps
  • Cloud
  • Observability

/ DELIVERY ENGINEERING

Enterprise CI/CD Delivery Platform

Architected and improved multiple delivery pipelines spanning Maven builds, automated tests, analysis, packaging and artifact management. Integrated Docker image creation for container workloads with environment deployments and post-deployment validation. Diagnosed failures across these boundaries and made release inputs and quality gates explicit for repeatable delivery.

TECHNICAL CONTRIBUTION

Automated build-to-validation workflows, separated application packages from container artifacts, and made release evidence available at each delivery gate.

DELIVERY LIFECYCLE · CONTAINER WORKLOAD

  1. Commit
  2. Build
  3. Test
  4. Analyze
  5. Package
  6. Containerize
  7. Deploy
  8. Validate
  • CI/CD
  • Maven
  • Docker
  • Git
  • Automation
  • Quality Gates
  • DevOps

/ SEARCH ENGINEERING

Designed an AEM search integration around user-facing site search and faceted filtering requirements. Translated discovery needs into Elasticsearch queries and integration APIs, balancing query performance with relevance and filter behavior. Connected backend contracts to the search experience rather than treating the search engine as an isolated service.

TECHNICAL CONTRIBUTION

Analyzed requirements, implemented Java integration services and optimized query construction, pagination and facet combinations against representative search cases.

  • Elasticsearch
  • AEM
  • Java
  • Search
  • Filtering
  • APIs
  • Performance

/ DIGITAL ASSET DELIVERY

AEM Assets & Dynamic Media Delivery

Integrated AEM Assets and Dynamic Media into a delivery approach spanning DAM workflows, authoring and responsive frontend assets. Defined delivery URL and transformation conventions around image dimensions, format choices and caching. Evaluated CDN behavior alongside editorial workflows, because asset architecture shapes both page performance and the authoring experience.

TECHNICAL CONTRIBUTION

Aligned component image requests with asset metadata and responsive requirements, validating transformations and cache behavior along the delivery path.

ASSET DELIVERY

  1. DAM
  2. Transformations
  3. CDN
  4. Responsive experience
  • Dynamic Media
  • AEM Assets
  • DAM
  • CDN
  • Performance
  • Caching
  • AEM

/ PRODUCTION ENGINEERING

Production Reliability & Platform Diagnostics

Diagnosed complex AEM production behavior by tracing slow requests across the delivery stack, runtime and external API dependencies. Correlated monitoring and logs with Dispatcher cache behavior, OSGi service health, JVM considerations and JCR access patterns to test incident hypotheses. Validated application health after deployments and shared diagnostic reasoning through mentoring, code reviews, pair programming, technical design discussions, client sprint demos and knowledge sharing.

TECHNICAL CONTRIBUTION

Connected request-path evidence to application changes and deployment validation, making troubleshooting decisions reviewable and transferable to other developers.

REQUEST PATH · DIAGNOSTIC VIEW

  1. Browser
  2. CDN
  3. Load Balancer
  4. Apache
  5. Dispatcher
  6. AEM Publish
  7. Sling
  8. OSGi
  9. JCR
  10. External Services
  • AEM
  • Dispatcher
  • OSGi
  • JVM
  • Monitoring
  • Performance
  • Production

/ AI ARCHITECTURE / POC

Enterprise Content RAG & Agentic Search

Designed a Proof of Concept for grounding a large language model in governed enterprise content managed in AEM. The architectural exploration treats structured Content Fragments as a knowledge source: content is exposed through GraphQL and APIs, ingested with its metadata, indexed for search and semantic retrieval, and supplied to an LLM as retrieved context behind an enterprise assistant. Emphasis on source grounding and traceability — every answer should resolve back to the governed fragment it came from — rather than free-form generation.

TECHNICAL CONTRIBUTION

Mapped the content-to-context pipeline end to end: fragment models and metadata as retrieval units, GraphQL and API contracts as the extraction boundary, and a retrieval layer feeding grounded prompts. Defined where governance, freshness and traceability constraints apply. Presented as an architectural PoC and exploration, not a production system.

CONTENT → CONTEXT PATH

  1. Content Fragments
  2. GraphQL / APIs
  3. Ingestion
  4. Search / Vector index
  5. Retrieval
  6. LLM
  7. Enterprise assistant
  • AEM Content Fragments
  • GraphQL
  • RAG
  • Retrieval
  • Semantic search
  • LLM
  • Knowledge grounding

/ AI ARCHITECTURE / POC

Tool-Using Enterprise AI Agent

Explored an agentic architecture in which an LLM orchestrates controlled tool calls against enterprise APIs rather than answering from its own parameters alone. The design investigates structured, validated inputs and outputs, retrieval for grounding, guardrails on what tools may be invoked, and a human-approval step before any consequential action. Evaluated the Model Context Protocol (MCP) as a standard boundary between the model and enterprise tools, keeping capabilities explicit and auditable.

TECHNICAL CONTRIBUTION

Defined the orchestration boundary: tool schemas and validation, retrieval as grounding, guardrails and approval gates, and structured output contracts. Framed evaluation criteria for correctness and safety. Presented as exploration and PoC-level design, with no claim of a production agent deployment.

AGENT ORCHESTRATION

  1. Request
  2. Retrieval
  3. LLM
  4. Tool call
  5. Validation
  6. Human approval
  7. Enterprise API
  • LLM orchestration
  • Tool calling
  • MCP
  • Guardrails
  • Structured output
  • Evaluation
  • Enterprise APIs

From application code to production behavior.
The platform is the responsibility.

Back to section
08ENTERPRISE AI ARCHITECTURE

Content becomes
knowledge.

Structured enterprise content, APIs, and search are increasingly the knowledge layer behind intelligent retrieval and RAG. An architectural exploration — not a production system — of AEM content as governed, traceable context for grounded AI.

ENTERPRISE CONTENT · SEARCH · AI
ENTERPRISE CONTENT → AI CONTEXTFIG. 03 · POC
SURROUNDS EVERY STAGE
  • Governance
  • Security
  • Observability
  • Evaluation
  • Guardrails
GOVERNED CONTENTAEM AuthorEnterprise content authored and governed in AEM.
STRUCTURED CONTENTContent FragmentsStructured, reusable content that becomes a retrieval unit.
EXTRACTION BOUNDARYGraphQL / APIsTyped access to content and metadata for downstream systems.
NORMALIZE & ENRICHIngestionNormalization, chunking, and metadata capture for retrieval.
KEYWORD + SEMANTICSearch / Vector IndexKeyword and vector indexes supporting hybrid retrieval.
GROUNDED CONTEXTRetrievalRelevant, governed context selected per query, with sources.
CONSUMES CONTEXTLLMGrounded in retrieved content — a consumer, not the source of truth.
TRACEABLE OUTPUTEnterprise Assistant / AgentAnswers and actions that resolve back to governed content.
AGENTIC BRANCH
  1. AgentOrchestrates controlled, auditable steps.
  2. ToolsExplicit, validated capabilities.
  3. Enterprise APIsSystems of record, behind guardrails.
+ GROUNDED. GOVERNED. TRACEABLE.
CURRENT FOCUS

Questions I’m working through.

CONTINUOUS LEARNING

Adobe Certified Expert - AEM Developer

Adobe

Issued Nov 2018

Big Data Developer - Mastery Award for Students 2016

IBM

Issued Dec 2015
09BEHIND THE SYSTEMS

Comfortable across
the whole stack.

I’m Mohammed, a Senior AEM Developer and platform engineer based in France. I move between Java code, AEM internals, Dispatcher configuration, Docker, Kubernetes, CI/CD pipelines, and production debugging — and I understand how the pieces connect.

A little more about me
BUILDING OR MODERNIZING AN AEM PLATFORM?

AEM IS A PLATFORM. LET’S ENGINEER IT.

From code to infrastructure to production.

Start a conversation