You know, you can't open a computer magazine or trade paper these days without hearing a least one of the "Re-words". What is the difference in the terms Re-porting, Re-hosting, and Re-engineering? And how do these differences affect your data processing future?

Almost everyone in the MultiValue community (or the Oracle or UNIX community for that matter) knows basically what it means to "port" a data base system. The company moves the software, essentially intact, from one piece of hardware to another. In fact the definition normally implies they have carefully arranged to be able to move the software to another system with as small an investment in the process as possible. While I hope you haven't had to "port'" your application so often that you are actually investing programming energy to make the process easier, the concept of porting an application is quite similar to data base systems. The main goal is to move it to another platform without any change to it's functionality and with minimal effort. As a group, the Pick and Pick-like vendors have made a science out of making it easy for you to port your application from PC's to mainframes and every where in-between!

Re-hosting is a term that implies two significant differences from re-porting. It is usually used when you know you have to do a whole lot more than just recompile, load and go. Rather than the relatively simple move from say, Pick to Universe, this is a move to a system that creates much more radical problems or requires larger application changes to fit on, or to take advantage of, the new system. This is a move from Pick to Oracle or Dbase. The other difference is you expect to be forced to tolerate some changes (large or small) in user functionality because of greater differences in the underlying data base and operating system. The motivation for this kind of move could be political such as the belief the old technology is obsolete or the new technology is the wave of the future, or financial/business such as the price/performance or features of the new system are just too compelling to ignore.

Re-Engineering is a reasonably self defining term recently stolen from its historical use in the engineering fields (mechanical, electrical, etc.) and now applied to almost everything from complete business restructuring to our areas of concern in the data processing field. It means the complete rethinking of a system design. Everything is open to question, including not just the reports and data flows, but the entire justification for a system. Rather than shuffling the application around, you are going back to basics. Is it even relevant anymore (or was it ever)? Should it be done completely differently? What business function does it serve and how do I best accomplish that function today? These are some of the kinds of questions you ask during a re-engineering effort. In the end, the application may look fairly similar, may look and feel quite different, or it may not exist at all!

Let's look at the effort, risks and expected benefits of the various options. It's obvious that in a raw sense, the levels of effort and the apparent implementation risks are lowest (sometimes near zero) for re-porting an application and rise significantly in a re-hosting effort. Fearing the unknown, most people have in-correctly assumed the risk is highest with a re-engineering effort, but that depends heavily on the actual outcome. The effort is low if the system is deemed obsolete and scrapped, and modest if the new design and structure end up substantially simpler than the old application. Of course, you could also end up with a system which is much more complex than the old one, but in that case, the old system probably isn't working real well anyway, and the risk of staying with it may be even higher than the risk of change. The effort may be high, but the risk varies and as we'll see, can be controlled.

What about the expected returns? Well, the immediate return for re-porting comes from the new hardware. It is usually faster, cheaper, and perhaps more reliable. More importantly, these returns are usually quantifiable up front and everybody likes that! A re-hosting effort can benefit from the same hardware boosts as re-porting, but the outcome is less certain. There is also uncertainty in the size and impact of required application changes. You may gain functionality in some areas and lose it in others. I suspect most MIS managers undertake a re-hosting effort without a clear understanding of the various risk factors.

Re-engineering's returns are expected to be the highest in an overall sense. The application should end up better suited to the business needs and the business runs better for the effort. If you scrap the application, you save both machine resources and the development and maintenance effort. It is a clear winner in returns, but it is a little used approach because of the higher levels of initial investment and the fear factor.

All three terms are almost universally tied to a triggering change in the underlying hardware. The implied thinking is "We are spending sooo much on new hardware, we need (can't afford not to) spare some effort for the software". This is typical but fallacious thinking. First of all, re-engineering is the one approach to application and performance improvement that doesn't need to start with new hardware. You can just decide to re-examine the way an application works and how it serves the business. Usually you can get tremendous benefit from an application re-engineering effort even without changing any hardware. And while open systems (see the last column) will let you apply other techniques to parts of systems, re-engineering is the easiest one of the three approaches that can quickly be applied to one sub-system (or even part of a sub-system) at a time. In other words, you can control the risk by choosing the size of your project!

In summary, as most of us know intuitively, if you just need to improve your price/performance and you are happy with your current applications, the best choice and least risk is to port it to a similar data base on hotter hardware. If, on the other hand, you have problems with the current application, re-porting it clearly won't solve the problems. Re-hosting an application on another dissimilar data base might help improve it's functionality over time, but the risk/reward ratio makes it foolish to stop there. Put a little more effort into re-engineering how the application fits the business and you may just find you don't need new hardware. You will surely end up with a better business fit, a better service level, and lower overall risks. You will probably also find you have improved your quality in the process. Don't be afraid to start small and start from scratch!