Short: DevOps and Separation of Duties

Can (should) DevOps and "separation of duties" co-exist?

As I understand it, separation of duties is a risk mitigation tactic in organizations, whereby "only Team A" can carry out some important set of activities. This approach does seem to have some value, on the surface.

For example, a software project manager may be more motivated by feature delivery dates than acceptable software quality; so it might make sense to have a separate QA role (or team) which enforces best practices for quality. Similar arguments can be made for software/data/infrastructure security, change control, and release implementation.

But DevOps proponents suggest otherwise. If a single team owns every aspect of the software (every phase, every nonfunctional requirement, etc.) even after its release, many things should go much smoother.

But how do we mitigate the original risks? Are they any less real now than they were before? I have seen a few strategies proposed and implemented to this end thus far:

* Automation as a gatekeeper
* Domain experts as a shared but team-embedded resource
* Emphasis on self-service tools which enable while enforcing compliance
* ACID principles  - changes should aim to be Atomic, Consistent, Isolated, and Durable (often enabled by cloud and container technologies, as well as infrastructure automation)