On October 6, IBM announced major new releases of WebSphere Studio Application Developer (WSAD) and WebSphere Studio Site Developer (WSSD). But getting comfortable with the new releases is only half the battle: IBM has also renamed the application development suites to suit its long-term market branding strategies. In typical IBM fashion, the move is designed to satisfy its software marketing executives. Yet it provides still more confusion for those of us who are trying to both keep track of IBM's game plan and learn the tools that the IBM Software Division is delivering.
New Names Reflect New Tool Development Strategy
First of all, along with the release of the newest version of WSAD, IBM renamed the product to IBM Rational Application Developer for WebSphere Software. In the same breath, IBM renamed the WSSD to IBM Rational Web Developer for WebSphere Software.
These new names are supposed to better describe the new products so that everyone will understand what they do. However, isn't it a little like describing the new Toyota Tacoma as "Toyota Tacoma Four-Wheel Drive People-and-Thing Transporter"?
The WebSphere Studio names were pretty good product names, as far as describing what they did, but IBM's marketing PhDs obviously felt that there was room for improvement.
Of course, the whole exercise is absurd because everyone within IBM will reduce it to acronyms anyway. So what's the point?
Shoring Up the Corporate Strategy
Well, the point IBM is trying to stress is that from now on IBM Rational is going to be the primary source for core developer tools that support the IBM Software Development Platform (SDP), and Rational will now directly managing the core Java integrated development environments (IDEs) as well.
So what, exactly, do we get besides new acronyms and a few more words with the new names? The list, while not impressive at first glance, does offer clues to the directions and the values that IBM Rational is hoping to bring to the suites:
- Portal tools for visually developing portal applications
- Automated code analysis and component testing tools to improve code quality
- Enhanced runtime analysis tools to identify and fix performance problems early in the development cycle
- Built-in Crystal Reports tools for building powerful, interactive data reports
- WebSphere Rapid Deploy to accelerate application deployment and simplify system testing on WebSphere Application Server (WAS)
- Eclipse 3.0 support for a more responsive, attractive, and customizable user interface that increases developer productivity
New and Improved for Whom?
All this is good news if you believe that what the world needs is a new, better, more integrated application development engine for J2EE and Java. But it's not so good if what you've got in your development shop is a bunch of older RPG programmers who are still struggling with the transition to J2EE or programmers who cut their teeth on procedural languages and are still wrestling with the object-oriented programming model.
IBM would like us to believe that these older skill sets are about to be retired to the dark nooks and crannies of the programmers' toolboxes, but--based upon our understanding of the iSeries community--this is an unrealistic expectation. Companies still have major investments in legacy applications built with time-tested tools. Unfortunately, instead of attempting to make programming in these environments more cost-effective, IBM would rather reinvent the programming paradigm and sell us new tools and software development methodologies.
What Ever Happened to Lotus?
The same dilemma is facing Lotus Notes developers: IBM purchased Lotus and sold Notes into our organizations with a commitment to the Notes development platform. But later IBM reorchestrated its commitment so that LotusScript quickly became one more legacy application language--joining an ever-deepening closet filled with legacy languages--subservient to Java and J2EE. Today, Lotus WorkPlace (another marketing exercise in renaming a tried-and-true product) is something entirely different in both its scope and power. It is Java-dependent, has been stripped of many of its workflow capabilities, and is marginally a better product than Lotus Notes.
The issue is not that the programming toolbox is worse off than before, but that the skilled craftsmen and craftswomen who built so many of the applications that real businesses use today are being made unproductive. The rationale for using IBM Rational follows a twisted logic that presupposes that Java and J2EE are the future of programming. But, as Borland proved in the 1980s with its Turbo Pascal compiler, the future is what you make of it.
The On Demand Thing
By the same token, IBM also says that using such sophisticated tools and programming modalities will better position the organization to take advantage of IBM's e-Business On Demand architecture. New solutions will be built faster--with higher quality, better integration, and open standards--by teams of developers distributed worldwide.
This is one very worthwhile vision for business computing. But it is only one vision of the future, and it's a vision that has limited meaning to a business that is trying to compete in a global marketplace with limited local talent and restricted budgets for personnel and training.
The Vision Thing
The great global vision of computing is only as powerful as its customer base, and if the cost of obtaining the tools and training its programmers is beyond the means of a company, it will look to smaller, cheaper, more manageable methods to obtain measurable results. That's why so many organizations are turning to Microsoft's .NET architecture or investigating the new Borland Delphi products that were recently released. They scale better to these companies' real business needs.
IBM Software, for its part, sees the small and medium business (SMB) marketplace--the place where most of us live and work--as a shopping mall where CFOs and CIOs browse for the most cost-effective solutions for their business requirements. And this is a true depiction of how many organizations view their opportunities for purchasing software.
But there's a flip side too that companies are rapidly discovering. Application software does break from time to time, and business goals and strategies do change--often radically--to compete in the global economy. Somebody has to be available to change the engine oil within software applications, swap out the burned out light bulbs, or weld on new extensions of the current application software mechanism to include minor and significant evolutions in the business strategy.
The Maintenance Problem
The problem is that if the mode for developing application software evolves too rapidly, the local skills needed to make those required modifications may be unavailable at any price. Programmers learn languages and then learn new languages, forgetting the old ones over time. Some of us actually retire or change professions. If companies consume too many code bases, the result can be that no one is available to do the work. If this trend continues into the future, software will cease to break in the traditional way. Instead, it will rot, like ripe fruit, deep within the infrastructures of the SMB community.
This is why IBM Software can't kill RPG or COBOL or LotusScript, as much as it might wish to. They are proven programming tools that have built valuable solutions with the minimal resources that the SMB community had at its disposal. These languages are living examples that ROI is not merely another marketing acronym, but a serious discipline that the SMB takes seriously, day in and day out. The SMB loves RPG and COBOL because it doesn't change much and because it knows where to find programmers to fix stuff when things go bump in the night.
Nonetheless, IBM is intent on selling On Demand programming development to the SMB. Yet, in order for IBM Software's On Demand scenario to really work in that environment, the cost of developing software will need to be reduced by a factor of 100. In fact, software will need to become so inexpensive that it will be truly disposable.
Likewise, IBM's own middleware products will need to be free for the asking, and the task of connecting the middleware components will need to become so intuitive and automatic that anybody--including the CFO--can accomplish it. Things like ERP, CRM, and SCM solutions will need to be as transparently implemented as the process of popping a bag of popcorn in the microwave. Pop in the code, press the button, and listen to those middleware modules crackle and snap together!
Is This What the SMB Really Wants?
But the question is, is this what the SMBs really want? SMBs may not see the competitive advantage of pop-and-go software solutions. They may like the idea, but they may not find it meets their real needs.
Consider that today most of these organizations make their mark by scaling services to meet customer requirements or customizing products to compete in specific market niches. Many are small suppliers in a larger supply chain that earn their profits through unique market strategies, often using their customized application software to reap competitive advantage.
The entire scope and scale of IBM Rational's approach to developing software applications is as foreign to them today as visual programming was to RPG developers in the 1970s.
Instead, what most serious SMB shops want is a better RPG, COBOL, or Visual Basic application development environment: something simple to work with that will interface with the in-house code they already have. They don't want to learn new languages or programming methods. Instead, they just want to leverage what they know and accomplish more with what they have.
Satisfying the Legacy but Not the Need
IBM Rational, for its part, says that it has solved the issue of the legacy programmer within its new Rational Application Developer for WebSphere Software toolset. Rational says that it has a 4GL called Enterprise Generation Language (EGL) that generates Java code for execution on IBM WAS. They say that EGL is a simple procedural language--easy to learn for any programmer proficient in business-oriented languages like RPG or COBOL. They also say that by making the entire platform work on the Eclipse IDE, they are universalizing the method of application development within the organization.
But the logic of using a 4GL like EGL to satisfy the needs of someone who programs in RPG doesn't seem really rational at all. Isn't it really just creating one more legacy code base that will, very quickly, become obsolete itself? Isn't that just one more sheet of coding wallpaper destined to line the closet of obsolete languages made irrelevant by IBM Rational's overriding obsession with J2EE?
Meanwhile, the question of what we, as application developers and as SMB customers, really want seems to be escaping IBM as it pushes its long-term software strategies down our throats. And from our perspective, this strategy isn't Rational. Not at all!
Thomas M. Stockwell is Editor in Chief of MC Press Online, LP.