The time could not be better for software development on the mainframe. With digital transformation, more and more emphasis is given to personalized, smooth and secure customer experience. Backend systems play an important role, including mainframe transactions and data. It truly is a new age for the mainframe.
Yet, you may find it challenging to get everyone on your teams excited about the opportunity.
Do some of your developers constantly complain about cumbersome tools and inefficient workflows on the mainframe? Are you hoping in vain to see a bit of enthusiasm in their eyes when they open the green screen and start editing their code in Endevor using ISPF?
Chances are you are looking at the new generation of developers raised using modern and often open source tools such as Git, Visual Studio Code, Eclipse Che or Jenkins. They want to make their lives easy and they have little to no patience for anything that seems old or clumsy compared to the user experience they are used to and consider standard. Does that sound familiar?
New generation of developers
If you want to learn more about this new generation, one of the most comprehensive sources of information is the annual Stack Overflow survey. Don’t expect to learn much about the highly skilled mainframe programmers who have been contentedly using 3270 for their entire career in this survey. Over 50% of professional developers responding to the survey fall into the age category 25 – 34 years old, and only 1.6 % are over 55 years old. One of the main takeaways from this particular segment of developers is that they put great value in how they go about their work. In the survey, the second highest priority for developers looking for a job was “languages, frameworks and other technologies I’d be working with” (second only to compensation and benefits). The same survey also shows that 69% of developers using mainframe are not interested in continuing to do so.
The situation most companies are facing today is that the traditional, content and highly skilled mainframer with decades of experience is slowly but surely becoming an endangered species. On one side, many organizations are moving their development off-shore to countries where such a profile does not exist at all, and on the other side, existing statistics for North America show that the average age of mainframe programmers is around 55 years old and growing. When looking for a replacement, as hiring managers you will likely look into the category of full-stack developers, knowing that further training would be required for the replacement to be complete.
Challenges and barriers
There are typically three barriers for new developers entering the mainframe:
- Programming Language (COBOL)
- Development tools
- Team Collaboration tools and practices
Programming Language (COBOL)
Let’s start with the first one – COBOL. Many companies have already investigated, tried, and failed in converting projects from COBOL to new, more modern languages like Java. Such projects have a high failure rate, just the same as most efforts to migrate off of mainframe to modern platforms. The amount of COBOL code is said to be constantly growing. Some studies refer to the number of around 1.5 billion new lines added every year to the existing 220 billion lines running globally, and over 70% of all business transactions worldwide are written in COBOL (Gartner).
I’ve recently had the chance to discuss these topics with some of our customers at a couple of mainframe conferences. I took that opportunity to validate some of the above assumptions, and to understand whether the numbers from surveys and statistics actually correspond to what real people experience. Within a group of representatives from companies using mainframe, 77% confirmed that COBOL is growing, 15% assess that it remains stable and less than 8% claim COBOL is on the decrease. At the same time, only 12.5% mentioned a positive experience with COBOL conversion versus 87.5% who expressed strongly negative experiences.
So, should we spend all this time, resources and energy trying to replace COBOL and get rid of something that has been working well for decades? Is COBOL really the biggest challenge we are facing in the mainframe world? The sensible answer is no. An established developer with the right mindset and incentive will probably look at COBOL as just another language to learn.
If we agree that the programming language is not a critical barrier, what is stopping the crowds of young, modern developers pouring in through the door of mainframe companies? The remaining barriers are development tools and team collaboration practices used on mainframe. We are looking into mainframe development tools in another blog post (Choice And Freedom For Mainframe Developers? You Bet.), so let me skip them now and zero in on the last barrier.
CA Endevor is the market leading SCM on the mainframe and many organizations rely on it to organize development activities and team collaboration. Still modern developers will not consider that Endevor meets their expectations for team collaboration (code review, concurrent development, merging, etc.). So what is the ideal solution to provide the desired user experience?
Move from Endevor to a new, more modern tool? I can only imagine that your loyal Endevor users would quickly cry mutiny when they hear this. Most Endevor admins would shiver at the thought and quickly enumerate all the reasons such an idea was short-sighted, expensive, and simply terrible. And in most cases they are right. Mainframe organizations often heavily depend on their mainframe software asset management with millions of elements and decades of history in Endevor. They have almost inevitably invested years of work into mainframe lifecycle automation, critical to their business processes and governance. Replacing Endevor with a new modern tool would then turn into an endless process of peeling an onion, with always a new emerging layer of details that had not been considered at the beginning. Such an effort would cost the organization countless valuable cycles that could instead be invested in new development. Many mainframers have at some point painfully learned the lesson “If it ain’t broke, don’t fix it”, which is still often true whether we like it or not, especially with legacy code or processes that have been built upon for decades.
For organizations developing on mainframe using Endevor, instead of reinventing the wheel and switching to a brand new mainframe application, the decision to leverage standard and well-known practices of a popular, industry-leading source code management and collaboration tool seems far more practical, efficient, and elegant.
Git is by far the most popular SCM among modern developers today and Git collaboration practices are becoming a de facto standard.
Git as a front-end for Endevor
Connecting Git to Endevor is the fastest way to get the benefits of both solutions without impacting the existing processes and the existing users. Your experienced mainframe developers do not want to change anything and they want to keep their current development tools and practices? No problem! Your freshly on-boarded developers prefer modern IDEs and Git? Sure! You need both of these groups to collaborate on one project? Of course!
With this approach you can attract the modern developers to mainframe (easy onboard, common skill set, de facto standard collaboration practices). You will support common practices for end-to-end enterprise application development (mobile to mainframe) and full-stack developers will enjoy a similar experience across all platforms (distributed, cloud, mobile, mainframe).
Knowing that such a solution dramatically reduces the cost and risk compared to moving completely to a new tool, would you like to know more about connecting your Enterprise Git Server to Endevor?
Read our Git Bridge Whitepaper for more details.
Try the validation version and give us feedback!