As we approach the year 2020, mainframe remains the platform of choice for processing large workloads, and despite what people may have thought 30 years ago, the mainframe shows no signs of going away. The world’s largest companies continue to rely on its secure, proven and unparalleled transaction processing capability. Yes – there are new interfaces and systems of engagement, leveraging mobile and web platforms – but the core of critical business applications continues to be mainframe which means, despite the natural attrition of expertise, development on the platform must go on.
However, attracting the next generation of developers requires evolution. Just like the end users of the business application systems we develop prefer to use modern interfaces like web and mobile to interact with the mainframe, so to do developers. The most successful teams have always used automation wherever possible to meet their demands, but to be effective today’s developers want more. They want rich and visual tools, from graphical IDEs providing language-specific productivity boosts like content assist and automated refactoring, to DevOps pipeline management tools that show at-a-glance where their changes are in the lifecycle while orchestrating specialized testing tools along the way. The Agile development methodology has required changes as well – for example to embrace incremental delivery, today’s developer leverages advanced branch and merge techniques to ensure they don’t create unnecessary dependencies between changes.
In the past, the adage “if it ain’t broke, don’t fix it” has been the rule, with the preference being stability over change. That is no longer the case though – the enterprise is seeing good return on investment with transformation and they want to bring mainframe into the fold, as well as enable new developers to be productive on the platform. Change has become inevitable, but the big question is “how do we do it”?
The seemingly obvious approach might be to convert to new tools and processes, ideally the same ones already used by mobile, cloud, and distributed developers, assuming those can be made to work on mainframe. Another choice might be to adopt different tools for the mainframe, at the very least newer ones that support the latest requirements of developers. But is that the best way? A conversion takes an enormous amount of time and effort and brings with it risk that either things will break or cause costly delays to mission critical deliveries. It also entails a retraining effort for existing developers. Regardless of whether you are adopting proven distributed standards or going the way of a new set of niche mainframe development tools, the fact is that your team will be slower for the near-term. That says nothing about the costs associated with the conversion itself. If time and money were not scarce, then the adage of “if it ain’t broke, don’t fix it” would probably still apply.
For CA Endevor SCM customers there is another way – incorporation of proven, popular modern tools to further enhance the value of your investment. We think it is the most practical and reasonable way to bring transformation to the mainframe, with minimal cost and risk. As I mentioned earlier, automation across the lifecycle is nothing new. CA Endevor SCM allows developers to automate builds on check-in and package deployments for promotion through a customizable SDLC, with mainframe automation possible at every step. Achieving the goals of modern DevOps doesn’t need to mean re-inventing everything. CA has introduced a new option called CA Endevor SCM Integrations for Enterprise DevOps that supports this very notion.
One of the marquee features of the new option is a suite of Enterprise GIT repository plugins (starting with a plugin for Atlassian Bitbucket) which allow developers to work in GIT and have their changes automatically sync’d to CA Endevor SCM. Furthermore, those developers who wish to continue to work in more traditional user interfaces like ISPF, CA Endevor SCM Quick-Edit or Eclipse can continue to do so, seamlessly merging their changes using native GIT or standard CA Endevor SCM processes to allow collaboration regardless of interface. The impact of this feature alone is hard to overstate. By adopting the GIT-Bridge-for-Endevor, developers open a world of integration – here’s how: pretty much every IDE has a native GIT integration, and with the cross-platform capabilities code quality tools and code-aware collaboration tools are easily added to pipelines. It also means developers can leverage the well-known, widely-used, much-desired support for advanced branch-and-merge capabilities while working with mainframe code.
On top of this, the option includes out-of-the-box integrations for Agile PPM tools. Developers using tools like Atlassian JIRA or CA Agile Central to track their efforts will seamlessly match changes back to agile items like user stories and defects. It will also enable Agile PPM reporting to help teams monitor progress and more effectively collaborate. Since the connection between Agile PPM tools is driven from events originating in CA Endevor SCM on the mainframe it will work regardless of whether the developer making the change is using an ISPF, Eclipse or GIT-based interface.
Tracking versions is only one piece of the puzzle though. To allow developers to continue to use the automation they’ve relied on for years, CA Endevor SCM packaging and promotion should be integrated into pipeline management and visualization tools. The option contains out-of-the-box integrations for these tools as well. Additionally, developers may find it even easier to use CA Brightside – a command line interface that allows CA Endevor SCM automation to be scripted in standard distributed and open-source DevOps tools like CA Continuous Delivery Director or Jenkins Pipeline. Either way, the option provides the means to consume events originating on the mainframe to trigger downstream processes and enable a hybrid DevOps flow, encompassing existing automation along with tests or other types of automation driven off-host.
Given all this, I think the answer to “how do we do it?” is easy – layer new interfaces on top of existing automation rather than start from scratch. If you think about it, this is exactly how the world has modernized its systems in general – layering instead of replacing. Why? The answer is clear – wasting time and money starting over is not an option in a competitive economy, especially when the outcome is not guaranteed to be any better that what was there. It didn’t work when distributed and open systems were going to replace mainframe as the workhorse for processing transactions in the 21st century, and it seems unlikely to be the best choice in transforming the tools and evolving the developers tasked with maintaining those applications.
If you would like more information on CA Endevor SCM Integrations for Enterprise DevOps, please contact me at Vaughn.Marshall@ca.com.