DevOps? NoOps? How about AllOps?
An interesting debate regarding DevOps versus NoOps has been active for some time. NoOps was introduced by Mike Gualtieri in a Forester blog post back in 2011 where he indicated that DevOps was a step backwards and that NoOps was the way to go:
“DevOps is a term used to describe better communication and collaboration between application development professionals and infrastructure operations professionals. "Dev"+"Ops"="DevOps." The goal of DevOps to make the process of deploying applications faster and smoother. DevOps is a loosely defined set of emerging practices to get developers and operations pros to work together. Developers and operations professionals are often at odds. Developers want to release software more frequently; operations professionals want to protect the stability of the infrastructure. I applaud the goal of DevOps to improve the process of deploying application releases.
"No"+"Ops"= "NoOps"
The last thing many application developers want to do is have a sit-down with the ops guys. Besides which, they don't understand. Sure, the ops guys efforts are critical to our applications because they have to run on something. But, developers should look to spend more of their time getting closer to the business, not getting closer to the hardware. I fully acknowledge that there is a need for quicker and less-rickety deployment processes. But, I think DevOps is a step backward. Instead I propose NoOps. The goal of NoOps is also to improve the process of deploying applications. But, NoOps means that application developers will never have to speak with an operations professional again. NoOps will achieve this nirvana, by using cloud infrastructure-as-a-service and platform-as-a-service to get the resources they need when they need them. Of course, this is not just about getting virtual machine instances. It is also about release management. Ops can run this public, private, or hybrid infrastructure and give developers the tools they need to responsibly deploy applications faster.”
It got me to thinking that maybe AllOps is a more appropriate context to set for ourselves. Let me explain by way of the model from our book shown below:
A basic principle of the model is that the typical reason for undertaking projects is that something in Business Operations (upper right) needs to be changed - that the Value we are currently getting is somehow insufficient and there is some new Value that we would like to receive. In this view though, the project is not the thing - delivering this new desired Value as quick as possible back into Business Operations is however the thing. It is only when Business Operations can use something that it has any actual Value.
The basic approach embodied in the model is as follows:
- We start from the “Right Premise” by understanding what is happening in current Business Operations and what it is that we would like to change (Operate quadrant)
- This allows us to focus on figuring out the Right Things”(Innovate Quadrant)
- Portfolio and Programme Management enables us to do them in the “Right Way” and in the “Right Sequence” (Prioritize quadrant)
- Project and Product Management, when coupled with Release Management where we do work in Sprints (i.e. iteratively and incrementally), helps us to ensure that the “Right Features” are “Done Well” which in turn create Value back in Business Operations (top of Prioritize, all of Co-Create and rolling back into the Operate quadrant)
The continuous arrows in the center of the model are meant to represent that the primary goal of all participants is to start delivering the new desired Value back into Business Operations as quickly as possible. This means that everyone necessary from business operations (which includes IT Ops), business and IT leaders, portfolio, programme, project and product managers, and development teams all need to be focused on Value delivery so that the organization can continuously realize Value in business operations - which means that AllOps is the focus. Ops in the model refers to Business Operations - not just IT Ops. Business Operations is about delivering to the organizations clients/customers. It's the face of the organization.
The ICD Model© also recognizes that there is more to Business Operations than simply deploying new IT applications faster. There may also be implications for business processes, organizational structures, roles and responsibilities, information sources, people capabilities, etc. We can't solve holistic messes at The Edge of Chaos simply by building more applications and deploying them faster to production.
Within the ICD Model© all facets of the business, including IT, operate as a single team in Value delivery. Yes each area brings different skills and different responsibility/accountability but ultimately it's only when they break down these artificial boundaries that we added over the years that they can start to operate coherently and cogently towards maximizing Value delivery.
So let's stop treating IT as this special case inside an organization that operates as if it is separate form the business and adopt an all AllOps view - that everyone in an organization exists to support Business Operations in some way. Period. Even those who dream up entirely new products. The goal of Innovation in existing or new products is to positively affect Business Operations and to create Value for its Clients/Customers. Without Clients/Customers most organizations really have no reason to exist. An AllOps view simply recognizes that basic premise.
In the book we make the case that one day we might get to the stage where we "will have stopped referring to Agile as something that is separate from how the rest of the organization works. Once that happens, people will stop calling it Agile and simply see it as how they normally work. This is the state we refer to as “Next Generation Agile” and the point at which we can stop using the term entirely." That's another way of saying we all exist to support Business Operations.
What do you think? Is an AllOps focus the way to go?
