Wednesday 20 February 2013

Integration, the old enemy

Blogs are very much like buses, you spend ages waiting for the topic worthy of sharing your perspective on and then you get a couple in a short period of time. Today's topic I wanted to discuss was the wide ranging topic of integration with a particular slant towards the Cloud.

Lots of people will be willing to wax lyrical on this topic for seemly hours on end but there is no need for this to be a scary or daunting thing for people to take on. There are a lot of complex issues wrapped up in the subject matter but like all problems, once you know what you want to do, it can be broken down into a series of smaller activities which are fundamentally much more straight-forward and at the risk of jinxing myself, actually quite simple.

If you take the simple and a-typical integration cloud scenario of linking Salesforce.com to an SAP system you first need to make your decision as to what integration is necessary:

  1. Does the integration need to be two way?
  2. Do you need a special integration platform such as Informatica, an ESB, MQ Broker, etc...
  3. Do you need "real-time" integration, interval (delta every x minutes) based integration or regularly scheduled batch integration.
  4. Technology, Web Services(Synchronous or Asynchronous, RESTful APIs, Flat File, RMI, etc...)
  5. What messages / data / objects will be passed between the systems

So to go through this (admittedly oversimplified) checklist we can answer the above scenario:

  1. For the purposes of this scenario I'll say the integration needs to be two way, e.g. the product catalog and price list needs to be taken from SAP and the orders need to be sent to SAP for fulfillment
  2. The business has indicated that in future, additional systems such as a finance system will need to be integrated into the solution so we'll say yes, an integration layer will be a much more future proof solution. (I personally would always recommend an integration layer in most cases)
  3. The timings are interesting as the product catalog and pricing can be loaded into Salesforce on a batch process, the reason being that this information would not typically be changed ad-hoc and therefore would not be changed regularly. Salesforce will need to send the orders through "real-time" so this integration will be different
  4. Again, the implementation strategy can drive this, for SAP to SFDC we can use Flat Files or API calls to Extract, Transform and Load (ETL) the data. For SFDC to SAP (assuming we have chosen Informatica as our integration platform) we simply have a connector for SFDC and a connector for SAP and that is the way we'll integrate.
  5. Now we have the answers to the first 3 questions we can now start to map this out.

As you can already see, by breaking down the problem into it's consituent parts, the problem becomes much more easy to manage. Now the devil here is in the detail of the interfaces but again this can be broken down into baby steps:

  1. Who is the master of which data components
  2. What are the process maps (this can be as simple as a visio flow chart showing the process)
  3. What data needs to move from System A to System B
  4. What interfaces will be needed to support the transfer
  5. And last but certainly not least, What do we do when something goes wrong?

Again I have oversimplied this process and left out some of the steps you would take on an integration project / design but I don't want this to become a weighty read, just get across the point that Integration is not just a big bag of snakes waiting to bite you. Like most things in IT, it's a process, a series of steps and checkpoints you go through to get to the desired final state.

So next time you look at your next integration project keep in mind it's not one huge problem of nightmarish proportions, just a problem that needs breaking down and solving in a methodical, process driven approach.

No comments:

Post a Comment