OmniSolutions Sponsor Message

January 2002

Buy or Build?

By Scott Hirsh

Lately I’ve been having thoughts of renovating my house. As anyone living in the San Francisco Bay Area knows, you don’t get a lot of house for your money. And unless you’re lucky enough to afford a monster house (aka “McMansion”), as soon as you’ve purchased your $500,000 “bungalow” you start plotting its expansion. But the choices are not necessarily that simple. Does it make more financial sense to plow another $100-200,000 into your existing place or should you use that money as part of a down payment on yet another overpriced house. What about the property tax issue? And what if you like the location, the neighbors, the schools? Is now the time to take action, or should you wait until contractors are more willing to negotiate?

This kind of decision-making is not unlike the situation we now face in the e3000 neighborhood. We have been told that HP will support us for five more years, and then… what? Just as our house does not stop providing shelter if the architect and builder retire or relocate, so it goes with the e3000. (Can we now start calling it the HP 3000 again? This “e” thing never felt right, did it?)

The immediate danger of the Year 2000 was rectified, so there is no reason to panic. In fact, unless you’re at the upper bound of the HP 3000’s performance capabilities, or you have your heart set on a SAN, you can take your time planning your next move. And that next move, like “buy or build” in the home space, is not as obvious as it seems.

I have had some experience lately with Compaq’s Tru64, which was also end-of-lifed recently. In the case I know first hand, the customer is on a fairly old version of Tru64 and has some SCSI limits adding new storage. Their upgrade decision involves a complex combination of operating system, driver and DBMS changes, which will all need to be done simultaneously. There will be downtime. And alternative Unix hardware is both inexpensive, higher performing and easily migrated to. Obviously, this decision is a no-brainer.

But what we’re faced with is not a migration from one Unix flavor to another. Our decision is more analogous to a change from an AS/400 to an RS/6000: totally different operating systems, different cultures, different strengths and weaknesses.

After we have finished our emotional venting (I’m still working on it), we are back to a business decision. Which way forward makes the most business sense? What alternative, if any, promises the lowest total cost of ownership? Here are a few of my thoughts.

No Rush

Your HP 3000 environment is blissfully unaware of its fate. True, there is a lot to be said for continued support by HP for your environment. But there are plenty of users these days using Beechglen for response center support and third-party consultants for system management. Likewise, your application and utility vendors are unlikely to abandon a reliable revenue stream, so you’re safe there as well. It seems to me that those who felt limited by the HP 3000’s choice of applications have already made, or are in the process of making, their move. And those who are enjoying the reliability of the HP 3000 platform remain confident operating with the most reliable computing platform available.

Application Alternatives

You have an investment in homegrown applications or some major third-parties that aren’t easily replaced. Presumably, you have periodically checked alternative applications and platforms to ensure that you’re current environment makes the most business sense. So you’re using HP 3000 applications for a reason, and that reason does not change with HP’s end-of-life announcement. In fact, with the same people who have always come through for us announcing support for MPE after we’re abandoned by HP, it’s quite likely that we’ll be even better off. If the Linux community, with endless options of the Intel-based hardware platform, can justify their existence, we have an even stronger case.

And rewriting your own applications for, say, Unix, is not trivial. Heck, I don’t see all that many applications that have a Web front-end yet. Even moving from one version of a third-party application to another platform’s version of the same application is difficult. And, as we know, some of our third-parties were never able to rewrite their applications at all.

What I saw at one small HMO that was swallowed by a bigger HMO was a cut-off. All transactions after a certain date would be added to the parent HMO’s homegrown mainframe application (there’s progress), while the HP 3000 application was retained for historical reporting only. No port, and minimal life support for the HP 3000. I expect this to be a likely scenario in many shops.

Alternative Platforms

It’s almost inevitable that senior IT management will see the HP announcement as motivation to “do something.” You may already be exploring alternatives. As HP 3000 system managers, we’re in for some real disappointment. While Unix has been described as “the IT Full Employment Act,” any of the so-called Open Systems are either more of a pain to manage, less stable, or both. Just in terms of hardware quality, the “dot in the dot com” can’t hold a candle to our own HP 3000. Keeping up with Unix patches seems to be a full time job. And despite what Bill Gates says, Windows is still reboot central. I know there is someone out there who has an HP 9000 that has been up forever. In fact, I support a few myself that are relatively uneventful. But they’re not very dynamic, and their third-party backup and job scheduling are a pain. Of course, as system managers (excuse me, administrators) it’s job security.

New Tools

We’ve covered this ground before. The other platforms either don’t include the same operations facility as MPE, or it costs extra – and from a third-party, to boot. So you’re probably looking at a backup package, a job scheduler, performance tools, etc. To be fair, there are also a lot of very decent public domain utilities. But you’ll need to know your stuff, which may take some time.

And speaking of backup, what will you do if, like many businesses, you need to retain backup history for something like seven years? You may need to keep your HP 3000 around just in case you need to recreate a report.

More Complexity

One big cultural difference between the HP 3000 world and open systems is the tendency to go distributed. That takes me back to when HP maxed out the Classic line, and hadn’t yet introduced PA-RISC. Our only alternative was to implement multiple HP 3000s, then network them. In a Unix/NT environment, expect more systems, more networking, more security issues (HP 3000s are almost never hacked), more complexity, more difficult disaster recovery.

Training Costs

Chances are, you already have other platforms in your shop. And with the economy being what it is, you are probably responsible for multiple platforms. Regardless, you should expect to require training for the new application, if nothing else. But if you’re strictly HP 3000, you’ll require Unix, Linux or Windows training. Typically, you will require a little handholding during the transition, so consultants will need to be engaged. And, of course, this is assuming the migration goes smoothly. Not all of them do. And that’s when things get really expensive.

Disaster Recovery

I’m working on a project at my old shop to implement true, no kidding, disaster recovery (I wonder why?). Since I left, the shop has migrated primarily to Unix (Sun and HP) and some Windows. Once upon a time, the entire application suite resided on an HP 3000. But that was too easy! So now the shop requires a patchwork quilt of applications running on over a dozen different Unix and NT hosts, plus other third-party feeds, with a combination of SAN and NAS storage. Recovering this environment is a major challenge, to say the least. It can (and will) be done, but the cost has skyrocketed from the good old HP 3000-only days. Don’t forget to factor in the costs of disaster recovery when you make your move!

Add It Up

Your CIO can’t stand the thought of running this “proprietary” platform that’s now end-of-lifed to boot. So your marching orders are to prepare for a migration. Here’s a recap of some of the costs you should expect to incur:

New hardware. Servers, storage, other peripherals.

New applications. Conversion. RDBMS. Consulting. If the conversion stalls, the meter keeps running.

Operations utilities. Backup, job scheduling, performance. Consulting to integrate and duplicate functionality of existing environment. If you go shareware/freeware, factor in your cost to customize for your environment.

Training: new platforms, new applications.

Downtime. A soft cost, but a cost nevertheless. And there will be some.

Disaster Recovery. It will get more complex, it will cost more.

If all this makes business sense – that is, you’re getting a better return on your new investment than you would with the existing HP 3000 – then by all means do it. But if you’re reacting to the emotion of having HP abandon the HP 3000, you may want to reconsider. The HP 3000 will continue to perform just as reliably after HP is reduced to a printer company. And the way it’s looking right now, the HP 3000 will be an even better platform when it’s supported by those who truly want to invest in its future.

Scott Hirsh (scott@acellc.com) former chairman of the SYSMAN Special Interest Group, is an HP Certified HP 3000 System Manager and founder of Automated Computing Environments (925.962.0346), HP-certified OpenView Consultants who consult on OpenView, Maestro, Sys*Admiral and other general HP e3000 and HP 9000 automation and administration practices.