DevOps Foundation Principles

📜 "Development Operations Done Right" (2006)

An early DevOps vision paper — written at Morgan Stanley in 2006, before the term "DevOps" existed

📄 Read the original paper (PDF)

What the Paper Is

"Development Operations Done Right" (Steve Messina, London, 2006) is an internal proposal written while running the SWAT team in Morgan Stanley's Private Wealth technology group. It argues that the department had mastered team-based development but failed at wider collaboration, and lays out a programme of technology, process, and culture changes to fix that with the people already in the building.

From the abstract:

"We have mastered team based development, but failed at wider collaboration. This is a proposed cultural and technological revolution that has become necessary, in order to provide a means of improving efficiency, by at least a factor of 2, with existing headcount, as well as mitigating some current critical risks."

The proposals came directly out of practices already being trialled in the SWAT team, and the paper describes them as "fairly tactical in nature, requiring only a moderate level of commitment to implement."

The Problem It Observed

The paper opens with concrete drivers, not abstractions:

Risk factors

• Knowledge about turnovers, support requirements, and processes was not discoverable. It survived by being passed down inside teams, or rediscovered just-in-time when something broke.
• Key parts of the development environment were understood by only a few individuals who might leave at any time.

Inefficiencies

• Every team re-implemented its own processes for building, deploying, and testing applications.
• No central index of documentation; every team had its own standards and locations.
• No QA environments, and no documented knowledge of how to set one up. In one case, the scripts needed to set up apps in QA were rescued from a departing developer's home drive on the day he left.
• Teams ran at full capacity in reactive maintenance mode, with no slack to improve the process.
• Developers learned little outside their own application and had little contact with the business.
• Support couldn't monitor their own workflow through the daily flood of email, so emergency turnovers needed a phone call just to flag that a change request existed.
• No automated, real-time dashboard of development and production status.

The paper also names the cultural side plainly: a "not invented here / not my problem" culture, redundant subject-matter-expert dependencies, and the observation that "busy work is not the same as productive work."

What It Proposed: 11 Changes in 3 Areas

Technology changes

1. "Compositional Architecture" methodologies
2. A CEP (Complex Event Processing) framework and tools for developers and end users
3. Full instrumentation of production applications, with a global dashboard showing this information

Process changes

4. Automate build processes and integrate tools with source control
5. A searchable, browsable index of all documentation across the department
6. Team member rotation through the SWAT team for business, technology, and ownership exposure
7. Agile project management tools

Culture changes

8. A culture of sharing knowledge between teams, e.g. an "Assumption Wiki"
9. Developer education: Friday Tech Questions, brown bags, master classes
10. A manifesto and implementation of Developer Support
11. A developer skill rating, with defined skills, metrics, and behaviour for each level

flowchart LR
    T["Technology changes
compositional architecture, CEP,
instrumentation + dashboards"] --> O
    P["Process changes
automated builds, doc index,
SWAT rotation, agile PM"] --> O
    C["Culture changes
knowledge sharing, education,
support manifesto, skill ratings"] --> O
    O["At least 2x efficiency
with existing headcount,
critical risks mitigated"]

How It Was Already Being Put Into Practice

The paper isn't purely speculative; most proposals were running or in negotiation:

• Continuous Integration build and testing. The SWAT team was implementing an end-to-end CI build and testing solution for C#, Excel, VB, and Java applications, documenting the process on a borrowed server.
• Source control and IDE integration. Working with global engineering teams to document an end-to-end process for integrating version control with common IDEs, then handing it to development and support teams.
• Unified monitoring. Negotiating with engineering teams to extract an admin console into a reusable library, so any application could expose remote log viewing and a one-click way to reach the logged-on user, feeding a unified production view.
• CEP framework. Discussions with Enterprise Architecture to give every message and state change a unique ID via a shared logging framework, so a request could be traced through multiple systems and explained as a graph. The stated goal: end users and developers "should be able to discover all the information they need for themselves, in one place. Self-reliance is key."
• Dashboards. Two proposed dashboards built as a plugin web framework: a development dashboard (build and test status, burn-down charts, code quality, version-control clash monitoring) and a production dashboard (a global heatmap of application status with alerts and live metrics).
• "Hot seat" rotation. Seconding developers into the SWAT team for around three months: an intentionally elite, temporary position with hard work, recognition, and a master class in the team's practices.
• Developer education and the Assumption Wiki. Friday Tech Questions documented on the team wiki and graded against three levels of experience; a wiki where developers register gaps in understanding, research them, and present the answers back to the group.
• Agile project management. Organising a vendor demonstration of an agile PM tool for interested parties across the bank, with an evaluation to be fed back to engineering groups.
• A Developer & Operations Support manifesto. The paper notes that smaller teams could spend up to 40% of their time during a turnover week simply "negotiating" a successful deployment, after development was complete. The manifesto's three aims: clearer development support practices and responsibilities, simple and available documentation, and automating the bulk of the development-to-QA/production process.

Compositional Architecture

The paper's most ambitious idea is an architectural paradigm aimed at scaling productivity out of proportion to team size, summarised as: never rebuild working code, never re-dist working code, never retest working code. It draws on Roger Sessions' work on partitioned architectures (partitioning makes system states additive rather than multiplicative) and John Boyd's observation from dogfight analysis that speed of iteration beats quality of iteration. It also proposes a Production Risk Metric: combining unit-test code paths, the number of users on those paths, and the dependency tree of changed code to score the potential production impact of a change before it ships.

Why It Reads as Early DevOps

The term "DevOps" did not exist in 2006. Without that vocabulary, the paper argues for things that later became standard practice: automated builds wired into source control, instrumentation of production systems surfaced on shared dashboards, documentation and knowledge made searchable instead of tribal, and deliberately breaking down the wall between development and operations support. Its framing of measurable team efficiency, key-person risk, and deployment friction as one connected problem is the part that holds up best in hindsight.

Early DevOps thinking from 2006 — written before the movement had a name.

📄 Download "Development Operations Done Right" (PDF)