midrange.com - In My Humble Opinion

Our friend Aaron Bartell produced a ... um ... interesting (yeah, that's the right word) video while taking a break from writing an article for System i Network magazine.

What do you think?

How did we do? Well, it has been a mixed bag. Our interest in keeping the solution cross platform quickly ran aground as we faced the difficulty in getting the more entrenched RPG programmers to embrace Java as well as finding Java programmers who were comfortable in the System i world. We also got some push back from customers who also did not have the Java programming resources to grow and enhance the solution. We also began to use, through the hiring of an individual, an ILE RPG CGI framework that would be more "comfortable" for the RPG programmers to use and be more productive. This two pronged approach was completely wrong for a host of reasons and has hampered, IMHO, the overall solution. The business model we used, using support revenue to fund the development of an Open Source solution is actually a good one and has been successful overall. Had those resources been more carefully managed, matching development costs more closely to the revenue model, it would have been an excellent way to grow the overall effort.

Focusing on the development approach: We completely underestimated the effort required to build a web application. I don't care whether it is written in Java or ILE RPG, the skill set needed to develop a UI using HTML, CSS and Javascript plus backend business logic and framework components completely overwhelmed our programming staff. It was recommended very early on that we hire at least two "HTML Monkeys" (as one programmer called them) to offload the UI to folks with the proper orientation to UI. That recommendation was never followed but would have saved countless hours of programmer time. I honestly don't think a programmer should be designing a UI in a web solution. Period. I also don't see any more productivity in either ILE RPG or Java (the only two programming languages we used). If the programmers could have focused on writing business logic and enhancing the framework, rather than designing UI, we would have been much better off.

If I was starting out today with the same code base and the same goals, I would do the following:

1. Use HATS to get a web interface in front of the customer NOW. I would do this because the lengthy wait for a completed solution led to some attrition in the customer base. Better to have a transitional technology in front of the customer now to hold their attention rather than to try to hold them with promises. HATS was not mature enough in 2002 and the System i not yet powerful enough to make HATS a viable solution at the time. It is ready for prime time now.
2. Decide on a single programming language and go with it. Personally, I like the idea of Java on System i because it makes a solution potentially portable to other platforms while leading with the strengths of System i. However, ILE RPG is a "natural" for the System i and many folks who are already on i are more comfortable writing RPG code. Naturally, RPG will be more productive for RPG programmers and Java more productive for Java programmers (duh!). But there is nothing inherently more productive about either language (although the OO nature of Java might lead to more productivity over time, IMHO).
3. Find a framework that is productive. Tough call here and this is where the "missing link" comes in, particularly for RPG programmers. IBM provides no tools or frameworks in RPG that made the move to the web easier. CGIDEV2 was a community response to that deficit,and a good one, but this deficit in in IBM supplied RPG web frameworks still remains. When I look at other tool providers, the successful ones who had proprietary languages that did text based applications migrated their tools to the Windows UI and then on to the web. Microsoft in particular did a great job with this, moving Basic to Visual Basic to VB.NET. Yes, very different languages but MS at least developed the solution (or bought it) and got it in front of their developers. IBM got with the Windows GUI program with Visual Age RPG but then when the web appears they did ... ? I am mystified that IBM who fully "owns" RPG and clearly saw the web as the next UI wave simply froze and did nothing to enhance the language to easily get applications to the web. What were they thinking?

We have an awesome platform, loyal customers, and a cadre of programmers just dying to cut their teeth on an IBM supplied, leading edge, ILE RPG based web framework. Where is that web framework, now 12 years after the popular advent of the Internet? That is the missing link. A "link" sorely needed as the platform struggles to maintain market share.

There are many, many other lessons learned from this experience and I am certainly ready and will to share them. Feel free to chime in.

We initially began our iSeries modernization process with writing custom web apps using WDSC utilizing the Webfacing feature. I first learned about WebFacing at COMMON in San Antonio in 2004. At the time it seemed like the answer we were looking for. So, I purchased Claus Weiss' book "Understanding the IBM WebFacing Tool." This is a great read and walks you through step-by-step on initially getting your custom iSeries apps to the web and also helps you customize the WebFaced app to suit the users needs.

However, from the time I deployed our first WebFaced app on our WAS Express 5.0, we began seeing lots of performance issues. The performance hit was only on the web side of things and was having trouble processing multiple requests. For example, one of the main issues we had with any WebFaced app was every 9 to 15 clicks of the mouse where the iSeries had to do something, the app would hang for around 5 to 8 solid minutes. Seeing this, I submitted a PMR to IBM and I got the dreaded response, "We've never seen anything like this before." So, we tried putting on some PTFs to hopefully fix the problem to no avail.

After a year or so of doing this, and a managerial change in my department, we decided to investigate CGIDEV2. I put together a few test programs just to see if the performance was the same as a WebFaced app. There was no comparison in performance. The difference was like night and day. My new manager was highly impressed and was wondering what language it was running behind the scenes. When I told her it was RPG, she didn't believe me. So, I had to show her what was really going on and she was floored. All we needed to do was convert the DDS screens to html, rework some of the RPG programs to utilize the CGIDEV2 APIs and add a few lines into our Apache configuration file and Viola!

Since that time, all of our WebFaced apps are now on CGIDEV2 and we're not looking back. This has truly been the answer to our iSeries modernization prayers. In a world where a sexy look and high performance is what users desire, I don't see how anyone can drink the WebFacing kool-aid.

Don't get me wrong. I think WebFacing is great for getting custom iSeries apps to the web fast. However, I truly believe that it's a short term solution. We have had an overwhelming number of positive responses to the new apps in CGIDEV2.

[tags]webfacing, cgidev, ibm, common[/tags]

Five years ago I started a company with a few other folks who were trying to "save" a school administration system that was written in RPG that we did not own. In this particular case, the company that owned the software and the source code was really just using the customer base as a revenue source while they pushed the customers into other school administration solutions that were not System i centric. You may have heard of PowerSchool, once owned by Apple, which is now owned by this same company. How a company that initially acquired the premier IBM Midrange (S34/S36/S38/AS/400) school administration system (once sold through IBM!) could end up selling a solution that runs on an Apple platform is a long, ugly tale that involves hundreds of folks and millions of dollars. But, the bottom line here is that IBM failed to capitalize on and captivate the mind share of system administrators that really needed a stable, reliable and easy to administer system. That failure was demonstrated in the reality that the company that acquired this software back in the 80's missed the fact that the true asset was the system the software ran on, as well as the software itself. The hardware was the key to the solution, not just an interchangeable component of it. As the software solution was bought and sold a few more times, the beauty of the platform was lost to the need to look more "modern".

But, that was also a bit before systems started to become commoditized. Commoditization has hurt the System i platform prospects because the system can run so many application that people miss out on the fact that running applications is only part of the solution. Running applications in a stable, reliable and easy to manage environment is the key. It is the holy grail. The System i has that. It is a slam dunk reality that no other platform, IMHO, can match.

So, now the issue for us System i die-hards is, the RPG applications of yesteryear, like the school administration solution I originally mentioned, are essentially unchanged in their 1980's look and feel. That is precisely because of the stability of the System i. I have customers who I trained on the System 36 version of the software in 1987 that are still running the follow on version of the software on the System i today. In some cases they are using data that was keyed in on a System 36 and migrated to the System i with minimal disruption. They love this platform and, in smaller school districts, they have managed to keep their IT staff to one or two people when it comes to running the school administration solution. In one case, I consulted at a district that had NO IT staff for the System i school administration system, just a janitor who swapped the tape out of the drive while he cleaned at night. Compare this to the instructional solution arena where there might be many, many IT people needed to keep the network, application, database, web and email servers running. From a management standpoint, it is a nightmare.

So back to the "missing link". Here is the reality of the marketplace we were facing when we started up the company:

1. Loyal Midrange customers. Some had been using versions of the software for 20 years.
2. Green screen stability was losing to GUI "glitz and glamor". PowerSchool looks great! Our solution looked like "DOS".
3. The "AS/400", although stable, was seen as a dinosaur.

Our decision, for better or for worse, was to lead with the System i. We didn't have source code so we had to rewrite from scratch. We used the database on the System i and released the code as Open Source. We were going to focus on a web based solution rather than a plump or fat client. We initially chose Java as the programming language because we could write code that would run (theoretically) on any platform. That would alleviate the need to fight the hardware battle during the sale of a system (although we would lead with the System i in all cases). We could continue to support customers running the RPG version of the code while we delivered a web version. They could use both simultaneously since both solutions used the same database.

Five years later, how did we do?

Continued in part two...

Together with user based pricing (9407-) for i5/OS, IBM released two new hardware models which support this new licensing scheme - those are the 515 for up to 40 users with limited extension capability, and the 525 for bigger deployments.

The 515 is mostly the same hardware as the 520+ (1.9 Ghz Power5+). So there's not that much to tell about the new hardware - the problems the 520 platform has are still the same.

The internal case design is a reminder of the years before 2000 - installing additional memory is about as complicated as it can get, as it requires removing the power supplies, service processor, tape/cd tray and fan modules. This isn't what you would expect from an expensive IBM server - because their System x division sure knows how to design the internals of a server (see comparison pictures to the right).

A few changes have been introduced, like the addition of a new 4mm low end tape drive. One of the systems we have received has one of these. The 4mm tapes are really small, and they look like they are going to break just by holding them in your fingers. With 36/72 GB capacity, they are just a bit better than the SLR60 drives that were standard in the 520 Express configs before. Some 515 Express configs still feature SLR60 drives, probably to aid migration from older systems.

One thing changed though - the 515 tower model lacks a front door. I'm still not quite sure if I like this change - while many customers broke the front door in it's first year of operation, it provided good isolation against drive seek noises, which is now missing. You can still use the machine in an office without causing too much disturbance, but it is now definitively louder than a 520.

On the other hand, IBM seems to have finally gotten around to pre-load the console configuration correctly, so you don't have to reconfigure the system console using the control panel when you're using a Thin Console.

On the disk side, IBM seems to be stuck with U320 - I don't really understand why, because with 2.5" SAS disks they would be able to fit 16 drives into the base unit. The good thing is that the 36GB disks are now gone, and the minimal size is 72GB (this also applies to 520 Express configurations). While this won't matter for most small business customers, it now allows you to store Image Catalogs of the OS and cumulative PTFs on the system without worrying about the disk running full.

IBM touted the now available 3800 CPW would offer much more bang for the back than the previous 600 CPW 520s. This hasn't worked out that great, because i5/OS is much more constrained with Disk IO than CPU - the administrative HTTP server is still crawling on these systems if you have only 1 GB of RAM and a single pair of disks. IBM should either offer more disk arms in their base systems (for the same price, of course), or fix the IO dependency of i5/OS.

In the end, the 515 isn't really a new machine, just a new licensing model which lowers the price for the System i a little bit for smaller businesses. While this might entice small businesses already running a System i to upgrade their hardware, I do not believe that IBM will be able to acquire many new customers without improving performance, lowering prices and improving remote maintenance access.

[tags]ibm, system i, 515, hardware, power5[/tags]