Today’s market pressures demand new functionality that must be delivered to Web servers as soon as possible, often within several days. As a result, many shops have adopted rapid application development
Both development styles have strengths and weaknesses. In this tip, you’ll see how a little creativity will help implement RAD on big iron to bring your company up to speed, as well as some advice on how to live with both approaches.
Classic application development
Most mainframe professionals grew up with the classic application development process. A typical classic development effort would start with sessions and interviews with business users to gather requirements. Meanwhile, application architects would develop a high-level design and coding guidelines. A few months later, after the requirements and design were documented, coding would begin while someone else developed test and implementation plans. As the new code came through the development pipeline, it would go through testing and trickle into production. The span of the project, from inception to final rollout, would span months, if not years.
It’s important to note that this style of development applies to all platforms, not just the mainframe. For example, say a company wants to change a website’s infrastructure. While the “look and feel” of the website may not change, programmers must modify all the underlying code for new framework. Given the importance of the website as the public face of a company, an effort like this requires extensive rigor, planning and execution.
This tried-and-true development style has served the IT industry well for many years. Rigor and discipline ensure the end product matches the requirements of the business. Additional benefits include more detailed functionality and performance testing, as well as some assurance the code has been developed efficiently. A broader background also allows for more detailed documentation. This is important, especially with object-oriented programming and the potential misuse of reused program code.
But these traditional development efforts are slow and expensive. Today, even a three-month timeline can be too long given the speed of change in a competitive environment where some requirements may become obsolete before the coding starts. In addition, application development talent is costly and project rigor can lead to processes that require two hours of paperwork for every hour of programming.
The use of rapid application development (RAD)
Because the traditional application development process doesn’t always work for today’s business environment, RAD is taking hold to increase development effectiveness, to attain tactical goals or to react to market forces in a shorter time. A programmer might start a typical RAD effort by interviewing an end-user about a small change to an existing system. After some analysis of the change and how to code it, the programmer may write some documentation. Then the programmer or a small team would code and test the change in an expedited development environment. After some coordination through Change Management, the modified code would go into production. The span of this type of effort might be measured in weeks. RAD employs smaller teams, smaller changes and less formality to achieve a faster time-to-market.
Again, this type of development extends beyond mainframes and across many different platforms. For example, short-duration efforts to add a column to a report or to change the format of a screen are perfect for RAD. In addition, in the mainframe's role as a corporate back-end processor, a lot of distributed platform RAD efforts won't get very far without also making changes to big-iron systems. Thus, any company considering a RAD strategy should plan to include all platforms up and down the stack.
RAD seems ideal for today’s accelerating rate of change. With fewer people involved in programming, tracking and testing, RAD efforts are certainly cheaper. Without traditional development formality or exacting requirements, much of the code can be designed on the fly while collaborating with the end user. There is also a lot to be said for freeing programmers to come up with creative, elegant solutions that produce big functionality for relatively little money.
But RAD also generates its own set of problems. Less rigorous testing leaves production exposed to potential major bugs. Application performance is also a major concern, and bad RAD-generated code can have a direct impact on customer experience and long-range capacity planning. Finally, RAD changes must be retrofitted back into the main development stream. Not only does the modified source code need to be considered, so do any interfaces or data schema changes. How this is done, and at what point, can be problematic for the development team.
Mixing development approaches for mainframes
Companies should be prepared to support both development styles. Major long-term project work won't go away; a large corporation can’t replace its general ledger over a weekend. On the other hand, RAD will get new features to consumers faster and cheaper. But, if both types of development must coexist, here’re some suggestions for making it work:
- “Think small”: build systems and programs with flexible and disciplined interfaces to increase change granularity. For example, each component should be loosely coupled to make for easy implementation and the smallest possible rollback if unexpected issues arise in production.
- Major projects should consider planned points where RAD-generated code can be injected into future longer term projects. There should also be plans for managing how the project’s requirements or functionality may change with each injection of RAD code.
- Use collaboration software that allows programmers to talk to users and each other. Keeping the path of communication open between developers and users will usually result in a better application development process.
While mainframes, in their long tenure, have accumulated many burdensome processes, a smart shop can develop ways to expedite host development and support RAD practices. Here are just a few suggestions that might help:
- Delegate traditional systems programmer tasks, such as bouncing address spaces, to application programmers.
- Use logical database partitioning that can assign subsets of data to different development efforts.
- Use “blank” CICS and IMS environments that individual programmers may tailor to his or her needs.
- Use mainframe cloud facilities, such as IMS’ Batch Terminal Simulator, that provide programmers with their own IMS. Another cloud tool is Rational Developer for Z-Unit Test, (RDz-UT) which supports a full z/OS image on a distributed server or laptop.
- Finally, better tools can enhance the application development process, so employ modern development workbenches that support host languages and testing.
Robert Crawford has been a systems programmer for 29 years. While specializing in CICS technical support he has also worked with VSAM, DB2, IMS and assorted other mainframe products. He has programmed in Assembler, Rexx, C, C++, PL/1 and COBOL. The latest phase in his career finds him an operations architect responsible for establishing mainframe strategy and direction for a large Insurance company. He lives and works with his family in south Texas.
This was first published in January 2012