eCommerce Integration Types

Chris Reddick, Founding Partner of Clarity Ventures, on the Pros and Cons of different types of integration

 Video Transcript: Okay, so this is going to be an overview today about four different models for integrating an external system to an internal system. And in this particular case, we're going to take a look at dynamic CRM, but it can be any line of business application that we're integrating to, to look at these different models. There are pros and cons of each of the models. Effectively, it varies from simpler to set up and more cumbersome to manage with more potential issues down the road, to more complex to set up and much more robust down the road, but higher costs, more expense up front to implement.

So, the first model we'll take a look at is a fairly standard model that leverages some of the more database-centric technologies and it's commonly referred to as Extract, Translate and Load, or ETL. In this model, we're taking the data, literally, out of the external database and we're using an ETL model, a lot of times SSIS or SQL Server Integration Services. Maybe, there is an XML format that gets pushed and pulled. Whatever it is, there is an intermediate layer that allows the two databases to talk to each other and it's commonly referred to as ETL. So, that would pass data securely over the wire from an external source to an internal source that you can see here on the right, and that's called ETL. So, pretty simple model there.

I'll go ahead and take a look now at the next model. Okay, so this next model is basically a direct API integration. For this model, we're looking at two external systems that have APIs that can talk to each other. Now, a lot of times, the external system or basically, kind of, the web application is going to have its own custom service layer that typically, Clarity would build or a service provider would implement. So, that's going to be one of the sides of the API. And then, the other side will be on the line of business application like CRM or GP, Great Plains, or any ERP or line of business application.

And so, those two APIs would basically need to talk to each other. So, we would implement a intermediate layer to connect those two. Now, both for this API, the direct API integration, as well as, the ETL integration, there isn't a lot of infrastructure there that makes them extremely robust, but they're pretty quick to set up. In particular, for the direct API integration, you can see from this image that if you start to add multiple databases, it gets pretty cumbersome pretty quickly. And so, the downside to this direct API integration, unless there is additional infrastructure, is it's not very easy to support and it can be cumbersome if there are any errors or issues that come up.

If you go back to the ETL example, it has a little bit more capability for more robust handling of issues because software platforms that support tools like SSIS are pretty robust and they can be very detailed in error reporting and error logging. Another way you go is you can build these out as you grow your model, your integration model, so that you can kind of develop additional support and robustness, but off the shelf, these two models tend to be low cost but not as robust. So, let's take a look at the next model.

This particular model is basically setting up a hub based system. So, in the hub based system we're effectively funneling all of the external data into this kind of central database and then, pumping that into our line of business application and pulling data from our line of business application back into that central hub and then, pushing that out to the different ends of the wheel or through the spokes as it were. So, this model is pretty simple. It takes a little bit more time to set up, as you can imagine, and any time we need to do additional integration, there's additional over head to adjust the database and configure these external systems to be able to talk to the central hub database. But, one of the strong advantages of this, even though it's got a medium level of effort to configure and set up is, now, we just have the single point of integration. So, anytime we change systems externally, we don't have to change our entire infrastructure to meet that.

So, the last system is really a enterprise service bus type of model. This model is very detailed, typically, to set up and takes the most amount of time. It tends to be the most robust, though. Basically, the way that this model works is it's got infrastructure for queuing so that messages can get pushed into a queue and messages are basically, data sets that need to be pushed and pulled between the different line of business applications. It's very normalized and, what I mean by that is, the data is very much in a kind of standard format that all of the line of business applications can consume. And by setting it up in that manner, it makes it very easy to extend and make adjustments quickly to this platform.

So, those are the four types of integrations that we typically would consider and recommend for clients, and it just depends as far as what type of integration is going to make the most sense for your particular business and your particular needs. It kind of depends on your timeline, what your need is for a liability versus meeting a certain timeline and a certain budget, and then, certainly, being able to upgrade and adjust and scale as you build the solution out. If you really need to scale and you need a performant, redundant, highly reliable, application integration, then it makes sense to go with one of the more enterprise solutions. If you don't need that and you just need something quick that does the job to start with and you want to upgrade later, you may want to just go with a direct application integration through an API, or you may want to go with one of the ETL options.

Okay, and just to wrap up as well, and make sure that you're aware of options that Clarity offers, we do have an integration platform called Clarity Connect. And as you can see here, it offers quite a few options for integration to different line of business applications. So, we are very comfortable with not just the queuing model that I mentioned earlier and being able to scale up and down, but we also do PCI DSS, HIPAA compliance, Sarbanes Oxley, all of the kind of standard compliance that you might need. We can certainly provide those services as well with your next integration. So, thanks for watching and I hope that was helpful.