I had the absolute pleasure last year of speaking at the DevOps Enterprise Summit 2015 in San Francisco and I’m pleased to say the video is available here. In this post I’m going to summarize my talk.
In my experience many large enterprises would love the adoption of DevOps to be as simple as bringing Development closer to Operations. In practice, they need to consider many development teams, multiple suppliers and multiple service providers, not to mention multiple business divisions. I believe that the simple act of re-evaluating and re-defining your Platform-as-an-application (PaaA) will have a significant impact on the improvement of IT.
It is first helpful to start with a working definition of DevOps:
We value: Enhancing IT systems to meet the business’ needs over IT operating efficiency
How can we organize everyone towards this common purpose? Most enterprises are far too large to make putting everyone in a single cross-functional team possible. Jeff Bezos, founder and CEO of Amazon.com, has recommend that you should be able to feed your team with two pizzas (i.e., 6-8 people per team). How in a large enterprise do you create end-to-end teams aligned to deliver high-throughput, complex IT without large teams? This is what I call: “The Two Pizza Paradox.”
To visualize the problem, we can draw a simple abstraction of the end-to-end software lifecycle and overlay the traditional functional teams—and they are littered all over the place.
Try to avoid using acronyms and abbreviations in your diagram, spell out release and UI etc.
In some ways organizing by skills is similar to organizing a zoo. We put the DBAs together over here, the Developers over there, etc. With a zoo you certainly aren’t thinking about organizing the animals to help them achieve a common goal. When you organize a zoo, you are trying to prevent animals from eating each other, or worse yet eating the public! The zoo metaphor goes further because zoos aren’t necessarily the best environment for nature to thrive in. If you think about a rainforest there is an amazing thriving autonomous, ecosystem filled with incredible symbiotic relationships. Zoos take a lot of money and micro-management just to keep them running.
A better way?
I think we have to rethink our lines of division and go back to prioritizing our products. Products are the things we need to optimize, and what we need to protect. So let’s create end-to-end teams to develop and operate products. We can even interpret the word DevOps as literally meaning:
Organizing for throughput by forming teams that both Develop and Operate products end-to-end.
Now, each product has one owning team primarily concerned with its development and support, or more importantly, its welfare and ability to evolve at the pace of business. There is no wall to chuck software over. Keeping these team sizes down by decomposing products is a common practice. The logical and fashionable conclusion of this is implementing Micro Services.
But what about the typical traditionally Operations concerns such as DBAs, Systems Administrators, Network Administrators, etc.?
My recommendation is to recognize that such concerns aren’t just performing a support / operations role. In fact, they are Infrastructure Coders also performing a development role. The platform is their product and is as much a first-class product as the business applications.
A new approach
Potentially, we now have a new approach and a new mind-set for something that has traditionally been very hard to define and had ownership shared by lots of teams. We have a way to tackle something I think is almost always the greatest constraint to IT delivery.
We can define a platform application as a thing on which everything else is run (“everything else” could be called your business applications). This assumes the responsibility of abstracting away all non-core hosting details from the application, allowing the business product teams to focus only on their product. For example:
The great thing about defining your platform-as-an-application is that it suddenly has a lot more in common with the other applications:
Making progress on a DevOps journey can be difficult but I believe re-evaluating your attitude towards the platform to be a valuable and tangible step forward. I’m also proud to now say that the DevOps Platform that my team developed is now open sourced, here on GitHub. It makes implementing the tools needed in the platform trivial therefore allowing you to focus on environments and completing your end-to-end platform application.