DevOps: A Rude Awakening in the World of Mainframe Computing?
The world of IT is all about buzzwords; many come and then go just as quickly, but DevOps is one of newer ones that might just have some longer-term impact. So what is it all about and can it succeed, especially in the rather staid world of mainframe computing?
According to Wikipedia, DevOps is a combination of Development and Operations; and that goes a long way to describing what it is all about—bringing application development and operational teams closer together in their day-to-day working.
One of the things that have brought about the need for DevOps is the rush to fulfill the promise of Agile application development. Agile seeks to deliver more frequent application releases out of development: Ideally a more or less continuous flow of new functionality, rather than the occasional and bigger revisions associated with more conventional waterfall development methodologies.
The idea is that the development process should be responsive to users’ requirements. This means new features can be brought to market earlier (delivering commercial advantage) and then (if necessary) refined based on real user experience. However, for Agile to work, you need good interaction between development and operations teams. This is often a stumbling block, especially in the world of mainframe computing.
In the early days of data processing, application developers and computer operations staff worked in close cooperation to create applications, get them running in production and maintain and enhance them to the benefit of the companies that they worked for. However, as IT shops have got bigger, the two groups have tended to drift apart, assume their own importance and develop distinctly different cultures.
Today, development is largely project oriented, with programmers working on one development followed by another, and development teams being built and broken up again according to project requirements. They are highly focused on change; once they have developed a new application or piece of functionality they move on to the next one.
In contrast, the operations side of things is clearly a production-based process, effectively a production line striving to repeat the same process efficiently and without error day after day. Operations keep the IT systems running and deliver the services the business relies on. As such, they are not fans of too much or too frequent change as it introduces risk and can impact stability and reliability.
Too often then, the two groups do not interact very well. Each views IT from a different perspective and has a different role. Each tries to do the right thing for the business based on the way they see it, but often they inhabit different parts of a company’s organizational structure. This makes the push towards more cooperative working in the overall interest of the company that much more difficult.
So ideally, an initiative to embrace this new emerging DevOps philosophy would see development and operations working together with quality assurance in cross functional teams to deliver a continuous stream of innovation into production.
The old ways of working in specialized silos get in the way of fast delivery. But with the two sides now in joint teams focused on the shared goal of continuous delivery, you no longer get the delays and inefficiency created by hand-offs production (which occur when a project gets handed back and forth between separate operations and development teams after each side has done its part).
Outsourcing poses additional challenges to successful DevOps. If the development function is outsourced, coordination and collaboration with operations can become more complex—and it gets even more problematic if outsourcing is to a different geographical location and, in some situations where development and operations are both outsourced, to different suppliers.
For DevOps to succeed, the focus will have to be on building a collaborative team, integrating people from a variety of specialisms into a single cohesive unit, regardless of geographic location. Technology can help by making it easier for people in joint production or operations teams to collaborate and share information and to streamline processes through workflow, but it’s the people issues that often provide the greatest challenge.
There’s some way to go before we see widespread uptake of these new ways of doing things, especially in the mainframe world. And one of the biggest challenges is the cultural shift, which will be necessary to break away from the old siloed ways of working. But there seems to be some momentum building behind the DevOps movement. So maybe there’s a chance DevOps will turn out to be more than just the latest buzzword.
Philip Mann is Principal Consultant at mainframe performance management expert Macro 4. Philip has been working with IBM mainframes for in excess of 30 years, including over 10 years with Macro 4, where application performance tuning is one of his major interests.