The typical way to accomplish this is to lay down data from the source systems into a file once a day. Next, transfer that file from the cloud provider to the enterprise server and load the data into the target application or database. While this may seem reasonable, no mechanisms deal with the differences in data structure or content. Also, the transfer can happen once or twice a day at most, so data latency is an issue. Finally, failures may leave the source or target systems with bad or inaccurate data. Although FTP seems like the simplest approach, it's never the right one.
In the same vein, some organizations opt to build integration technology themselves, in effect coding an integration server from scratch. While this keeps developers busy, the results are almost always ineffective and inefficient. Now that such a broad range of integration solutions are available and affordable, there's no excuse to go down the path of ground-up custom coding.
That leaves you with commercially available and open source solutions, which vary widely. Navigating the technology requires some basic understanding, including the concepts of semantic mediation, connectivity, validation, and routing.
Semantic mediation (also known as data transformation) is the process of dealing with the differences in data structures or data semantics as they exist within the source system -- say, from Salesforce.com to an SAP target system. The structures and data content are changed in flight while moving from source to target, such as First_Name(char 20) to F_Name (char 10). Data is sent to the target using the native structure, even though the structure consumed from the source is foreign.
Typically the links between source and target structures are set up using maps that chart the structure from the source schema to the target schema. Within most integration engines, this is typically a visual, drag-and-drop process. Structures can be mediated in a matter of minutes, and information can flow between two very different data structures.
Connectivity is the ability for the integration technology to adapt to the interfaces provided by the cloud or enterprise-based systems -- typically, APIs. Adapters account for the differences in the interfaces and the way the integration technology deals with the data. In the case of Salesforce.com, for example, you invoke a Web service that produces data bound to a structure, and the adapter is able to consume that data into the integration engine where it is manipulated as required -- and then sent out another adapter to a local application, such an ERP or an inventory control system.
Validation is the ability of an integration server to validate data, such as making sure a ZIP code is correct. Routing is the ability to make sure the right data ends up getting to the right system.
The way this technology works is rather simple: It reacts to events, such as a customer record being updated or a sale being recorded. In reacting to the event, it carries out some preprogrammed function, such as extracting the changed data from the local enterprise system, accounting for the differences in structure and content, and updating the remote cloud-based system with the changed data, typically in less than a second. These events can occur at a rate of hundreds or thousands a minute, or just a few per day.
Choosing the right integration solution
Today, you have a choice of where your integration technology resides. It can live in a cloud, be bolted into a rack in your data center, or install on a server in your data center like conventional software. There are good and bad points to each.