This is the seventh in a series of blogs about enterprise DevOps. The series is co-authored by Nigel Willie, DevOps practitioner and Sacha Labourey, CEO, CloudBees.
Hopefully, most of you have read The Phoenix Project. If not, we highly recommend it. (It is actually required reading for all new CloudBees employees.) Those of you who have done so, will be aware that one of the critical issues experienced by the author was a critical dependence on Brent, the key technologist, who solved everybody’s problems. It becomes clear in the book that Brent, as competent as he is, is a logjam as everything passes through that one individual.
Any centralized team introduces exactly this risk. It is one of the fundamental objections that many people raise whenever the idea of a central DevOps team or function is raised. We acknowledge this is a valid concern. Our previous article on <a href="https://cloudbees.com/blog/enterprise-devops-creating-service-line">creating a service line</a> advises some potential approaches.
Regardless of the structure, or structures, you choose it is critical that you avoid becoming a bottleneck to progress. In a large enterprise this can be very difficult, as DevOps initiatives tend to be high profile, flagship programmes. As a result, senior stakeholders are extremely keen to demonstrate rapid progress. This, of course, is a significantly better problem to face than customer apathy! Something it sometimes pays to remind yourself as you try to keep many plates spinning.
Many vendors now deliver capabilities as services. For example, CloudBees Jenkins Enterprise provides a delivery framework that couples a level of central control and consistency with customer self-service. It also decomposes the previous architecture based around larger, shared controllers to a more flexible approach based around individual team- or project-specific controllers, spun up in minutes. All this supports a self-service approach to be pursued in a larger enterprise.
Whether using external or internal capabilities, we recommend that you prioritize customer self-service as a core competence. There are fundamentals that need to be completed to achieve this; exposure of services via API’s, defined patterns that integrate into an end-to-end flow, templated pipelines with drag and drop capabilities, etc.
Today, many larger enterprises follow a matrixed organizational structure. We do not intend to discuss the advantages of various organizational structures in these articles, we would, however, pass on specific advice for anyone working in an organization of this type. It is a given that any service will need maintenance and upgrades. These potentially impose a short service outage. From experience, if a service is shared across business streams within the organization, agreeing on an outage can involve significant negotiation. It is human nature to believe your personal priority has primacy. In matrixed organizations, cross-business stream priority requires consensus. When architecting any service, in addition to the usual considerations (availability, scalability, service latency, etc.) it is useful to consider this factor when allocating consumers to servers, controllers, availability zones, LPAR’s, etc.
In short, key considerations when providing a centralized capability should be:
Your customers can achieve self-service of the capabilities they require wherever possible.
Any service should, wherever possible, consider segmentation via customer to assist prioritization discussions around outages.
Once the fundamental foundation has been created, your focus should be on customer experience and ease of adoption
The role of any central IT team is to enable its customers to deliver rapidly via fully supported, consistent automation capabilities. It is not acceptable to become an impediment to progress to the entire enterprise by imposing dependencies on one group of individuals.
Follow the Enterprise DevOps blog series from Sacha and Nigel
Enterprise DevOps: I Wouldn't Start from Here: Understand Your DevOps Starting Point
Enterprise DevOps: Creating a Service Line
Enterprise DevOps: The Peoples' Front of Judea, or Don't Sweat the Small Stuff
Enterprise DevOps: 13 Principles of Meaningful Metrics Measurement, Part 1
Enterprise DevOps: 4 Further Considerations for Metrics Measurement, Part 2
Sacha Labourey
Sacha is a native of Switzerland and graduated in 1999 from EPFL. While at EPFL, he started his first consulting business - Cogito Informatique. In 2001, he joined Marc Fleury’s JBoss project as a core contributor and implemented JBoss’ original clustering features. Sacha went on to become GM for JBoss Europe, leading the strategy and helping to recruit the partners that fueled the company’s growth in the region. In 2005, he was appointed CTO, overseeing all of JBoss engineering.
In June 2006, JBoss was acquired by Red Hat (NYSE:RHT). As CTO, Sacha played a crucial role in integrating and productizing the JBoss software with Red Hat offerings. In 2007, Sacha became co-General Manager of Red Hat’s middleware division. He left Red Hat in 2009 and founded CloudBees in March 2010. Follow Sacha on Twitter.