One common misconception that we often encounter is that all custom software development needs to start from nothing. Not only is this untrue, but a complete, stand alone development project might actually be counter-productive. Here’s an example:
Client requires custom software to track unique, specialized product build process and desires to integrate it with their accounting system. Because the legacy accounting software provides only rudimentary software integration features, client is requesting that the software development project include the build process as well as some (or all) of the accounting features. Assuming that valid pay-back opportunities exist, one approach might be:
Review and finalize the software design and software requirements.
Create a software development plan.
Replace the accounting software with a COTS (commercial off the shelf) package that provides one of the following:
SDK (software development kit). An SDK is a set of developer tools that provide software developers a controlled environment through which they can interact directly with the parent software (in this case, the accounting system). These tools typically include accessibility objects such as APIs (Application Programming Interface), debugging tools, and other utilities designed to assist the developer in the creation on companion software products. A significant advantage of development using an SDK is that the SDK ‘protects’ the parent software from developer induced problems by only allowing non-injurious (code doesn’t produce errors or database irregularities) software development. Another advantage is that subsequent updates to the accounting software product don’t require a conformity review of the custom software.
Import / Export utilities capable of running unattended on a scheduled basis. This choice is typically inferior to the SDK environment but, if not other practical option exists, sometimes must be considered. The major drawbacks are the lack of real time interaction between the software components, the ‘snap shot’ nature of scheduled data exchange, susceptibility to development errors and software failures encountered during product updates.
Run parallel tests and convert to the new accounting software.
Create a test environment using the baseline accounting software. Do not develop against a live, operational business software system.
Develop the product build software utilizing the SDK or, if utilizing the import / export method, develop the software and necessary data exchange software objects.
Test the product build software interaction with the accounting software in the test environment.
Install finalized product build software in the production environment.