midrange.com – In My Humble Opinion

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.

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…