IBM's announcement on December 6, 2002, that it will purchase Rational Software for $2.1 billion to make it IBM's fifth software product brand is an important event for professional software developers and IT management alike. But it's not about to change how midrange shops conduct their software development, and that simple fact is going to further limit the advances that midrange IT will make over the next few years.

Rational Software, which sells substantial project management and testing software tools specifically designed for the software industry, has an impressive and comprehensive set of products to help create, develop, track, and test software projects. These cross-platform tools are applicable to almost every aspect of the software development process. In fact, without such management and testing tools, it's certain that the productivity of software developers will continue to degrade while the costs for company management continue to astronomically rise.

However, implementing these software management tools in the midrange arena is going to be a difficult and challenging experience. Why? Well, though the environment for software development has changed drastically in the last 10 years, small to medium-sized companies are still stuck in the 1980s in their thinking about how software and software projects can and should be managed. And changing that culture is going to take at least another decade of failed projects and an expensive trial-by-error education.

Rational and the Software Development Cycle

Much has been written about software development methodologies, including Boehm Spiral Data Modeling, the Cleanroom Technique, Prototyping, Rapid Application Development, Extreme Programming (XP), and the pervasive Waterfall Development Methodology. But it was Rational Software that created and developed the Unified Modeling Language (UML), and that has become the accepted industry standard. (Today, UML is managed by the Object Management Group [OMG].) By creating a software standard language for creating software itself, Rational is in a unique position to control and accelerate the software development process within the industry. How?

Consider that UML unifies larger developers around the world by providing a single language for application, data, business, Web, XML, and test modeling. For its part, Rational Software has built upon its success with UML with a suite of products that touch nearly every aspect of the software development cycle--using UML as its base--including requirements and analysis, visual modeling, automated testing, project management, and configuration management. Rational Software's tools are not trivial, and they're designed to interface with other de facto standard office productivity applications such as Microsoft Word so that all levels of management can work seamlessly in a modern organization without excessive training.

So, in essence, Rational has built a software development methodology, from the bit-level upward, to reach the goals of project management from a practical, hands-on perspective. This is a powerful way to approach the whole issue of software project development: Forget the theories and bring each project into a common virtual environment that everyone can see, touch, and understand.

In the end, Rational Software's tools are actual automation processes for software development: tools that lead from the real-world problems of software development outward toward the abstractions and requirements of the software management process and, ultimately, business project management. This is a software development methodology that is burned into the tools themselves. Understand the tools, and you understand the methodology. Use the tools, and the methodology works.

Real World Software Development Is the Rationale

For larger software developers, working in virtual teams in a digital world, Rational Software's tools have proven to be extremely useful: They coordinate requirements planning, enable digital collaboration of software design elements, streamline the development of software from data models directly into prototypes and--in many cases--directly into code, and accelerate the processes of final testing and evaluation of finished products. And the benefits are extraordinary. Furthermore, this kind of virtual integration is exceptionally powerful as the number of software technologies continues to explode--particularly in cross-industry Internet-based e-business applications in which standards are in a constant evolutionary state. As new technologies surface, UML remains the "Lingua Franca" that connects the designs from one technology to the next technologies, without requiring extraction, transformation, and loading of requirements from one medium to another. Meanwhile, Rational Software's tool suite becomes the mechanism for control, extending the mechanisms and the development methodology by which applications come together. They become the glue that helps hold the software development processes together, providing management with a clear description of the process and an up-to-date picture of each project's status and cost.

This is much the same way, in analogy, that Microsoft's Word word processing software ascended to become the de facto standard for business documents, and IBM believes that Rational Software (with a market penetration of nearly 100% in Fortune 1000 companies) will similarly become the de facto standard for software development methodology into the foreseeable future. And if you control the manner by which people develop software, isn't it possible that you control the software industry itself? IBM thinks enough of this idea to pay $2.1 billion to find out.

The Myth of "Rational" Midrange Software Development

Meanwhile, however, most mid-market and midrange firms--which comprise the real target market that IBM would like to monopolize with its software products--are still stuck in a kind of sublime 1980's ignorance about the need for software development methodologies and serious management tools. How IBM and Rational Software are going to crack this nut is still unknown.

Part of the problem is that an unfortunate number of CEOs and CFOs have little or no understanding of the complexities of managing teams in a virtual software development project. For them, the software development cycle begins and ends when they complain about buggy code on their desktop: Their exposure to actual program development is limited to adjusting their Palm PDAs to Daylight Savings Time or debugging a wayward Excel macro. As a consequence, they offer little encouragement for their IT managers to embrace rigorous tools or methodologies that might significantly improve software development productivity. The result is stunning: Even though stories of software projects gone awry, poorly documented requirements, botched enhancements, technology mismatches, and cost overruns within corporations are legion, when the subject of IT project management tools is broached, these execs tend to turn their backs.

IT managers too in the mid-market are usually limited in understanding how such project management tools might improve quality and throughput while reducing cost. Too often these managers have a jaded perspective, relying on less-proven, informal, and often-failed methodologies like Extreme Programming (XP)--methods that are essentially simplified iterative debugging techniques. In such environments, formal requirements planning is considered too time-consuming, too inflexible, and too work-intensive; they'd rather have a programmer sit down with the user and a pen and paper to take notes. The notes are seldom formalized and scarcely analyzed or reviewed. And too often the prototype that is delivered to the user ends up as the final product, filled with bugs, un-tested, lacking any documentation, and hopelessly consigned to a legacy of incremental maintenance that only the original programmer can perform.

How many software projects are managed this way? No formal study has ever been conducted, but judging from the estimated 80% failure rate of IT projects, one might presume a great number.

Midrange Software Development Limitations

Of course, this kind of informal software development process within the midrange may have worked marginally well in the days of simple RPG and COBOL applications, but it doesn't stand a chance when building IT infrastructural e-business projects that meld together multiple architectures with the latest programming technologies. And, as a result, it's doubtful that midrange organizations will be able to fully take advantage of real significant technological advancement except when they are offered by a single software vendor like a Microsoft. This means, for the midrange in particular, that their organizations will become more permanently captured by unique vendors of integrated products, limiting the leverage that cross-vendor standards-based technologies might offer.

So it is this culture within the mid-market--and the midrange in particular--that will be the greatest challenge facing IBM's newly acquired fifth software product brand, and it is not a challenge that is likely to be quickly met.

Thomas M. Stockwell is the Editor in Chief of MC Press, LLC. He has written extensively about program development, project management, IT management, and IT consulting and has been a frequent contributor to many midrange periodicals. He has authored numerous white papers for iSeries solutions providers. His most recent consulting assignments have been as a Senior Industry Analyst working with IBM on the iSeries, on the mid-market, and specifically on WebSphere brand positioning. He welcomes your comments about this or other articles and can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..