Architecture Diagrams as Political Documents: Research Compilation
A research brief compiled for a Director of Technical Strategy at a healthtech company, supporting a LinkedIn post arguing that enterprise architecture diagrams function as political documents rather than purely technical ones. Organized by theme; primary sources prioritized; quotes preserved verbatim with attribution.
THEME 1: CONWAY'S LAW IN PRACTICE
1.1 The Original 1968 Paper
Citation: Conway, M. E. "How Do Committees Invent?" Datamation, Vol. 14, No. 4, April 1968, pp. 28–31. PDF: [1]
Provenance: Submitted to Harvard Business Review in 1967; HBR rejected it on grounds [2] that Conway "had not proved [his] thesis." [3][4] Conway has said publicly: "In retrospect, HBR's basis for rejecting the paper says more about differences in notions of 'proof' than it does about the paper." [4] The paper was then published in Datamation [4][5] (the major IT trade journal of the era). [2] Fred Brooks popularized the name "Conway's Law" in The Mythical Man-Month [6][7] (1975, p. 111). [6] Conway was Manager of Peripheral Systems Research at Sperry Rand UNIVAC at the time; he had previously coined the term coroutine [8] (1958).
Exact wording (p. 31, "Conclusion"):
"The basic thesis of this article is that organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations. Wikipedia +2 We have seen that this fact has important implications for the management of system design. Primarily, we have found a criterion for the structuring of design organizations: a design effort should be organized according to the need for communication." [1]
On bias being baked into team structure (p. 28):
"The very act of organizing a design team means that certain design decisions have already been made, explicitly or otherwise. Given any design team organization, there is a class of design alternatives which cannot be effectively pursued by such an organization because the necessary communication paths do not exist. Therefore, there is no such thing as a design group which is both organized and unbiased." [1]
Conway's later reflection (cited in Team Topologies):
"Is there a better design that is not available to us because of our organization?"
Worked example from the paper: "A contract research organization had eight people who were to produce a COBOL and an ALGOL compiler. After some initial estimates of difficulty and time, five people were assigned to the COBOL job and three to the ALGOL job. The resulting COBOL compiler ran in five phases, the ALGOL compiler ran in three." [1]
1.2 MacCormack, Baldwin & Rusnak — The Mirroring Hypothesis (HBS)
Canonical paper: MacCormack, A., Baldwin, C., & Rusnak, J. (2012). "Exploring the Duality Between Product and Organizational Architectures: A Test of the 'Mirroring' Hypothesis." Research Policy 41(8): 1309–1324. DOI: 10.1016/j.respol.2012.04.011. PDF on Harvard DASH: [9]
Method: Matched-pair natural experiment. Paired commercial software products (developed inside firms with tightly-coupled teams) with functionally equivalent open-source products (loosely-coupled, distributed contributors). [3] Pairs included Linux vs. Solaris-class kernels, Mozilla/Firefox vs. proprietary browsers, GnuCash vs. proprietary accounting, OpenOffice/AbiWord vs. MS Word, Gnumeric vs. Excel-class spreadsheets. They measured propagation cost from Design Structure Matrices (DSMs) of each codebase — the proportion of design parameters affected, on average, when a random parameter is changed. [10]
Headline finding (direct quote from abstract):
"We find strong evidence to support the mirroring hypothesis. Wikipedia In all of the pairs we examine, the product developed by the loosely-coupled organization is significantly more modular than the product from the tightly-coupled organization. Harvard UniversityWikipedia The magnitude of the differences is substantial – up to a factor of [six to] eight, in terms of the potential for a design change in one component to propagate to others."
The published Research Policy version reports "a factor of six"; [11] the working-paper version reports "a factor of eight." [9] Both numbers circulate.
Statistical significance: With 5 matched pairs all showing the predicted direction, p < 0.05 (specifically (0.5)^5 = 0.03125). [12]
Counter-pattern observation: Gnumeric (an open-source product with an unusually integrated, non-modular design) had high propagation cost compared with peer OSS — and showed declining contributor participation, "consistent with the mirroring hypothesis," because contributors needed to comprehend too much of the system to safely change any part. [9][12]
Earlier paper: MacCormack, Rusnak & Baldwin (2006), "Exploring the Structure of Complex Software Designs," Management Science 52(7): 1015–1030. Compared Linux (loosely-coupled OSS org) vs. Mozilla (proprietary, tightly-coupled). [13] Linux significantly more modular; after Mozilla's deliberate "redesign for modularity," propagation cost dropped substantially — Mozilla post-redesign was more modular than Linux. [13]
Survey of the field: Colfer, L.J. & Baldwin, C.Y., "The Mirroring Hypothesis: Theory, Evidence and Exceptions," HBS Working Paper 16-124. Surveyed 142 empirical studies; found mirroring "in approximately 69%" of within-firm studies. PDF: [14]
1.3 Microsoft Research — Nagappan, Murphy & Basili (2008), Windows Vista
Citation: Nagappan, N., Murphy, B., & Basili, V. (2008). "The Influence of Organizational Structure on Software Quality: An Empirical Case Study." Proceedings of ICSE '08, pp. 521–530. ACM. Microsoft Research Technical Report MSR-TR-2008-11. PDF: [15]
Setting/scale: Subject was Windows Vista, 3,404 binaries, >50 million lines of code, several thousand engineers [15] — among the largest empirical studies of commercial software ever published. Quality metric: post-release failures during the first six months after Vista release. [15]
The 8 organizational metrics they introduced:
- Number of Engineers (NOE) — unique engineers who touched a binary and remain employed. [15]
- Number of Ex-Engineers (NOEE) — engineers who touched the binary and have since left (knowledge loss). [15]
- Edit Frequency (EF) — total check-ins/edits to source comprising the binary. [15]
- Depth of Master Ownership (DMO) — depth in the org tree at which 75% of edits roll up to a single owner. Deeper = better. [15]
- Percentage of Org contributing (PO) — ratio of contributors at DMO level to size of master owner's org. [15]
- Level of Organizational Code Ownership (OCO) — share of edits coming from the org containing the binary owner. [15]
- Overall Organization Ownership (OOW) — ratio of engineers at DMO level to total editing engineers. [15]
- Organization Intersection Factor (OIF) — number of distinct orgs each contributing >10% of edits. [15]
Headline quantitative results (Table 4, p. 8 of PDF): Logistic regression model using only org metrics, evaluated by 50 random [15] 2/3–1/3 train/test splits, predicting whether a binary will be failure-prone:
| Model | Precision | Recall |
|---|
| Organizational Structure | 86.2% | 84.0% |
| Code Churn | 78.6% | 79.9% |
| Code Complexity | 79.3% | 66.0% |
| Code Dependencies | 74.4% | 69.9% |
| Code Coverage | 83.8% | 54.4% |
| Pre-Release Bugs | 73.8% | 62.9% |
Key direct quote (Abstract):
"The precision and recall measures for identifying failure-prone binaries, using the organizational metrics, was significantly higher than using traditional metrics like churn, complexity, coverage, dependencies, and pre-release bug measures that have been used to date to predict failure-proneness." [15][16]
Nagappan, Microsoft Research blog ("Exploding Software-Engineering Myths"):
"That took us by surprise. We didn't expect it to be that accurate. We thought it would be comparable to other code-based metrics, but these factors were at least 8 percent better in terms of precision and recall than the closest factor we got from the code measures." [17]
Companion finding (Bird, Nagappan, Devanbu, Gall, Murphy, also at Microsoft): Geographical distance had statistically negligible impact on collaboration, but organizational distance mattered enormously. People preferred to talk to someone from their own organization 4,000 miles away rather than someone five doors down the hall in a different org. [17]
1.4 Industry Case Studies
Amazon — the API Mandate (~2002). No public primary source from Bezos exists; the canonical text is Steve Yegge's accidentally-public 2011 Google+ "Platforms Rant" (archived at [18]):
"1) All teams will henceforth expose their data and functionality through service interfaces. 2) Teams must communicate with each other through these interfaces. 3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network. 4) It doesn't matter what technology they use… Nordic APIs +2 5) All service interfaces, without exception, must be designed from the ground up to be externalizable… Kong Inc.ProFocus Technology 6) Anyone who doesn't do this will be fired. 7) Thank you; have a nice day!"
Yegge: "Over the next couple of years, Amazon transformed internally into a service-oriented architecture." [19][18] This directly enabled AWS (S3 launched 2006).
AWS Executive Insights, "Amazon's Two-Pizza Teams": "Our tightly coupled architecture and organization were simply not helping us move as fast as we wanted… We fundamentally changed our technical architecture to what became known as a microservices architecture. We decoupled our monolithic architecture into a vast network of single, standalone services… Amazon Web Services But it wasn't good enough to simply overhaul the technology our builders used to drive innovation. We also needed to restructure the way teams were organized." [20]
Werner Vogels (Amazon CTO), "you build it, you run it" — ACM Queue, June 2006 ([21]):
"Giving developers operational responsibilities has greatly enhanced the quality of the services, both from a customer and a technology point of view. The traditional model is that you take your software to the wall that separates development and operations, and throw it over and then forget about it. Not at Amazon. You build it, you run it." [21][22]
Amazon's deployment-frequency improvement (Chris Richardson summary): "Between 1998 and 2002, the rate of software delivery at Amazon dramatically slowed down because they outgrew their software architecture… Their deployment frequency went from 20/year in 2002 to an astonishing 49 million/year in 2015." [23]
Spotify Model — original Kniberg & Ivarsson (2012) whitepaper "Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds" ([24]). Snapshot: Spotify had grown from 30 to 250 people over 3 years; ~30 squads across 3 cities; April 2012 employee satisfaction = 4.4/5. [25]
The critique — Jeremiah Lee, "Spotify's Failed #SquadGoals" (April 2020), [26]. Lee was a Spotify PM 2017–2019:
"I joined the company after it had tripled in size to 3,000 people over 18 months. I learned the famed squad model was only ever aspirational and never fully implemented. I witnessed organizational chaos as the company's leaders incrementally transitioned to more traditional management structures." [26]
"If we remove the unnecessary synonyms from the ideas, the Spotify model is revealed as a collection of cross-functional teams with too much autonomy and a poor management structure. Jeremiahlee The Spotify squad model failed Spotify and it will fail your company too." [26]
Spotify agile coach Joakim Sundén (2011–2017): "Even when we wrote it, we weren't doing it. It was half ambition, half approximation. People really struggled to copy something that never really existed." [27]
Co-author Anders Ivarsson: "It worries me when people look at what we do and think it's a framework they can just copy and implement… We are really trying hard now to emphasize we have problems as well." [26]
Netflix — Adrian Cockcroft (Cloud Architect 2010–2014). Netflix went from a monolithic Java DVD-rental app (~100 engineers) to >1,000 microservices handling >2 billion requests/day. [28] Cockcroft:
"Conway's law says that the interface structure of a software system will reflect the social structure of the organization that produced it. So if you want to switch to a microservices architecture, you need to organize your staff into product teams and use DevOps methodology." [29]
"We set up the architecture we wanted by creating groups that were that shape. We typically try to have a microservice do one thing, one verb… InfoQ Mostly one developer producing the services." [30]
Cockcroft has described his role not as designing architecture but as "discovering and formalizing the architecture that emerged as the Netflix engineers built it" [31] — itself a Conway's-Law point.
1.5 The Inverse Conway Maneuver
Origin: Coined by Jonny LeRoy and Matt Simons, ThoughtWorks, in the December 2010 Cutter IT Journal. [6][2] Their pithy framing: "Dysfunctional organisations tend to create dysfunctional applications." [2] Confirmed by Martin Fowler (footnote in his Conway's Law bliki).
ThoughtWorks Technology Radar entry ([32]):
"The 'Inverse Conway Maneuver' recommends evolving your team and organizational structure to promote your desired architecture. Ideally your technology architecture will display isomorphism with your business architecture." [32]
Martin Fowler, bliki: ConwaysLaw (last updated October 2022):
"Accepting Conway's Law is superior to ignoring it, and in the last decade, we've seen a third way to respond to this law. Here we deliberately alter the development team's organization structure to encourage the desired software architecture, an approach referred to as the Inverse Conway Maneuver. Martin Fowler … Martin Fowler This, indeed, is why I describe microservices as primarily a tool to structure a development organization." [6]
Fowler's caveat: "While the inverse Conway maneuver is a useful tool, it isn't all-powerful. Martin Fowler If you have an existing system with a rigid architecture that you want to change, changing the development organization isn't going to be an instant fix. Instead it's more likely to result in a mismatch between developers and code that adds friction to further enhancement." [6]
Forsgren, Humble & Kim, Accelerate (IT Revolution, 2018), Ch. 5:
"Our research lends support to what is sometimes called the 'inverse Conway maneuver,' which states that organizations should evolve their team and organizational structure to achieve the desired architecture. Kislay Verma The goal is for your architecture to support the ability of teams to get their work done Kevin Vecmanis — from design through to deployment — without requiring high-bandwidth communication between teams." [33]
The DORA dataset behind Accelerate drew on 23,000+ survey responses across 2,000+ organizations. The DORA 2023 State of DevOps Report extends to 36,000+ professionals over nine years. [34]
THEME 2: ORGANIZATIONAL POLITICS SHAPING SYSTEM BOUNDARIES
2.1 Service Ownership Reflects Reporting/Budget Lines
Martin Fowler, bliki: ConwaysLaw:
"Conway's Law is essentially the observation that the architectures of software systems look remarkably similar to the organization of the development team that built it… If a single team writes a compiler, it will be a one-pass compiler, but if the team is divided into two, then it will be a two-pass compiler." [6]
"If an architecture is designed at odds with the development organization's structure, then tensions appear in the software structure. Module interactions that were designed to be straightforward become complicated, because the teams responsible for them don't work together well. Beneficial design alternatives aren't even considered because the necessary development groups aren't talking to each other." [6]
Chris Ford (quoted by Fowler): "Conway understood that software coupling is enabled and encouraged by human communication."
Sam Newman, Monolith to Microservices (O'Reilly, 2019):
"The Distributed Monolith [is a] system that consists of multiple services, but for whatever reason the entire system has to be deployed together." [35]
"A useful structure to follow with microservices is to make sure each service is owned by exactly one team. One team can own more than one service, but having clear ownership of who owns a service helps in some of the operational challenges with microservices… InfoQ If you find that you can only release in a release train, you are likely building a distributed monolith." [36]
Newman, QCon London 2020: "The monolith is not the enemy. Microservices should not be the default choice."
Eric Evans on bounded contexts as cultural/political artifacts (DDD Europe 2019 keynote, summarized by InfoQ):
"Various factors draw boundaries between contexts. Usually the dominant one is human culture, since models act as Ubiquitous Language, you need a different model when the language changes." [37]
"Large corporations are known for reorganizations InfoQInfoQ leading to changes in processes and responsibilities. This could result in two teams having to work in the same bounded contexts with an increased risk of ending up with a 'big ball of mud.'" [38]
Evans on DDD's Customer/Supplier and Conformist relationships explicitly frames inter-context relationships as political: "Highly influential groups may create an API that other groups must conform to… InfoQ you commonly must adapt to their APIs irrespective of the direction data is flowing." [38][39]
2.2 Team Boundaries Becoming API Boundaries — Team Topologies
Skelton & Pais, Team Topologies (IT Revolution, 2019). Defines four fundamental team types — stream-aligned, platform, enabling, and complicated-subsystem — and three core team interaction modes: collaboration, X-as-a-Service, facilitating. [40]
Direct quotes:
"Thinking of software architecture as a standalone concept that can be designed in isolation and then implemented by any group of teams is fundamentally wrong."
"Team structures must match the required software architecture or risk producing unintended designs." [33][41]
"The organization's design limits the number of possible solutions for a given system's architecture. The speed of software delivery is strongly affected by how many team dependencies the organization design instills."
"Fast flow requires restricting communication between teams."
"Organization design and software design are, in practice, two sides of the same coin."
The "Team API" concept (pp. 47–49):
"With stable, long-lived teams that own specific bits of the software systems, we can begin to build a stable team API: an API surrounding each team. An API (Application Programming Interface) is a description and a specification for how to interact programmatically with software, so we extend this idea to entire interactions with the team." [42]
Cognitive load argument (Fowler, bliki: Team Topologies): "A crucial insight of Team Topologies is that the primary benefit of a platform is to reduce the cognitive load on stream-aligned teams." [43][44]
Skelton & Pais (newsletter, July 2024): "The question is not 'monoliths vs microservices'; instead you should be focusing on managing team cognitive load over technology choices." [45]
Quotes Skelton/Pais bring forward:
- Michael Nygard: "Team assignments are the first draft of the architecture."
- Ruth Malan: "The organizational divides are going to drive the true seams in the system." [46][40]
- Allan Kelly: "Software developers love building platforms and, without strong product management input, will create a bigger platform than needed."
2.3 Ruth Malan — Architecture as Social/Political Activity
Most-quoted modern restatement of Conway's Law ("Conway's Law" essay, ruthmalan.com, Feb 13, 2008, [47]):
"If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins."
"The organizational divides are going to drive the true seams in the system. The architecture of the system gets cemented in the forms of the teams that develop it. The system decomposition drives team ownership. Then the organizational lines of communication become reflected in the interfaces, with cleaner, better preserved interfaces along the lines where organizational distance increases." [48]
"If we have managers deciding on teams Thinkinglabs (what they'll do, who will be on them, and how they will relate), and deciding which services will be built, by which teams, we implicitly have managers deciding on the system architecture." [46]
On the architect as political actor (Trace in the Sand, 2011):
"The arrows of strategy (formal) and all the informal and politically charged personal agendas and local goals of various stakeholders, in addition to constraints… [The architect] holds the umbrella fending off the political crud so the team can get great work done." [49]
"Organizations are fraught with power struggles and ag Ruthmalanenda pushing and it makes this whole arena a matter of influence and creating alignment."
"What we believe architecture is, shapes what we do. If that were not so, we'd just be swaying in the political breezes of our organizations… subject to compromises forced by political breezes."
On architecture as social co-construction (Oct 2011):
"Beginnings of social constructions Ruthmalan are not about 'I' but about 'we' — about drawing people in, connecting them into the social co-creation process."
"Architecture decisions are…[exactly those] that need us to be motivating, persuading, influencing, educating, coaching, and even governing… architecture by nature is working to achieve strategic system-level outcomes that would not be achieved if local concerns of some party with a vested inter Ruthmalanest (a 'stakeholder') was to dominate the solution and so skew the choice/outcome in their favor."
2.4 "Political Modules" / Compromise Architectures
Gregor Hohpe, The Software Architect Elevator (O'Reilly, 2020). Chapter titles read like a political ethnography of IT: Black Markets Are Not Efficient, Control Is an Illusion, No Pain, No Change, Money Can't Buy Love, Reverse-Engineering Organizations, The Pen Is Mightier Than the Sword, but Not Mightier Than Corporate Politics.
On reading reporting lines as belief systems:
"The reporting lines can be a useful indicator of an IT organization's belief system. For example, if the CIO reports to the CFO, the chief financial officer, IT is likely seen as a mere cost factor, not as an innovator and enabler of market opportunity."
On lines vs boxes (the "diagrams as political documents" core support):
"If I see an architecture diagram without any connecting lines, I am skeptical as to whether it qualifies as a meaningful depiction of an architecture. Unfortunately, many diagrams fail this basic test."
"The lines are more interesting than the boxes."
On shared services as political compromises (IT Revolution, "How to Make Shared Services Suck Less"):
"When defined or operated poorly, shared services can be a source of intense frustration and inefficiency, with a reputation for behaving like silos and for putting would-be customers through burdensome bureaucracy and arbitrary decision-making. All too often shared services are conceived as a conglomeration of systems and services that market-facing teams have deemed mundane."
Don Reinertsen (cited in IT Revolution shared services paper): "Every time someone tells me that they are using a completely autonomous cross-functional team, when I dig deeper I find they have had to put in place a mechanism to create infrequent but quick access to deep expertise."
2.5 Reorganizations Trigger Architectural Rewrites (and Vice Versa)
Skelton & Pais, Team Topologies: "Existing software architecture will initially 'push back' against the new team structures."
The "fracture planes" concept (pp. 115, 121):
"A fracture plane is a natural seam in the software system that allows the system to be split easily into two or more parts."
"Litmus test for a fracture plane applicability: does the resulting architecture support more autonomous teams (less dependent teams) with reduced cognitive load (less disparate responsibilities)?"
Among the listed fracture planes: business-domain bounded context, regulatory compliance (especially relevant in healthcare — HIPAA, audit trails), change cadence, team location, risk tolerance, performance isolation, technology, and user persona.
The "platform reorg" pattern. Companies hit scale, decide to build a platform team, carve out infra/SRE/data into a central org — then discover (per Allan Kelly's quote) that the platform team builds far more than needed, and stream-aligned teams resent the dependency. Result: usually another reorg 18–36 months later. Team Topologies' "Platform-as-a-Product" mode is explicitly framed as a political fix — the platform team must compete for internal customers, not mandate adoption.
Healthcare M&A — architectural rewrites driven by reorgs. EHR is so central that healthcare offers some of the cleanest documented cases.
- American Hospital Association study cited by Definitive Healthcare: "35% of acquired hospitals switched to the dominant vendor of their acquiring system after a merger, suggesting that hospital consolidation may be contributing to EHR vendor consolidation."
- Optum Advisory: "Even when both organizations have the same EHR system, each instance can be different depending on how a health system has chosen to maintain and customize it… Going from one Epic instance to another can be hard, because providers in each system have gotten used to how that Epic instance works."
- Dale Sanders, Health Catalyst: "Mergers, acquisitions, and partnerships are a dominant force in today's healthcare system. These new organizations, however, will not be functionally integrated until their data is integrated."
THEME 3: TARGET ARCHITECTURES VS POLITICAL REALITY
3.1 Gregor Hohpe's Architect Elevator Framework
Core thesis (architectelevator.com / Martin Fowler reproduction at [50]):
"If you picture the levels of an organization as the floors in a building, architects can ride what I call the architect elevator: they ride the elevator up and down to move between a large enterprise's board room and the engine room where software is being built… Stretching the analogy to that of a large ship, if the bridge officers spot an obstacle and need to turn the proverbial tanker, they will set the engines to reverse. But if in reality the engines are running full speed ahead, a major disaster is preprogrammed."
On architects as political translators:
"Architects can fill an important void: they work and communicate closely with technical staff on projects, but are able to convey technical topics to upper management without losing the essence of the message… But even if new technologies are rolled out, existing processes and politics may prevent them from realizing the expected benefit. In both cases, architects must visit the upper floors to unblock or to trigger organizational changes."
On architects' real role (architectelevator.com homepage):
"Modern architects don't try to be the smartest people in the room. Instead, they make everyone else smarter. They shun buzzwords in favor of increasing decision discipline, understanding trade-offs, and communicating across organizational levels."
"Architecture is selling options" ([51]):
"I sell options. In the financial world, an option is well-known as the right, but not the obligation, to buy or sell a financial instrument at a future point in time… Translating the formula to IT architecture, selling options gives the business and IT a way to defer decisions… in times of technological uncertainty, as we are facing them today, the value of the options that architecture sells increases."
Hohpe's Law: "Excessive complexity is nature's punishment for organizations that are unable to make decisions."
Architects live in the first derivative (Ch. 3 of Software Architect Elevator):
"If I had to name one primary factor that influences architecture, I'd put rate of change at the top of my list… Good architects, therefore, deal with change. This means that they live in the system's first derivative: the mathematical expression for how quickly a function's value changes."
"Black Markets Are Not Efficient" — Hohpe's framing of shadow IT and workarounds: organizations whose official processes are too slow develop unofficial "black markets" (workarounds, shadow IT, fake project labels). Black markets are a symptom of organizational dysfunction that an architect must surface, not exploit.
On EA being political (Agile India 2018 interview):
"I hope to show that Enterprise Architecture done right is not about being in the ivory tower."
"Control Is an Illusion" chapter argues top-down enterprise architecture cannot work because of three gaps: knowledge gap, alignment gap, and effects gap.
Segment, "Goodbye Microservices" — Alexandra Noonan, July 10, 2018 ([52]). Segment built ~50+ destination microservices in 2015 (one per integration partner) and reversed course by 2017:
"It seemed as if we were falling from the microservices tree, hitting every branch on the way down. Instead of enabling us to move faster, the small team found themselves mired in exploding complexity. Essential benefits of this architecture became burdens. As our velocity plummeted, our defect rate exploded. Eventually, the team found themselves unable to make headway, with 3 full-time engineers spending most of their time just keeping the system alive."
The key political point: the original split was driven not by team boundaries but by destination type — Segment had split infrastructure by where data was being sent rather than by the teams making changes — a violation of Conway's Law that the org chart never solved.
Segment co-founder/CTO Calvin French-Owen: "With microservices, you have a tradeoff where the nice reason to adopt them is it allows more people to work on different parts of the codebase independently, but in our case it requires more work operationally and more operational overhead to monitor multiple services instead of just one."
Amazon Prime Video (2023): Reported 90% cost reduction by consolidating microservices back to a monolith ("Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%," Prime Video Tech Blog).
CNCF 2025 Survey: 42% of organizations are actively consolidating microservices back to larger deployment units; service mesh adoption declined from 18% (Q3 2023) to 8% (Q3 2025).
NHS National Programme for IT (NPfIT / Lorenzo) — ~£10–13B failure. Launched 2002 by Tony Blair; dismantled 2011.
- Final cost: officially £9.8B–£10B+ (some sources £12.7–£13B with transition/exit).
- NIH/PMC analysis: only 22 of 220 NHS trusts joined the integrated network — i.e., overwhelmingly a political adoption failure, not technology.
- Henrico Dolfing case study: "Failure to recognize the risks or limitations of big IT projects… Sheer ambition… The project being too large for the leadership to manage competently… A lack of clear leadership… Not knowing, or continually changing, the aim of the project."
- Cambridge case history (Anderson et al., 2014): [53]
- Retrospective: "The NPfIT was a project built on political mythology and bureaucratic centralization. Its tragic collapse teaches us that technology cannot fix organizational chaos; it only amplifies it."
Healthcare.gov, October 1, 2013. Crashed within 2 hours of launch; only 6 people enrolled the first day.
- HHS OIG: "Most critical was the absence of clear leadership, which caused delays in decision-making… CMS's organizational structure and culture also hampered progress, including poor coordination between policy and technical work."
- Politically driven scope change: In August 2013, the White House and Office of Health Reform insisted on requiring user registration before shopping for insurance — to produce sign-up numbers as political optics. This was not communicated to the contractor (QSSI), creating discrepancy between actual and expected load on the EIDM. Kentucky and Massachusetts exchanges (the inspirations) allowed anonymous browsing.
- Washington Post: federal officials received 18 written warnings that the project was off course but never considered postponing launch — including 11 scathing McKinsey reviews.
- Harvard D3: "94% of large federal information technology projects were unsuccessful, more than 50% were delayed, overbudget, or didn't meet expectations and a total of 41.4% were judged to be complete failures." (Standish-derived figure.)
Istio governance dispute (2020). Despite IBM, Google, and Lyft co-founding Istio in 2017 with a publicly stated commitment to donate it to CNCF, in July 2020 Google moved Istio's trademark to a new entity it controlled (Open Usage Commons).
- IBM VP Jason McGee: "Today's announcement by Google of the creation of the Open Usage Commons is disappointing because it doesn't live up to the community's expectation for open governance… Without this vendor-neutral approach to project governance, there will be friction within the community of Kubernetes-related projects."
- CNCF CTO Chris Aniszczyk: "Google set up an organization with no details claiming to be solving a 'trademark issue' in open source that doesn't exist… just bonkers."
- Oracle's Jon Mittelhauser: "My team is in the process of reevaluating (and likely moving away from) the use of Istio… Without open governance, we can't support it."
The technical architecture was never the issue — vendor power politics determined adoption. (Istio later joined CNCF as an incubating project in September 2022.)
Failed enterprise architecture frameworks (CIO.com, "The dark secrets of enterprise architecture"):
"What you really want to avoid is an EA function with permanent staffing. Do this and you'll have a hard time keeping it from becoming an ivory-tower white-paper factory."
WWT: "Once EA ascends this ivory tower of abstract thought within an organization, it is extremely difficult to shift focus back to the realm of business relevance. And once the business loses trust in an EA's ability to produce actionable artifacts, it is not too long before EA becomes shelfware."
3.3 Why Target-State Architectures Fail — Stats
- McKinsey (Harry Robinson, Senior Partner): "The academic research is really clear that when corporations launch transformations, roughly 70 percent fail. The root causes of those failures are straightforward… Often the CEO doesn't set a sufficiently high aspiration… he or she doesn't build conviction within the team about the importance of this change… People throughout the organization don't buy in."
- Standish CHAOS 2020: ~31% successful, 50% challenged, 19% failed. Small projects ~90% success; large projects <10% success; projects >$10M are >10× more likely to be cancelled than those <$1M. Only ~13% of major U.S. federal IT projects succeed.
- CHAOS 1994 (original numbers): Only 16.2% completed on time, on budget, with all features. 9% of projects at large companies (>$500M revenue) succeeded; 61.5% challenged; 29.5% cancelled.
- BCG (2020): ~70% of digital transformation efforts fall short of targets.
- Bain (2024): 88% of business transformations fail to achieve original ambitions.
- Gartner: 80% of organizations seeking to scale digital business will fail through 2025.
- McKinsey 2020: 17% of large IT projects go so badly they threaten the very existence of the company.
- CISQ (2020): Total cost of unsuccessful development projects among US firms: ~$260B; cost of operational failures from poor software quality: ~$1.56T.
Caveat to flag: The "70% transformation failure" statistic, while ubiquitous, has been critiqued by Mark Hughes (University of Brighton, 2011, Journal of Change Management), who reviewed five published instances of the claim and "found absolutely no valid and reliable empirical evidence to support the claim." Trace it to Hammer & Champy's Reengineering the Corporation. Use as McKinsey-attributed conventional wisdom, not peer-reviewed fact.
Joel Spolsky — "Architecture Astronauts" (2001):
"When you go too far up, abstraction-wise, you run out of oxygen. Sometimes, smart thinkers just don't know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don't actually mean anything at all… That's one sure tip-off to the fact that you're being assaulted by an Architecture Astronaut: the incredible amount of bombast; the heroic, utopian grandiloquence; the boastfulness; the complete lack of reality."
John Carmack (2021) called the metaverse "a honeypot trap for architecture astronauts."
3.4 Building Evolutionary Architectures
Ford, Parsons, Kua, Building Evolutionary Architectures (O'Reilly, 2nd ed. 2022).
Definition: "An evolutionary architecture supports guided, incremental change as a first principle across multiple dimensions."
Fowler's foreword:
"For a long time, the software industry followed the notion that architecture was something that ought to be developed and completed before writing the first line of code… It was felt that the sign of a successful software architecture was something that didn't need to change during development… This vision of architecture was rudely challenged by the rise of agile software methods."
On diagrams as snapshots:
"Software architects have the responsibility to elucidate decisions about how systems fit together, often by creating diagrams. Too many architects fail to realize that a static, two-dimensional picture of architecture has a short shelf life. The software universe exists in a state of constant flux; it is dynamic rather than static. Architecture isn't an equation but rather a snapshot of an ongoing process."
The book explicitly contains a chapter section: "Don't Fight Conway's Law."
3.5 Architectural Debt Tied to Organizational Debt
Damian Tamburri — "Social Debt" (academic). Original paper: Tamburri, Kruchten, Lago, van Vliet — "What is social debt in software engineering?" IEEE/ACM CHASE 2013. Industry follow-up: Tamburri et al., "Social debt in software engineering: insights from industry," Journal of Internet Services and Applications 6:10, 2015.
Definition:
"Social debt is analogous to technical debt in many ways: it represents the state of software development organisations as the result of 'accumulated' decisions. In the case of social debt, decisions are about people and their interactions… we learned that social debt is strongly correlated with technical debt and both forces should be reckoned with together during the software process."
"Community smells" Tamburri identified: organisational silo effect; black-cloud effect (information overcrowding obfuscates reality); leftover-techies (disgruntled operations people); lonesome architects (architects who work in isolation accelerate decay).
Tamburri later finding: "'Lonesome' architects are more likely to generate debt and… 'invisible' architecting might be increasing this debt."
Adam Tornhill — Behavioral code analysis ("Your Code as a Crime Scene," "Software Design X-Rays"):
"Software projects rarely fail because of messy code alone — they fail because organizations lack visibility into how their teams actually work with the code."
His key insight: "Dependencies between code = dependencies between people. Conway's Law… Align your Architecture and your Organization." The 2nd edition adds Chapter 14: "See How Technical Problems Cause Organizational Issues" and Chapter 13: "Discover Organizational Metrics in Your Codebase."
Forsgren et al., Accelerate — on governance theatre as political artifact:
"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… It is, in fact, worse than having no change approval process at all."
The Westrum culture typology used in Accelerate: pathological (power-oriented, info hoarded for political reasons), bureaucratic (rule-oriented, turf-protecting), generative (performance-oriented). Culture predicts delivery and organizational performance — measurably.
3.6 Eltjo Poort — Architecture as Risk/Cost Management
2016 Linda Northrop Software Architecture Award winner for Risk- and Cost-Driven Architecture (RCDA).
Core thesis (Poort & van Vliet, JSS, 2012):
"We propose to view architecting as a risk- and cost management discipline. This point of view helps architects identify the key concerns to address in their decision making, by providing a simple, relatively objective way to assess architectural significance. It also helps business stakeholders to align the architect's activities and results with their own goals."
Most quotable line: "The architect's main deliverable isn't a document but a stream of decisions."
3.7 Healthtech-Specific Context
HL7 / FHIR adoption is political, not technical.
- ScienceDirect scoping review (Mar 2025): The two cited categories of FHIR adoption barriers are technical and organizational — political factors weighted equally.
- Itirra: "Inconsistent implementation of FHIR across different healthcare systems… variations in how FHIR is implemented from one organization to another, creating compatibility issues."
- Hypercare: "Antitrust concerns can make competing healthcare organizations hesitant to collaborate on interoperability initiatives, even when it would benefit clinical teams."
- Vendor-lock framing (Alli & Dada, 2023): "While vendors may offer HL7 or FHIR-compatible APIs, these are often implemented in ways that only partially conform to the standard, adding proprietary extensions or custom logic."
- Firely State of FHIR 2025 (82 experts, 52 countries): 78% of countries surveyed have regulations for electronic health data exchange; 73% of those mandate or advise FHIR — but "contradictions in responses — even from the same country — suggest inconsistent implementation and communication between national bodies."
EHR interoperability "Catch-22": "Healthcare organizations face a 'Catch-22': high upfront costs versus persistent ongoing costs from inefficiencies like redundant tests and administrative overhead. The ROI for interoperability may not be immediately clear for individual practices, making it hard to justify initial expenditure."
Hypercare: "When multiple organizations participate in data sharing, establishing governance becomes a negotiation of competing interests and organizational cultures."
THEME 4: SPECIFIC DATA POINTS AND QUOTABLE STATISTICS
4.1 Drop-in Statistics
| # | Statistic | Source |
|---|
| 1 | Org metrics predicted defect-prone Vista binaries with 86.2% precision / 84.0% recall, beating every code metric | Nagappan/Murphy/Basili (Microsoft Research) ICSE 2008, Windows Vista, 3,404 binaries, 50M+ LOC |
| 2 | Loosely-coupled orgs produced software up to 6–8× more modularthan tightly-coupled orgs | MacCormack/Baldwin/Rusnak,Research Policy2012 |
| 3 | Mirroring confirmed in ~69% of within-firm studiesacross 142 empirical studies surveyed | Colfer & Baldwin, HBS WP 16-124 |
| 4 | Amazon:**20 deploys/year (2002) → 49 million/year (2015)**after API mandate + microservices | Cited via Chris Richardson summarizing Amazon |
| 5 | DORA dataset:23,000+ survey responses across 2,000+ organizations(Accelerate); 36,000+ professionals over 9 years (DORA 2023) | Forsgren/Humble/Kim |
| 6 | 31% of large transformations succeed, 50% challenged, 19% failed(CHAOS 2020);<10% success rate for large projects | Standish Group |
| 7 | **9% project success rate at large companies (>$500M revenue)**in original CHAOS 1994 | Standish |
| 8 | 70% of corporate transformations fail | McKinsey (Robinson, Garcia) |
| 9 | 88% of business transformationsfail to achieve original ambitions (2024) | Bain |
| 10 | 17% of large IT projectsgo so badly they threaten company existence | McKinsey 2020 |
| 11 | 42% of M&A due diligencefails to provide adequate roadmap for synergies | McKinsey |
| 12 | 70–90% of M&A deals failto achieve expected synergies | HBR (Roger Martin 2016, Graham Kenny 2020), McKinsey |
| 13 | 35% of acquired hospitals switched EHR vendorsto match acquirer | American Hospital Association, cited in Definitive Healthcare |
| 14 | 30–40% of large-enterprise IT spend is shadow IT(Everest Group says 50%+) | Gartner; Everest Group commentary on CIO.com |
| 15 | 75% of employees will create shadow IT solutions by 2027(41% in 2022) | Gartner |
| 16 | 65% of SaaS apps in enterprises were never approved by IT; 92% of enterprises have shadow IT | BetterCloud State of SaaSOps 2023 |
| 17 | 76% of employees use unapproved SaaS(avg 25 such apps/user) | McAfee 2021 |
| 18 | 40% of cloud apps are unauthorized; 83% of IT pros call shadow IT a growing concern | Cisco 2022 Annual Cybersecurity Report |
| 19 | 71% of hospitals allow BYOD; 65% of doctors and 41% of nurses use personal devices even where prohibited | Spok 2017 |
| 20 | 91% of healthcare professionals use a personal mobile during clinical practice | Journal of Mobile Technology in Medicine |
| 21 | 70% of new enterprise apps now built by citizen developers/non-IT(2024+) | Gartner |
| 22 | 94% of large federal IT projects unsuccessful | Standish-derived, cited Harvard D3 |
| 23 | 42% of organizations consolidating microservices back to larger units; service mesh adoption fell 18% → 8% | CNCF 2025 Survey |
| 24 | Amazon Prime Video:90% cost reductionby going microservices → monolith | Prime Video Tech Blog 2023 |
| 25 | Vista: each legacy binary had ~31 engineers working on it; only 2 had checked in code on the same binary in Server 2003 | Nagappan et al. 2008 |
| 26 | NHS NPfIT:only 22 of 220 NHS trusts joined the integrated network(~£10B failure) | NIH/PMC analysis |
4.2 Highest-Density Quotes (verified attribution)
| # | Quote | Attribution |
|---|
| 1 | "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." | Conway,Datamation1968 |
| 2 | "There is no such thing as a design group which is both organized and unbiased." | Conway 1968 |
| 3 | "Is there a better design that is not available to us because of our organization?" | Conway, later commentary |
| 4 | "If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins." | Ruth Malan, "Trace in the Sand," 2008 |
| 5 | "Team assignments are the first draft of the architecture." | Michael Nygard, cited inTeam Topologies |
| 6 | "You can read the history of an enterprise's political struggles in its system architecture." | Michael Nygard (paraphrase widely circulated; flag verification) |
| 7 | "I describe microservices as primarily a tool to structure a development organization." | Martin Fowler, bliki: ConwaysLaw |
| 8 | "Conway understood that software coupling is enabled and encouraged by human communication." | Chris Ford (quoted by Fowler) |
| 9 | "You build it, you run it." | Werner Vogels, ACM Queue 2006 |
| 10 | "Anyone who doesn't do this will be fired. Thank you; have a nice day." | Bezos API Mandate (per Yegge 2011) |
| 11 | "Excessive complexity is nature's punishment for organizations that are unable to make decisions." | Gregor Hohpe (Hohpe's Law) |
| 12 | "Architecture is selling options." | Hohpe,Software Architect ElevatorCh. 11 |
| 13 | "If I see an architecture diagram without any connecting lines, I am skeptical as to whether it qualifies as a meaningful depiction of an architecture." | Hohpe,Software Architect Elevator |
| 14 | "The lines are more interesting than the boxes." | Hohpe (paraphrasing Bredemeyer/Malan teaching) |
| 15 | "Modern architects don't try to be the smartest people in the room. Instead, they make everyone else smarter." | Hohpe |
| 16 | "The reporting lines can be a useful indicator of an IT organization's belief system. For example, if the CIO reports to the CFO, IT is likely seen as a mere cost factor." | Hohpe, "The Architect Elevator" |
| 17 | "Thinking of software architecture as a standalone concept that can be designed in isolation and then implemented by any group of teams is fundamentally wrong." | Skelton & Pais,Team Topologies |
| 18 | "Fast flow requires restricting communication between teams." | Skelton & Pais |
| 19 | "Organization design and software design are, in practice, two sides of the same coin." | Skelton & Pais |
| 20 | "We found that high performance is possible with all kinds of systems, provided that systems—and the teams that build and maintain them—are loosely coupled." | Forsgren/Humble/Kim,Accelerate |
| 21 | "Approval by an external body simply doesn't work to increase the stability of production systems… It is, in fact, worse than having no change approval process at all." | Accelerate |
| 22 | "All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change." | Grady Booch |
| 23 | "Every software-intensive system has an architecture. In some cases that architecture is intentional, while in others it is accidental." | Grady Booch |
| 24 | "Architecture is the decisions that you wish you could get right early in a project." | Ralph Johnson (cited by Neal Ford) |
| 25 | "Architecture is about the important stuff. Whatever that is." | Martin Fowler / Ralph Johnson |
| 26 | "The architect's main deliverable isn't a document but a stream of decisions." | Eltjo Poort |
| 27 | "When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes." | Joel Spolsky 2000 |
| 28 | "Architecture decisions… need us to be motivating, persuading, influencing, educating, coaching, and even governing." | Ruth Malan |
| 29 | "The monolith is not the enemy. Microservices should not be the default choice." | Sam Newman, QCon London 2020 |
| 30 | "If you do a big-bang rewrite, the only thing you're guaranteed of is a big bang." | Sam Newman,Monolith to Microservices |
| 31 | "Without strong code ownership a microservices' architecture will grow into a distributed monolith." | Sam Newman |
| 32 | "To truly get the best impact from our efforts, we will have to push ourselves to transcend Conway's law." | Satya Nadella,Hit Refresh |
| 33 | "As our velocity plummeted, our defect rate exploded. Eventually, the team found themselves unable to make headway." | Alexandra Noonan (Segment), 2018 |
| 34 | "Every time we find value streams with big pauses and big delays in it, guess what: it's almost always true that you're crossing organizational boundaries at that point." | Mary Poppendieck |
| 35 | "The very act of organizing a design team means that certain design decisions have already been made, explicitly or otherwise." | Conway 1968 |
4.3 Architect Time-Allocation Studies (Caveat)
No primary survey data with specific percentage breakdowns of architect time allocation (politics vs technical work) was surfaced in research. The Stack Overflow Developer Survey reports salary/role data but not granular time-allocation. Iasa surveys are mostly behind paywalls.
Recommendation: Either omit a quantified time-allocation claim from the post, or use Hohpe's qualitative framing ("architects ride the elevator") as a substitute.
THEME 5: ARCHITECTURE AS ORGANIZATIONAL TRUCE LINES
5.1 Architecture as Encoded Compromise
Architectural Decision Records (ADRs). Origin: Michael Nygard, "Documenting Architecture Decisions" (2011). ADRs explicitly capture Context, Decision, Consequences — i.e., why a compromise was made, the forces at play, who pushed for what, what was traded away.
Martin Fowler on ADRs ([54]):
"This kind of decision log creates a valuable historic record that can do much to explain why things are the way they turned out."
ThoughtWorks Tech Radar moved ADRs to Adopt category. The deliverable is itself political: a record of compromises, not a statement of truth.
Philippe Kruchten — "An Ontology of Architectural Design Decisions in Software-Intensive Systems" (2004). Classifies decisions as existence, property, and executive decisions, with state machines (proposed → decided → approved → challenged → rejected/superseded).
Kruchten's talks page lists: "A collection of cognitive biases, reasoning fallacies and political games I've seen at work in 35 years of practice."
"You end up being in a position of architectural technical debt not because you made the wrong decision 10 years ago, but because those decisions are not the right one in the current circumstances." — Kruchten
5.2 "The Architecture You Have vs the Architecture You'd Design"
Joel Spolsky, "Things You Should Never Do, Part I" (April 2000) — the canonical anti-rewrite essay ([55]):
"They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch… When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work. You are throwing away your market leadership. You are giving a gift of two or three years to your competitors."
The Netscape rewrite (4.0 → 6.0) caused a 3-year release gap that contributed to AOL acquiring Netscape (1998) and effective obsolescence by 2008. The legacy code embodies institutional knowledge and past compromises with reality (corner cases, customer demands, regulatory edge cases). Throwing it away discards the political settlement, not just the technical artifact.
Martin Fowler — Strangler Fig pattern (2004): "Replacing a software system that's deeply embedded with business processes is never going to be an easy task. What this approach does do is make both investment and returns occur gradually and visibly, allowing the organization to evolve its software and business process to better support the current environment."
Fowler: "Let's face it, all we are doing is writing tomorrow's legacy software today."
Werner Vogels (AWS re:Invent 2022): "The benefit of loosely coupled systems is the evolvable architecture. Evolvability is extremely important when you think about your systems. It's evolve or die."
Vogels (ACM Queue 2020): "The way that we were storing objects in 2006 is not the same way we're storing objects now."
5.3 M&A Baking Acquired-Company Politics into Architecture
Failure rate baseline:
- HBR (Roger Martin, June 2016): "M&A is a mug's game, in which typically 70–90% of deals fail."
- HBR (Graham Kenny, March 2020): "According to most studies, between 70 and 90 percent of acquisitions fail. Most explanations for this depressing number emphasize problems with integrating the two parties involved."
- McKinsey "Where Mergers Go Wrong" (June 2010): "A recent McKinsey study found that 42 percent of the time, due diligence conducted before a merger failed to provide an adequate roadmap for capturing synergies and creating value."
HP–Compaq (2002, $25B). Combined ops in 160+ countries, 145,000+ employees. ~$13B in market cap lost within 2 days of announcement. Walter Hewlett's SEC filing: "This report shows that large computer mergers historically have failed to achieve expected revenue and cost synergies." Compaq–DEC (1998, $9.6B) before that: Compaq acquired Digital Equipment for incompatible technology (minicomputers, non-Intel chips), ballooning debt to $4B+.
AOL–Time Warner (Jan 2000, $165B). "AOL's digital systems were not easily compatible with Time Warner's media infrastructure… The companies had different customer databases, leading to issues like duplicate data and inefficiencies." Spun off in 2009. Steve Case tweet: "'Vision without execution is hallucination' — pretty much sums up AOL/TW."
Healthtech: Optum / UnitedHealth as "platform of platforms." Optum brand created 2011; acquisitions include Sierra Health, Picis, Axolotl, Executive Health Resources, WellMed, Surgical Care Affiliates, MedExpress, DaVita Medical Group, Genoa Healthcare, Equian ($3.2B 2019), Change Healthcare ($13B incl. debt, closed Oct 2022), Atrius Health (2022), Solutran, EMIS Health (2022, ~$1.5B).
AHA letter to DOJ on Optum–Change: "The acquisition…will concentrate an immense volume of competitively sensitive data in the hands of the most powerful health insurance company in the United States."
UnitedHealth disclosed "investments to accelerate technology, system and product integration and development activities" through 2022+. Each acquisition becomes a bounded context with its own political truce; OptumInsight's "modern analytics" had to integrate with Change's clinical decision technology, EMIS's UK primary care EPR, etc.
5.4 Shadow IT as Political Workaround
Headline numbers (most-cited):
- Gartner: Shadow IT accounts for 30–40% of IT spending in large enterprises
- Everest Group: Estimates shadow IT closer to 50% or more of enterprise IT spending. "I believe these statistics are an understatement of the shadow IT ecosystem."
- Gartner forecast: 41% of employees acquire/modify/create technology that IT isn't aware of (2022); projected to 75% by 2027
- Productiv: Shadow IT accounts for 42% of applications in a typical company (~78 of 187 apps)
- McAfee 2021: 76% of employees admitted to using unapproved SaaS, averaging 25 such apps per user
- BetterCloud State of SaaSOps 2023: ~65% of SaaS applications never got IT approval; 92% of enterprises have shadow IT
- Capterra 2023: companies waste avg. $43,500/yr on unused shadow SaaS
- IBM 2023 Cost of a Data Breach: Shadow IT contributes to ~28% of incidents in 75% of breached organizations; avg cost ~$4.2M
Healthcare-specific:
- Spok 2017: 71% of clinicians said their hospital allows BYOD, up from 58% the prior year. 65% of doctors and 41% of nurses admitted using personal devices despite hospital policy prohibiting them.
- Aruba Networks: 85% of hospitals support BYOD; only 8% allow full network access.
- Journal of Mobile Technology in Medicine: 91% of healthcare professionals owned a mobile phone, of which 87% used it during clinical practice.
- Children's Medical Center of Dallas (2017): $3.2M HHS settlement over patient privacy breaches linked to an unencrypted, non-password-protected BlackBerry.
- JMIR Human Factors 2025: hospital BYOD is explicitly a "sociotechnical" issue with "tension between clinical and IT departments."
Gartner formal definition of citizen developer: "a user who creates new business applications for consumption by others using development and runtime environments sanctioned by corporate IT."
CIO.com on the political nature: "For low code to succeed, IT leaders can't address it as shadow IT… Getting the right balance of control and autonomy for citizen developers is critical. You don't want poor security, but if governance and access processes are too onerous, people will just go back to ungoverned shadow IT."
5.5 DDD Context Maps as Political Negotiations
Eric Evans (DDD, 2003). Strategic patterns are explicitly team/political relationships:
- Shared Kernel — partnership where two teams agree to keep a common subset consistent (treaty)
- Customer/Supplier — structured co-dependency requiring coordination
- Conformist — "The downstream team eliminates the complexity of translation between bounded contexts by slavishly adhering to the model of the upstream team" (asymmetric power)
- Anticorruption Layer — "Translation becomes more complex. The translation layer takes on a more defensive tone" (literally a defense mechanism)
- Open Host Service / Published Language — public diplomacy
- Separate Ways — détente / non-alignment
The Open Group standard ([56]):
"A context map describes the flow of models between contexts and provides an overview of the systems landscape. A context map helps to identify governance issues between applications and teams, and to reveal how teams communicate, as well as their 'power' relationships."
Avanscoperta on context mapping ([57]) — most explicit political framing:
"The upstream-downstream relationship captures the political relationship between the two models, not the technical one. Connectors between bounded contexts can convey extra information: thickness can represent the available communication bandwidth between two models. Communication bandwidth is a scarce resource in many organisations, and a common source of friction and misunderstanding."
Vaughn Vernon (interview with Rebecca Wirfs-Brock, InformIT):
"If the politics in your organization, wherever it may be, prevents you from breaking off the new features into a clean Bounded Context, you can carve out your own clean space right in the existing system… Create some abstraction components — usually called an Anticorruption Layer — that queries the parts of the legacy system needed for your operations."
Eric Evans (Explore DDD 2018, InfoQ): "Anti-corruption layers are bi-directional; they protect new code from the legacy system, and they also keep the legacy system from being affected by the new code."
He compares team coordination across bounded contexts to "a three-legged race, where success requires the participants finding a balance between speed and coordination."
5.6 Conway's Law: Deterministic vs Deliberate
Yourdon & Constantine (1979) — the harder version: "The structure of any system designed by an organization is isomorphic to the structure of the organization."
Allan Kelly: "Organisations with long-lived systems will adopt a structure modelled on the system. Organisational design is system design."
ThoughtWorks "Reckoning with Conway's Law" podcast — James Lewis:
"There's quite a lot of evidence that points to the fact that the deeper the hierarchy of an organization… the slower an organization proceeds and in fact, the less effective an organization is at doing the thing that it's there for which is making money, saving lives, or whatever it is."
Martin Fowler, same podcast:
"If you're going to want to be a competent software architect, you have to be aware of Conway's Law and thus have to be interested in the design of software development organizations. Unfortunately, you may think your job is only about technical stuff, but no, it's about people and about organizations."
RESEARCH GAPS / CAVEATS
- The Bezos API mandate has no primary source from Bezos himself; the canonical text is Steve Yegge's 2011 secondhand recollection. Treat verbatim wording as a reconstruction, not a quote.
- The "70% transformation failure" figure is McKinsey-attributed and ubiquitous, but Mark Hughes (University of Brighton, 2011) found "no valid and reliable empirical evidence" for the claim. Use as conventional wisdom, not as peer-reviewed fact.
- Standish CHAOS reports are widely cited but criticized for proprietary methodology. Founder Jim Johnson: "All data and information in the Chaos reports and all Standish reports should be considered Standish opinion."
- The Michael Nygard line "You can read the history of an enterprise's political struggles in its system architecture" appears in secondary sources (Thierry de Pauw's "Shades of Conway's Law," thinkinglabs.io 2021); primary citation should be flagged with caution.
- The MacCormack 2012 paper reports propagation-cost differences "up to a factor of six" in Research Policy; the working-paper version says "up to a factor of eight." Both circulate.
- Conway's Law was named — separately — by both George Mealy (1968 National Symposium on Modular Programming) and Fred Brooks (Mythical Man-Month, 1975). Brooks's book is why everyone knows the term; Mealy may technically have priority.
- Architect time-allocation surveys with specific percentages do not appear to exist publicly at credible-quote quality; recommend using Hohpe's qualitative framing instead.
- Shadow IT statistics (30–40%, 41%) are Gartner-attributed but circulate primarily through vendor blogs (Auvik, JumpCloud, Zylo); original Gartner reports are paywalled.
- Page numbers cited for Team Topologies are from the IT Revolution Press first edition (2019); the second edition (2024) may renumber.
- No widely-cited public "architecture diagram = political document" case studies in healthtech specifically exist. This is a gap the LinkedIn post can fill from the author's own experience. The strongest documented healthtech examples are EHR integration after M&A and the regulatory-compliance fracture plane in Team Topologies.
PRIMARY-SOURCE URL INDEX
- Conway 1968 PDF: [1]
- Conway's website: [4]
- MacCormack/Baldwin/Rusnak 2012: [9]
- Colfer & Baldwin: [14]
- Nagappan/Murphy/Basili 2008: [15]
- Yegge "Platforms Rant" archive: [18]
- Vogels in ACM Queue: [21]
- Kniberg/Ivarsson Spotify whitepaper: [24]
- Jeremiah Lee, "Failed #SquadGoals": [26]
- Fowler, ConwaysLaw bliki: [6]
- Fowler, Architect Elevator: [50]
- Fowler, StranglerFigApplication: [58]
- Fowler, ArchitectureDecisionRecord: [54]
- Hohpe, "Architecture: Selling Options": [51]
- Malan, "Conway's Law" essay: [47]
- Malan, "Trace in the Sand" journal: [49]
- Spolsky, "Things You Should Never Do, Part I": [55]
- ThoughtWorks Inverse Conway Maneuver: [32]
- Segment, "Goodbye Microservices" (Noonan): [52]
- AWS Two-Pizza Teams: [20]
- Open Group on DDD strategic patterns: [56]
- Avanscoperta context mapping: [57]
- Cambridge NPfIT case history (Anderson et al., 2014): [53]
- McKinsey "Common pitfalls in transformations": [59]
- IT Revolution, "Conway's Law: Critical for Efficient Team Design": [60]
This research compilation is organized for direct deployment in a senior-engineering-leadership LinkedIn post. Each item has been verified to the primary source where possible, with caveats explicitly flagged. The strongest chains of evidence — Microsoft Vista (86.2%/84.0% precision/recall), MacCormack/Baldwin/Rusnak (6–8× modularity differences), Forsgren/Humble/Kim's 23,000-respondent dataset, plus Conway's original 1968 wording and Malan's 2008 reformulation — together form a citation-grade backbone for the thesis that architecture diagrams encode organizational politics, not just technical decisions.
- https://www.melconway.com/Home/pdf/committees.pdf — https://www.melconway.com/Home/pdf/committees.pdf
- CTO Craft — https://ctocraft.com/blog/how-can-the-inverse-conway-manoeuvre-help-drive-organisational-change/
- Thoughtworks — https://www.thoughtworks.com/en-us/insights/articles/demystifying-conways-law
- Melconway — https://www.melconway.com/Home/Conways_Law.html
- O'Reilly — https://www.oreilly.com/library/view/building-microservices/9781491950340/ch10.html
- Martin Fowler — https://martinfowler.com/bliki/ConwaysLaw.html
- ACM Queue — https://queue.acm.org/detail.cfm?id=3395214
- Wikipedia — https://en.wikipedia.org/wiki/Melvin_Conway
- https://dash.harvard.edu/bitstream/handle/1/34403525/maccormack%2Cbaldwin%2Crusnak_exploring-the-duality.pdf — https://dash.harvard.edu/bitstream/handle/1/34403525/maccormack%2Cbaldwin%2Crusnak_exploring-the-duality.pdf
- ResearchGate — https://www.researchgate.net/publication/263392218_Hidden_structure_Using_network_methods_to_map_system_architecture
- ScienceDirect — https://www.sciencedirect.com/science/article/abs/pii/S0048733312001205
- Harvard University — https://dash.harvard.edu/bitstream/handle/1/34403525/maccormack,baldwin,rusnak_exploring-the-duality.pdf;jsessionid=E6CC96702942728051E62E96723E2170?sequence=1
- Google Scholar — https://scholar.google.com/scholar_lookup?title=Exploring+the+structure+of+complex+software+designs:+An+empirical+study+of+open+source+and+proprietary+code&=&author=A.+MacCormack&=&author=J.+Rusnak&=&author=C.+Y.+Baldwin&=&publication_year=2006&=&journal=Management+Sci.&=&pages=1015-1030&=&doi=10.1287/mnsc.1060.0552
- https://www.hbs.edu/ris/Publication%20Files/16-124_7ae90679-0ce6-4d72-9e9d-828872c7af49.pdf — https://www.hbs.edu/ris/Publication%20Files/16-124_7ae90679-0ce6-4d72-9e9d-828872c7af49.pdf
- https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-2008-11.pdf — https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-2008-11.pdf
- Michael Tsai — https://mjtsai.com/blog/2013/08/14/the-influence-of-organizational-structure-on-software-quality/
- Microsoft — https://www.microsoft.com/en-us/research/blog/exploding-software-engineering-myths/
- https://gist.github.com/chitchcock/1281611 — https://gist.github.com/chitchcock/1281611
- GitHub — https://gist.github.com/kislayverma/d48b84db1ac5d737715e8319bd4dd368
- Amazon Web Services — https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/
- https://queue.acm.org/detail.cfm?id=1142065 — https://queue.acm.org/detail.cfm?id=1142065
- AWS — https://aws.amazon.com/blogs/aws/acm_queue_inter/
- Microservices.io — https://microservices.io/post/architecture/2024/11/09/loose-coupling-enabling-the-winning-org.html
- https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf — https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf
- Slideshare — https://www.slideshare.net/slideshow/scalingagilespotify/15236965
- https://www.jeremiahlee.com/posts/failed-squad-goals/ — https://www.jeremiahlee.com/posts/failed-squad-goals/
- OyoMy — https://oyomy.fr/en/2020/04/l-echec-du-modele-spotify/
- Openapi — https://openapi.com/blog/microservices-architecture-from-netflix-to-api
- DZone — https://dzone.com/articles/adopting-microservices-netflix-0
- InfoQ — https://www.infoq.com/presentations/microservices-netflix-industry/
- DZone — https://dzone.com/articles/adopting-microservices-netflix
- https://www.thoughtworks.com/radar/techniques/inverse-conway-maneuver — https://www.thoughtworks.com/radar/techniques/inverse-conway-maneuver
- Gitbook +2 — https://yoan-thirion.gitbook.io/knowledge-base/xtrem-reading/resources/book-notes/team-topologies
- Google Cloud — https://cloud.google.com/blog/products/devops-sre/announcing-the-2023-state-of-devops-report
- GitHub — https://github.com/SaraLerma/Monolith-To-Microservices
- InfoQ — https://www.infoq.com/podcasts/monolith-microservices/
- Martin Fowler — https://martinfowler.com/bliki/BoundedContext.html
- Packt Publishing — https://hub.packtpub.com/eric-evans-at-domain-driven-design-europe-2019-explains-the-different-bounded-context-types-and-their-relation-with-microservices/
- InfoQ — https://www.infoq.com/news/2019/06/bounded-context-eric-evans/
- InfoQ +2 — https://www.infoq.com/articles/book-review-team-topologies/
- Remenar — https://vladimir.remenar.net/wp-content/uploads/2022/12/Team-Topologies-Vladimir-Remenar.pdf
- Medium — https://medium.com/agile-outside-the-box/team-apis-af2dbc1805e7
- IT Revolution — https://itrevolution.com/product/team-topologies-second-edition/
- Martin Fowler — https://martinfowler.com/bliki/TeamTopologies.html
- Team Topologies — https://teamtopologies.com/news-blogs-newsletters/2024/7/23/newsletter-july-mastering-team-effectiveness-the-power-of-managing-cognitive-load
- Thinkinglabs — https://thinkinglabs.io/articles/2021/05/07/shades-of-conways-law.html
- https://ruthmalan.com/traceinthesand/conwayslaw.htm — https://ruthmalan.com/traceinthesand/conwayslaw.htm
- Eavoices — https://eavoices.com/2008/02/13/conways-law/
- Ruthmalan — http://www.ruthmalan.com/journal/2011/2011journaljuly.htm
- https://martinfowler.com/articles/architect-elevator.html — https://martinfowler.com/articles/architect-elevator.html
- https://architectelevator.com/architecture/architecture-options/ — https://architectelevator.com/architecture/architecture-options/
- https://segment.com/blog/goodbye-microservices/ — https://segment.com/blog/goodbye-microservices/
- https://www.cl.cam.ac.uk/archive/rja14/Papers/npfit-mpp-2014-case-history.pdf — https://www.cl.cam.ac.uk/archive/rja14/Papers/npfit-mpp-2014-case-history.pdf
- https://martinfowler.com/bliki/ArchitectureDecisionRecord.html — https://martinfowler.com/bliki/ArchitectureDecisionRecord.html
- https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ — https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
- https://pubs.opengroup.org/architecture/o-aa-standard/DDD-strategic-patterns.html — https://pubs.opengroup.org/architecture/o-aa-standard/DDD-strategic-patterns.html
- https://www.avanscoperta.it/en/context-mapping/ — https://www.avanscoperta.it/en/context-mapping/
- https://martinfowler.com/bliki/StranglerFigApplication.html — https://martinfowler.com/bliki/StranglerFigApplication.html
- https://www.mckinsey.com/capabilities/transformation/our-insights/common-pitfalls-in-transformations-a-conversation-with-jon-garcia — https://www.mckinsey.com/capabilities/transformation/our-insights/common-pitfalls-in-transformations-a-conversation-with-jon-garcia
- https://itrevolution.com/articles/conways-law-critical-for-efficient-team-design-in-tech/ — https://itrevolution.com/articles/conways-law-critical-for-efficient-team-design-in-tech/
Commissioned from our research desk. Subject to final editorial discretion.
