Advertisment

The Scaffolding Methodq

author-image
PCQ Bureau
New Update

The frantic pace of the dotcom days might be over but most companies are working hard at improving their IT infrastructure.

Advertisment

There is a strong realization that solid core systems are the bedrock on which future growth depends. Much of this effort involves replacing legacy systems with newer systems based on modern-day RDBMS backends and Web technologies. 

One problem that arises routinely is how to test and implement systems in the middle of a financial year. Imagine a mid-sized

company running an integrated business software suite that consists of an invoicing and finished goods inventory module, a purchasing and raw material inventory module, a payroll module and a financial accounting module. The sales, purchase and payroll modules automatically transfer data into the financial accounting module by directly creating vouchers based on the underlying transaction.

The company now desires to replace this suite with another suite of similar architecture but with improved features. It has two options–either replace the entire software suite at one go or do the replacement module by module. Let us examine the implications of both options.

Advertisment

If the entire software suite is replaced then the company can either do it in the middle of a financial year or wait till the next financial year starts. If it replaces the entire suite in the middle of the financial year then it will have to import all data pertaining to the current financial year into the new software. Failure to do so will result in a situation where every report generated by the new system is incomplete- reports pertaining to period before the switch over will have to be generated from the old software. Even supposing the import process goes smoothly the organization will still face a huge amount of disruption as employees struggle to come to terms with the new system. No matter how much training is imparted to users before switchover the real issues only emerge when the new system goes live.

The other way is to wait till the new financial year starts and then do a complete switchover. In this case no transaction data has to be imported, only the master files are required in the new system. There are two disadvantages to this method. First is the loss of time–you have to wait till next April to switch to the new system. Second is the fact that April and May are extremely busy months for people in accounting departments.

Now let us turn to the other option–switching over one module at a time. The problem here is the dependencies between modules. For instance if the sales module is replaced then the sales to financial accounting link gets broken. You can’t solve the problem by switching the financial accounting module before the sales system because that way the links to payroll and purchase get broken. The only way out is to construct some scaffolding–put in place routines that can export data from the new system to the old one. You can then proceed to do the switchover one module at a time.

Advertisment

Modern RDBMS-based systems usually contain the tools to do this. Legacy systems based on dBase/ Clipper/ FoxPro are also easy to deal with provided you have detailed information about database structures. Real problems arise when the legacy system uses a proprietary or non-standard database. A different set of problems arises when the new system consists of modules from multiple vendors. Making software from different vendors talk to each other requires work in the best of circumstances, another layer of complexity gets added when interfacing with a legacy system is required. 

The Bottom Line: Your problems don’t vanish when you decide to switch to newer generation software. They probably multiply.

Gautama Ahuja, runs a turnkey software copany, AHC Infotek

Advertisment