Over the past decade, more companies have begun to adopt standardized software development tools across multiple languages and platforms within the enterprise. Among the reasons for this adoption, graphical development environments have matured, enabling programmers to be more productive. Intuitive and standardized interfaces mean less training and quicker adoption. Also, many mainframe developers are close to retiring, and the new generation of mainframers set to fill their ranks won’t have TSO/ISPF skills and probably won’t want to acquire them. From a mainframe perspective, all of this means the long legacy of 3270 character-based tooling will slowly turn and head for the sunset.
Transitioning your mainframe development environment from TSO/ISPF to a modernized, graphical Integrated Development Environment (IDE) is a significant journey that varies from shop to shop, depending on how they’ve configured and equipped their TSO/ISPF environment over the past few decades. Having worked with numerous shops to modernize their mainframe development environments, I’ve seen a variety of rollouts—some more successful than others. One thing is certain: A well-orchestrated rollout is key to getting newer developers up to speed quickly, so they can work productively alongside their more experienced colleagues. A smooth transition can also accelerate adoption rates among veteran mainframers, so they, too, can leverage the power of newer technologies. Here are some tips and techniques to effect a painless transition to a modernized development environment:
1. Increase screen real estate with two (or more) monitors. People, developers included, like to get the most amount of work accomplished with the minimum amount of effort. The current trends of Graphical User Interface (GUI) development environments and inexpensive flat screen panels means developers can now have the tasks (views) they perform most frequently open and available all the time. No more searching through the system tray for an active window to restore; it can simply be accessed by going to a different window.
If you haven’t increased your development screen real estate already, understand that it’s vital to a successful deployment of a new, modernized mainframe development environment. No one is going to stop using TSO/ISPF one day and completely switch to a new GUI environment the next. So make sure developers have at least enough screen real estate to have both a 3270 emulator and a GUI IDE active simultaneously. Simply put, more is better here.
A good example of developers naturally choosing the easiest, quickest environment in which to accomplish a task is the ability to drag and drop PDS members from one PDS to another in a GUI. It’s simple, intuitive and much quicker than the multiple ISPF panels you would otherwise have to navigate. Once you’ve done a PDS drag and drop, you’re unlikely to go back. That would be, simply put, unproductive.
2. Internal contact(s). Transitioning to a new development environment is a lot easier and less frustrating if you can ask someone questions about usability and functionality. Some sites designate a full-time product administrator while others designate lead sponsors in every development team. Use whatever works best in your shop. These contacts should be enthusiastic and creative; evangelists, essentially. Along with helping with the “how to’s,” they often wind up setting up sharable profiles, debugging configurations and making available other community resources that ease and speed the transition.
Another component of this is to mix up your mainframe and distributed developers. Historically, these different development groups have typically sat in different areas, if not different buildings, or, at worst, different countries. Unfortunately, this often builds an “us vs. them” culture.
Years ago, I met with a development group that supported a large mainframe-based banking system. They were one of the first banks that enabled retail customers to deposit checks into their accounts by taking pictures of the front and back of the checks with their smartphones and emailing the pictures to the bank.
As you would expect, the mainframe developers were “more mature” than their smartphone colleagues, but the bank had physically gathered all of them in one area and they all sat together, completely integrated. There wasn’t a physical mainframe/mobile divide. They were all united by this application, which they were keeping current and enhancing with newly available technology.
During my visit, it quickly became apparent that there was a lot of shared respect and pride in their work within this team, which basically spanned three generations: Boomers, Gen X’ers and Millennials. They readily shared tips and techniques amongst each other. The mainframers in this group had easy access to people who grew up in GUI development environments and could easily see where modernized user interfaces were both simpler and more powerful in many areas. Likewise, the distributed people had that same type of access to veteran mainframers, who could teach and mentor them in that environment. A win-win situation here.
3. Blog/forum/Wiki. Here’s a great way to leverage social media. Setting up mechanisms where developers can discuss their issues with colleagues accelerates the learning process and speeds adoption of newer technologies. In addition, there’s a cross-mentoring effect that comes into play here. Veteran mainframe developers can help the new generation of mainframers with their platform and application-specific expertise, and the new generation can help the veterans with their in-depth knowledge of graphical IDE functionality.
This is also a great place to ease any technology transitions with a little bit of humor. All you need to do is Google “technology cartoons” and you will find a plethora of material that when coupled with helpful information, will make a shared-technology blog a great resource people will want to visit.
4. Regularly scheduled internal online meeting. One company is rolling out a modernized mainframe GUI development environment to some 300 internal developers and 300 external contractors dispersed all around the U.S. To help in this endeavor, every other week they have a one-hour “lunch and learn,” with an online Webcast where they can do demos/presentations. They cover issues that have been submitted to their blog (as per item number 3), along with any other questions or comments people want to share. It’s very successful, with an average attendance of roughly 70 participants. They also invite vendors to present as well.
5. Regularly scheduled vendor interaction. Just about every shop will take a unique approach to their mainframe development modernization and buy, build or configure a new environment that best meets their particular needs.
However, there’s an opportunity in this transition to simplify. In our industry, one of the tendencies of development environments, applications and technologies is to become more complex over time. Functionality is added, capabilities are extended and eventually, it becomes apparent that there’s a whole lot of “stuff” that gets little use. But it’s not in our IT nature to get rid of “stuff,” just in case it’s needed in the future.
In the long run, however, there’s a need to simplify. Doing so means fewer administrative requirements, shorter learning curves and reduced costs. So, now is an opportunity to build and buy the “essential” functionality for mainframe development that can be deployed in a modernized environment, but leave the rarely used functionality behind. It can be done.
Include your vendor(s) in this journey. It’s new territory for them as well, and they’re also seeing other companies on similar journeys and can share success factors with you. Both parties will benefit when there’s a continuous discussion of challenges—and progress—along the way.