Glossary Item



Integration is not rocket science - but then again it is what we do - to the rocket scientist, I suppose rocket science "isn't rocket science!"

At one time it was almost impossible to have one application talk to another because each was in a different programming languages, used different database managers and file systems, and probably different fields sizes and naming conventions.

But today, if a software product is designed to be integrated, then doing so is much easier than most people realize, especially if your integrator knows what he (or she) is doing and understands what business results you need to achieve.

Wherever possible, most integration should be done at the database level: this in as "application-independent" a method as possible. Unless there is a significant database redesign in a new release of an application, the integration will not require update just because mainline applications are updated. Even if the database undergoes a restructure, there are still technologies available with most database languages that will allow adaptation quickly.

An application is designed to be integrated if:

* API technologies exist. API stands for Application Program Interface. An API is essentially a set of program subroutines that are the same as the software vendor uses to update the database. These subroutines are made available to technically qualified clients to be incorporated into other programs to communicate with the database. In this way any queries, updates or insertions into the database use the same techniques and rules as the native applications.

* Open database design. Even if there are not APIs available, a well designed and documented database design is often sufficient for integration with other systems. A well documented and designed database makes finding information as easy as using the library. A poorly designed or undocumented database design is like trying to find a book in random boxes. In that case an API is absolutely necessary.

* It is often a good idea to standardize on one database manager to be used across all applications rather than have one application running on an Oracle™ database, and another on an Microsoft SQL Server™ platform. This minimizes the training and support requirements, and the expense of licensing 2 or more database managers. But, as long as your applications use ODBC compliant database managers, there is enough similarity that database standardization is not absolutely essential.

Learn more...

To discuss your needs, contact us at

This page last updated: 08/30/2011