This is the fifth in a series of blogs about enterprise DevOps. The series is co-authored by Nigel Willie, DevOps practitioner, and Sacha Labourey, CEO, CloudBees.

In a previous article we discussed creating a standard taxonomy and from there defining your technology stack. This is an important first step; however, it is also critical that you define a process to govern requests for changes to this stack.

It is a given that in the world of technology there is rapid change. It is also a given that the rate of change will only increase in the future. A technology stack that ossifies will lead to significant difficulties and lost opportunities. By the same token, an uncontrolled proliferation of solutions will lead to greater financial cost, a likely divergence in process and potentially a loss of the feedback and process control that is critical to successful DevOps. If your organization is heavily regulated, it could also lead to a reduction in auditability and the incumbent risks associated with this.

It is thus critical that a process is created to enable and govern change. This may already be in place in your organization, but in our experience, once an organization starts to adopt a DevOps mindset, the rate of request for change increases and the cadence of governance decisions needs to be able to respond to this. A further consideration is that DevOps relies on practitioner empowerment. Many extant governance processes rely on central command control and this is anathema to the culture we are looking to inculcate in the organization.

Below we detail a range of considerations and a potential approach to governance.

Within a governance board, we believe the following considerations should be represented.

• Governance chair: Chairs the meeting, ensures minutes are taken and discussions are documented. Is accountable for maintaining the core principles that requests are judged against. Includes any change to the core principles.
• Practitioner representative(s): Presents the request(s) and represents their community.
• Enterprise architecture representative: Owns the Enterprise Information Management (EIM) and acts as design authority for technology within the organization.
• Service line representative: Owns the provisioning of services for those capabilities which are deemed to be centrally provisioned.
• Infrastructure representative: Represents that part of the organization accountable for centralized infrastructure provisioning. Even in an organization that has fully adopted cloud, somebody will be accountable for that relationship and provisioning.
• Procurement representative: It is likely you have a vendor strategy. This needs to be represented. Assists with RFP considerations if the proposed change looks to have potential to benefit the organization. You may have commercial arrangements with one vendor that are pertinent in the capability space. Larger organizations may have actually invested in a vendor (such as the automotive industry).
• Security representative: Represents security considerations and ensures security is engaged at the earliest possible stage.
• Financial representative: Represents whoever owns the overall budget and signs the check.

Please note in a large organization each consideration may be represented by a different individual. In smaller organizations, an individual may represent more than one consideration. At startup, having awareness of these considerations will assist in ensuring you create a robust and scalable process even if a single individual is involved in making the decisions.

Suggested governance board outputs:

• This request is in line with our principles and should be centrally provisioned
• This request is in line with our principles and should be locally provisioned
• This request is not in line with our principles, our principles should change.
• This request is not in line with our principles and is rejected.

Hopefully, this decision list is self-explanatory. In our view, a key consideration is decision point three. It is important that you consistently question whether your principles are correct and leave the opportunity to amend these in line with changes in circumstance and objectives. In our experience, this also stresses to the practitioners that they have a measure of control in the governance process and this helps to drive engagement and the collaborative culture that DevOps thrives upon.

The last point we wish to stress is that while all these considerations are material, any governance model has to be fit for the purpose of making robust and rational decisions rapidly. Governance is a means to an end, not an end in itself. You should constantly validate that you are not building bureaucracy and waste into this process, as boards and processes tend to mutate and bloat over time if not consistently challenged.

Follow the series from Sacha and Nigel

1. Enterprise DevOps: An Introduction
2. Enterprise DevOps: I Wouldn't Start from Here: Understand Your DevOps Starting Point
3. Enterprise DevOps: Context is King
4. Enterprise DevOps: Creating a Service Line
5. Enterprise DevOps: On Governance (this post)