To integrate software-as-a-service (SaaS) applications with internal applications, you need to think about integratability and control, not development speed.
Integratability, the underlying ease with which systems can be integrated, is fundamental, but we rarely think about it for in-house systems or demand it for packages. Integratability is achieved by having a defined, meaningful interface that opens up the functionality of the system to other systems. The technology is less important – it could be flat files, web services, or some sort of programming interface. What is important is that the interface is well defined and properly supported, and that it fully encapsulates the required processing, for example managing the rejection of invalid data.
When systems have good integratability, integration is hugely simplified. Basic integratability is the first step if you want to integrate your internal systems with SaaS.
Once these basic interfaces are in place, there are many options for connecting systems.
Personally, I tend towards hand-coding. I would define a common format and technology that represents the contract between two systems, and then write an additional layer of code at each system to bridge between this and the system's own interface. This approach protects your investment, because the impacts of changes to each end can be managed locally and do not have a knock-on effect.
Many organisations use specialist middleware tools and specialist teams for integration work. When considering the problem from an integration and middleware viewpoint, specialist tools and teams look like they give economies of scale and control.
I think there can be problems, though. We would not centralise, say, all user interface programming, because we know that the user interface is a fundamental part of the system that needs to be managed alongside the rest of the code.
Within an application team, economies of scale from centralised teams can mean project blocks when the work has to be scheduled. It can be easier to get your own team to write integration code in their normal development language, rather than to have to wait for a specialist team, even if the specialist team is more efficient. Centralising integration centralises control, but arguably it is better to align control with the business applications. Specialised tools add more components that need to be kept up-to-date, making it harder and more expensive to make your systems last longer.
The approach for integrating external systems, such as SaaS, is pretty much the same as internal systems. I would expect to develop a local proxy to convert the external system's interface into the common format used by the organisation. I have less of a problem with specialist tools for external systems, because there are fewer impacts to your organisation when the tool reaches the end of its life. However, it is still important to think of the common formats and underlying integratability of the applications to which the SaaS connects.
I know many are drawn to tools that promise to make integration easy. But in the long run, the easy option stores up problems as you take control away from the applications and become reliant on more components. Pushing integration effort to the applications looks harder, but is a much more stable option for the long term.