My notes from the DevOps Handbook

by Gene Kim, Jez Humble, Patrick Debois, John Willis

Part II: Where to start

We must pick our transformation projects carefully - the ones that will improve the state of our organization the most.

Integrate testing into everyone's daily work instead of a separate phase.

The practice on relying on a stabilization phase or hardening phase at the end of a project often has very poor outcomes, because it means problems that are not being found and fixed as part of daily work and are left unaddressed, potentially snowballing into larger issues.

Greenfield vs brownfield services

Greenfield projects - new software or initiative in the early stage of planning or implementation where we build our applications and infrastructure anew with few constraints.

Brownfield projects - existing products that are already serving customers and have potentially been in operation for years. They are usually with significant amount of technical debt, such as no test automation or running on unsupported platforms.

DevOps is for both starting greenfield projects and transforming brownfield projects.

The significant predictor of performance of an application is whether the application can was architected or can be rearchitected for testability and deployability.

Brownfield projects are those that have the largest potential business benefit, they are the most relied upon with the largest amount of customers and revenue depending on them.

When transforming a brownfield project we may face:

Consider both systems of record and systems of engagement

Bimodal IT systems: * systems of record - ERP-like systems that run our business * systems of engagement - customer or employee facing systems

Type 1 systems:

Type 2 systems:

DevOps can break chronic conflict between doing it right and doing it fast.

When we improve brownfield systems, we should not only strive to reduce their complexity and improve reliability and stability, we should also make them faster, safer and easier to change.