In this article, I'm going to try to present you with the future of the System i. I ask you to read this and to join in with your comments, because I see this as a watershed time. As Mike was giving his talk, he was careful to mention that some of the things he was talking about might make it into V6R1, many would not, and some might never make it at all, depending on things like marketplace acceptance (read: profitability). All of which means that this may be one of those special leverage points, where you and I as the end users can most affect the future of our platform.

From my vantage point, I see five major trends in the System i family that are changing the face of the industry.

• Pricing
• Granularization
• EGL
• Super-integration
• i Blades

Many of these we've seen coming over recent years, and some are out of the blue. But in either case, I don't think many of us put all the pieces together to make a coherent view of the future. I'll try to make some passes over the crystal ball, though, so hang on.

Pricing

First of course is pricing. For the longest time, System i hardware was selling at 10 or even 100 times the price of comparable Intel-based hardware. A lot of different reasons pushed that price structure, but it did allow for something rather unique in the industry: the tier-based price. This simplistic model allowed a shop to buy a machine and the software it needed and then stick as many people on the box as it could.

Those days are gone. Over the next few years, I expect IBM will move the platform to an entirely user-based model, although, as seems to often be the case, IBM chose the most difficult time in history to make such a change. With the explosion of the Internet and multi-tiered systems, the concept of a "user" has become very difficult to define, and even now IBM is winging it, trying to define the difference between authenticated users and anonymous users and named users and concurrent users.
Rest assured, though, the result will be that you will pay a base cost for your server and then incremental costs for each user, and those costs will be determined in a large part by what they do. In the end, that makes sense: It allows IBM to more directly apportion development dollars based on the number of people using the tool. On the other hand, it doesn't bode well for niche technologies like VisualAge for RPG.

The trend here is that tools will either be paid for by the marketplace (you and I), or they will die. Niche capabilities will become more and more expensive and then will disappear. This will include both hardware, such as twinax support, and software.

Granularization

Which leads us pretty directly into granularization. That's the term Mike used, although the other word for it is "unbundling." However you spell it, what it means is that IBM will be carving up large pieces of software and selling them to you a la carte.

I hate this concept. Every fiber in my IBM midrange evangelizing body screams against this concept, because I'm just so comfortable with the idea of being able to use any development tool whenever I need it. I pays my money, I gets my software, and after that it's up to me how I use it or whether I use it at all. It's been phenomenal for me over the last several years that, if I wanted to play with the COBOL compiler, I could just do so. And things like PASE were no more than a disk away. To me, it was one of the last major differentiating factors for the platform—and one that was sorely needed because, at the time, it looked like IBM was turning the platform into just another database server (and an overpriced one to boot).

But granularization is the wave of the future, both in tools and in utilities. From a developer's standpoint, all-for-one is a great way to live, but it plays havoc when trying to calculate return on investment for the vendor.

What that means, though, is that hopefully you'll be able to tailor your environment a little better. If you're purely a green-screen shop running S/36 code, you may be able to buy only those components that allow you to develop there without any additional cost. On the minus side, of course, if you plan to use both WDSC and PDM in the same shop, you'll probably have to pay more than someone who uses one or the other. My gut feeling is that this is going to force some shops to WDSC, and of course that's not going to go over very well.

My big argument with this notion—and one I brought up specifically to Mike during the Q&A after his presentation—was how to get software into the hands of System i developers so that they could evaluate its value to their shop. Since a lot of the push for this comes from the tools side of the business (especially Rational), they seem to favor the PC concept of downloading a 90-day trial. I made it clear that System i shops don't have the ability to perform an assessment of a multi-thousand dollar investment in 90 days, especially in the SMB space. First, we have to find the time to evaluate the product in our copious free time, which may take many months on its own. Only then can we present that to upper management, and their approval might take several more quarters. So if they do intend to go with a trial period concept, then it had better be a rather lengthy trial (like on the Zend products, which currently have a three-year license-free period, after which maintenance kicks in).

Personally, I prefer a single license-free developer seat for every tool. That seems to have done companies like Linoma Software pretty well. A developer gets to use the tool as much as necessary, and if the company needs more seats, it buys them. This does several things: It makes the platform extremely attractive to developers, it builds goodwill among smaller shops (which probably wouldn't be able to buy the tools anyway), it provides a base of free beta testers for the tool, and it builds product loyalty, which then extends to the paying community.

You need to decide which way you want to go with this, because it's coming one way or the other, whether you like it or not. You will either have to download trialware for every tool you want to use, or else you'll get a single license-free (and possibly unsupported) seat for each tool.

EGL

And that brings me to EGL. That's good, because EGL allows me to honestly call this a "Weaving WebSphere" column, since EGL is so intertwined with WDSC. Right now, you need to have either Rational Application Developer or WDSC installed on your workstation in order to install the Rational Business Developer extensions, which provide the tooling for the EGL language.

I'm biased here. You know me; I've been trying to bring browser-based technology to the System i for nearly a decade now, and I keep seeing pushback both from industry pundits and from IBM itself. IBM's disastrous attempt at replacing RPG with Java cost us several years, and the introduction of PHP is going to muddy the waters for another couple of years until people realize that it takes even more work to create a commercial, production PHP environment than it does to build one in Java. But most of this is because IBM hasn't presented us with a clear direction for the future.

That's over. EGL is the clear direction. You may not like it, but then again a lot of people hated subfiles. It's pretty clear to me that, like it or not, if you're going to do anything other than green-screen, you're going to have to get over it and embrace this technology. EGL is built from the ground up to provide easy, WYSIWYG design capabilities for the browser as well as direct, high-level access to SQL, MQSeries, and ILE programs. You can define a record (a set of named fields with attributes such as length and prompt literal and validation), drop it on a page using click and drag to do all the work of painting the screen, and then call an RPG program with that record by adding a single CALL statement to the generated code. It takes minutes, and no other language comes close.
The language is completely contained within the Rational tooling, which provides end-to-end debugging from the browser page to the Web application to the business logic back-end, again something no other architecture provides. And while I can't tell you what's coming in the new release, I can tell you that when it gets here, it's going to put every other tool in the also-ran bucket.

The only hang-up is going to be pricing. The problem is the collision between the old tier-based pricing world of OS/400 and the new user-based pricing of i5/OS and the Rational tools. My concern is that Rational wants to charge some $1,500 a seat to a company that already paid $10,000 or more for their compilers. No other platform gets this sort of double whammy, and IBM is either going to have to drastically reduce the price of RPG or include a couple of seats in the 5722WDS product. This is something you ought to be weighing in on. Would you rather pay an extra thousand or so for 5722WDS or pay a couple thousand less and spend that on seats for WDSC and EGL?

Super-Integration

I use the term "super-integration" because the correct term, "assimilation," is a little too scary. But the recent announcements regarding integration and virtualization have made clear a master strategy that can best be summed up as "All Your Server Are Belong To Us!"

We've seen virtualization in the last several years. I went to a class on Linux LPARs a while ago that just blew me away: I couldn't believe how easy it was to carve a virtual Linux partition out of your i5/OS system and then be able to save, restore, and even resize that entire server as if it were a simple physical file.

That's going to continue. IBM's direction is to allow you to point at a physical server in your network and then just sort of suck it up into a virtual server, sort of like materializing it with a transporter beam and plopping it onto the holodeck (OK, enough of the Star Trek references). What it means is that instead of an ever-proliferating number of Windows or Linux machines, you'll instead be able to import them into a single server and then manage them, even clone and deploy them, with all of them sharing the same hardware resources (including centralized backup and recovery).

So now, instead of the old legacy box being pushed out by the cute little Windows servers, the System i is instead the central repository for all your software images. It doesn't matter what you run; they all run on the i. Of course, this will require ever more computing power from the System i, but with the introduction of the Power 6 and the concept of Capacity on Demand, IBM is making even that more manageable. If you need the really big Web servers only once a month, you can deploy 10 of them, flip a switch on the System i, and have mega-capacity without having to pay for the fixed costs all year.

But the final bit of this that really caught my attention was the stated direction that IBM will provide some sort of hooks (and I'm still not sure exactly how this will work, although my guess would be through some sort of extender utility) to DB2 that will allow it to access other databases throughout the network. One of the biggest complaints about DB2 on the System i over the years has been that it's pretty much one way: SQL Server on a Windows box can easily access DB2 on the System i, but RPG can't easily access SQL Server data. That's going to change and, in the future, you'll be able to access any network-capable database "natively" from the System i. It will be interesting to see whether this applies all the way down to RPG and how much such an ability might cost, but the benefits are pretty obvious.

i Blades

And that leads me to the last bit, the infamous i Blades. Long rumored, and finally semi-official now with a delivery date sometime next year (dates to be determined, forward-looking statements, your mileage may vary), i5/OS will appear on POWER 6 servers in a blade center near you.

With i Blades, even if you don't travel down the road of full assimilation, that doesn't mean that i5/OS won't be able to live in your IT environment. In fact, the concept of an i5/OS blade that can interact with all of the databases in your network may have enormous appeal to ISVs that can write applications taking advantage of both Java and RPG and then simply sell blade plug-ins to IT shops. The heavy transactional applications that simply don't scale well in Wintel environments can be supplied in an i Blade and connected to the system via an EGL front-end, and then can supply data to Wintel/Lintel dashboard back-ends via DB2 integration.

This to me is the most important point for the future of RPG. The entry point for ISVs has become progressively higher compared to Windows applications, leading many vendors to either move to platform-independent (read: non-RPG) solutions or to abandon the platform entirely. By providing an avenue for low-cost entry into smaller IT environments through a standalone (but integrated) blade, vendors may once again be able to position an RPG solution as the high-power transaction-processing component in an overall integrated architecture.

Integration and Simplification

What I see here is a trend toward a simplified, integrated shop. It doesn't matter which end of the spectrum you come from. For large shops, mainframe applications can be migrated down to the System i and then integrated with the Linux Web applications that have sprung up to provide Web presence. Small shops that started out with an ERP system and a Web server and have since grown to a small server farm can now re-integrate into a single server. Even shops that don't use System i today can now add powerful enterprise applications by adding an i5/OS server to their blade center.

So, whether your IT shop is going to consist of either a single large server holding all of your virtualized environments or a rack of individual servers sharing data to provide information for rapid business decisions, it really looks to me like IT starts with "i."