When working with Drupal to build data rich applications for your clients we often find we need to integrate other systems into Drupal. Some of these systems come with a ready made Drupal module, some with a helpful API using interfaces such as SOAP, REST or XML-RPC and some have to have their connection to the outside world created first. Examples include payment gateways, CRM systems or search systems such as Apache Solr. Though there are great benefits in utilising these systems they can become the Achilles heel of your site and poor architecture choices can mean that when these systems go down, they take your site down with it.

In this session we will explore the different interface standards, discuss what happens to your Drupal site when the third party system goes down and look at some of the design patterns and strategies that can be employed to decouple the dependencies and ensure you protect your Drupal site from third party failure.

In addition to the technical issues there are also common business or project issues with integrating third party services. These systems often require another project team which is distinct from the client. Your build project may not be there top priority, you may not share a language, a time-zone or even a common understanding of how it should work! We shall look at how to plan for contingency and unexpected issues, including the third party vendors in the project, service agreements and monitoring.

We will finish with some good examples of how some well used contributed Drupal modules approach this issue to see what we can learn from them.