DevOps: Befriending the alien
We are living in interesting times where organizations are
re-thinking their commitment to value. There is more focus on the question:
"Are we doing this right and creating value?"
We are living in interesting times where organizations are re-thinking their commitment to value. There is more focus on the question: "Are we doing this right and creating value?"
Globally, production cycle times are getting reduced and time to market for any product is expected to be "quick". There is a concerted focus on automation which has given birth to relatively new jargons such as DevOps, Orchestration etc. Despite decades of process and policy re-engineering, we run the risk of missing out on success without automation systems to support us.
So what are we trying to bring in our lives?
DevOps is an interesting practice that has silently invaded the IT professional's sphere of influence - almost like the friendly neighborhood alien made famous by Steven Spielberg.
Let us figure out for a minute on what is DevOps and why it makes a difference to us here?
"DevOps is associated with a collaborative set of practices that "influences" IT Development, Testing & Operations/Service Management staff to join hands and deliver high quality IT Services/applications to the end-users "more frequently & consistently".
Based on my recent experiences with clients and prospects, I can say that nearly every global IT organization has heard about it and is interested to explore this 'jargon' (I say this is a jargon since there is no official framework which is authoritative enough to set a global definition and prescription to implement DevOps).
I have a rather radical observation and interpretation here. Innovations in technology mainly around Cloud, Mobility & Social space has taken a big lead compared to people practice maturity levels. There are expectations now to roll out frequent application/service releases - in some cases, a daily release.
This has resulted in the need of more "people centric" development methodologies that sometimes need radical shifts in organizational philosophy. For e.g. how many of us have actually seen application development and IT operations members sitting together in the same room working daily to rollout regular releases?
In the next couple of years, this debate is likely to continue about how much of local collaboration is required to make DevOps a realistic goal. Again, technology has moved ahead in the game here, and it can be actually seen among the DevOps tool vendors where they aggressively claim to make this happen.
There are tools in the market that claim to automate the entire software delivery provided the developer writes the code (many a times using re-usable components), tester has uploaded the test cases at the same time when code is written and the environment/infrastructure is readily available on-demand. In a nutshell, you can check-in the code into a repository and go home; the rest is taken care of by the systems to make the new release available to the end-users.
But reality is different. It will not be so easy to adopt this disciplined practice - it is like applying moral science lessons in a chemistry lab!
The success of this concept hinges on the level of understanding of all the stakeholders involved and befriending this concept - however alien it may sound. (In the end, even the scientist ended up liking ET!)