DevOps
is the culture in which the development teams partner with the operations/IT
for the purpose of seamless integration of development cycle through to the
implementation and continued operations. Though tools and processes (For
example, agile processes show your 'DevOps' intentions) help DevOps, it's the
cultural aspect of DevOps that is considered most important than those tools
and processes. That cultural aspect makes it difficult and a dampener in many
organizations for better adoption of DevOps.
In
the ideal world, developers support the IT guys by making provisions for
diagnostics, performance, load testing etc. early in the development cycle
itself. Operations people support developers by giving quality feedback about
users, their behaviours features the users like most, exceptions etc. in a
timely manner. Some automation is a real possibility in this area, but still if
the organization hasn't caught up with the DevOps culture, returns from these
automations and tools cannot be large.
Some of the DevOps Dampeners
- Silos within the organization spoiling effective integration between the development and operations
- Lack of product ownership (to some extent lack of agility)
- Politics, blame game etc. (Dev throwing it to QA and QA throwing it to Operations and Operations finding nowhere to go)
- Out sourcing development under Fixed Price contracts
First
3 points are obvious and a systematic overhauling of the organizational culture
can only address those issues gradually (there cannot be quick fixes for
cultural issues though). But the fourth one is a business decision and it's
very difficult to stop because of the cost arbitrage regimes that we are
operating.
Out
sourcing the development work to an external group, that too under a fixed
price contract would be a big setback for the DevOps culture. In a fixed price
service environment the service provider
earns their margins by efficiently utilizing the resources and giving the bear
minimum as defined by the statement of work (SOW). Under these conditions, it's
very difficult to expect the DevOps culture to flourish. Support to the
operations team is governed by the warranty clauses and subsequent AMCs (Annual
Maintenance Contracts) and not by team spirit and ownership
It's
very difficult to encourage the DevOps culture under the contractual culture;
that's why the agile proponents preferred customer collaboration over signed
contracts. So the question is if it's mandatory for the DevOps to die under the
out sourcing contractual environments?
I
am a born optimist and I still have some hopes.
- Customers will have to evaluate the service provider and establish trust with them through initial pilots.
- Once that trust is established, they need to treat the out sourced development team as their 'own virtual' team.
- Since the trust is established, the customer should focus on collaboration over the signed FP contracts.
- Constant traveling of Dev team members to customer premises and customer operations staff to the development houses as CBMs
- Processes and tools must be used to bring about the trust
- There has to be a separate SLAs between Dev and Ops but not in the form of signed contracts but mainly as team norms
