DevOps, solving the non-existent problem for good IT

I have been flooded with articles, case studies, and the benefits of DevOps; every newsletter that I subscribe to (over a dozen that arrive in my inbox every day) has at least one link that headlines DevOps. In the initial days I read a few of them with curiosity and forwarded some of the articles to friends and peers in the industry. The flood of discussions and seminars raised my anxiety if I had missed any salient point in my analysis and understanding. So I dug deeper to understand the subject and its relevance to good IT departments.

What is interesting is that many vendors are now offering tools and consultants providing frameworks and expertise on helping organizations create DevOps centers of excellence. It’s the new buzzword that promises to fix the issues faced by enterprises when they deploy new custom solutions. The most interesting and highly impressive manifestation appears as “a cross-disciplinary community of practice dedicated to the study of building, evolving and operating rapidly-changing resilient systems at scale”. Do you get what it says ? I don’t !

If you search for the term online, the definition on Wikipedia is as follows: “DevOps (a portmanteau of "development" and "operations") is a software development method that stresses communication, collaboration and integration between software developers and Information Technology (IT) professionals. DevOps is a response to the interdependence of software development and IT operations.” Note the keywords that stand out, communication, collaboration and integration between IT and developers !

Over the decades there were many methodologies that evolved since we needed to develop “for purpose” software. I am not discussing one over the other or their pros and cons; there are proponents and opponents to each depending on what has worked for them. The point is that whether you followed one or the other, all of them required communication to flow between the stakeholders (Business, IT teams and developers). Else how do you ensure that everyone understands the problem or the opportunity and what is needed ?

When in a group people collectively work together towards a common objective, I would safely assume that they are collaborating. There are instances when differences of opinion or point of view may result in conflict or disagreements; that does not imply that they are not collaborating. The level of integration is determined by the crisp and clear communication from the top as well as within, and a shared vision and objective of their goal. That is how I have seen almost all projects, IT or otherwise, – big or small – getting off the ground.

What changed in recent times that gave birth to this new term and the wave that is following ? The underlying assumption is that development teams and operations teams are independent (which they are in many cases though not a universal truth) and that they don’t talk to each other; that is an interesting hypothesis and rare occurrence when both teams are collocated. Companies who outsourced support operations of applications or moved them away from core teams did suffer often requiring rework and occasional disruption.

So should CIOs be bothered or worried about DevOps ? The starting point would be to diagnose if there is a gap, perceived or real. Once deployed, are applications able to scale and sustain themselves ? Or they slowly wither away into the IT Orphanage (where applications who no one wants rest until they find a benefactor). Are business users happy with the solution provided and the support rendered ? Some of these questions would probably point you into the right direction on what needs to change to the desired state.

Simplistically many solutions may endeavor to push for additional investments in tools, technology and consulting; my belief is that tools and technology do not solve a problem if the underlying process and culture don’t support it. As the CIO or for that matter the CEO, it is necessary and essential to look at the facts and data before beginning to get paranoid about competition or next door neighbor doing it. Even if you have your support teams sitting across the seas, if the development team has thought about support, you are already there !

Formula One IT

Congratulations for being the chosen one ! The business likes your solution and we are also fine with the technology, functionality and customer references. Now that we have an agreement on the price lets quickly get legalities and other formalities out of the way. The process for PO creation and other paper work will take another couple of weeks. The question is how quickly can you allot resources to our project ? I do not believe that we need 3 months to get the solution off the ground into a pilot or for that matter go-live.

Any objections to aggressive timeline expectations from the customer are brushed aside citing urgency in business need and the dynamic business environment. Software vendors sheepishly accept the modified forceful project plan which assumes turnaround of all documentation from users with no delay or for that matter existence of clean data. Idealistic as it may appear both sides approach the project with enthusiasm that is outward for the vendor who is happy to get the business. D-day arrives and the project kicks off with much fanfare.

This situation has occurred a lot more often than gets visibility; time to market expectations from commercial-off-the-shelf software implementations (leaving aside ERP type solutions) are getting shorter. Most of them offer standard process automation or functionality that is typical across companies. Thus with basic configuration and some integration the anticipation is that the solution will be up and running in no time. Reality however bites every time with outcomes that do not live up to such expectations exposing the fallacy in the approach.

Analyzing scores of such projects undertaken by many of my peers the discovery was not very surprising. The facts were largely consistent and created a picture which when played back to the CIOs made them cringe and accept it. There were reasons and there were reasons; they were not the usual that have been published by various groups who track challenged projects. In almost all cases these failed to achieve timelines as well as deliver the functionality expected and the CIO ended up with the short end of the stick.

To begin with the evaluation of available options extended to eternity with high business expectations wanting to select the perfect solution. Comparing apples with pineapples creates a situation where the end result morphs from being a custard apple to a jackfruit. Moving from one demo to another scope expands to encompass all exception conditions. Sanity prevails after some time with CIO or business CXO intervention to bring back expectations closer to reality. Elapsed time through evaluation now puts pressure to achieve results in impractical timelines.

What started as a city street drive has now converted into a formula one race ! We need to finish the journey in the fastest possible time; get your experts, put more people on the job, why does hardware delivery take so much time, put it on the cloud. Configurations cannot take that long, it should be possible to reuse expertise from other customer projects. We are not that different but we are different; what we meant is not what you have understood, you don’t know our business and we don’t have time to educate you.

Time keeps ticking with business participants unable to adhere to unworkable timelines resulting in missed milestones and angst on all sides. Reviews soon become infrequent with everyone wanting to just finish the project with redoubled effort. The cascading effect leaves everyone frustrated and wondering why they accepted the stretched targets or ever got into the project in the first place. The formula one race with no equipment, trained drivers and crew suddenly is back to being what it should have been, a street car race.

Accepting reality brings everyone back to what they should have done to begin with; plan with real assumptions, acknowledge dependencies and the need to follow a workable model with good project management practices. It is good to take time to find the right solution which needs to be given due time for deployment too. I believe that CIOs need to continuously educate business users not to apply consumer principles to enterprise software deployments. They need to push back even at the cost of being unpopular or appearing unaligned.

Sometimes they should also be ready to go to a formula one race !