I started my technology writing journey with a 2 part blog (One & Two) on Service Delivery Excellence, before jumping into the DEVOPS bandwagon, but now as I read across all related discussions, I end up feeling that the good kid is always the DEV and OPS are the unnecessary tag along.
We always talk about how the end goal is to make quicker releases, fixated towards adding value with continuous deployments, insinuating that OPS is the roadblock towards that goal, or that collaboration is the name of the game, and OPS should stop being confrontational, etc, etc.
Today, I am on the other side of the fence and will sit on judgment on the question of if any changes are needed at all for the OPS teams to engage themselves into the DEVOPS culture.
The lifecycle framework, defined by ITIL, COBIT or MOF (looking at the ‘Microsoft Operations Framework’ with renewed interest after my initial days of GRC stint) is quite similar across all phases of IT Service Delivery and consistent with the DEVOPS principles of stable, scalable, lean and quicker delivery of value to the user community.
ITSM’s broadly references
- Focus on services rather than systems
- Process oriented management approach
- Continual Improvement as part of their Deliver, Support and Operate lifecycle,
Then, the questions arise:
- Does the Service Delivery Framework (SDF) changes?
- Do we have to revisit the 3P’s (policies, processes & procedures) which are working well, as we move on to align ourselves with DEVOPS?
Historically in almost all large organizations, Operations [OPS] has always worked in silo, minimal trust of the development & testing teams to deliver a high quality change with a very suspicious view of all changes, as understandably they are responsible for the stability and maximizing availability of the Production environment with a consistent user experience.
On the other hand Developers [DEV] are under greater stress to deliver features and fix defects at a much faster pace due to many reasons. Shorter coding windows, cutting corners on testing cycles, deferring performance/ regression issues ( yes it happens!), and of course your team’s efforts are not just measured but the survival depends on the count of production runs rather than on quality, innovation or improvements.
“Throwing a dead cat over the wall” is how someone wrote of the handover of new code to OPS, I wouldn’t agree with that analogy, as OPS will at least expect it to land on three legs, a DOA would be thrown back with the same impunity!
The business value, Operations add in terms of availability and support to the customer far exceeds the risk of adding half-baked features in the ‘need for speed’. On the other hand it’s also imperative that we work towards a goal of a collaborative approach to a stable, sustainable and faster delivery of features to remain competitive.
I define DEVOPS as “combining a right mix of interdependent variables like People, Process and tools for fast and quality software delivery”, and Operations contribution towards this effort spans across all the variables adding immense value towards a successful initiative, with new insight of the challenges and shared concerns in improving the processes and delivering better software.
DEVOPS is not just about creating scalable infrastructure on the fly, or implement newer tools for rapid and automated deployments, or even about creating a SWAT response around monitoring. It is equally about envisaging a collaborative model, ensconced in proven principles and practices in order to add business value by delivering quality software rapidly.
So, what should OPS do differently to be an effective contributor of the DEVOPS team?
To start with, OPS should grab the advantage of being involved at the outset of the planned lifecycle by contributing with constructive inputs and using their expertise in:
- Assessing Infrastructure impact and capacity review.
- Influence design decisions & operational needs.
- Review all Service commitments and SLA’s
- Security and entitlement management
- Highlight any potential changes to operational procedures.
- Update monitoring and alert mechanisms
- Improve automation.
- Upgrade run-books; training of the service desk, share knowledge.
OPS also can keep a strict overview in the issues faced during the deployment/testing journey of the release and measure it against their own operational readiness thresholds.
The best outcome of this collaboration, in my opinion is that there will be no need for a ‘Warranty’ or ‘Initial support’ period by the DEV teams. OPS will be fully aware of the journey and has partnered to ensure the ‘Cat’ has passed the minimum health checkup and also is fully aligned with the changes to the support model from day one.
In fact the ‘Cat’ will no more be chucked over the wall, rather will formally pass through immigration!
Thank you for the time.
Visit my blog http://askhurram.com/
Read On, Live On.
