September 2004

"Sorry, We Don't Support That."

A system's implementation quirks might prompt verse of migration blues

Roy Brown

When migrating to a different system or platform, there’s usually something the vendor needs you to lose. But is it essential business functionality, or just an implementation quirk of your old system?

So now you are going to migrate. But which is it going to be? The luxury option of a bespoke (custom) replacement of your old system? To a package on a new platform, maybe a version of a package you had before, or one new to you? Perhaps the rewrite option, where a team of programmers, possibly offshore, re-implement your system in a whole new environment, but keeping the existing functionality? Or will it be a conversion, where your existing system is transferred to a new platform using automated tools?

Each has its advocates, and each has its pros and cons. Chances are, your constraints are going to be cost, time, and risk. Probably in that order. I can’t say much about the first two; that depends on your circumstances.

Code Conversion

But risk comes in two timescales; immediate risk – “Can we do this? Can we get onto the new platform?” – and the longer-term risk that you are maybe painting your company into a corner by accepting some compromises now that later will turn into shackles.

Those with long memories may recall some of the early packages being offered for the HP 3000, with KSAM file structures, not IMAGE ones. You just knew they had been ported from elsewhere, not written native on the HP 3000. And if you could find what you wanted, on IMAGE, you were surely glad.

That’s the longer-term risk, then, for some conversions with low short-term risk; you’ll be on the new platform, certainly. But you’ll have something that plays like the modern-day equivalent of having KSAM, when the smart money is on IMAGE.

However, if the cost and time objectives point this way, how bad can it be? Anything short of a full ground-up rejig of your application is going to be a compromise of some sort.

But look hard at where you are going to be after a tools-based conversion; will you be fully on the new platform with all-independent code, or will you be running in an environment provided by your conversion specialists? If the latter – and these can indeed lead to faster, cheaper, lower-risk conversions – treat your supplier as a package implementer that you are in with for the long haul, and judge them accordingly.

Likewise, what about ongoing, internal support? One of the reasons to move to new platforms and new paradigms, perhaps, is to tap in to the upcoming generation of people who know their way around them. But if it’s hard to see how you are going to get ongoing support for your HP 3000 apps, how much harder will it be to find people who can support the hybrid old/new system you are going to wind up with?

Finally, and on the same note, how maintainable is the migrated system going to be? You need to ensure that the generated code is going to be something that a human can easily work with – and likewise the environment the code runs in – or you are going to be effectively frozen in the converted state. Fine if it’s a subsidiary app, perhaps, and this is a stopgap until it dies or you replace it more fundamentally. But not if it’s a key business app that needs to grow with your business going forward.

All this is assuming the conversion is feasible. Hopefully, in the average application suite, you are not going to have done too many unusual things that the automated conversion can’t cope with; maybe some system-y job and user status calls that are done differently on the new platform, and other corner cases, but nothing fundamental.

But sometimes the gotchas can be quite widespread. Inadvertently exploiting the specific way VPlus works, we had an application that let you put a partial key and a question mark, hit f2, and go to a lookup screen where you could review matching keys, and select the exact one you wanted.

This was used across quite a range of screens, and relies on VPlus not trying to validate the partial key when you went that route. But move to a screen handler that works rather differently, and you may lose that option. Nothing insurmountable; we just needed to change things so the partial key was entered in the lookup itself, with a code to say what sort of key it was. But this small inconvenience for the user was surely also a bypass of nicer techniques we could have used if we’d had the new handler from scratch.

Rewrites

If a conversion isn’t the way you want to go, then likely you’ll be offered a rewrite. This can be more flexible than a code conversion (though you can bet the conversion team will be using some internal tools for the straightforward bits). And you should wind up with an app that is fully and independently implemented on the new platform, dispensing with any helper environments. Likely, though, it will not quite be what you’d have got starting from a zero base on the new platform – it will retain a few traces of its HP 3000 origins. But hey, is that such a bad thing?

Here again, you need to make sure that you can work with the resulting code going forward, to keep on track with your business needs. But the main issue is what shape is the application you are migrating.

One way of looking at a rewrite is that it’s a full custom conversion, but the results of the business analysis, instead of being expressed as use cases in UML, or whatever, are being presented in “HP 3000 Modeling Language.”

So if you are really happy with how your HP 3000 app fits the business – and if your users are — this can be a better way to go than embarking on a needless rediscovery process. If it ain’t broke – at the business level – then fix it only at the code level.

Not to say you can’t save some money by looking hard at the app, and maybe trimming out some dead wood – old functionality that is no longer used, and that thus does not need conversion. But do try – at least in the first go-round – not to request new features. Else your rewrite starts creeping towards being a new custom implementation, thus losing you the best of both approaches.

But even with a rewrite, perhaps there will be a few things the rewrite team will balk at, or instances where you will find that the cost of keeping them in is likely to be disproportionately high. Maybe they will come up with an alternative approach, or maybe you will.

But if not, consider what you are losing. A nice-to-have, but which you use once in a blue moon? Or something integral to your business? On a rewrite, it’s less likely to be the latter that when considering packages, which I’ll come to later. And it’s likely to be something system-y again, albeit at the user level, where they interact with job streams, or print queues, or whatever.

Maybe something in the user interface? Though I’m always pleased to see how closely forms on the web follow the VPlus paradigm of fill in all the data, press Enter, get it validated, go forward if okay.

But you do need to be as flexible as possible about doing things a new way on a new platform. On Usenet newsgroups, people often ask “How do I do x?” where x is an attempted solution they can’t get working. Invariably, the response is “Yes, but what’s the actual problem you are trying to solve?” And the answer turns out to be quite different from x.

Adopt that precept here; go right back to the problem you are trying to solve, and not how to get an envisaged solution working. You’ll get a much better answer.

Packages

If you have a package running on your HP 3000 which you are happy with, and the vendor provides that same package, or something very similar, on other platforms, then it’s likely just a case of choosing which platform to go with.

Your vendor-supported migration path should be pretty straightforward, and your hardest problem is going to be to decide what to do with the crust of subsystems and reporting programs that have built up, and which surround the package proper. If there are some you can’t do without, and the features aren’t provided by the package anyway, on the new platform, this may be a good chance to get to grips with the tools and utilities on the new platform, and how things are done there.

But maybe you had a bespoke or home-grown application on the HP 3000, in an area now covered by one or more packages on other platforms, and it makes more sense to move onto a package now than to go bespoke again?

In that case, you have a three-way analysis to do; what does your existing system provide, what does the new package provide, and what are your users looking for?

I’m hearing the advice “don’t go for customization, go for plain vanilla” a lot these days. It certainly gives cost and risk reduction, though perhaps at the expense of business fit. I reckon that a shame; every company has something that is its USP – unique systems proposition – something in its IT that gives it its edge in its chosen business.

On the other hand, sometimes a company does things differently because it was easier, or “it was always done that way.” Those are things you shouldn’t lose sleep over giving up.

A couple of concrete examples; firstly, meaningful SKU numbers. Chances are your SKU numbers, or product codes, have a structure you understand. If so your homegrown systems will likely have dozens of places where a program takes a different path based on what that SKU number is. A package is unlikely to support that; each property needs an explicit flag on the Part Master, and the package has to work off those.

This doesn’t mean that you can’t keep your meaningful SKUs, where everyone in the business knows what they mean. Just that the package won’t know from the SKU, and so you will need to set those flags for each one. And carefully too, or there will be some real confusion.

That’s a case where you go with what the package does. But in the system I’ve just migrated, we had a critical financial value, set against every order, in a complex and special way that was important to the business. The old system calculated it. The new system would accept a pre-calculated value as input, sure, but it wouldn’t do the calculation.

We could, I guess, have asked for it to be customized in. In practice, we built an Excel spreadsheet as a preprocessor to the package proper, and did the calculations there.

There’s still a little bit of me that says moving stuff off the HP 3000 onto a spreadsheet is going backwards. But then there’s a bit of me that says that of moving anything off the HP 3000.

Custom replacement

This is the Rolls-Royce (or should I say Cadillac?) option. But if your application is unique, so there’s no chance of a package solution, and if rewrite/code conversion doesn’t suit, possibly because of a pent-up backlog of business change requests, or the knowledge that your business area is changing radically, it can be the only sensible way to go.

And if so, you don’t need a few thoughts and observations about compromise; you need to know how to choose from the myriad of possibilities out there. I only wish I knew myself…

In your next NewsWire, back to hard information, with Verse Three: “Hey, look at this great stuff I can do with MS Office!,” or, data manipulation off of the HP 3000.

Roy Brown is CEO at Kelmscott Ltd., a developer and consultant with more than 25 years’ experience on MPE and the HP 3000.