Control Your Code, Control Your Costs And Destiny

January 16, 2012 Timothy Prickett Morgan

After decades of reading this newsletter, you know a thing or two about me. One of them, which may not be immediately obvious, is that I can be something of a control freak. (Just saying that in a sentence is difficult, and I want to deny it. But there it is.) And guess what? So were AS/400 shops back in the day, and a fair argument could be made that they were better off, technically and economically, when they freaked out (in a good way) and controlled their application code.

Maybe I have been around too long, but I am not as impressed with the open source revolution as a lot of people are because I know that in the heydays of the System/38, System/36, and AS/400 midrange system business back when I was still a kid and then a young man, a lot of shops coding their own applications and an equally large number licensed software from vendors, which included access to source code, and made their own modifications to that code. This was not open source code–it was not freely distributed–but if you paid the vendor, you had access to the source code for internal use. That, in fact, was why it was worth any money at all.

In many cases, companies did so many modifications to the application code that they could no longer obtain tech support from the vendors that originally created it. A lot of the time this was absolutely intentional, or at least it was not a concern. Midrange IT shops understood that they had very specific needs and they paid people a good salary to tweak existing code and create new code whole cloth to fit their very specific situations. They understood that paying for this was a true differentiation in the business and not just some sunk cost that should be grumbled about. They believed in their businesses and they invested heavily in relatively expensive systems and the people to create the complex applications that actually defined their businesses.

This approach to applications also did something else very interesting. In a lot of cases, customers might have liked a general ledger from one vendor, accounts receivable or accounts payable from another, and payroll from yet another. So they took these programs and integrated them on the System/3X or AS/400 iron themselves, or sometimes they took a hodge-podge of homegrown and heavily modified source code and ran with that. Sometimes, they didn’t have to change a module.

Then something funny happened at the end of the 1990s. The Y2K bug came along at the same time as the Enterprise Resource Planning (ERP) wave took off. The Y2K bug made CEOs and CFOs nervous about having lots of code that needed to be tweaked (it turned out to not be such a big deal) and the ERP wave made them all feel unimpressive if they didn’t have an integrated stack of apps from a dominant supplier. The recession at the end of the dot-com boom helped convince many midrange shops to ditch the AS/400 and move to another system, which has been hard on the IBM midrange business, but it also convinced others to jettison the whole idea that a group of programmer/analysts working inside of a company could keep up with all the innovations and integrations that the modern world required.

Maybe they were right. And maybe not. It depends on the time horizon you look at.

What was the number one complaint that I heard in the past two years while considering upgrading to Power7 machines and IBM i 6.1 or 7.1, or the ability to consolidate workloads onto more cloudy infrastructure? I’ll tell you: it is that even when you can justify the cost of moving to more modern Power Systems iron and systems software, the cost of upgrading third-party application software is so prohibitive that CIOs can’t get approval for the upgrades. Other related complaints I hear all the time are that vendors do not offer true utility pricing on their code, so companies can’t consolidate workloads onto a big Power Systems machine, or that they won’t offer hourly or monthly pricing on their code, which would allow for the software to be bought like cell phone service on a pay-per-use model.

I understand that the software companies have to make money, and that human beings are not subject to Moore’s Law, where things get cheaper every 18 to 24 months and capacity also rises. People costs are quite the opposite, rising with inflation every year and perhaps more in certain industries. I also understand that writing your own code is out of fashion, almost too retro.

Well, unless you happen to be Google, Amazon, Yahoo, eBay, Facebook, and Twitter. Not only do these hyperscale Web application properties write their own code, but they create their own standards and tools a lot of the time (often tweaking existing tools and standards) and in the case of Google, Facebook, and Amazon, they actually go so far as to design and build their own servers and data centers for maximum efficiency.

They believe in engineering and in the concept that by doing things differently from everyone else, you get an edge. Imagine that.

The whole point of the Application System/400 was simple, and it is a proposition that is as valuable today as it was 24 years ago. It was to mask the complexity of a relational database management system and the underlying hardware to make it run well on a borg collective of relatively cheap iron and sophisticated microcode to make it run as reliably as a mainframe. The idea was to insulate programmers from all the underpinnings in the system and to automate this so they could concentrate on creating business logic that differentiated their business from the pack. The insulation is exactly what modern cloud and application frameworks do on distributed networks, although I would argue they don’t do it as elegantly. You still need to know too much to use Microsoft Azure or VMware Cloud Foundry. But even after you do that, you need to pay some smart programmers a lot of money to create innovative applications. To encode your business and then recode it.

What we have been doing since the late 1990s is to let industry experts tell us how to run our businesses instead of figuring it out for ourselves. There has been so much talk (and then action) about ditching everything but core competencies that maybe we have lost a lot of core competencies. The upshot is that we don’t understand how our systems work at all, but we just pray they keep working.

I am not silly enough to suggest that you can throw out your third party ERP apps and hire a lot of programmers and start from scratch in RPG, Java, or PHP. What I am suggesting is that the competition that you can’t see coming can, in fact, do this. Or something like it.

This competitor might be using a mix of SaaS-style apps residing on clouds mixed with internal apps, which could be closed sourced apps like you are probably using as well as open source applications that are maintained by people as much for love as for money. Maybe they will create something that is better than what you have, and maybe not.

WyattERP was an early open source ERP player that I got excited about when it came out in 1999, but it hasn’t gone very far. Compiere, OpenBravo , OpenERP, and Opentaps, and a dozen or so other open source ERP projects are a way to get going. Many of these suites are programmed in Java or PHP and therefore can be hacked onto an IBM i platform. In fact, you could do the work and share it with others. Or you could pull a Google and consume lots of open source, make your tweaks to get a competitive edge, and hardly give anything back.

All I know is that my best friend’s uncle, who was a very bright marine biologist with a keen interest in computers, was able to nearly single-handedly program an MRP II system on one of the first System/38s in the world. He didn’t make nearly as much money as application software vendors extract from companies today that have been trained that they really shouldn’t create their own code or heavily customize someone else’s. (In fact, I don’t know of any IBM midrange ERP software supplier that still supplies source under license to customers.)

There are also some more interesting possibilities. I hear rumors about it all the time that someone is going to take an RPG-based ERP suite open source, but somehow, this never seems to happen. Maybe it will someday. In fact, maybe it will someday when you talk your company into letting you start an open source project based on its RPG code and thereby spreading the cost of enhancing the product over a larger number of user companies while still allowing you to do the customizations that make your business unique and competitive. Maybe a big company like Infor will take some of its software open source (or at least revert to providing source code) to better compete with Oracle, SAP, and Microsoft, all of whom are absolutely allergic to open source software.

Stranger things have happened.

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search