Addressing Challenges to Ensure Successful Tool Integrations


In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.

Tool integrations have been going on ever since the initial days of JCL (IBM's Job Control Language). JCL actually made things a lot simpler. But as tools have become more complex and diverse, tool integration presents many challenges. How do you integrate user interface and simplify the corresponding training? What about administration? How do you deal with varying scalability capabilities, and varying server requirements? What about multiple site operation? Successful tool integrations must effectively address these issues and must do so by starting from a process-centric view of the world.

There have been many "backplane" recommendations over the years for plugging tools into a common framework.  How successful are these and what success can be expected in the future?  There has not been much of success here.  Eclipse is an open source effort to push forward and has had some success.  Like other companies, Neuma has embraced the effort with it's own Eclipse plug-in, but with an order of magnitude of more effort than first anticipated.  In my opinion, this complexity will make it difficult for this solution to succeed in the long term as a full solution.  No doubt it has and will have more specific partial solution successes.

The work of tool integration is not easy.  Some say it should not be approached with over ambitious expectations.  However, if you find you have to limit your approach, you're losing before you get going.  Instead, a process-centric understanding of the goal is necessary.

To begin, every company and organization, wants to do CM/ALM/development differently.  Looking first at the technical side of things, in the '70s, diversity was in computer platform.  In the '80s the focus moved to programming language.  As user interfaces cropped up in the '90s, a new level of diversity emerged, with GUI toolkits and languages popping up to support these.  From a management side of things, there were a number of factors that caused diversity:  small and large projects, hardware and software projects, embedded and end-user projects, business and engineering projects, and so forth.

Initial Success Stories
This amount of diversity isn’t good if you're trying to integrate tools into a common framework.  My first attempt at an integrated solution was in the 1970s.  Putting together full-screen editors, compilers/linkers, version control, change management and build management into a single tool that could support automation and give project control was a definite challenge. 

The project was initially hundreds of developers, but that grew quickly to thousands.  It was an IBM mainframe based environment in a telecom setting.  "Network” didn't apply to the data side of telecom back then.  In fact, there was very little, if any, data side of telecom.  Surprisingly, things like Virtual Machines (VM) were an integral part of IBM's mainframe capability.  And so, even though each developer didn't even have his/her own keyboard and monitor (i.e., there were shared resources in the "computer room”), each did have his/her own virtual machine.  This first tool, named PLS, understood the source language enough to identify dependencies, and understood the target OS enough to automate builds.  It understood and worked with the full-screen editor so that it could effectively do version control.  It was a very successful project and is still in use to this day.  However, though it was ahead of its time, it still barely addressed things like integration with project activities/tasks and with the problem reporting system, which was just moving from a paper-based to a mainframe-based application.

Still it enjoyed success.  Here are a few factors that contributed:

  • It was designed for a particular computer system.
  • It had a small, fixed set of development tools that had to be integrated.
  • There was a single data repository that held all of the CM data.
  • We had full control over how the tools would work together.
  • It was designed to support a single common configuration management process.

Before we explore further, let's look at the second CM tool I put together, this time in the 1980's at another telecom company.  Again, it was a single computer platform (initially at least, on VAXes, eventually expanding to SUN workstations as well).  There was a great deal of experience from the first go around.  It covered more than just CM, from system requirements to test suites, and supported a more diverse set of compilers and editors.  It had a generic name: Software Management System (SMS). The concept of network was being established, initially as a small network of VAXes and then with work stations added in. 


About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.