Mainframe developers have relied on the waterfall methodology of app development since the 1970s. This lengthy, linear development process usually lasts between 12 and 18 months, with delivery of a final product relegated to the very end of the endeavour. Waterfall development worked for decades, but it also came with a few significant downsides:
1. Delayed testing
Development teams can’t conduct in-depth product tests until late in the development stages. After all, until the team has reached a certain point in the process, there isn’t a product to test. With testing delayed until late in the game, you risk running into significant problems with the app.
2. Lack of user and requirements feedback
In the same vein as the above, users can’t provide requirements feedback throughout the process because they can’t sandbox an iterative working prototype early enough in the dev process. Feedback that comes at the end of beta development is far less valuable than early feedback because your developers might have spent months of their time working on features that users don’t like or weren’t asked for in requirements documentation.
3. Inefficient change management methodology
With the waterfall methodology, an unwanted feature can’t be easily replaced with something new. In some cases, going back and making changes after the feedback stages requires ripping out lots of code that took time and budget to build.
4. Questionable budget management
With testing, feedback, and alterations happening so close to the end of the development process, organizations could end up spending a fortune on a product that doesn’t meet the software requirements. Every dev method regardless of waterfall or Agile or DevOps starts with requirements by the users of the service. When requirements are missed in waterfall you must go back to start. In DevOps you merely need to go back to the last iteration which is less costly to your budget.
Recognizing the shortcomings of the waterfall methodology, more mainframe shops are adopting DevOps, which allows for development in iterative stages and regular feedback throughout the process. Large teams of developers working on an application in iterative releases can accomplish incredible things in far less time, but the practice poses a threat to the Db2 Catalog that’s often ignored — clutter and version accuracy.
The Consequences of Catalog Clutter
When applications within Db2 are pre-compiled, a Database Relational Module (DBRM) is created. BIND PACKAGE then takes this DBRM and enters it into the associated Db2 system as executable machine code in the form of a PACKAGE.
With large teams of mainframe developers working on different aspects of an app and compiling several times per day and five or more days a week, a Db2 Catalog can quickly become inundated with thousands of package versions that are outdated and unnecessary. The result is a poor-performing Catalog that can bog down applications and negatively affect other linked systems.
DB/IQ Package Management product or PackMan allows you to quickly establish which packages are critical and which are not needed, so you can clear your Catalog of the latter and unlock quick and easy performance improvements for things like Backups and REORGs.
Don’t let a cluttered Catalog negate some of the amazing benefits of your DevOps development initiatives. Download our latest whitepaper titled “With a Mainframe Skills Gap Amidst a Global Pandemic, Effective People, Processes, and Systems are Critical Now More Than Ever” for tips to help maintain application code quality within your DevOps strategy and amidst the mainframe skills gap. For more information and a free trial of DB/IQ PackMan, please click here.
