Config-as-architecture

When XML, YAML, and low-code graphs replace design decisions — until the config becomes the unmaintainable system.

Config-as-architecture is the enterprise tradition of hiding design in files too large to code-review. Spring XML, ESB routes, Terraform stacks, BPMN diagrams, low-code graphs — all can be legitimate tools, and all can become a shadow codebase owned by nobody who understands git blame.

The pattern thrives where buying is easier than hiring. A consultant can deliver ten thousand lines of XML that "wire services together" faster than a team can write explicit modules with tests. For a while, change requests flow through a integration team that speaks WSDL. Then the original authors leave, the tooling rots, and every change is archaeology with a IDE that validates syntax but not intent.

UML-everywhere and waterfall-big-design were cousins of this failure: diagrams and documents treated as the product instead of running software. DevOps partially fixed packaging but sometimes recreated the problem in YAML — infrastructure as architecture theater without service ownership.

Healthy config is thin: it declares environment differences and leaves business logic in code with tests. Unhealthy config is where the if-statements went to retire — and where outages hide until someone toggles a flag nobody documented.

Exhibits

← All patterns

© 2026 Fadstack · Shane Code

Opinionated history · not a ranking