Trust No One Architectures

A Trust No One Architecture is one where each organizational unit minimizes accidental risk by owning as much of their processes as possible.  Companies end up with a Trust No One architecture where each sub-organization is most likely to meet its' goals if it controls as much of its development, technical and operational processes as possible. Each division / operational unit acts as an independent entity with loose coupling at the edges and just enough cooperation to meet the company goals. 

I recently attended a talk of a Departmental Information Officer for a large bank who said their software process accelerated and their business deliverables came in earlier when they pulled architecture, operations and infrastructure back from the corporate level to the department level. The bank traded costs, standards and duplicate work for time to market and agility. This was in strong opposition to the previous attempt at minimizing risk by centralizing functions.

Trust No One Architectures may be analogous to the agile concept of a cross functional team that owns all aspects of a deliverable. The team owns requirement, development, production, customer satisfaction, security and testing. The organizational team takes ownership of the project's success.  Scale that up to the 100-300 person organization and you end up with a self-contained mini company that attempts to minimize issues around external dependencies.

Tool for self-preservation or sign of organizational dis-function?

I always thought of Trust No One Architectures as a sign of dis-function.  I've come to realize it is really the only way many teams have any hope of meeting their business and technical needs without creating a system of unreasonable complexity and instability. Modern software continues to grow in essential complexity  because of ever expanding business requirements and ever increasing complex interactions.  

Concepts like Enterprise Architecture, Enterprise Services and Centralized Operations cyclically rise up and fall as they crash upon the rocks or organizational realities. Some claim SOA is a technology issue.  Public press tends to mostly describe the failures of SOA as organizational failures. SOA architectures are hard because they are technically hard.  They are brutally hard because they do not align with organizational structures.

Architecture Follows Organization

Developers and organizational anthropologists have known that software product form follows the structure of the organization that creates it.  Conway said this as far back as 1968.  The organization creates the accountability and incentive boundaries. 

Current software  shiny objects include distributed applications and micro services.  People rant about how services Amazon Services are the company's secret sauce.  This only works if people make it completely mandatory in a no if's and's or but's kind of way.  This is can only happen if companies organize around this.  A forward looking distributed architecture cannot be back ported into an existing organizational structure where teams attempt to minimize risk by owning as much as possible.

Orignally written 6/25/2015