SYSTEM MIGRATION
I know there are some of you out there who are seriously thinking of migrating from your midrange system into the world of PC's and database management systems. You're wondering how hard it will be and whether you'll be able to do the things you can now do. You're wondering if it's worth the effort given IBM's strong support and development efforts in the midrange family of computers. After all, they're bound to catch up eventually.
Having been a strong believer in AS400 technology for most of my programming career, I've come to realize it's both foolhardy and narrow minded to consider the AS400 as the end all of computing. Since I've written many applications on both platforms, I feel I am in a good position to evaluate both camps both in terms of reliability and capability.
Foremost in any kind of decision such as this is the basic needs of the organization. Moving from one platform to another at a minimum involves significant investments of both time and resources. In addition, there is the hardware/software consideration to support the move. You'll also need expertise to plan, organize, facilitate and implement the move. What about general staff education on the new hardware and software not to mention possible opposition by diehard non-change specialists. There are opposing viewpoints that can affect both decision making and purse strings. Finally, and quite possible the most serious impact of all--we have the user, notoriously resistant to any change.
Nobody likes change! It threatens jobs, security, responsibilities and most of all bottom lines. There is just no end to its repercussions. Everything points to and screams out "we are OK the way we are."
Given all of this, if you still feel the change is required your first and probably most important decision will be "who will do it?" Chances are the expertise needed is not on your staff so you'll have to go out and find it, a task that is easier said than done. The consultant/contract person should have expertise on both platforms and in both languages. They should have expertise in project management and scheduling. They need to be able to ascertain your immediate and long term needs and design a system that will accommodate both. Excellent communication and presentation skills are a must since a large part of the job is selling the migration to management and users alike. Once you hire that person, you've got to be able to get along with him.
The organization should have a presence in the development team and maintain overall control of activities and scheduling. That means your best programmer should work closely with the consultant or team of consultants. That helps to maintain outside integrity and support company standards and goals. So now you're underway. You've got someone to do the job. What's next? You now need to think about two things--database system and language. Both help to determine your hardware selection. Chances are if you're not currently on the web, you will be soon, especially if you have the capability. Web based presence should be a deciding factor in database and language selection. With Web presence Java is the only way to go. It's built for the web and it's easy to set up for web operation. In addition, all the latest technology such as Applets, Servlets, Application Servers, Java Server Pages, Enterprise Java Beans all point to Java. Choosing another language would be foolhardy.
Database selection is also relatively straightforward. With Web access, connectivity will be restricted to ODBC, JDBC or some variant. Desktop databases such as Access are simply not up to the task. Stay away from them. Depending on the size of your current database + future growth, database possibilities range from MSSQL Server on the low end and Oracle on the high end. Both are excellent databases that will serve your needs nearly indefinitely. Even at the low end, MSSQL Server can easily handle millions of records but is better suited to the hundreds of thousands of record databases that make up most organizations. Oracle is virtually limitless and can handle hundreds of millions of records efficiently. So why buy anything but Oracle? Oracle is very costly and might be overkill for a smaller organization. Maintaining an Oracle database requires specialized skills not needed for MSSQL Server. Java works great with either one of these database systems and both use SQL exclusively keeping you in the mainstream of technologic development. Don't wander from the mainstream.
Can it be done? I've personally consulted with a number of companies who have done just that and they were all successes. Is everybody happy with the results? From personal experience, as long as planning was thorough and the consultant was very experienced in the legacy language, expectations were often met. Legacy systems are a funny thing. Written in 3rd generation languages they usually consist of several versions of code such as a little early RPG II and some RPG III mixed in. Matching records and look aheads brings terror to mind. Experience is everything.
One last comment about hardware selection. Buy the biggest servers you can afford. They do 90% of the work. Users don't need big systems if the server is big enough to handle its work load. Finally, make sure you get good documentation on your new system.
|