Enterprise Architecture Value Model

There is an uncomfortable reality you need to understand before you decide how to structure your architecture function: the boundary between Enterprise Architecture and Software Engineering is eroding, and the pace of that erosion is accelerating because of technologies like Cloud and AI. The forces driving it are engineering realities, not organizational preferences.

Infrastructure as Code and Platform Engineering

The shift to infrastructure-as-code has moved infrastructure provisioning and configuration management from operational disciplines executed by specialized administrators into software engineering disciplines executed by engineers writing code in version-controlled repositories. An architect who designs an infrastructure topology but cannot write or meaningfully review the code that implements it is working in a medium that is increasingly disconnected from the medium in which architecture actually exists. Platform engineering teams that build internal developer platforms and cloud abstractions are doing work that is simultaneously architectural — making decisions about what the organization’s technology foundations should be — and deeply engineering — building and operating the systems that embody those decisions. The boundary between these disciplines is not a line. It is a gradient, and it is moving toward engineering.

AI-Assisted Development and Vibe Coding

The emergence of AI-assisted development — and specifically Vibe Coding, where large language models generate substantial portions of a codebase from natural language prompts — is compressing the distance between architectural intent and working code. An engineer with strong systems thinking, a clear architectural vision, and facility with AI development tools can now design and implement complex systems at a pace that would previously have required a team of developers. This capability does not belong exclusively to people with the title of architect. It belongs to technically deep practitioners regardless of designation. The competitive alternative to your architecture function is not abstract. It is the technically capable engineering team that can think architecturally and implement architecturally simultaneously.

What Software Engineers Bring to the Architectural Domain

Software engineers who work on complex horizontal and foundational platforms bring a particular combination of capabilities that the traditional architect profile does not always include. They design complex systems — not only at the conceptual level but at the implementation level, where the actual trade-offs between performance, reliability, maintainability, and cost are made real in code. They implement those designs using high-level and often mathematically complex languages and frameworks. They build, package, and deploy the artifacts their designs produce. They instantiate environments, configure systems, and operate them under production conditions. They administer the platforms they build and support the users and systems that depend on them. This full-lifecycle technical fluency — from conceptual design through operational support — is what produces the deepest and most practically grounded architectural understanding. Software engineers who have built and operated complex horizontal platforms at scale have resolved the same cross-cutting trade-offs that architecture is supposed to address at the enterprise level — and they have done it in the most concrete and consequential way possible.

The Implication for Your Architecture Function

If your architecture function is staffed exclusively with practitioners who have never built or operated a complex platform at scale — who have designed systems, advised on systems, and governed systems but never owned one end to end — you have a capability gap that is becoming more consequential as engineering teams develop architectural thinking and AI tools narrow the implementation gap. The recommendation is not that your architecture function should abandon architectural thinking and become an engineering team. The recommendation is that it should develop genuine software engineering capability within its ranks, and that the most effective mechanism for doing so is giving it horizontal platforms to build and operate. The ownership is the training ground as much as it is the organizational objective.