We find ourselves today in a war of worlds created as a byproduct of our success in the computing industry. We have innovated and given customers a glimpse of what is possible with modern technology. In doing so, we created a beast (read as customer). This beast wants faster innovation, constant changes and improvements, old is the new broken. If a customer app doesn’t improve (read as change) every month, it’s outdated. “Where are my new features?,” screams the beast. Though, while innovation and constant change is a must to Feed the Beast, a war of the worlds is not inevitable.
Businesses responded with a new world (read as department) of application developers. This race of people embraced change as their lifeblood so responded with new processes they called agile, continuous integration, and continuous delivery. The new world embraced source code management products like ISPW and GitHub, as well as deployment software like Jenkins and XL Deploy. These processes and products made development faster while maintaining code quality and made it possible for the new world to feed the beast and keep him happy.
UNTIL, they encountered something strange when they tried to make changes to the mainframe. On their journey there, they encountered a chasm keeping them at a distance. On the other side of the chasm was an old world of strange people known as Systems Programmers and DBAs. This strange race of people has been happily doing their job of maintaining system and ensuring database reliability, stability, performance and availability for decades without being bothered by having to directly deal with customers. This race of people is strange because they seem perfectly happy NOT to be changing anything. In fact, they seem to actively RESIST change – as long as nothing changes, the system and the database stay reliable, stable, fast and available.
Thus began the war of the worlds.
The battlefront of this war is virtually every mainframe environment in the world and the loser right now is the business, not IT. Instead of having a happy collaborative culture, the war has created an us vs. them mentality. Instead of working together, departments are not even speaking the same language when it comes to development and deployment. Communication, if it exists at all, is strained. What suffers is application deployment speed and reliability, employee satisfaction, cost control, and ultimately, customer satisfaction and loyalty.
The good news is that the battle is almost over. The new agile world is winning the battle. In the 13th annual State of Agile Report, a staggering 97% of respondents1 said their organizations practice agile development processes. More glaring is that 33% of those had adopted agile only in the past 2 years. The scales have tipped and the last obstacle to full agile development (read the mainframe) has to adapt or fall.
When the smoke finally clears what will be left of the mainframe? Well, with 90% of the largest airlines and 87% of all credit card transactions2 running on the mainframe, it is still perhaps the most vital aspect of IT Operations at major corporations. Therefore, it needs to evolve and embrace change while holding on tightly to what has made it so vital to every industry for more than 5 decades. It has to embrace agility while maintaining system and database reliability, stability, performance and availability.
By now we have all heard the term DevOps. DevOps is the area surrounding and bridging that chasm between application development and IT Operations. Proper DevOps gives a company a cohesive end to end strategy or pipeline (for those familiar with Jenkins) from planning to coding to deployment. In the State of Agile survey, 73% of respondents3 said they are planning a DevOps initiative in the next 12 months. To be successful, all 97% who are implementing agile should address DevOps. When a company successfully manages the DevOps process from end to end, they are successful in not just implementing a process, but in changing the culture. Worlds (departments) who were previously at war with one another are now collaborators all on the same side of the battle, working in harmony from end to end, all with the same goal of deploying quality applications quickly to continue to feed the beast!
After witnessing this war in too many mainframe environments, we do have some lessons to share to help others avoid or end the war peacefully and successfully integrate the mainframe into the agile process.
- To be successful, the entire organization needs a change of mindset, not just a change of processes.
- EVERYONE needs training. While mainframe IT needs training on Agile, application developers may need training on relational database best practices etc.
- Embrace new mainframe DevOps offerings which can automatically integrate the mainframe into the agile processes.
- Work as a unified team where EVERYONE shares in the responsibility of moving new changes to the customer.
A well implemented strategy will cohesively bring together very different groups and unify the IT organization from application development to database maintenance in what will be a very powerful competitive advantage.
To see how BMC is supporting mainframe database management with agile DevOps, please visit the AMI DevOps for Db2 page at bmc.com.
1 The annual State of Agile Report is compiled through a survey by CollabNet VersionOne and surveys 1319 respondents from around the world and in all industries. For more information on the survey see: https://www.agilebusiness.org/news/452606/The-13th-annual-state-of-agile-survey.htm ↩
2 https://www.ibm.com/it-infrastructure/z/why-mainframe ↩
3 https://www.agilebusiness.org/news/452606/The-13th-annual-state-of-agile-survey.htm ↩
Struggling to Incorporate the Mainframe Into Your Agile Development Process?
These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.
See an error or have a suggestion? Please let us know by emailing blogs@bmc.com.
