You have to admit it: I've been a pretty good boy lately, haven't I? I don't think I've really said anything to make anyone angry. Well, maybe the fine folks who want to start charging System i developers extra for the tools they need to do their jobs, but I'm not sorry about that; they ought to be ashamed of themselves. However, besides them, I can't think of anyone I've aggravated in quite some time. Well, let's see if I can change that in this article!

This article is about a subject that goes to the very core of programming and one that you don't learn from a visual IDE or by reading a book on Extreme Programming. Speaking of Extreme Programming, how about that for a fad that burned out fast? Of course, what did you expect from a technique that was borne out of one of the more spectacular programming failures of the last millennium? It would be sort of like insisting that your company use the San Francisco project to build your software. Of course, that's the idea behind shrink-wrapped business software, which is actually being pushed by some people (notably the Microsoft crowd). But I'm already digressing....

Shrink-Wrapped vs. Custom Software

Or maybe I'm not digressing. There are so many places where I can start, but this might be the most important since it addresses the very nature of business software.

Since Og and Grunt, my favorite cave programmers, developed the first pterodactyl tracking system, there have been those in the business community who have been trying to get rid of them. Even though it's clearly demonstrable that computer technology aids every business venture, the IT department is still viewed by many as a cost center. Because IT can't point to a specific tangible revenue stream in this age of maximizing short-term profits at the expense of strategic growth, the IT department continues to be a target of the indiscriminate cost-cutting sword. (IT managers really need to show management exactly how much they are saving the company by comparing costs to non-computer methods.)

In that mindless pursuit of reduced expenses, the idea of shrink-wrapped software always rears its ugly head. It's not surprising; the only software ever seen by some of those in charge is often desktop automation software like Office or Outlook. Given that universe of experience, it's not unreasonable to assume that software in general is a one-size-fits-all proposition. However, as was clearly demonstrated in the San Francisco project that I alluded to earlier, finding a piece of shrink-wrapped software that fits your business exactly is nearly impossible. No two companies agree on what a calendar is, much less a customer.

There is another, more insidious problem: If you run your business on software that everyone else is using, you get no unique benefit from that software. You lose the benefit of custom code that can encapsulate and even reinforce those things that make your business special. If you have unique pricing, your business software should be written to take advantage of that fact. And I think it's clear that if you have a unique business practice, it's unlikely that a generic software package is going to support it. The inevitable consequence of plug-and-play software is that eventually everyone will be using a combination of components written by the same developers, developers who have no knowledge of the special characteristics of your business. In effect, you commoditize yourself, and the global economy makes it impossible for industrialized nations to compete in the commodity end of any business. The only way to be competitive is to provide a unique advantage, and packaged software isn't going to do that.

This isn't to say that you need to write everything from scratch. Especially in this day of complicated user interfaces and super-powerful programming, I think it's safe to say that the era of completely in-house developed software is waning. Except for completely unique requirements (Google, for example), it's unlikely that you won't be able to find packaged software that can adequately address part of your business flow. I'm sure I've already alienated some folks, so let me continue down that path by suggesting that there aren't a lot of ways to customize an accounting system. In fact, given the strict legal rules that accounting must play by, creative accounting could be considered a real liability. For many companies, payroll is an even more stringent area, although I have found that some companies actually rely on their own particular compensation practices to help incent their employees.

Neither extreme is the answer. Instead, the best solution is an amalgam of custom and packaged software, a mix I call semi-custom (not particularly original, but it gets the point across). You can do this in a number of ways. You can, for example, purchase shrink-wrap solutions and write your own custom extensions. This presupposes that the software you buy can be modified or extended, but except for utility software such as word processing, I think you should always try to find software that has some way of being extended. Heck, even game developers are smart enough to allow user customizations ("mods"). If you purchase a package that can't be extended, you're taking quite a gamble. Another option is to buy a solution that the vendor will customize for you, but it's becoming very rare to find a vendor willing to support custom modifications in the field.

This second alternative becomes even more attractive when combined with an interesting development that I spoke about in a recent article: Software as a Service (SaaS). SaaS is making the rounds again as a viable IT strategy. And while it's not often addressed, there are really two kinds of SaaS: shrink wrap and semi-custom. Some SaaS offerings (probably most of them today) basically allow you to run whatever software a company is willing to make available online. You may be able to set some runtime preferences, but in general you will run the exact same software every other user runs. This ranges from the various Google offerings to Microsoft's online Office offerings to business applications such as Smart Online. This is definitely the playground of the Windows or Linux server farm, with lots and lots of servers shipping out the same stuff to jillions of users.

This model will definitely be an ongoing component of businesses; it fits the same need that TurboTax fits for consumers. But it's the other side of the coin, the semi-custom SaaS offering, that really piques my interest. If you look at it carefully, you'll realize that this is really a rebirth of the old Service Bureau concept of the '70s and '80s except with the browser as the delivery mechanism. This model is eminently well-suited for the System i, requiring as it does both reliable and scalable delivery as well as highly productive business rules development. The ability to easily create and deploy specific modifications for individual clients is going to make the System i a particularly attractive platform for application service providers, as long as IBM is willing to make the appropriate tools available for developers (which of course is yet another, different topic, which I recently wrote about). Since custom business rules will always provide a competitive advantage; custom software of some form is going to be necessary.

Platform Independence vs. Platform Optimization

It was probably the coming of age of Java that spurred the idea that all software should be platform-independent. There is a certain appeal to the idea that your software will run on anything, especially for those using a platform that is seen as somewhat of a niche player. And while the IBM midrange has a solid reputation among those who understand the strategic requirements of business computing (reliability, scalability, simplicity, total cost of ownership), that message isn't widespread outside of the business-programming community.

Instead, we have the new crowd of nontechnical C-level executives who didn't come up through the ranks and who are getting advice from college-trained technicians who never saw a midrange. Since this new generation has never seen anything besides Windows and/or Linux, it's nearly a foregone conclusion that they'll be pushing platform-independence. The argument is that by writing code that will run on any platform, you'll be insulating the company from the chance that the IBM midrange platform will disappear and that this is a benefit for the company.

Nothing could be further from the truth. The only people who really benefit from platform-independence are consultants and software vendors, because they can sell their product to a wider audience. The truth is that, as with any business, a product that is optimized for its environment will outperform one that is not. This isn't some sort of magic; it's pure common sense. That's why native Windows applications outperform Java and why even within Java applications Eclipse's Standard Widget Toolkit (SWT), which uses platform-dependent code, outperforms the corresponding functions of the completely platform-independent Swing.

Not only that, but it's almost impossible to write a platform-independent application anyway. The only language you can really use is Java, and then you're stuck with using the Java Database Connectivity (JDBC) interface for your database I/O. This in turn ties you to SQL, which is anything but platform-independent. One of the topics I discuss when I'm on the road is SQL Hits and Myths, in which I talk about both the benefits and the downsides of SQL. One point I make is that SQL is anything but a platform-independent language. In fact, some of the basic features we require in a business environment (such as getting the first 10 records of a list) require a completely different syntax for every major SQL vendor.

This isn't to say that platform independence is a bad thing! There are certainly applications that would benefit from a completely platform-independent approach. But remember, that includes even the database, such as I show in Figure 1.


Figure 1: This is a true platform-independent approach. (Click images to enlarge.)

In the figure, UI is user interface, AC is application controller, BL is business logic, and DB is database. The truth is that most people talking about platform-independence mean what I show in Figure 2.


Figure 2: Here, everything is platform-independent, but the database is on an SQL server.

The problem with Figure 2 is that you've traded platform vendor dependence for database vendor dependence. I'm not sure that's a great trade, especially if you consider the loss of performance involved.


Figure 3: Give me platform-independence at the UI level, but let me write my business logic on the System i.

I much prefer the architecture I've shown in Figure 3. I use the platform-independence of Java to allow me to move my user interface wherever I need to. It could be on the System i, or it could be on another box in the DMZ, or it could conceivably be in some other location entirely, such as a handheld device. At the same time, my business logic is written in RPG and maintained by RPG developers who can quickly react to changing business requirements.

(I get a kick out of the whole notion of "agile development" and its implication that somehow previous generations of programmers can't keep up with business. Try dropping a new pricing scheme on a bunch of OO programmers and see what happens. My guess is that by the time they redesign their class hierarchy, the RPG programmers will have already put their new version into production. But, hey, that's a personal bias.)

Stateless Transactions

This is one of the perfect examples of how over-application of even the best idea can be a bad thing. A stateless architecture can certainly make sense when you're talking about thousands of users accessing one application at the same time. It makes even more sense in an anonymous browser environment when little session-specific data needs to be passed from one page to another and the overall state of the application is really quite small.

Notice, though, that for all but the most trivial of business applications, there really is a state. The term "stateless" is actually a bit of a misnomer; business applications are almost always stateful in that they do indeed keep track of state information; it's just not kept in memory. Instead, the state information is stored on disk and is retrieved and/or updated when necessary. For example, even an anonymous a shopping cart application will probably keep your order in a database file somewhere. Note that this doesn't have to be the case, but if it didn't and you were to accidentally lose your connection, your order would be lost as well. The state could be stored in a simple comma-delimited cookie on your desktop, or it could be in a keyed file on the server (with the key being stored in the cookie on your desktop). In either case, it's important to note that state is stored; it's just not kept in memory.

No, what the stateless advocates are really talking about is not statefulness per se but instead persistent connections, in which each user session has a unique job on the server. This session job holds data not only on disk but more importantly in memory for its associated user session. The in-memory information gives persistent applications their great response time, information that would otherwise have to be read in from disk every time. It is the difference between modern interactive applications and the old multiple requesting terminal (MRT) jobs of the '70s. The problem is once again the "one size fits all" mentality. In this case, the one size is the persistence model, and the fact is that causal browsers are a completely different fit than online business users.

The issue that's raised immediately is that persistent connections don't scale to millions of users, but the counterpoint is that most internal business applications or even business-to-business (B2B) applications have millions of users. Any IP address can support tens of thousands of persistent browser connections, and only the largest business-to-consumer (B2C) sites such as Google will ever run into any sort of limitations. I might be wrong, but it seems to me that if you have more than 10,000 users on your machine at any one time, chances are you can probably afford a second IP address.

To Summarize

Have I left any of the major new programming techniques off my list today? I've hit extreme programming, component-based software, platform-independence, and stateless architectures. And while I've been honest enough to admit that each of these has its place in certain situations (with the possible exception of extreme programming), I think it's clear that, in my opinion, in the domain of business applications for which the IBM midrange has historically served, these newer techniques really don't apply.

Of course, you may not agree with me....

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. and has been extending the IBM midrange since the days of the IBM System/3. Joe uses WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. He has written several books, including E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. Joe performs onsite mentoring and speaks at user groups around the country. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been extending the IBM midrange since the days of the IBM System/3. Joe uses WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. He has written several books, including Developing Web 2.0 Applications with EGL for IBM i, E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. Joe performs onsite mentoring and speaks at user groups around the country. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..

---

MC Press books written by Joe Pluta available now on the MC Press Bookstore.

		Developing Web 2.0 Applications with EGL for IBM i Joe Pluta introduces you to EGL Rich UI and IBM’s Rational Developer for the IBM i platform. List Price $39.95 Now On Sale
		WDSC: Step by Step Discover incredibly powerful WDSC with this easy-to-understand yet thorough introduction. List Price $74.95 Now On Sale
		Eclipse: Step by Step Quickly get up to speed and productivity using Eclipse. List Price $59.00 Now On Sale

Also Read

The Power of Writing Code in a Low-Code Solution

TechTip: Let’s Have a Date, Part 2

Going off the Rails