How to create an integration strategy to power growth

Most conversations we have with growing companies start with one or more of the following statements:

• “Our business teams need to log into multiple systems to get the data they need”
• “We have multiple manual processes”
• “We can’t scale with all the rekeying we are doing”
• “We’re adding a lot of new technology and it’s taking too long to integrate it into our existing systems”

To grow your business, you must scale business operations. To scale operations takes people, process and technology. Your integration strategy sits at the crosssection of these three pillars. The typical goal for any integration strategy is to:

• Enable business teams with data in the systems they use
• Innovate and automate processes
• Free up resources to work on high-value projects and tasks
• Fully utilize your technologies

Three Steps to Get Started

Step 1

Determine is your system of record. Meaning, what system is the source of truth? For some organizations, it’s their ERP but for others, it’s their CRM. There is no right answer, but determining the system of record is a critical starting point for your integration strategy. The system you choose is your data management system and the anchor for the bulk of your integrations. Without clearly determining your system of record, you will find it impossible to trust your data which will make it difficult to decide what data to move to what systems and when.

Step 2

Map your applications. A recent survey by IDC of mid-sized companies showed that 65% use 20-99 different cloud applications to run their business. Of those companies, the best-run ones were actively working to eliminate data silos while the laggards were barely making a dent in the problem.

Step 3

Identify the apps that need to be integrated, and remove the apps that don’t add enough value. Try to simplify your application landscape as much as possible so your teams are not managing business applications and building integrations that bring no real value.

Tip: Be harsh.

Start Small but Don’t Think Small

Integration requirements tend to be fluid in high growth companies. Your integration strategy needs to be flexible enough to accommodate changes without forcing a massive IT project or forcing you to rewire your integrations when you add new technologies. A common mistake is to think you just need to build a couple of integrations and all will be good. That might be the case initially but it rarely remains that way.

As you think about your integration needs, look beyond immediate requirements to what might be needed in 3-6-12 months time. Giving equal weight to current and future requirements plus a healthy nod to the unknown reduces the risk that you’ll need to rework your strategy and technology decisions in a few months.

As the IDC chart below shows, the greatest difference between best-run companies and laggards is the ability for IT to deliver an integrated application infrastructure that supports business agility and innovation.

Free Advice:

Don’t try to boil the ocean and integrate everything all at once. It will take too long to execute and see the value. Instead, create a staggered execution plan so you are consistently delivering value and incremental improvements. In development terms, think Agile not Waterfall.

If budget is a concern, most integration vendors provide tiered pricing so you can start small and expand as needed. Once you’ve nailed implementation of your mission-critical integrations and realize value, you can usually get the funding needed to expand to secondary systems and processes.

Selecting the Right Solution: Comparing Integration Approaches

Coded point-to-point integrations

In this approach, a developer is writing code to integrate APIs. This is done by an internal or external development resource. An API integration tool, like Cloud Elements, may be used to help expedite the integration development or developers just code directly to the API.

When to consider this approach

• You only have a couple of applications to integrate to a hub app, i.e. 1-2
• You already have IT developers on staff with bandwidth to implement, manage, and maintain the integrations
• You don’t want to leverage third-party solutions

Cautions

• If you have more than a couple of applications to integrate, writing custom code for each integration may take too long to meet business needs (average of 41 days per integration)
• Custom integrations require a dedicated resource(s) to maintain and manage as business teams will have no visibility to errors or any ability to make changes without using IT
• IT will need to resolve any integration errors
• If integrations are mission-critical and time-sensitive, you will need to staff for 24x7 365 rapid response support
• You will need to create a process to be made aware of endpoint (API) changes to avoid unintended downtime

Vendor provided (native) integrations

This approach is relatively common as many apps provide native integrations to large hub applications like Salesforce.com. In this approach, the vendor has built an integration that typically a business system admin configures to exchange data between their app and one other. For example, HubSpot to Salesforce.

When to consider this approach

• You don’t have any unique or custom integration requirements
• You don’t have a need to send the same data to multiple other applications

Cautions

• You may have to buy a higher tiered version of the respective apps to gain access to the APIs and integration services
• It is hard to customize these integrations outside of what the vendor provides out-of-the-box
• Determine who is responsible and a process for managing errors as typically only system admins have the necessary visibility
• Visibility and error handling is basic often with no ability to recover without resending the record from the source system or manually re-keying

Point-to-point integration solutions

These solutions are typically built for individual tech-savvy business users to enable relatively simple integrations between the systems they use. They provide a highly abstracted view of the underlying APIs that enable users to configure integrations so no specialized skills are needed. Users typically need admin access to the systems they are trying to integrate or access to API keys. Example solution providers are FarApp and Zapier.

When to consider this approach

• You have individual or department level integration needs
• You only have a couple of apps to integrate with a handful of simple integration flows
• Business teams own apps and integrations

Cautions

• Because of the high abstract interface, It is hard to customize integrations outside of what the solution provider has built
• These solutions do not scale well to organization-wide use
• Pricing is “task” based which can get expensive if you have large numbers of small data packets moving between systems
• Visibility and error handling is basic
• There are no checks to ensure integrations are not stepping on each other, i.e. different integrations are mapping different values to the same field
• It is very difficult to perform audits when there is a proliferation of point-to-point integration

Integration Platform as a Service (iPaaS)

This class of integration solutions is relatively new to the market, coming up in the past 3-5 years. The are designed to eliminate the problems that often result from a proliferation of point-to-point integrations by providing centralized integration management. Like point-topoint solutions, they abstract APIs to enable configuration of connections from apps to the iPaaS. Beyond that, the user experience can vary widely. Some iPaaS solutions are built for large enterprise use cases so they are more like integration “toolkits” better suited for IT use, such as Dell Boomi, Jitterbit, and Mulesoft. Others offer more pre-built integrations designed to help organizations get started quickly and the ability to build custom integrations to serve any use case. These solutions tend to serve midsize companies better as they can be used by both business and IT teams to build simple to complex integrations. Celigo and Workato are good examples of iPaaS solutions that cater to the mid-market.

When to consider this approach

• Your integrations are mission-critical
• You have a mix of complex and simple integrations
• You have multiple applications to integrate
• You want business teams to manage and maintain integrations, not your IT team
• Your integration requirements are fluid and change often
• You need to build custom integrations
• You need advanced operational visibility into your integration performance, including error handling and auto-recovery

Cautions

• Not all iPaaS solutions are the same, so develop a checklist of your specific requirements
• Ensure you are not paying for enterprise-level features you will never use

Contact Us for more information on getting your operations ready for the holiday with Celigo for your Business.