I've been an IBM midrange user and developer for over 20 years. I've been an advocate, an evangelist, and occasionally a critic. The IBM midrange platform, from way back in the days of the System/3 and Series/1, has provided the best tools for developing business applications. This is my unequivocal position--no other platform, be it competing midranges, beefed-up PCs, or the venerable and constantly re-invented Unix variants, has even come close to the programmer productivity and total cost of ownership of the IBM midrange. This benefit has evolved over the decades as the line has evolved. The iSeries is simply the latest manifestation of that line and a most worthy successor.
Why this unabashed enthusiasm? It's certainly not based on raw price/performance or features like native GUI or price-per-gigabyte of disk storage, or inexpensive peripherals. And until recently, it also had nothing to do with advanced language support or interoperability with other platforms.
In fact, until quite recently, the iSeries' predecessor, the AS/400, had limited capabilities for interacting in a heterogeneous network. And while we certainly applaud the addition of TCP/IP support and standardized SQL access, Java support and Unix-like capabilities, Linux partitions and Web application support, I'm writing this letter to point out one fact that seems in danger of being totally lost in the rush to new technology.
For the most part, today's iSeries users used to be AS/400 users. And AS/400 users were previously S/38 users. S/38 users came from S/34 or S/36 shops (although that line is a little blurred), many of which started out as System/3 houses. There has always been a certain amount of conversion from other platforms (and, unfortunately, conversion away), but a very substantial part of the user base of the platform has come from within the existing user community. Let's call these loyal customers your "legacy users." And one of the primary, unique strengths of the IBM midrange platform--and indeed the reason the platform has enjoyed such a loyal following over the years--has been the fact that these legacy users could move their applications from one version of the platform to the next with little or no change.
I can understand the desire to attract new customers from outside the legacy user pool. Without new additions, this pool can only grow smaller over time, not larger. In order to really grow the business, IBM must find new users and encourage defections from existing platforms. Today, that means focusing on new technologies and interoperability with other platforms, and that inevitably means a little bit of hype. If the whole world wants C++, then you better provide C++, regardless of whether it falls by the wayside a few months from now when the fickle focus of bleeding-edge technology changes to the latest new buzzword.
However, those technologies often don't mean much to your legacy users, especially if they're designed in a vacuum, as they sometimes seem to be. I'd like to present a few areas that have changed over the years and give you my perception of how well or poorly you've done in taking care of your legacy users.
This is the single most important contribution you've made to the legacy user community. By allowing us to move legacy systems to the new ILE architecture with a minimal amount of intervention, legacy users can take advantage of new technology while still keeping their investment in their legacy systems. The implementation of ILE is the most powerful example of how to advance IBM's unique technology yet maintain the relevance of legacy systems. The ILE team definitely understands the needs of the legacy users.
Grade: Technology A+, Legacy Support A+
This area has been wonderful, at least to a non-power user like me. You've added tons of support for most TCP/IP features that any business would need. There are a few issues that always come up, such as printer drivers and the like, and some of the APIs could be a little easier to use, but in general your support has been outstanding. Not only that, most everything is available to the legacy user. I believe some advanced features require Operations Navigator, and we can go on and on about how there might be better legacy support for that particular tool, but in my opinion you've done an outstanding job here.
Grade: Technology A, Legacy Support A+
This may be the shining jewel in your move toward open systems. You have not only implemented a core open technology, but you've also managed to take advantage of the power of base OS/400 in ways that have pushed the technology beyond anything the non-IBM community would have been able to do. Your inter-language support is nothing short of phenomenal, and I'd put that on every piece of Java-related literature I have: "Our Java talks to the world!" There are still a few areas that need some work in HLL interoperability, but the team continues to improve the support, and the Java Toolbox is one of the great pieces of Java software.
Grade: Technology A+, Legacy Support A
And here we begin a bit of a slide. IBM's commitment to SQL technology is obvious. But the idea that SQL will supersede DB2/400 is a little bit like the idea that Unix will supersede OS/400. While SQL is good for many, many things, the one thing it is not good for is keeping legacy investment intact. The idea that all business logic will someday be written using SQL is one that many of us in the user community find a little hard to swallow. And if you compare some of the dense, difficult to read expressions needed by SQL programmers to the simple syntax of RPG or COBOL, it's a bit worrisome to us that you have decided to kill off DDS in favor of SQL. Scrollable cursors may someday be as powerful as logical views, but they aren't there yet, and the SQL preprocessor still needs some work. So while we realize that keeping two standards is difficult, killing one before the other is ready isn't a good move either.
Grade: Technology B+, Legacy Support B
This is one of the most subjective areas--and one in which I often find myself in the minority. However, I think there needs to be some review. After many years of slow, stable movement, RPG has gone through an explosion of change, with RPG IV, ILE support, and now free-form syntax. And while each of these changes has unquestionably been an advance of the state of the art, there is also a certain backlash. The fact that various features of the old versions of the language will not be supported in the newer versions means that many legacy users face a real difficulty in moving to the newer standards. As the biggest example, I find it difficult to understand that you've removed the MOVE opcode from the new free-form dialect. It means that an application that uses MOVE needs to be carefully reviewed and rewritten to support the new syntax. This in turn means a potentially prodigious amount of work that adds no value to the product. In many cases, legacy users won't be able to justify this expense and, thus, won't move to the new syntax. And that means you will have to support the older syntax for as long as the legacy systems are around, or else you'll completely abandon those legacy users. This seems to me to be a pretty poor strategic decision.
Grade: Technology A, Legacy Support C
6. Web Technologies
This is another subjective area, and I have made my position known over the years. I believe that IBM's Web technology is second to none, but this technical superiority is diminished by the constant changes in direction and the confusing and contradictory marketing decisions that seem skewed toward short-term revenue as opposed to legacy user support. Legacy users can't afford to move to J2EE, but they need Web technology. WebSphere currently provides little support for these users.
Grade: Technology A, Legacy Support C
7. Development Tools
One particular issue colors my views on this particular subject: the abandonment of VisualAge for Java. However, the new Eclipse-based tool set has the potential to remove most of my doubts. It's unfortunate, but I suppose understandable, that you had to stutter-step your way to where you are today, so I'm willing to wait a little while to see what the new version of WDSc looks like before I make up my mind.
Grade: Technology A, Legacy Support (Incomplete)
So what's the common thread to all of this? The common thread is that in most areas of software development, you have done great things in incorporating the newest technologies into the base operating system, but you seem to have forgotten about the folks who have been with you forever, especially the smaller shops that can't afford wholesale rewrites of their legacy systems just to keep up with your changes in technological direction. OS/400 has made great strides in legacy interoperability, strides that other platforms can't even begin to match. Yet there are still areas where your legacy users have been left in the lurch during your headlong scramble into the 21st century. And there's no reason for it. In fact, if you were to take a little time to really think about it, I think you might come to the conclusion that this legacy interoperability is a core strength, one that you should always focus on, because it's one that you have always had the lead in and one in which other platforms will never be able to overtake you, unless you let them.
So it occurs to me that perhaps what is needed is a core group within IBM that focuses on legacy interoperability issues. This group would be charged with determining how legacy systems will interact with the next-generation application architecture. Of course, this also means that there needs to be a corresponding group that is focused on identifying what that next-generation architecture will look like. Because in the current rush to technology, it seems to me that little or no time has been spent on determining how these new technologies will interact to form real applications. The good news is that we have a great base of experience to draw upon--namely, the existing legacy user base! If you were to take the time to analyze and categorize the various applications legacy users have, you would end up with a wealth of information about how business applications grow and evolve. This information, together with a solid understanding of the new software architectures, would allow you to create a sort of road map to the future. This road map could be applied to any existing legacy system and allow legacy users to determine which technology upgrades they need to apply. Rather than the wholesale rewrite of a legacy system that has been fine-tuned and working for a decade or more, legacy users would instead be able to make strategic decisions as to how and where to apply the new technologies, and they'd be able to choose proven ways of doing so.
An entire industry would appear: legacy rejuvenation. This would not be simply putting a pretty face on an existing system, but instead leveraging the thousands and thousands of programmer years already invested in the platform. And since they wouldn't have to spend time reinventing all those wonderful wheels that are already in place, the new technologists would instead be spending time developing the next generation of killer apps, which would not only look good, but also have as their foundation the combined knowledge of all those legacy programmers.
The idea, it seems to me, is not to replace all those existing systems with whatever new technology comes down the road. That could be done on any platform. Indeed, that's the Microsoft strategy--in order to stay with us, you have to rewrite everything, and once you do, you'll be rewriting everything over and over again, introducing new generations of bugs into what were previously working systems.
Instead, you should be trumpeting your strengths--in particular, your ability to interoperate with legacy systems. You should be positioning yourself as the leader in evolutionary technology:
IBM, the company that values your legacy investment as much as you do.
IBM, the company that can take you and your legacy into the next generation.
IBM, where there is no estate tax on legacy software.
Nobody would be able to touch you.