Architecture usually fades after delivery
Making Data Architecture Part of CI — How MDDE turns architectural intent into continuous guarantees.
Architecture usually fades after delivery
Most data architectures are strongest at the start of a project.
- Decisions are discussed.
- Diagrams are drawn.
- Guidelines are agreed upon.
Then delivery accelerates — and architecture slowly fades into the background.
- New queries appear.
- Exceptions accumulate.
- Rules become optional.
The problem is not intent.
It’s the lack of continuous enforcement.
MDDE addresses this by treating architecture as something that runs — not something that is reviewed once.
This article explains how MDDE-style architecture integrates naturally into CI pipelines.
What CI should protect (but often doesn’t)
Typical CI pipelines for data projects focus on:
- Syntax checks
- Unit tests
- Linting
- Build success
What they rarely protect is:
- Semantic consistency
- Architectural decisions
- Deterministic behavior
- Migration safety
As a result, architectural drift happens quietly — even in well-managed projects.
MDDE expands the scope of CI to include architectural correctness.
The MDDE CI loop
At a high level, the CI loop looks like this:
Metadata changes
→ SQL generation
→ Rule validation
→ Regression comparison
→ Diagnostics output
If any architectural invariant is violated, the pipeline fails early — before deployment.
Step 1 — Validate metadata
CI starts with intent.
mdde validate metadata/
This checks:
- Schema consistency
- Required attributes
- Referential integrity
- Semantic completeness
If metadata is invalid, nothing else runs.
This prevents downstream ambiguity.
Step 2 — Generate SQL deterministically
mdde generate sql --engine postgres
CI never runs against hand-written production SQL.
Generated SQL is:
- Deterministic
- Reproducible
- Comparable
Changes in SQL always trace back to changes in metadata, rules, or templates.
Step 3 — Enforce executable rules
mdde validate rules
Rules run automatically:
- No SELECT *
- Explicit joins
- Deterministic filters
- Naming conventions
Violations fail fast.
Not because someone disagrees — but because the architecture does.
Step 4 — Run regression tests
For migrations or significant refactoring:
mdde compare \
--source legacy.sql \
--target generated.sql
Regression checks include:
- Structural equivalence
- Semantic alignment
- Result comparison (where applicable)
This shifts migration confidence from belief to evidence.
Step 5 — Emit diagnostics as artifacts
Every CI run produces diagnostics:
{
"entity": "sales_summary",
"rules_passed": 12,
"rules_failed": 0,
"regression": "equivalent",
"sql_hash": "9a7f..."
}
These artifacts:
- Are stored
- Can be compared over time
- Provide auditability
Architecture becomes observable across commits.
Failing for the right reasons
One of the most important benefits of architectural CI is how it fails.
Failures are:
- Deterministic
- Explainable
- Actionable
They point to:
- Which decision was violated
- Which rule failed
- Which assumption changed
This removes ambiguity from reviews and accelerates resolution.
CI changes team behavior
Once architecture runs in CI:
- Reviews focus on intent, not formatting
- Discussions move to ADRs instead of opinions
- Exceptions become explicit decisions
- Drift becomes visible early
Architecture stops being something people “try to follow”.
It becomes something the system enforces.
Start with one invariant
You don’t need full MDDE CI on day one.
Start with:
- One rule
- One generated query
- One regression comparison
Add invariants as pressure increases.
CI scales architecture incrementally , just like code.
What’s next
In the next articles, I’ll cover:
- Rule design patterns (what makes a good rule)
- Handling exceptions without breaking discipline
- Evolving ADRs without freezing architecture
- Metadata versioning and compatibility
- When CI should block — and when it should warn
All focused on the same goal: architecture that remains correct under continuous change.