The pace of technological changes in software engineering is continuously increasing, and every day we are surprised with new innovations. Most of them are insignificant, but some of them are true revolutions. With no doubt, cloud computing is one of those.
There is a certain rule. The bigger a change is; the bigger the resistance it causes. Our processes, organizational structures, and ways of thinking do not adapt to changes easily.
This time it is no different. It is not a coincidence that the tension between traditional IT Operations (Ops) and Development intensified recently. The rise of creativity in this area is also not accidental. The DevOps movement and many Continuous Delivery solutions are attempts to reduce the tension. Unfortunately, despite all the efforts, the tension is still there.
I think that we can resolve the conflict and free ourselves from the tension, if we deeply understand the true nature of it. Is there really a Wall of Confusion caused by Ops resisting Developers’ changes in the name of stability? Or maybe there is a lack of trust?
I believe there is another explanation.
In this blog post I will show my reasoning and answers, which I found on the way. If they are correct, they can point us to a practical solution and prepare us for changes on the market to happen.
Context Sensitivity
In 2001, Takahiko Masuda and Richard E. Nisbett published a study on cultural differences between Westerners and East Asians. In the study they presented their findings on how our culture changes the way we perceive the world around us.
Masuda and Nisbett conducted a series of experiments. In one of them Japanese and American students were asked what they could see, after viewing a short video featuring underwater life.
The answers revealed a pattern. American students typically mentioned the biggest and most colourful fish whereas the Japanese students would describe the entire scene: a lake or the ocean, then the rocks and fish swimming together.
Psychologists categorise people falling into these categories as either Specific or Holistic Thinkers. The former sees the details, the second the context. The former sees fish, the latter the ocean.
I realised that context sensitivity gives a new perspective. Let's have a look at the following diagram:
It shows four roles: Developer, Application Tester, System Administrator (an Ops role) and Cloud Provider, and their place on a context sensitivity axis.
The Developer and Cloud Provider are extreme cases. One sees every single algorithm and data structure of an application, the second does not even know what systems have been deployed to cloud. That's why they have been depicted as outermost.
The Application Tester and System Administrator are in-between. The Tester knows the application very well, but not in as much detail as the Developer who wrote it. The thinking of the System Administrator is holistic, but not as much as of the Cloud Provider, because Ops still requires basic knowledge of applications (servers used, ports open, etc.).
The picture reminded me the illustration of the Wall of Confusion, where Dev and Ops have been depicted as opposing forces. But then, after looking deeper, the model started changing.
Evolution
To explain this, we need to use our imagination. First, notice that the relationship between an application and the cloud, in many respects, resembles the relationship between a fish and the ocean.
In nature, fish evolve to be more specialized. The same happens to applications. Developers make them more feature-rich, and specific thinking helps them with that.
Cloud Providers follow a different path. Similar to how oceans began (life-less), and then gradually evolved into a life-friendly environment, Cloud Providers are working to make clouds friendly to more and more types of system. Well-developed holistic thinking gives an insight into the ecosystem.
System Administrators follow Cloud Providers. That's why they are not eager to investigate application-specific problems, instead, they would gladly spend time on "cloudifying" their data centers. Application Testers are pulled in the opposite direction. They would rather learn some programming to be more like Developers.
The arrows in the following diagram show the tendencies.
In this way, we can see a visible gap growing between Dev and Ops. This is a source of polarity.
Polarity
Pini Reznik described recently a similarity between the way Application Testers and Ops automate their work. This inspired me to look at the two roles in a historical context, which revealed yet another pattern.
The complexity of Application Testing reduced dramatically, after the idea of Test Driven Development appeared in 1994. Before that date, testers used to maintain their own servers (own test-rooms) and create test automation tools. Nowadays these tasks belong to Ops and Dev, and Testers mostly operate tools, which are exposed to them by Developers (like defining tests scenarios).
In 2006, the first implementation of cloud appeared on the market (Amazon EC2). I believe in that moment something similar started happening to Ops, and this can be clearly seen when looking from the perspective of Context Sensitivity.
In the following diagram, diameters symbolise the complexity of each role.
If my observations are correct, the "magnetic" forces that pull Specific and Holistic Thinkers apart have particularly strong influence on the roles that are in the middle. Whatever is in that area, is quickly attracted to the closest pole, and on the way loses its energy to the outermost roles (the red arrows). Those remain stable.
This happened first to Testers, whose responsibilities have been distributed mostly between Dev and Ops. The roles were building up importance, until suddenly Cloud Providers proposed something that was more holistic than anything Ops could ever offer. And that moment Ops found themselves to be in the middle, and started undergoing a similar erosion.
This is the reason why developers have recently been acquiring Ops knowledge, and if the trend continues, soon Ops will be mainly operating tools and interfaces exposed to them by Cloud Providers. And this won't be the end of the evolution.
Conclusions
IT Operations resist Developers' changes not because of resistance to change in general, but because of the direction of change. In fact they both want to improve the environment, but they have opposite goals, which causes them to define "improvement" differently.
The real reason for this is psychological conditioning. Just as it is difficult and against the nature of Ops to focus on a specific application (fish), it is equally hard for Developers to understand the interconnectedness of systems (the ocean).
The model explains the opposite tendencies, and shows that the polarity deepens. As a result we can expect that only the strongest organizations will be able to keep Dev and Ops together (DevOps), for withstanding natural processes requires a significant organizational force.
But the most important thing it points to is an alternative. Fish and the ocean evolve in opposite, but not conflicting directions. They complement each other.
This is exactly the transition we are witnessing now. Ops are quickly losing their position to Cloud Providers. In the end, the difficult cooperation of Ops and Dev will be replaced by a complementary relationship of Dev and Cloud Providers:
- clouds will be accepted as a standard deployment model.
- developers will be able to deploy and maintain complex systems on their own.
- all tools for that will be provided entirely by developers and cloud providers.
The change will give software development an immense boost. Conflicts will be left behind and developers will have all the tools to take applications from idea to market.
Previous article
