#process #architecture #organization
idea
Organization, architecture and process influence, enable and limit each other. Any change to one require changes to other.
Organization is how teams are structured and mandated.
Process is how teams work to achieve their mandate.
Architecture is how the product is laid out and how the components relate to each other.
The boundary between organization and process defines and is defined by the control and reporting structure, such as reports and delegation frameworks[6].
The boundary between process and architecture defines and is defined by the automated delivery and control mechanisms such as CI and monitoring.
The boundary between organization and architecture defines and is defined by operational responsibilities and ownership definition.
graph LR
Organization <--> Architecture
Architecture <--> Process
Process <--> Organization
Organization is impacting architecture because of Conway's law[1]. A team will tend to define software that corresponds to its mandate within a single boundary, because it is the easiest - e.g. a front end team will create a front end service. Architecture impacts organization because of the same law. A 3-tier system will tend to produce teams organized in three tiers, a system organized around functional boundaries will produce functional teams, a large tightly-coupled system will produce large co-dependent organizations with lots of programs to synchronize initiatives, effectively making them a single team (which is not a good thing[2]).
Architecture is impacting process in that a set of decoupled microservices can be delivered in short iterations that each bring value, while trying to increase the scope of change in a microservice architecture (either large change in one service or many changes across many services) is riskier and impractical, incentivizing smaller iterations. On the opposite, large and coupled systems are harder to deliver iteratively because of their inertia and cross-dependencies, which increase the cost of transaction[5] and prevent iterations. They will traditionally favor a process which controls large deliveries through dates, i.e. waterfall. Respectively, projects delivered through outcome-oriented objectives and iterations will tend to push for lower transaction cost to increase iteration rate and outcome maximization, therefore favor smaller, decoupled pieces of software. Projects delivered with a fix large scope and far deadlines will tend to deliver more rigid systems.
Organization is impacting process in that co-dependant organizations where goals are output driven[4] and initiatives are spread across several teams will push creation of large programs, which favor upfront planning and design, and control with deadlines (aka waterfall) ; whereas organizations with decoupled teams that are outcome driven will favor team independence and local-maximization of derivative objectives, which themselves are obtained favorably by iterative processes[3], aka lean, agile et. al. Micromanaging organizations will produce defensive processes, while objective-driven organizations will produce outcome-driven processes. Process is impacting organization in a similar way, as iterative processes will force independence of the team running them, while larger projects with long-posted dates will create dependencies across the organization, generally increasing its entire coupling.
You can't change just one, you have to change the three.
links
[2]: Collaboration is celebrated by default in the corporate world, but have tens or hundreds of people working in lock-step is the worst that can happen for productivity.
[4]: Outcome over output should have teams favor organizing around outcome.
[5]: Batch size predicts that higher cost of transactions means bigger batches means larger queues and longer lead times.
Self organizing teams is an example of teams where organization is shifted to the local level, which produce outcome-driven processes and smaller decoupled pieces of software.
[6]: Delegation Framework links an organization to the process
references
[1]: Conway's law on Hacker's Laws and Wikipedia.
Technical boundaries of a system will reflect the structure of the organization
[3]: Sriram Narayan / Outcome Oriented discussed that teams oriented towards an outcome organize to deliver the outcome, whereas teams oriented towards activity... organized towards doing the activity.