Does your business structure help or hurt your DevOps move? “Organizational DevOps” is the enterprise level action for a DevOps strategy and tactics. There is a natural struggle when moving towards DevOps, but therein is the value. First some context …
Process or Project
Operations management is the attempt to run things better – in the current steady state. Generally, ops tries to achieve a fixed scope (getting the job done) while minimizing schedule and resources.
Conversely, development attempts a change in response to disruption or update request. Development is project based. Generally, agile software dev involves maximizing scope with fixed schedule and resources.
There is nothing wrong with this contradiction. We almost always have both. From the highest level, the COO and CTO are often two separate roles.
Yet, this tends to get exaggerated with DevOps. The desire for shorter development cycles, increased deployment frequency, and more dependable releases has made these differences more pronounced. You may call it “organizational DevOps magnification.” Yes, change is the new constant.
DevOps seeks to improve steady state efficiency (ops) through more frequent state changes (dev)!
Operations or Development
DevOps is both Dev and Ops
Whether you like the ops or dev, the whole view wins. DevOps is a two-way street. The thinking is that both sides work more closely with, be more like, and check each other.
DevOps drives the ops team to act more like a dev team. We see this in more development-like tooling, virtualization, test execution, creation of infrastructure as code, micro-service enablement, etc.
At the same time, DevOps drives the dev team to act more like an ops team. We see this (i) at project reqs time with more thought for architecture, production/analytics data/feedback, and (ii) in doing more risk analysis, change management and disaster recovery planning, etc.
We have (want) Ops driving Dev concerns and Dev driving Ops concerns. DevOps means both.
Organizational DevOps
So, how should an enterprise respond to the DevOps movement? It is clear that one or both of ops and dev teams have to adjust their most basic ethos. Albert Qian talks about “transforming the organization … for the better” and the “emergent business ecosystem.”
Team Measure
Imagine agile devs teams being held to an SLA and ops teams being measured by velocity of innovations delivered. Blindly force fitting a dev team to perform business running activities is not the answer. Nor is an ops team doing business changing activities.
Crazy talk: All three scope, schedule, and resources cannot at the same time be the highest priority.
Team Size
At first look, DevOps seems to be lowering the role and team size of [true] ops. But, at the same time making what remains of higher importance. This is because the final value proposition rests in ops. Ops is client facing and carries the company branding. There is a limit. This march ends with the scary sound-byte “NoOps,” which at the same time would have the most business value!
A trade-off exists and the company brand is in the cross-hairs. The stakes are high, so the business must find the same old balances:
- Versatility and reliability
- Development and operations
- Investment and return
There is nothing new here, but there is organizational DevOps magnification of the timing and effects of a good or poor choice.
Team Vision
Any DevOps effort has to come from a strategic vision of the highest level and not as a dev novelty. The two (or more) chiefs of ops and dev must know where they stand with each other. They must share a vision; this is “Organizational DevOps.”
The winning business will return the most ops value from the least dev investment.
