Should you call time on your existing mainframe development environment?

The traditional 3270 mainframe development environment deserves respect. It has enabled developers to create and support some of the world’s most enduring business-critical software applications running on ‘Big Iron’ boxes around the word. Many of these core systems continue to deliver today for banks, government departments and large enterprises, decades after they first went live.

At the same time the mainframe is constantly evolving to help customers address new challenges. The platform has already embraced cloud computing, Blockchain, Big Data and mobile – and IBM has recently announced its strategy for ensuring it is in prime position to support the rise of machine learning.

The new breed of developers who will most likely be responsible for the mainframe through the years ahead will have cut their teeth working with programming languages such as C, C++ and Java – those that are widely taught in colleges and universities. To them the mainframe’s green screen command line interface is an alien concept. They want a contemporary development environment that is familiar, easy-to-use, has a quick learning curve and helps them work effectively and productively.

So the challenge for today’s mainframe shops is: “how do we adapt the trusty 3270 development environment to help us tap into the new developer talent – as well satisfy our existing mainframe experts?”

Migrating to Eclipse?

A route many are taking is to build a new, intuitive mainframe development environment based around Eclipse and open source applications. As a powerful, free development platform, Eclipse is quickly becoming the standard development environment for Java, JavaScript and other languages. Eclipse is also the preferred development environment in universities and college courses so most new developers will have come across it. Plus there is a wide array of free and paid-for open-source tools that can be used alongside Eclipse. Source management systems, task process engines, schedulers and application lifecycle management systems all come with Eclipse interfaces.

For those who are grappling with the tough decisions around modernizing their mainframe development environment, I want to share six lessons from Macro 4’s own experience when we trod a similar path of migrating towards Eclipse and open source tools:

1. Ensure you get buy-in from all key stakeholders
   Changing the development environment is a big cultural change, so it’s essential to get all interested parties involved. This especially includes experienced mainframers on your team who may have a long history with the outgoing environment. Ensure that they buy in to the reasons and benefits of adopting any new approach.
2. Get your non-mainframe personnel involved
   It’s very likely that the open systems developers within your organization will have first-hand experience of using some of the new developer tools that you may be considering. Be sure to pick their brains.
3. Ask these questions when deciding which Eclipse-compatible products to select
   As I highlighted above, there is a long list of Eclipse-compatible development tools that could be helpful to you. Useful questions to ask when deciding which ones will be right for your organizations include: Is there already some level of existing internal experience with the products you are considering? Are they intuitive and easy to use? Are they used extensively by other enterprises? And would they help you attract new recruits and look good on their resumes?
4. Take it step by step
   Take one application at a time, learn from it and use your knowledge as you focus on the next application. We created a matrix of all our mainframe applications to help us prioritize, taking account of the value of the application to the business, application knowledge within the company, the complexity of the current application development environment and its risks going forward. Of course every organization’s matrix will be different.
5. Choose carefully when to move to the new approach
   Your development teams will need time to adjust to using the new tools so try to switch over during a quieter period – and definitely not while you are under pressure to get a new application out of the door!
6. Keep other departments in the loop about your plans
   Other departments (such as security, procurement and business process teams) will need to know what you are doing and how it could affect their own decisions in the future. If you switch to open source software, for example, it may mean you can cancel some of your existing software licenses.

Remember why you’re making the change

Making a change such as this takes careful planning. Along the way, it’s worth reminding yourself about the benefits to your organization of migrating away from a 3270-based development environment towards an open source solution. For example:

• Recruitment may get easier because you will be able to promote the fact that you are using industry-standard software that will be familiar to new talent.
• Your training budgets will be reduced because it is likely the new environment will make it quicker and easier to train new recruits (and cross-train existing staff) to work on new applications.
• Team members who support multiple applications will benefit because they are able to use the same consistent process across the board.
• Your software development costs will likely fall because some of the new tools you use will be open source and free of charge.

The way that the mainframe is continuing to evolve will keep it relevant and central to many organizations’ development plans for years to come. We need to ensure we are giving today’s developers the right tools to make the most of its capabilities.