This is a contributed comment piece for the Cloud Developer Review from Kevin Parker, VP and lead cloud software development evangelist at Serena Software.
“The more things change, the more they stay the same” — goes the old French proverb.
Since we moved computing from the air-conditioned silo on to the air-conditioned desktop we have been inventing, and re-inventing, better ways to deliver business information. All too frequently we have seen the same growing pains repeat themselves as new technologies stumble and falter over the same issues the previous technology stumbled an faltered over too.
How many innovations can you name that are truly a product of micro-computer revolutions? How many were identified and solved several decades ago by the mainframe community? The irony of the tablet is that it is really a dumb-terminal in a pretty wrapper but relying for real computing power and access to big-data from some remote computing source. Tablets are certainly and more convenient than the monster 3270 terminals of yesteryear but they are, nonetheless, merely places to express data from a distant source and place to enter data for processing at a distant source.
We’ve come full circle, again.
The tempo of development has reached a dizzying cadence causing code to pile up awaiting deployment at the door of the datacenter. Meanwhile the pressure on operations for strict governance, unending uptime and ubiquitous availability is straining the infrastructure and we all know one more change might bring it crashing down. So in a universe where these worlds collide there is bound to be friction.
So the latest innovation, DevOps, is born out of the realization that the needs of development and operations should focus on what is common rather than what is adversarial. This takes organizational maturity to even consider it and takes executive will to make it happen. The exciting news, some may think it a curse however, for anyone in Change and Release Management today is that there is a focus on your profession. Never has the ability to deploy code had more business scrutiny, been more of a C-level strategy conversation or become the primary target of IT automation at the expense of other projects.
But just wait one minute!
For more than four decades the mainframe community has lived this life. The number of users impacted by change stretches into the hundreds of thousand, even millions, for the large banks and telco’s. So getting change and release right has been a major focus for both the mainframe development and mainframe operations teams for a long time.
Our new generation of DevOps practitioners can learn much from mainframe change and release managers. It starts with the shared understanding of the impact of change and the shared responsibility to ensure that change happens without drama. But it also comes from mutual respect for the roles involved and for the clear delineation of the boundaries of those roles. Much of that delineation is enforced through the mainframe security system with access control very tightly limited.
Technology is important too
Mainframe change and release management solutions have had 40 years to evolve to where they are today. For many shops they have comprehensive vended solutions that manage the change, development, testing, release and deployment lifecycle. Others have a combination of vended and homegrown and, just a few, have completely homegrown infrastructure. The point to note though is that no one tries to release code into production on the mainframe without some level of automation and significant amounts of control infrastructure.
And we are not talking about spreadsheets here. Many mainframe organizations use spreadsheets to back up the controls they have implemented but no one hands off that level of responsibility to what is, nothing more grand than, documentation.
Beware of thinking that because it is written down it is
a) the truth, b) up to date or c) anyone is going to pay attention to it. You must have mechanisms that enforce the practices, policies, procedures and processes of the organization as well as ones that document them. This we learned, on the mainframe, the hard way decades ago.
Thirteen years ago the mainframe faced its greatest challenge
Almost every piece of code that had ever been written up to that point faced some form of change and the go-live date was not something that could be moved. Y2K brought about a new industry, off-shoring, almost overnight and created a middle class in India and in China.
Change on this level had never been seen before and when it was all over the only sound you heard was the press complaining about what a monumental disappointment it was because nothing happened. Precisely the point: nothing happened because the million or so mainframe professionals, who did not sleep that New Year’s Eve, put in place the process and technology infrastructure to make sure they didn’t become front page news.
Since then, the scourge of terror, the collapse of the banking industry, the nightmare of privacy, and a dozen other disruptions, has driven change into the way we deliver business systems. At each stage though the mainframe has been able to adapt without experiencing the distraction these events usually create. The reason for this is simple and it goes back to those well-defined roles we spoke of before.
So if you are starting up a new DevOps initiative go and talk to your mainframe team. They have already solved this problem. They know what it is like to deal with the competing priorities in your organization and have been doing so for decades. Their approach is one that was hard won and one that suffered many setbacks along the way. Their customers have been the hardest taskmasters and the most vocal critics. The systems that they develop, support and manage are the backbone of your organization and critical to its success. They will appreciate being asked. They will share what they know. They will offer to help.
DevOps is about nothing unless it is about attitude. Sloughing off pre-conceived ideas about how it should be and collaborating to create how it needs to be. This is the way of DevOps: this is the way of the mainframe.