Until recently, the mainframe and Agile development practices lived in different worlds. The mainframe was optimized for maintaining a rock-solid system of record. Meanwhile, the advent of Web interfaces and mobile devices has driven a new era of rapid and iterative development. In essence, the mainframe ended up becoming a bottleneck for rapidly deploying new capabilities. IBM hopes to change that.
Tim Hahn, who holds the lofty title of distinguished engineer of CTP Enterprise Modernization at IBM software, recently outlined a number of advances to the mainframe to bring it up to speed with a faster pace of development.
Hahn explains, “Organizations have core information systems and want to open these up to new kind of interfaces.”
From IBM’s perspective, DevOps covers the entire software development lifecycle, starting with customer and business requirements, moving through development and test, streamlining operations and production and building continuous innovation with feedback for providing improvements on the operations. The goal is to create an enterprise capability for continuous software delivery that enables organizations to seize market opportunities and reduce time to customer feedback on the mainframe.
The latest release of the IBM mainframe transaction server, CICS 5.1, baked in a number of key capabilities to improve operational efficiency and service agility. As part of this refresh, IBM developed a DevOps-friendly definition of a CICS application that includes application code, dependencies, and configurations, which can all be bound into a single file and given a version number. A developer creates a single CICS bundle that has all the parts and requirements defined in a single file. This makes it easier to deploy on a CICS platform in an automated fashion.
Danny Mace, director of CICS Products IBM, says, “For around 40 years there was no formalized definition of an application.” In the worse cases, there were applications with thousands of programs and parts spread around the mainframe file system. In order to deploy to do testing, there was a conversation with the operations team about where these pieces were, and how they needed to be deployed. After these details were worked out, the development team had to undergo a long process of getting approval, implementing the code and doing QA tests.
Developers now have the ability to click and choose the deployment platform. A second click activates the application so it can go live. Now the runtime is prepared and ready to deliver the applications, so the QA can begin from the developer’s workbench.
Another new concept is a CICS policy engine. This provides governance around the platform to allow developers to deploy to the QA and production environments. The engine creates a framework for tracking and limiting things like CPU utilization and the number of DB2 or file accesses. If an app tries to violate the rule, certain actions can be taken such as abandoning the task or logging an error message.
The Need for Service Virtualization
In the emerging era of multiple application interfaces, a lot of code runs on different tiers including back-end, middleware and front-end applications. To address this trend, IBM is leveraging Service Virtualization technology to allow developers to write code in parallel, which can work together once deployed in these environments.
Using Service Virtualization, developers can test against simulated services that look, act and feel like the live environment before deploying to a larger shared environment.
“This supports the notion of compile, link, and test early and often,” Hahn says. “This gets to a key element of the DevOps solution, which is to get quick turnaround, not just about saving a file and looking at syntax correction.”
By adopting Service Virtualization, teams can work in relative isolation, and then progressively move to environments with more and more real implementations working together. Automated tests can help them to understand if new code and configurations works as intended.