With the new year right around the corner, most companies are in the process of finalizing budgets and developing strategies for new IT investments. Integration is (or should be) one of the key investments any company with multiple applications and disparate data is looking to make. With that in mind here are a few quick guidelines to use when picking a direction for your on-premise and cloud integration initiatives.
First up, the classic question: build vs. buy? It’s 2012, so frankly, building an integration shouldn’t really be considered an option. But there’s no convincing some people, so if you are still considering coding integration in-house, be sure you can answer these questions:
- In the world of SaaS, APIs are updated at least four times a year. What is your plan to keep your custom code updated at this pace? How will your custom code deal with data format changes? Will you learn about these changes in advance and be able to plan for them, or will you find out about the changes when your integration stops working?
- What type of performance do you need and how does custom code address these requirements? Will scalability be built into your solution? Will you handle latency and unavailability issues, timeouts, etc.?
- Will you code to guarantee that data won’t get lost when something inevitably goes haywire?
- How will you monitor your integration code and are you planning to write robust logging and error handling scripts?
- If you add or change source/target systems will your custom code support it – or are you writing throwaway code?
If that hasn’t scared you straight, I’ll give you one last piece of data: a packaged integration solution can reduce project costs by up to 90% – reducing analysis, development, support and enhancement costs across the board. Still not convinced? Read the whitepaper Cloud Integration: Build vs. Buy.
Ok, so you’ve decided to “buy” your integration solution in 2012. Nice work! But you should be aware of some hidden costs that can come with some solutions. Be sure to ask the vendor about these costs and have them clearly covered before you sign a contract:
- Data metering. Many cloud-based solutions meter the number of transactions processed on a daily or monthly basis. Many of their cheapest plans include a maximum number of records, rows, or volume of data that can be moved in a given time period. Like cell phone minutes, once you go over, there can be an expensive upcharge. Figure out how much data you need to move 12 months from now and price compare solutions accordingly.
- Connector/Endpoint costs. Many vendors charge per endpoint. This is a solid model – you pay for the value you are deriving from the solution. But some vendors charge not only for the application connector, but for each specific instance of that application. For example, if you have multiple instances of an application (CRM or ERP) at corporate and other divisions, you would be charged separately for each. Be sure to understand what the vendor definition of “endpoint pricing” is.
- Trading partners. If you’re running a B2B business and looking to hook your partners into your systems via integration, check on trading partner pricing metrics. Some vendors price per partner, so the more trading partners, the more expensive ongoing integration will be. Consider including these incremental costs as part of the cost of supporting the partner – and make sure it makes business sense when weighed against the potential revenue that partner can bring in.