Making Legacy SAP Codebases Queryable: ADR Generation from ABAP

The Hardest Test for Queryable Architecture

In Self-Documenting Architecture: When Code Becomes Queryable, I described a pattern where codebases become queryable in natural language - where you can ask "how do these services work together?" and get grounded answers with citations to actual code.

The examples were modern event-driven systems. Clean repos. Good documentation.

But that's not where the pain is.

The pain is in enterprise SAP shops with 8,000+ custom Z-programs accumulated over 18 years. The pain is when your two deepest ABAP experts are retiring next year and nobody documented why anything works the way it does. The pain is staring at a generic error message and spending hours tracing message flows that a senior developer could explain in thirty seconds - if they were still here.

So I tested the pattern on ABAP.

The Setup

SAP publishes a reference implementation called abap-platform-refscen-flight. It demonstrates the Unmanaged RAP (RESTful ABAP Programming) pattern - modern ABAP sitting on top of legacy function modules. It's small enough to understand, complex enough to be realistic.

I ingested it: behavior definitions, behavior pools, CDS views, function modules, the README. The system built code maps - architectural summaries that describe how the pieces connect.

Then I asked a question that any SAP developer working on a brownfield RAP implementation would eventually ask:

The Query

./scripts/outcome-ops-assist "In abap-platform-refscen-flight unmanaged scenario,
  why does the implementation wrap legacy function modules instead of
  implementing CRUD directly in the behavior pools?
  Generate an ADR documenting when to wrap legacy function modules
  versus implementing business logic directly in RAP." --advanced --topK 6

This isn't a code generation request. It's asking the system to reason about architectural decisions embedded in the implementation and produce documentation that captures the "why."

The Output

The system returned a complete ADR. Here's what it produced:

Why This Matters

Look at what the system produced:

Grounded reasoning. Every claim cites a source. The "Dual-Buffer Pattern" reference points to actual code structure. The validation rules table lists specific error codes from the implementation.

Architectural insight. It didn't just describe what the code does. It explained why the pattern exists - legacy investment, buffer complexity, cascade behavior - and when to apply it versus alternatives.

Immediately useful documentation. A developer joining this codebase could read this ADR and understand the architectural intent in minutes. Without it, they'd spend hours reverse-engineering the same conclusions.

In What is an ADR?, I wrote that ADRs document the "why" that lives in places you can't grep: Slack threads, departed engineers, whiteboard sessions. This demonstrates extracting that "why" from the implementation itself.

The Pattern

This isn't magic. It's the same self-documenting architecture pattern, applied to ABAP:

1. Ingest - Pull the repo: behavior definitions, pools, CDS views, function modules, documentation
2. Embed - Convert to vectors with metadata (file type, path, relationships)
3. Map - Generate code maps that summarize architectural structure
4. Query - Ask natural language questions; retrieve relevant context
5. Reason - Synthesize grounded answers with citations

The insight from the original post holds: when systems can explain themselves, organizations stop maintaining documentation and start maintaining understanding.

SAP codebases are notoriously hard to document. They're also notoriously valuable - decades of business logic encoded in custom programs. Making them queryable isn't just convenient. For organizations facing expert attrition, it's strategic.

The Question

The question isn't whether AI can write code. It's whether your systems expose enough context for AI to reason about them accurately.

When they do, the architecture starts explaining itself.