Program Conversion - Mainframes - Business RulesThe system has been in 'production' for, say, 18 months, although only by managers running ad-hoc queries. This has created an experienced user community that are now 'bought in' to the new system. A new set of 'read only' users are getting accustomed to the web interface, the menu navigation, and the search screens, although they still apply updates through the old system. Given that the newer system has improved search functionality, it is often convenient to 'find' records using the web based forms, then pull the found records up on the mainframe for editing. While still not a complete system, it has already impacted productivity. It is unlikely that automated conversion tools are going to be of much help in this phase. First, certain design conventions will have emerged that are kind of 'obvious': things that work a particular way, a way which bears no resemblance to the prototype. Second, security will have been split off into to the menu functionality and 'search' functionality will have been placed in a separate container, so to speak, so the code that is left is primarily for CRUD (CReate, Update, and Delete). Third, it will be obvious that the original forms were so small that what existed in separate screens will now be consolidated, perhaps at two levels. At one level, fewer forms will have more fields each. At another, 'separate' screens in the prototype program will now exist as divider tabs in a controlling form. The user will no longer be forced to page from screen to screen to update one field in a large table. They will be able to select the relevant tab, make their edit, and commit their change more or less directly. At this point in the migration neither the schedule and budget bear a resemblance to the original plan. More than likely, a project manager or two has moved on. Despite what appear to be missed objectives, something of substantial value is in place and operating. Had the plan for hiring programmers and technical writers at day one been followed, it is likely that a lot more money would have been spent, and none of the resulting work would have been usable. Since the original budget plans are pretty much shot, the people authorizing spending may want to reduce the scope of the project until certain elements are in full production. Since the database is usable and the query tools are usable, there are a couple of pathways to follow: one is the 'core' pathway, the other the 'peripheral'. In the 'core' scenario, the complex application with the most transactional activity is converted. Master tables that can still be updated using mainframe screens are updated through that path and synchronized overnight. The transactional tables in the host system are no longer imported, and the order entry or billing or accounts receivable system runs on the web host. Master table maintenance programming is taken care of later. In the 'periphery' scenario the master table maintenance forms are converted from the tables with fewest dependencies onwards. In short, a table of zip codes has no dependencies so it's maintenance is completed first, followed by the city table that has to validate against the zip code table. The customer table program is converted next. The system does not go into production at this point, since these tables don't 'flow in reverse' to the mainframe. However, many of these are sufficiently trivial that they are moved out of the way fairly quickly. The hard, complex (and expensive) work is deferred to later budget cycles. This approach creates some flexibility in the timelines, management can 'dial in' as much talent as they can afford, and is available. While the person authorizing funding would be horrified at schedule slippages, the point of this pathway is to limit the downside risk. Work that gets done 'stays done', and a rush to put bodies in cubicles before work is ready for them is avoided. Users aren't led down the garden path; they are as aware as anyone else as to development progress, because they're involved. Effort is made from the beginning to make an incomplete system as usable as possible, reaping some benefits for investments as they are made. For those that feel like their system is way overdue for an upgrade, please call 210-734-5575 for free initial consultation. Or, eMail us at Info@ResourceLogic.net |