DevOps is all about a cultural change to move to agile and lean IT practices throughout the organization. It brings transparency, visibility, and automation to all phases of the lifecycle. Many of the practices of DevOps have been applied to different parts of the organizations over time, including the Mainframe.
In many ways the z/OS environment was first by having the production control tools that provided the SCM, build, and deployment capability. However, these tools were built for the capabilities in the 1980s. They focused on the control of the production environment and limited development paths. In the days when the 3270 was the best development environment, and there were no standard practices for dynamically creating test environments, this worked well.
Today, organizations use different languages and need to expose existing assets as services. In order to facilitate this capability, modern tools are required. You would not imagine making your distributed teams use a host-based SCM for their Java or .Net development, so why segregate the COBOL and PL/1 developers into tools not appropriate for today’s development practices? The transformation to modern tools and practices is part of the overall DevOps transformation and is key in facilitating the exposure of the existing capability as services. These modern tools allow teams to create services or REST-based interfaces on existing applications. Modern tools also facilitate the ability to refactor these large monolithic applications into the individual components that provide services that need to be exposed.
Modernization of existing assets
With capabilities such as z/OS Connect the ability to expose existing function as a service has never been simpler. There are multiple ways to modernize. One way is to add service interfaces to the existing monolithic applications, creating new ways to name the application. Another way is to split out the specific function required for this service and to create a new module that is then exposed with z/OS Connect. Usually the original program is left intact to support the current business process.
Depending on the business context one or the other may be seen as the most efficient method. Over time, to support the DevOps transformation it will be important to break up the monolithic applications into smaller service functions, and have these new smaller services used in all cases. For those customers who already started down the path to SOA, they already have a set of services that can be easily exposed via z/OS connect. The transformation to a more agile development process will also help with this modernization. Working in small batches and working iteratively will develop the capabilities needed.
Once these services are created using capabilities such as z/OS Connect, the business APIs should be created from them and exposed in an API manager such as IBM API connect. These APIs can now participate in the hybrid cloud environment, and can be exposed to not only internally but can be exposed externally transforming to a new business model. These APIs now can be monetized and generate revenue streams for the organization, fueling additional innovation. This way the existing mainframe functions are now participating in the API economy and developers are building better apps. Customers gain the value of years of investment in the business capability, leveraging the platform for its scalability, performance and reliability, and providing capabilities needed for the digitization of the industry.