Understanding IBM’s new Dependency Based Build vs. IBM Team Concert Enterprise Extensions

Strongback Consulting

IBM’s Collaborative Lifecycle Management (CLM) solution provides a comprehensive toolset to support the software delivery lifecycle for IT shops.  One of the products it includes is Rational Team Concert (RTC) which supports the collaborative development of software across multiple platforms.  RTC’s primary focus is on the software development team and it provides support for tracking and planning (e.g. work items, plans, reporting) as well as version control (SCM) and build.  Additionally, if you purchased the specialized IBM Developer for Enterprise Platforms license for RTC, you get access to the Enterprise Extensions (EE) capabilities that RTC provides.  These are designed to support teams that develop software to run on IBM’s Enterprise Platforms (e.g. z/OS and IBM i).  

The EE feature includes the ability to understand the different types of file systems that those platforms support (vs. the hierarchical file system that most modern SCM tools normally support) as well as the ability to interact with tools (such as the COBOL compiler or the REXX interpreter) that run on those platforms.  The other expectation on these platforms (unlike on distributed platforms) is that we shouldn’t have to rebuild the whole code base every time a build runs but the build process should be “smart” and understand what needs to be rebuilt based on what’s changed. Likewise, since binaries are rebuilt selectively, they should be selectively promotable (along with the changed source) and deployable.  

In a sense, the EE feature of RTC allows an organization to replace the existing build and deploy infrastructure (usually scripts written using JCL and REXX) with a set of reusable declarative constructs that are captured in the RTC repository (database) and can be maintained independently of the actual driver process that’s involved in building the code.  That is, I can define a “translator” for doing COBOL compilation once and reuse that declaration in many “build” definitions and source member “types” (aka language definitions). Other mainframe source code management systems provide similar constructs, usually using JCL like constructs (e.g. processor groups, SKELs, etc.).

The power of defining the mainframe build and deploy infrastructure using reusable constructs can certainly reduce the potential for maintenance issues, since you’re no longer cloning sets of code across multiple scripts which you then have to mass update whenever a change is needed (such as adding a new optimization feature or turning on debug).

However, there is also an inherent potential problem when you stray away from the operating system and implement a proprietary implementation.  The semantics of that proprietary implementation is often only understood and tightly integrated into that vendor’s tool set and you’re effectively “locked-in” to that vendor’s implementation and tool set from then on.  

The solution to this lock-in problem is to modularize the implementation even further and decouple it from the vendor’s toolset.  This is what IBM has done with the introduction of the new Dependency Based Build (DBB) feature that ships as part of the IBM Developer for Z EE product.  With this feature, you’re no longer tied to the IBM CLM/RTC toolset as your SCM provider (although you may still use DBB with that toolset) but you are now able to integrate this new way of building mainframe software with your SCM and build tool of choice (e.g. Git, Jenkins or commercial/3rd party SCM/build tools).  The nice thing about this technology is that you can now “script” your Enterprise build infrastructure using a modern scripting language (e.g. the samples are written in Javascript or Groovy).  This opens up the mainframe world to new graduates as the baby boomers that possess the mainframe skills are retiring in droves.

If you’d like to learn more about DBB, here’s a link to the documentation.

Let Strongback be your implementation partner for this new and exciting technology.



Comments are closed.