Some integration doodles
I was a part of some conversations today about software integration. We were talking about integration and how it’s important to solve the problems that nonprofit staff are having today. A lot of work processes can’t be completed in one software platform. You often have to jump to another platform midway through a process. For example: you look up your recent donors in your CRM and then you want to send a blast email to them. That’s a place where you may need to leave your CRM and take your donors over to an email blasting tool.
So integration can make those bridges between software invisible, or at least easier than the manual options of hand entering them, or doing an export and import. But what does integration really look like? In doodling in the meeting I came up with some drawings that helped me get my head around it.
First we’ve got platforms. These are the software applications we’re looking to integrate. Next, we’ve got web APIs. This is a way to make the platform do things from a distance, over the Internet. Then we’ve got custom logic and UI to make the integration happen. The logic implements the business rules–when x happens, then do y, finish with z if y was successful. Sometimes UI can be helpful in an integration like this, sometimes it isn’t necessary.
On to the doodles.
Doodle 1: One platform with no API integrating with another that has an API
When I integrated dotproject with Salesforce I used this method. I built logic and UI into dotproject as custom code. It would then speak to the Salesforce.com API, doing what I wanted it to do. It could manipulate dotproject data and/or Salesforce.com data according to the business rules I created and hard coded into the logic.
Pros: Can get integration with only one API. UI is embedded in one of the platforms, so the interface can be seamless. No outside server to run.
Cons: Have to host the code in the system without the web API. The integration may break if the underlying platform code changes.
Examples: my dotproject integration, What Count’s email integration with Salesforce.com.
Doodle 2: Integrating two applications with APIs via an external client
If I have two platforms with web APIs, I can write UI and logic by which someone can manipulate both systems. That code and UI can live anywhere on the web. It could be PHP code on a web server, for example. Or it could be a dedicated integration server that can be configured to support your business process and connections to the services you care about. Jitterbit is an open-source example of this.
Pros: Depending on complexity, client can live anywhere: your desktop, a webserver, your phone. Integration code is portable–can be moved around as necessary.
Cons: Need to run it somewhere. If it needs to have high uptime, someone is responsible for that.
Examples: Polling a CRM looking for newly places sales orders and then turning those into work orders in another system.
Doodle 3: Integrating two applications with APIs via code embedded in one application
Salesforce.com, for example, allows me to embed custom UI and logic in their system. This is a lot like the first example but instead of making calls to underlying code, all calls go through the web API.
Pros: UI is embedded in one of the applications, so the interface can be seamless. Don’t need outside server to run.
Cons: Code isn’t portable, has to live in one service.
Examples: Not sure if I can come up with any examples here that I’ve seen.
Discuss the doodles.
