About

Why does an Enterprise Architect build software?

In my consulting practice I audit IT landscapes and rationalize technology portfolios for large organizations. The greatest threat to enterprise agility today is, in my experience, architectural gridlock, i.e. application and data landscapes that are too fragmented to be maintained, too complex to be modernized and too disjointed to adapt to a fast changing business environment.

I build software as architectural theses, and SwarmCoder is the current one. It is an agentic coding system for organizations that need proper traceability on their software development, and it is meant to show that AI can be brought into a delivery lifecycle safely, with mechanical governance and human guardrails, rather than the work being thrown over the wall to an agent that reinvents its process on every run.

It also addresses an economic risk that is architectural in nature. Frontier tokens are currently sold below cost, and organizations are building their delivery pipelines on that pricing as if it were permanent. When it corrects, the cost of building software becomes a number that somebody else sets, and by then the dependency is load bearing. The architectural answer is to treat token economics as a design constraint now, so SwarmCoder confines the frontier spend to a few capped judgment calls and runs the volume on hardware you own, which mitigates the correction, whenever it comes, as much as possible.

It is built on ZeroZ4j, my zero impedance Java stack, and seen from ZeroZ4j's side SwarmCoder is its demonstration project. Both make the same point, which is that whether you are working at the software architecture level or the enterprise application level, the path forward is generally to unify and simplify your architecture.