Integrations, Imports, Exports and Similar Architectural Considerations

When we talk about creating an architecture for the future, integrations should always be a part of the discussion.  These include importing, exporting, and direct integrations via an API.  It is limiting to assume that an application will always stand on its own.  Even a solution that proves better than all others is served by providing a way for other application data to be brought in.

Importing and exporting data are the easiest ways to integrate with other systems.  While there can be some challenging mappings, these often are little more than selecting the fields to work with and connecting in a one-to-one manner.  Even the most complicated import or export processes can off-load some of the most onerous work to a manual process.  This approach is not the most desirable, but it is an option.

When your architecture provides hooks for imports and exports you are making those mappings easier.  These in and out methods can combine to become a form of language your system speaks.  When someone wants to bring data into your system, they need to translate that data into your language or format.  Therefore, these features off-load work the implementation team would have to do to more directly integrate with other systems.  Better yet, a well-defined export and import process puts the onus on others to work with your system instead of creating customizations for other systems.

Importing and exporting data are ways to integrate with other systems.  However, those are limited integrations.  It is difficult (if not impossible) to do a realtime integration via these methods.  That is where an API can save the day.  The application programming interface is rarely easy and requires coding.  Nevertheless, it provides far more lee-way and control in system integrations.  There are some problems that can only be solved by creating this level of integration.