If you’re reading this blog post, you already understand that your mainframe hardware, software and people assets are strategic to your business. Ongoing investments are merited to ensure a transitioning workforce will be motivated and best equipped to leverage high value mainframe assets in meeting the never-ending business demands for increased velocity to quality application delivery.
If Batch processing is a mission-critical component of IT service delivery for your business, JCL is one of your source languages. If you are on the Z DevOps journey, you have probably established shared value in behavior that delivers constant improvement in assessable, predictive, and measurable testing.
Should JCL Testing be considered on the DevOps Journey?
In suggesting considerations intended to offer increased value, let’s discuss how an organization on the Z DevOps journey might describe a shared vision for their destination point using the following items:
- Mainframe considerations for Z DevOps: Identifying common attributes of a Z Batch environment that might assist in clarifying your Z DevOps Enterprise vision and serve as consistent, reliable markers throughout your journey.
- Refining your description of your Z DevOps target state: What types of modernized tools, common services, and adoption strategies will be needed to support predictable and reliable batch testing and defect elimination, while also opening up core batch product functionality for consumption across the entire enterprise.
- The role of JCL testing in Z DevOps: How an organization might use these considerations to determine requirements for JCL Testing services congruent with its vision for the Z DevOps Enterprise.
Beginning with the destination in mind: What might be a shared description of what you would want to see as a result of your DevOps Journey, i.e., it’s desired ending destination or future target state?
Your business leadership might say they want accelerated, high quality IT application delivery serving the business in a quickly changing market. Your IT organization might say they need common tools and processes for the enterprise, defect-free continuous integration/continuous delivery, and development infrastructure that attracts the most talented developers entering the job market.
Take time to understand and incorporate the various expectations that different Z DevOps Enterprise stakeholders will have for the future target state of your DevOps journey.
Setting and fulfilling those expectations in your shared vision will be critical to your journey’s success or failure.
Considering the Mainframe on the DevOps Journey
To clarify your organization’s shared vision, it’s helpful to identify the common Z batch environment attributes that will help shape that vision, including investments in current infrastructure, shareholder profiles and current application delivery. These are core building blocks for constructing and completing your shared vision and achieving your target state.
Investments in Current Infrastructure: For the Z Enterprise, perhaps more than any other platform, accumulated investments in software for infrastructure management, tooling, and business applications, are considerations of scale. This inventory of time-tested software assets was designed for the mainframe and adapted over time for your business. It encompasses decades of development effort enabling the quality, efficiency, security, and reliability that has become the cornerstone of mainframe service delivery.
Stakeholder Profiles – In addition to veteran developers, mainframe system administrators, and related subject matter experts for database, security, networking, and operations all possess a deep and valuable operational knowledge of the IT delivery aspects of the business. In addition to a common preference for green screen interface, user requirements for the same toolsets will change depending on job responsibility. For JCL testing, consider that a release tester is thinking about volume testing for unidentified dependencies and production environment runtime conditions. A developer might be interested in ad–hoc unit testing through an Eclipse IDE. These nuances will become very important as you think about requirements for common tools.
Application Delivery – The mainframe release schedule is time–based. Although possibly unstated, this level of control might be viewed as a way of protecting quality by limiting change. If you have modeled your Change Management process around ITIL, you will probably not have an intuitive understanding of how an approval step requiring a Change Review Board meeting would be compatible with continuous delivery. You might also be thinking about the last time your approval process was bypassed.
Refining Your Description of the Target State
In addition to the mainframe considerations listed above, also consider how modernization, common tooling, common services and adoption will affect the future target state of your shared Z DevOps Enterprise vision.
Think in Terms of Common Services AND Common Tooling: How can tools be modernized by ISVs to offer embedded capabilities that might conceptually be viewed as a cost-effective service? How might an emerging DevOps Enterprise protect investments and add further value by opening up core product functionality for consumption across the enterprise?
If you are thinking only in terms of common tooling; do you see a reasonable probability that your Z enterprise monitor, without significant risk and expense, could be replaced by a product used widely among Application Support teams on a UNIX platform?
When thinking in terms of common services and advancing the predictive capability of your test environment; consider the complexities of multi-tier applications. What if the testing and diagnostic requirements for a distributed Java application requiring mainframe network and database services could be accessed without calling a mainframe DBA, Network Administrator, or another subject matter expert who is fluent in operation or your mainframe performance management tool?
The Journey is Unsuccessful Without Adoption: At some point in your journey, achieving critical mass in adoption will become a key predictor of success. Anticipating and planning for this outcome early in your journey may be well worth the upfront investment: Think about how you might engage Release and Production stakeholders in promoting change. In return for consensus on increasing release frequency, how might you incorporate testing metrics to show positive trends in early defect elimination and verifiable process compliance?
If you are promoting the adoption of an Eclipse IDE for developers:
- Quickly address any functionality/productivity gaps that might justify context switching between green screen and IDE.
- Investigate how you can utilize IDE configuration settings to enable user interface perspectives that are closer to what new adopters might be accustomed to
- Prioritize identification and promotion of interesting IDE functionality that is not available through your green-screen interface. Consider incremental investments in your modernized tooling if the outcome has an observable impact on the adoption trajectory.
If you are considering tool replacement, remember that common tooling implies by definition a wide breadth of functionality supporting different user preferences and requirements. Your Change/Release testing team will be interested to know that expected functionality and predictive reliability will not be sacrificed as the result of your development organization‘s need for an Eclipse interface.
What does this mean for JCL testing?
Maintain and leverage the investments made in existing tooling if you can do so cost-effectively and without compromise in rejecting limitations that detract from your ability to deliver continuous gains in adoption, reliability, and accessibility.
Regardless of how you define your target state, commit to constant improvement in testing approaching 100% confidence in target system predictive outcome. Your vision for your JCL testing service should describe:
- Hosting the testing service on the mainframe system where runtime conditions will be emulated
- A modernized architecture where cross-system testing can be initiated and managed through vendor supported green screen, Eclipse plug-in, or Rest API access points
Your DevOps Practice should accommodate the JCL testing preferences and requirements for all stakeholders. The value in attending to this need early will pay dividends as you realize the positive impact on adoption and stakeholder collaboration.
Although adoption of an IDE interface may be a priority, consider that different stakeholder groups outside of your development organization may have no short-term need or offer an organizational benefit by discontinuing the use of the green screen.
If the interface and the testing service are not dependent on one another, you can maintain both access points to common JCL testing services. Your implementation and vision maintain integrity.
If you have committed to continuous improvement, how does your vision accommodate measurement? Your JCL testing product should provide a complete and granular history of defect avoidance metrics. This data should be easily assessable for reporting informing:
- Process adoption and who might need training
- Trending on early defect elimination
- Process ROI
Demand that your testing tool vendors demonstrate they understand your needs and provide specific insight on how their customers are using their products, expertise, support, and ongoing enhancements in pursuit of continuous improvement in predictive testing.
“The only thing constant in life is change”
In considering the wisdom of this long-documented paradox, who in your IT organization would not accept the inherent wisdom of striving for cost effective steps delivering continuous improvement in quality and delivery?
Even if you have begun your DevOps journey, validate your current position and ask yourself if your shared vision is being articulated in terms all will embrace. Priorities will be reinforced, engagement with stakeholders will become more interesting, and questions like’ “Should JCL Testing be Considered in Z Modernization and the DevOps Journey? “, will answer themselves.
Wishing you great success on your DevOps journey!
