Divided Ownership of Software Delivery as a Failure of Enterprise Architecture
Abstract. The term DevOps was coined to dissolve the boundary between building software and running it. It has since been institutionalised as a job title, a team and, in larger organisations, a department — reconstituting the very boundary it named a remedy for. This paper argues that the persistence of the split is not adequately explained as a failure of engineering culture alone. It is equally a failure of enterprise architecture: organisational boundaries determine measurement, measurement determines behaviour, and behaviour then hardens into beliefs that defend the boundary. Using the analogy of a body whose limbs answer to separate masters, the paper sets out the mechanisms by which divided ownership damages a business, distinguishes legitimate specialisation from severed command, offers five diagnostic questions, and proposes a remediation sequence in which ownership boundaries are settled before technology.
DevOps is a compound word. Development and operations. It exists because the two functions had been separated in most organisations, and because the separation was doing observable damage: developers built software and passed it over a wall; operations received it and was held accountable for a system it had no hand in shaping. The word named the remedy — that the people who build a thing should be the people who run it.
The present state of practice is an inversion of that intent. DevOps is a job title. It is a team. In larger organisations it is a department with its own cost centre, its own director and its own line in the reporting structure, supported by a dedicated recruitment market. A word coined to remove a wall has been used to build one, with the name of the remedy on the door.
The common diagnosis is cultural, and it is not wrong. I argued it myself in an earlier treatment of the same subject. The argument of this paper is that it is incomplete, and that the incompleteness explains the poor success rate of remedies aimed at culture alone.
What people optimise for, what they decline to own, and whom they hold responsible during an incident are shaped by boundaries drawn long before any of them were hired. Those boundaries are enterprise architecture, whether or not a person holding that title drew them.
The causation is bidirectional. Once a structure has persisted for several years it produces beliefs, and those beliefs then defend the structure: that developers cannot be trusted with production; that operations exists to refuse; that an organisation of this size and this regulator has no alternative. By that point, redrawing the boundary is insufficient on its own, because the people on either side of it will faithfully reconstruct the previous arrangement inside the new one.
Two conclusions follow. Values work without structural change produces a statement of intent that the measurement system immediately contradicts. Structural change without the accompanying cultural work produces a reorganisation that reverts within a year. The remedy has to be applied at both ends, and the end more often neglected is the architectural one — not because it matters more, but because it is the one almost never attempted.
Consider what a human being would be if each part answered to a different authority.
One party holds the hands and is measured on grip strength. A second holds the feet and is measured on distance covered. A third holds the eyes and is rewarded for detail observed. A fourth holds the arms and is judged on reach. None is negligent. Each is diligent, and each optimises the thing they have been given and can be assessed on.
The body does not go anywhere. The feet advance while the eyes examine something behind. The hands grip an object the feet are already walking away from. Every part meets its target and the organism starves.
What makes a body work is not that each part is well managed. It is that there is one nervous system carrying a single intent, and one circulatory system carrying a shared supply. Specialisation is not the defect — a body is nothing but specialised organs. The defect is specialisation without common command. Once the nerve is cut, competence in the limb stops helping and begins to hurt, because a strong limb pulling in the wrong direction does more damage than a weak one.
The damage begins as arithmetic, recorded in two documents that are rarely read side by side. The delivery organisation is measured on throughput: features shipped, roadmap delivered, dates met. The operations organisation is measured on stability: uptime, incident count, change failure rate. Both are legitimate objectives. In a system where a change is the only means of delivering value and simultaneously the principal source of risk, they are also in direct opposition: one party is funded to increase the rate of change and the other is funded to reduce it.
No participant is behaving badly. A change advisory board that returns a release with a question is doing what it was constituted to do. A team that wraps a schema change in a feature flag so that it does not qualify as a change is also doing what it was measured to do. The friction both parties complain about is not a deficiency of goodwill; it is the designed output of the arrangement.
The characteristic incident involves ten people from ten departments on a conference call, each arriving with a partial view and a private need to establish that the fault lies elsewhere, and spending the first forty minutes on jurisdiction before anyone touches the system. This is commonly described as a cultural failure, and the defensiveness is real. It is also structural: no single party holds enough of the picture to diagnose the fault, and every party holds enough of the blame to be defensive. The same ten people in one team with one objective resolve it in minutes, and the observable culture on the call improves without anyone having addressed culture directly.
Production feedback is the only authentic information a system produces about itself. Where it lands on people who cannot change the code, and the people who can change the code never receive it, the organisation stops learning about its own product. The degradation is not abrupt. The organisation simply ceases to improve, and the cause is invisible on every dashboard being reviewed.
Vogels described the alternative in 2006, and it has been quoted for two decades without being widely acted upon:[2]
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. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service.
What is being described is not a tooling decision and not a statement of values. It is an ownership boundary — an architectural determination of where responsibility for a system begins and ends.
Conway observed in 1968 that an organisation produces designs which copy its own communication structure.[1] The observation is usually cited as a warning about software. It is more useful read in the opposite direction: if the required system is known, a great deal is already known about the structure capable of producing it, and every other structure chosen instead is a decision to produce something else.
This makes the organisation chart a technical artefact and its drawing a technical decision — which is why it should not be settled solely on the basis of headcount, procurement convenience, or which supplier happened to sell the tooling. Where responsibility for a service is divided across four departments, the interfaces between those departments become interfaces in the system. They acquire queues, request forms, service level agreements and waiting time. That handoff cost is real engineering cost, paid daily and indefinitely; because it is distributed across four budgets, no single department observes the total, and therefore no single department can build the case for removing it.
Enterprise architecture is the practice of keeping business intent, the systems that deliver it and the people accountable for them aligned to one another: determining where boundaries fall, what each side of a boundary owes the other, and who holds the decision. Where it is done badly, no amount of values work survives contact with the measurement system, because individuals are being asked to act against their own assessment. Where it is done well, the culture is not thereby fixed — it is made affordable. Cooperation stops costing an individual something to offer, which is the condition under which the stated values become sustainable rather than heroic. Heroism does not scale beyond the people currently performing it.
Creating a DevOps department is what an organisation does when it recognises the symptom and treats it at the wrong layer. The wall is causing pain, so a team is established on top of the wall to pass work across it more efficiently. The wall remains, now with dedicated staff, a budget, a director with a career interest in its continuation, and a name that makes it difficult to discuss.
None of the foregoing argues that every engineer should do everything, and that misreading is why many attempts at integration fail. A body is composed entirely of specialists. Deep expertise in networks, storage, databases and cluster operations remains necessary. Removing those specialists and asking a product engineer to absorb their work is not integration; it is amputation.
The distinction that matters is not whether a specialist team exists, but what that team owns.
The same skills and frequently the same people; entirely different architecture and entirely different outcomes.
The organisation chart will not reveal which arrangement is in force. The following questions will.
The remedy is neither a reorganisation nor a renaming. It is architecture performed in a specific order: establish what the business is attempting to do; identify the capabilities that deliver it; draw service boundaries such that each can be owned end to end by a team that can be held accountable for it; and only then determine what platform, tooling and specialist support that structure requires. Ownership first, technology second. Most failed transformations invert this order.
The second half cannot be drawn on a diagram and cannot be omitted. Ownership must be accepted as well as assigned, and a team handed responsibility for production on Monday does not feel accountable for it by Friday. That is the work of a definition of done that ends in production and is enforced; of engineers carrying the pager for their own service, with leaders visibly carrying it alongside them; of incident reviews that establish cause rather than fault, held often enough to become ordinary; of hiring and promoting for willingness to own a system end to end rather than for depth within a silo; and of ceasing to reward heroics, since an organisation that celebrates the rescue purchases more of whatever required rescuing. None of this survives while the structure contradicts it, and the structure, once corrected, does not populate itself.
Divided ownership of software delivery is a cultural problem with an architectural cause, and the two are not separable in practice. The structure teaches the behaviour; the behaviour then defends the structure. Remedies aimed at one end alone fail predictably: values work is contradicted by the measurement system, and structural change reverts under the beliefs it did not address.
Where an organisation is hiring for DevOps, the vacancy is real and the pain behind it is real. The question worth asking before filling it is what the role is compensating for — because a body with several masters does not need a better coordinator between the limbs. It needs a nervous system.