A lot of the DevOps conversations I have had lately have been around organization issues and what to do about the artificial barriers and silos that exist in most shops. Interestingly there is a pattern emerging among those discussing or even implementing changes to deal with this discussion. The pattern involves matrix organizations and the rise of what I call a “DevOps Management Organization” (DOMO). The actual names vary, but the role of the organization is consistent.
Most software delivery organizations end up with some kind of matrix where product managers, project managers, engineers, architects, QA are all tied to the success of a given project / product while maintaining a discipline-specific tie. In the case of an ISV, you can add some other disciplines around fulfillment, support, etc. The variable is whether the project/ product is their direct reporting organization or they report to a discipline. And the answer can depend on the role. For example, a Project Manager might be part of the engineering organisation and be a participant in the company’s PMO. Or they might be part of the PMO and simply assigned to (and funded by) the project / product they are working on.
When you add Agile to the mix, the project dimension tends to take on a much higher level of primacy over the disciplines since the focus becomes much tighter on getting working software produced on a much tighter iteration timeline. This behavior leads to the DevOps discussion as the project/product team discovers that there is no direct alignment of Operations to the project efforts. Additionally, Operations is a varied / multi-disciplinary space in and of itself. Thus it becomes extremely difficult for the project/product team to drive focused activity through Operations to deliver a particular iteration/release. The classic DevOps problem.
The recent solution trend to this problem has been the creation of what I call “Ops Sherpa” roles in the project/product teams. This role is a cross-disciplinary Ops generalist who is charged with understanding the state of the organization’s operations environment and making sure that the development effort is aligned with operational realities. That includes full lifecycle responsibility – from ensuring that Dev and QA environments are relevant equivalent configurations to production in order make sure deliverables are properly qualified to making sure that various Operations disciplines are aware of (and understand) any changes that will be required to support a particular release deliverable. In more mature shops, this may grow out of an existing Release Management role or, if a particularly large
Critically, though, this role gets matrixed back into the Operations organization at a high enough level to sponsor cross-operational silo action. This point is the head of what I call the Head of the DOMO and provides the point of leverage to deal with tactical problem as well as the strategic guidance role to drive cross-project continuous improvement into the operations platform space in support of faster execution (aka DevOps speed releases).
Whatever the name, the fact that large scale companies are recognizing the value of deliberately investing in this space is a validation that being good at release execution is strategic to cost-effectively shortening release cycles.
Pingback: How a DOMO Fits « Crossing Silos