Why I write horrible code. (And so can you!)
“Technically, anyone is allowed to edit any system. Since the squads [scrum team] are effectively feature teams, they normally need to update multiple systems to get a new feature into production. The risk with this model is that the architecture of a system gets messed up if nobody focuses on the integrity of the system as a whole.
To mitigate this risk, we have a role called “System Owner”. All systems have a system owner, or a pair of system owners (we encourage pairing). For operationally critical systems, the System Owner is a Dev-Ops pair – that is, one person with a developer perspective and one person with an operations perspective.
The system owner is the “go to” person(s) for any technical or architectural issues related to that system. He is a coordinator and guides people who code in that system to ensure that they don’t stumble over each other. He focuses on things like quality, documentation, technical debt, stability, scalability, and release process.
The System Owner is not a bottleneck or ivory tower architect. He does not personally have to make all decisions, or write all code, or do all releases. He is typically a squad member or chapter lead who has other day-to-day responsibilities in addition to the system ownership. However, from time to time he will take a “system owner day” and do housekeeping work on that system. Normally we try to keep this system ownership to less than a tenth of a person’s time, but it varies a lot between systems of course.
We also have a chief architect role, a person who coordinates work on high-level architectural issues that cut across multiple systems. He reviews development of new systems to make sure they avoid common mistakes, and that they are aligned with our architectural vision. The feedback is always just suggestions and input - the decision for the final design of the system still lies with the squad building it.”
https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf
