When governance and funding quietly override architecture: a research overview

TL;DR

• The empirical record strongly supports the core thesis: DORA/Accelerate research shows that loosely coupled architecture and team autonomy (the ability to make large changes without permission from outside the team) are among the strongest predictors of software delivery performance, while external change approval bodies (CABs) correlate with worse throughput and NO better stability. Governance and funding structures are the mechanisms through which stated "microservices and autonomy" strategies get quietly reversed.
• Multiple independent research traditions converge: Conway's Law and the "mirroring hypothesis" (MacCormack, Baldwin, Rusnak) show organizational and governance structures get stamped into architecture; the shared-database / "distributed monolith" anti-pattern shows how a shared data store defeats service independence; project (vs product) funding, annual budget cycles, and CABs act as centralizing coupling forces; and organizational-behavior classics (Kerr, Goodhart, Argyris) explain why incentives beat espoused strategy.
• Important nuance: DORA is self-reported survey data with known methodological limits; centralization genuinely helps in some contexts (security, compliance, avoiding duplication); and regulated firms CAN reach elite performance with automated, "compliance-as-code" controls. Several widely repeated statistics (a "73% of microservices migrations fail" figure, some strategy-execution numbers) are folklore or weakly sourced and should not be repeated uncritically.

Key findings

1. DORA's most directly relevant result: formal change approval by an external body (CAB or senior manager) was negatively correlated with lead time, deployment frequency and restore time, and had NO correlation with change fail rate. In the 2019 report, organizations using heavyweight change processes were 2.6x more likely to be low performers.
2. Loosely coupled architecture plus team autonomy is one of the strongest predictors of delivery performance. The specific DORA capability: "teams can make large-scale changes to the design of their systems without the permission of somebody outside the team." ^[1]
3. The mirroring hypothesis is empirically supported: loosely coupled organizations produce significantly more modular products, with coupling differences "up to a factor of eight." The authors explicitly name "governance structures" as one of the constraining forces, which extends the logic beyond reporting lines to funding and procurement.
4. Project-based funding, annual capital cycles and business-case gating are documented coupling mechanisms (Kersten's "Project to Product," Beyond Budgeting, Cagan's product operating model). Empowered teams predictably fail when funding and decision authority stay centralized.
5. Shared databases are the canonical technical expression of the same problem: they create a "distributed monolith" where a schema change ripples across services and independent deployment becomes impossible.
6. Incentives and decision rights beat stated strategy: Kerr's "folly of rewarding A while hoping for B," Goodhart's / Campbell's laws, Argyris's espoused theory vs theory-in-use, and Bain's decision-rights research all point to the incentive/authority layer as the true determinant of behavior.

Details

1. DORA / State of DevOps evidence

The CAB finding (the strongest single data point). The most-quoted result comes from Accelerate (Forsgren, Humble, Kim, 2018), summarizing the DORA program: "We found that external approvals were negatively correlated with lead time, deployment frequency, and restore time, and had no correlation with change fail rate. In short, approval by an external body (such as a manager or CAB) simply doesn't work to increase the stability of production systems, measured by the time to restore service and change fail rate. However, it certainly slows things down. It is, in fact, worse than having no change approval process at all."

The 2019 Accelerate State of DevOps report (the largest of its kind at the time, drawing on data from more than 31,000 professionals over six years) created two constructs: a lightweight, clearly understood change approval process, and a formal heavyweight one. Per the report: "formal change management processes that require the approval of an external body such as a change advisory board (CAB) or a senior manager for significant changes have a negative impact on software delivery performance. Survey respondents were 2.6 times more likely to be low performers." DORA's guidance instead recommends peer review and automated checks ("shift left" on approvals), and reframes the CAB's role toward coordination and strategic sign-off rather than gatekeeping every change.

Architecture and autonomy. DORA's "loosely coupled teams / architecture" capability defines the outcomes: teams "deploy and release their product or service on demand, independently of the services it depends on"; "do most of their testing on demand, without requiring an integrated test environment"; and, crucially, "can make large-scale changes to the design of their systems without the permission of somebody outside the team or depending on other teams." Accelerate found loosely coupled architecture was among the strongest predictors of continuous delivery and deployment frequency, independent of process or culture. ^[1]

2024 report (10th edition). Key findings relevant here: internal developer platforms (IDPs) deliver, per the 2024 DORA Accelerate State of DevOps report, "8% higher individual productivity" and "10% improved team performance" (and roughly a 6% increase in overall organizational performance) but this is offset by "an 8% decrease in throughput and 14% decrease in change stability." In other words, platforms help individuals and teams feel and perform better locally, but can slow and destabilize delivery if they are not built for developer independence and self-service. The report stresses "platform-as-product" and user-centricity. It also found AI adoption at that point correlated with small productivity gains but slight declines in delivery throughput and stability (larger batch sizes were a mechanism). ^[2]

2025 report ("State of AI-assisted Software Development," nearly 5,000 respondents). Headline: AI is an amplifier, not a fixer. Per DORA, "AI's primary role in software development is that of an amplifier. It magnifies the strengths of high-performing organisations and the dysfunctions of struggling ones." Platform quality is the difference-maker: "90% of organizations have adopted at least one platform," and roughly three-quarters have dedicated platform teams; high-quality platforms amplify AI's benefits while low-quality platforms see negligible benefit. The 2025 edition replaced the four-tier performance model with seven team archetypes via cluster analysis. ^[3]

Budget/funding autonomy specifically. DORA does not publish a clean, dedicated finding on "permission to spend" as a bottleneck; the closest empirical touchpoints are the CAB/approval findings and the autonomy capability. This is a genuine gap: the funding-autonomy link is strong in practitioner literature but not yet a headline DORA metric.

2. Funding models and architecture

Project vs product funding (Mik Kersten, "Project to Product," 2018). Kersten argues project-oriented management, cost-center budgeting and org charts are mismatched to software. Named concepts: the "watermelon" project (green outside, red inside) and the "project end fallacy," where cost-center accounting forces a focus on cost reduction after launch. He identifies structural differences across budget, teams, success criteria, prioritization, risk, visibility and timelines: project funding forces all learning and specification up front (a waterfall driver) and incentivizes teams to "ask for everything they might need upfront." The Flow Framework proposes funding persistent value streams rather than temporary projects. ^[4]

Beyond Budgeting (Bjarte Bogsnes). Originated before the Agile Manifesto; Borealis abolished its traditional budget in 1995, and Bogsnes later led implementations at Statoil/Equinor. The argument (his "roundabout vs traffic light" metaphor): people at the front line have fresh information but, in traditional management, "you don't have the authority to act on that information. That lies with somebody else." Beyond Budgeting favors decentralized, rolling/relative targets over fixed annual budgets. Evidence base is largely case-based and practitioner-driven rather than controlled study. ^[5]

Product operating model (Marty Cagan, SVPG; "EMPOWERED" 2020, "TRANSFORMED" 2024). Cagan's core point maps directly onto the thesis: empowered teams fail without funding and decision authority. He wrote TRANSFORMED after product managers told him they wanted to be product-led "but did not have any authority to do so." The most substantive criticism he acknowledges: "The only people that matter are the execs. They set rules, they create systems, they control what gets built by controlling what gets funded." Empowerment fails without trust, strategic context, and control over funding. ^[6]

Annual capital cycles / business cases as coupling. McKinsey's "agile funding" work describes quarterly business reviews (QBRs) as the mechanism agile firms use to create portfolio transparency and shift funding, including a "kill rate" for stopping low-value work. The practitioner consensus: annual capital allocation forces teams to batch work and front-load specification.

3. Conway's Law and the mirroring hypothesis

Original (1968). Melvin Conway, "How Do Committees Invent?" (rejected by Harvard Business Review, published in Datamation, April 1968). The law: "Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure." Corollary: "To the extent that an organization is not completely flexible in its communication structure, that organization will stamp out an image of itself in every design it produces." Fred Brooks named it "Conway's Law" in The Mythical Man-Month.

Microsoft / Windows Vista study. Nagappan, Murphy and Basili, "The Influence of Organizational Structure on Software Quality: An Empirical Case Study" (MSR-TR-2008-11; ICSE 2008). Organizational metrics (e.g., number of engineers, edits, org distance) applied to Windows Vista binaries were statistically significant predictors of failure-proneness, with precision and recall significantly higher than traditional metrics like code churn, complexity, coverage, dependencies and pre-release bugs.

Mirroring hypothesis (MacCormack, Baldwin, Rusnak). "Exploring the Duality between Product and Organizational Architectures: A Test of the 'Mirroring' Hypothesis" (HBS working paper 08-039, 2008; Research Policy 41(8), 2012, pp. 1309-1324). Comparing products of similar function built by tightly coupled firms vs loosely coupled open-source communities, they found "strong evidence": loosely coupled organizations produced significantly more modular designs, with differences "up to a factor of eight, in terms of the potential for a design change in one component to propagate to others." Crucially, the authors attribute mirroring to the fact that "the organization's governance structures, problem solving routines, and communication patterns constrain the space in which it searches for new solutions" — explicitly naming governance, which supports extending the hypothesis to funding and procurement structures. ^[7]

4. Shared database as a coupling mechanism

Martin Fowler's enterprise integration writing traces a maturity line from file transfer through shared database and RPC to messaging, with a shared database being convenient (immediate updates, common schema) but a source of coupling; messaging offers fuller decoupling. Practitioner literature is near-unanimous that a shared database defeats microservice independence: "All services connect to a single database and share tables... they bypass each other and communicate through the database instead of APIs... Any schema change affects all services." The result is a "distributed monolith": services that must be deployed together and where changes ripple across the system, combining "the rigidity of monoliths with the operational overhead of distribution." A common litmus test: if you can't deploy Service A without also deploying Service B, you have a distributed monolith, not microservices. ^[8][9]

There is legitimate counter-nuance: some architects argue a shared database is a valid trade-off for specific cases (read-only reporting/BI, temporary migration states, strong-consistency needs), and that calling it a universal anti-pattern is itself harmful.

Survey data. O'Reilly's "Microservices Adoption in 2020" (released July 16, 2020; 1,502 respondents) found 77% had adopted microservices and 92% reported some success; teams that owned the full build-test-deploy-maintain lifecycle succeeded at a rate 18% higher than those who did not, and 74% said their teams owned the full lifecycle. The biggest barriers were complexity (56%) and corporate culture/mindset (40%). IBM's "Microservices in the Enterprise, 2021" (1,200+ respondents) found 87% of users said adoption was worth the expense and effort. Importantly, no reputable named survey found publishes a clean single percentage for "share of microservices organizations that share a database"; that specific number is not well quantified and should be treated as an evidence gap. Documented reversions to monoliths exist as named cases (see section 8) but are individual engineering decisions, not evidence that microservices fail at scale.

5. Change advisory boards and ITIL

DORA's evidence (above) is the core empirical finding on CAB ineffectiveness. The mechanism DORA cites: CABs are "good at broadcasting change, but people that far removed from the change might not understand the implications"; they tend to treat all changes equally regardless of risk. Value-stream mapping practitioners consistently find that wait/queue time (including approval queues) dominates total lead time, though a single canonical statistic is hard to pin to one primary source and should be presented as a well-established practitioner observation rather than a precise figure. ITIL 4 has softened its stance, moving toward "change enablement" and acknowledging that high-performing delivery uses peer review and automation rather than a standing board for every change.

6. Governance and incentives overriding stated strategy

Strategy-execution gap. Sull, Homkes and Sull, "Why Strategy Execution Unravels — and What to Do About It" (HBR, March 2015), based on a multi-year study of over 250 companies (and surveys of many thousands of managers): "Two-thirds to three-quarters of large organizations struggle" to execute strategy. Their central, counterintuitive finding is that the problem is usually NOT vertical alignment but horizontal coordination across units and the inability to adapt. (Caveat: the "60-90% of strategies fail" family of statistics that circulates online is often traced to Kaplan and Norton or Bridges Business Consultancy and is frequently weakly sourced or misquoted; the Sull et al. "two-thirds to three-quarters struggle" figure is the most defensible.)

Incentives beat intent. Steven Kerr, "On the Folly of Rewarding A, While Hoping for B" (Academy of Management Journal, 1975; updated 1995): organisms "seek to do (or at least pretend to do) those things" that are rewarded, "often to the virtual exclusion of activities not rewarded." Goodhart's Law ("when a measure becomes a target, it ceases to be a good measure") and Campbell's Law reinforce this. Argyris and Schön's distinction between "espoused theory" (what an organization says it values) and "theory-in-use" (what its systems actually reward) is the academic frame for "strategy as decoration."

Decision rights. Rogers and Blenko, "Who Has the D? How Clear Decision Roles Enhance Organizational Performance" (HBR, January 2006; Bain's RAPID framework): decisions stall at bottlenecks including "center versus business unit" and "inside versus outside," and clear decision roles are "the defining characteristic of high-performing organizations." Bain's associated research links decision effectiveness to financial performance. This is the general-management analogue of DORA's autonomy finding: the locus of authority (including budget authority) determines speed and quality of execution.

Team Topologies (Skelton and Pais, 2019). Formalizes the "inverse Conway maneuver": deliberately design team boundaries to match the desired architecture, rather than mandating an architecture and hoping teams follow. Core concepts: managing team cognitive load, stream-aligned teams owning a value stream end to end, and platform teams providing self-service "paved roads." Their warning captures the thesis precisely: "the communication paths and incentives in the organization will end up dictating the software architecture." ^[10]

7. Counter-evidence and nuance

• The case FOR centralization. Centralized platforms and governance demonstrably help with security, regulatory compliance, cost control and avoiding duplicated spend; DORA's own 2024/2025 platform findings show IDPs raise individual and team productivity (even as they can dent throughput and stability). Uncontrolled autonomy produces fragmentation, duplicated tooling and inconsistent standards. The mature answer in the literature is federated governance / "aligned autonomy" (autonomy within guardrails), not a binary.
• Spotify's model is widely misunderstood. The squad/tribe model was aspirational and never fully implemented. A former insider's critique, Jeremiah Lee's "Spotify's Failed #SquadGoals" (self-published, April 2020), argues the model "fixated on team autonomy" without sufficient alignment and accountability. A Spotify agile coach who co-authored the original whitepaper, Joakim Sundén, is quoted admitting: "Even at the time we wrote it, we weren't doing it. It was part ambition, part approximation. People have really struggled to copy something that didn't really exist." This is a caution against copying autonomy structures without the supporting governance. (Note: some secondary sources misattribute the "Failed Squad Goals" critique to an MIT Sloan article by other authors; the authentic primary source is Jeremiah Lee's personal site.)
• DORA methodology caveats. DORA relies on self-reported survey data, convenience/snowball sampling, and cluster analysis to define performance tiers. Correlation is not causation; respondents self-select; and the metrics are best applied per-application, not blended across an organization. The findings are robust and repeatedly replicated within the program, but should be presented as strong correlational evidence, not experimental proof.
• Regulated firms CAN be elite. DORA data has included highly regulated industries (financial services, government) among high performers; the path is "compliance as code," automated change controls, and lightweight peer review that satisfies auditors without a standing board. The 2019 report specifically noted large enterprises struggle largely because of heavyweight processes, not because regulation makes elite performance impossible.

8. Case examples

• Amazon — "you build it, you run it." Werner Vogels, in "A Conversation with Werner Vogels" (ACM Queue, 2006): "Giving developers operational responsibilities has greatly enhanced the quality of the services... You build it, you run it. This brings developers into contact with the day-to-day operation of their software... Each service has a team associated with it, and that team is completely responsible for the service — from scoping out the functionality, to architecting it, to building it, and operating it." Combined with the "two-pizza team" sizing rule (no team larger than can be fed by two pizzas, designed to increase ownership and single-threaded focus), this is an explicit organizational/governance mandate, not merely a technical one. (The "Bezos coined two-pizza teams" origin is well-established lore rather than a single documented quote.)
• ING Bank. McKinsey Quarterly, "ING's agile transformation" (January 2017), interviewing CIO Peter Jacobs and former COO Bart Schlatmann. Per Schlatmann, ING's "initial focus was on the 3,500 staff members at group headquarters," reorganized into "about 350 nine-person 'squads' in 13 so-called tribes" in 2015, with a quarterly business review (QBR) borrowed from Google and Netflix as the funding/governance rhythm. Schlatmann: "It requires sacrifices and a willingness to give up fundamental parts of your current way of working — starting with the leaders" (top leaders gave up private offices and reserved parking; the layer below had to re-apply for their jobs).
• Adidas platform engineering. Per the Kubernetes.io adidas case study: "Just six months after the project began, 100% of the adidas e-commerce site was running on Kubernetes. Load time... was reduced by half. Releases went from every 4-6 weeks to 3-4 times a day. With 4,000 pods, 200 nodes, and 80,000 builds per month, adidas is now running 40% of its most critical, impactful systems on its cloud native platform." Senior Director of Platform Engineering Daniel Eichten framed the platform team's purpose as enabling internal developer autonomy, contrasting the prior state where getting a developer VM could take "half a week or sometimes even a week."
• Documented reversions to monolith (nuance, not thesis-support). Prime Video's Video Quality Analysis team (Marcin Kolny, Prime Video Tech blog, March 22, 2023, "Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%"): "Moving our service to a monolith reduced our infrastructure cost by over 90%. It also increased our scaling capabilities." Twilio Segment publicly collapsed 140+ microservices back into a monolith after developer productivity declined. Both are decisions about specific systems, not company-wide abandonment of microservices, and were widely misreported as the latter.
• Failure pattern. The recurring failure case in the literature is an organization that changes its architecture (adopts microservices) without changing funding or governance: it keeps the shared database, the annual project budget and the CAB, and ends up with a distributed monolith that is harder to operate than the system it replaced — combining the coupling of a monolith with the overhead of distribution.

Recommendations

1. Diagnose the incentive layer first, not the architecture. Before (or alongside) any microservices or platform initiative, map where budget authority, change approval and data ownership actually sit. If a team cannot make a large design change without outside permission, cannot deploy without a CAB, and cannot change a table without coordinating with other teams, the architecture strategy is decoration. The threshold that should trigger action: any deployment that requires sign-off from a body outside the delivering team.
2. Move from project to product funding incrementally. Fund persistent teams/value streams with rolling or quarterly allocation (QBR-style) rather than annual project business cases. Benchmark: track the share of work funded as persistent product capacity vs one-off projects, and a "kill rate" for stopped low-value work. If lead time is dominated by approval/queue wait rather than hands-on work, that is the signal to attack the funding gate.
3. Replace the CAB with lightweight, automated controls. Shift to peer review plus automated policy/compliance checks in the pipeline ("compliance as code"); reserve any board for genuinely high-risk, cross-cutting decisions. Watch change fail rate and MTTR: DORA's evidence says these should not worsen (and throughput should improve) when you remove external approval.
4. Break the shared database deliberately. Treat data ownership as a governance decision, not just a schema decision. Use the "can Service A deploy without Service B?" litmus test as an ongoing fitness function. Accept shared data only for explicit, bounded cases (read-only reporting, temporary migration).
5. Design teams for the architecture you want (inverse Conway), and give them the "D." Align team boundaries, cognitive load, decision rights AND budget to the desired service boundaries. Autonomy without alignment (the Spotify caution) is as damaging as central control.
6. Preserve federated guardrails. Do not swing to unbounded autonomy. Keep centralized standards for security, compliance and shared platforms, delivered as self-service paved roads, so autonomy operates within guardrails. Note the DORA 2024 signal that platforms can reduce throughput and stability if imposed rather than built as user-centric, self-service products.

Caveats

• DORA is correlational, self-reported survey data with convenience sampling; treat its findings as strong, repeatedly replicated evidence rather than experimental proof.
• Much of the funding-model literature (Beyond Budgeting, Project to Product, Cagan) is practitioner argument and case study, not controlled research; it is persuasive and internally consistent but should be labeled as such.
• Several popular statistics are folklore or weakly sourced: a widely shared "73% of microservices migrations fail or become distributed monoliths" figure traces to a blog with no underlying survey (and appears to be a corruption of a real LightStep/Dimensional Research finding that 73% of enterprises found it harder to report problems); "42% reverting to monoliths (CNCF 2025)" and "60% regret microservices (Gartner)" appear only in SEO blogs and could not be verified; and the broad "70-90% of strategies fail to execute" family is often mis-attributed. The defensible strategy-execution figure is Sull et al.'s "two-thirds to three-quarters of large organizations struggle."
• The specific quantity "what percentage of microservices adopters still share a database" is not cleanly quantified by any reputable named survey found; state it as an evidence gap rather than citing a number.
• Reversion-to-monolith cases (Prime Video, Segment) are individual engineering decisions about specific systems, not proof that microservices or autonomy fail in general.
• The DORA 2024 IDP figures (roughly +8% individual productivity, +10% team performance, offset by around -8% throughput and -14% change stability) come from a single report wave; treat the exact percentages as point estimates from correlational data, not durable constants.

1. Medium — https://medium.com/solheimsviken/autonomy-and-devops-in-organizations-of-scale-c91d4fc30333
2. User's blog — https://us.nimbleevolution.com/dora-2024/
3. Axify — https://axify.io/blog/state-of-devops
4. Eatingpolicy + 2 — https://www.eatingpolicy.com/p/project-vs-product-funding/comments
5. LinkedIn + 3 — https://www.linkedin.com/pulse/purpose-beyond-budgeting-create-more-agile-human-says-naresh-jain?trk=portfolio_article-card_title
6. Aakash Gupta — https://www.news.aakashg.com/p/transformed-product-operating-model-marty-cagan
7. Harvard Business School — https://www.hbs.edu/faculty/Pages/item.aspx?num=43260
8. Medium — https://medium.com/@subham11/the-shared-database-anti-pattern-c87013d2dcb2
9. MerginIT e.U. — https://merginit.com/blog/31102025-microservices-antipattern-distributed-monolit
10. IT Revolution — https://itrevolution.com/articles/conways-law-critical-for-efficient-team-design-in-tech/