Integration-Defect Rework Cost: Conway's Law in the Build

Updated May 2026. Sources: Conway 1968; Capers Jones; DORA 2024; portfolio operational data.

The five common patterns

1. API schema drift. The server changes a field name, type, or nullability; the client breaks. The most common single integration defect, and the one most amenable to contract testing.
2. Async event payload mismatch. The publisher changes the event shape; subscribers process events with stale assumptions. Harder to catch than synchronous API drift because the failure is delayed and often surfaces as data corruption rather than a clean error.
3. Database schema migration race. Two services depend on the same table; one ships a schema change without coordinating; the other breaks. Particularly common when database ownership is informal or shared.
4. Version skew (client / server). The mobile app deployed in production is older than the API expects, or vice versa. Almost universal in mobile-first systems where users may run app versions months old; harder to surface than expected because the failure pattern is small numbers of broken users rather than a clean breakage.
5. Auth contract change. A token format, scope structure, or session-cookie convention changes; a service that depends on the old contract breaks. Disproportionately damaging because the failure mode is usually total (the user cannot log in) rather than partial.

Why integration rework grows with team count

Conway's Law (Mel Conway, "How Do Committees Invent?", 1968) states that systems mirror the communication patterns of the organisations that build them. The corollary, formalised in much subsequent work, is that integration defects scale roughly with the square of the number of independent teams, because each new team adds N-1 new team-to-team communication interfaces.

The practical implication: a single-team organisation has essentially no integration rework (it has design defects and code defects instead). A 5-team organisation has integration rework around 20 to 25% of total rework spend. A 30-team organisation can have integration rework above 35%. The growth is not linear, and it is the single largest reason microservices architectures often disappoint on their first measurement: the saving from smaller deployment units is overwhelmed by the cost of new integration surfaces.

The Inverse Conway Manoeuvre (Allan Kelly, popularised by Sam Newman in Building Microservices, 2015) is the deliberate counter: structure teams around the desired system architecture rather than letting the architecture emerge from arbitrary team boundaries. Done well, the manoeuvre reduces integration rework by aligning team boundaries with system boundaries; done badly, it adds reorganisation cost on top of unchanged integration cost.

The detection ladder

Integration defects can be caught at five points, in order of cost-effectiveness:

1. Design-time contract review. The cheapest catch. The two teams discuss the contract before either side writes code. Usually costs 30 to 60 minutes; eliminates roughly 20% of integration defects that would otherwise emerge later.
2. Schema validation in CI. OpenAPI / gRPC / Protobuf schema validation runs on every PR; breaks the build on contract violations. Standard infrastructure once set up; catches roughly 35 to 45% of contract drift before merge.
3. Consumer-driven contract testing. Pact, Spring Cloud Contract, or similar tooling lets consumers express what they require from providers; the provider build fails when it would break a consumer. Catches roughly 60 to 80% of schema-drift defects when implemented end-to-end; requires meaningful upfront investment.
4. End-to-end integration tests. The expensive catch. Tests that stand up multiple services and exercise cross-service flows. Catches the residual integration defects that contract testing missed; cost is high (maintenance overhead, slow CI, flakiness).
5. Production discovery. The catastrophic catch. A customer encounters the integration defect in the wild. Cost is the highest of any category in the rework taxonomy, often by an order of magnitude. The point of investing in the four earlier catches is to keep production discovery to a residual rate.

The contract-testing investment

Consumer-driven contract testing is the single highest-ROI integration-rework investment for most teams with more than 5 services. The upfront cost is typically 4 to 8 engineering weeks (build the framework, integrate with CI, train teams on the patterns). The ongoing maintenance cost is typically 1 to 2% of engineering capacity per service. The avoided rework typically lands at 8 to 15% of total integration-defect rework, which for a mid-sized organisation is usually 1 to 3% of total engineering capacity.

The ROI calculation gets stronger as the team count grows because the integration rework being avoided is growing super-linearly. For a 10-team organisation, contract testing typically pays back in 6 to 9 months; for a 30-team organisation, it pays back in 2 to 4 months. The smaller the team count, the harder it is to justify the upfront investment, which is why most contract-testing programmes are introduced after a costly integration incident rather than proactively. The miscommunication root-cause page covers the organisational mechanics that make this preventable cost so often missed.

Sources

• Conway, M. How Do Committees Invent? Datamation, April 1968.
• Newman, S. Building Microservices. O'Reilly, 2015 (and 2nd ed., 2021).
• Skelton, M. and Pais, M. Team Topologies. IT Revolution Press, 2019.
• Jones, C. Applied Software Measurement. 3rd ed. McGraw-Hill, 2008.
• Pact contract testing documentation. docs.pact.io.
• Google DORA. State of DevOps Report 2024.

Frequently asked questions