This deep dive expands on the Loop Asia conversation with Nilesh Gule, Enterprise Architect, Microsoft MVP, and Docker Captain.

Nilesh Gule mentioned Conway's law almost in passing on this episode of The Loop Asia, describing two organisations that solved the same DevOps problem two different ways. It deserves more weight: an organisation's systems mirror its communication structure, whether anyone designs it that way or not.

Two working models, two different org charts

At a mid-size insurance company in Singapore, a shared services team built reusable infrastructure — Terraform modules — that business units consumed as building blocks. Teams in Singapore and Indonesia each assembled their own infrastructure from those shared components, independently. Call it shared-plus-democratic: one team builds the primitives, everyone else keeps the decisions.

At a large bank, also in Singapore, an enterprise SRE team owned the tooling layer outright — source control platform, CI server, Jenkins or Bitbucket, decided centrally — while a DevOps team inside each business unit customised how those tools got used day to day. Centralised infrastructure, decentralised practice.

Neither model is more mature. Which one an organisation ends up with traces less to strategy than to how it was already structured before anyone thought about DevOps. Most organisations inherit their platform topology — reporting lines, historical mergers, whatever autonomy finance or compliance already granted. By the time a CTO notices the platform team isn't working, the org chart has usually written the architecture for years.

Reading your own organisation against the two models

The insurance model works when business units are autonomous enough that local judgment calls carry real value — Jakarta and Singapore won't make identical decisions, and forcing them to would slow both down. Its cost is drift: teams building from the same modules diverge, over time, into environments too different to reason about centrally. The bank's model works when divergence is the bigger risk instead — regulatory reporting, audit trails, a security posture that must be provably consistent — at the cost of speed: a unit wanting a different tool queues behind the SRE team.

The question a Technical Champion needs to answer isn't which model is better in the abstract. It's which failure mode the organisation can tolerate less — drift, or a bottleneck. That's an organisational design question wearing a technology costume, which is exactly why it tends to get delegated rather than decided deliberately at the top.

Where this becomes urgent, not academic

This stops being theoretical the moment a core system is up for replacement — a billing platform, a customer data store, a source control migration deferred for years. At that point the topology question decides whether the replacement ships on the timeline the board was told, or quietly doubles in scope because nobody decided who owns which decisions.