Offshoring Alternative for Salesforce Integration

Outsourcing development to offshore teams is a standard practice for software projects in organizations large and small. The perceived savings from the lower per-hour costs for offshore developers, as well as the internet-enabled ability to communicate with teams situated anywhere on earth, makes offshoring seem like the ultimate no-brainer to many enterprises. Here at Integrate.io, we think offshoring is a good solution for some projects, but we also know that our integration solution can save significant time, money, and risk when it comes to Salesforce integration.

Salesforce and Offshoring are Targeted at the Same Problem

Software development is hard.  Even with new approaches like Agile, software projects are often more expensive than anticipated, and don’t fully address user requirements. The offshoring approach tackles this project by adding a large amount of relatively cheap overseas resources. Salesforce takes a different approach -- their platform allows non-developers to accomplish tasks that formerly were only accessible to coders.

Salesforce is built on a powerful and configurable object database technology, branded Force.com. Force.com has workflows, easy reporting, dashboards, the ability to customize the presentation of data, and a robust security model. But most Salesforce users aren’t buying Force.com - they are buying a pre-built but highly customizable application for a given problem domain. The most widely used application, Sales Cloud, is a sales and CRM solution that can be customized by administrators to meet the ever-changing sales requirements of companies large and small.

Though there are companies selling offshore Salesforce administration, generally at least some administration takes place in-house, because a good administrator has a much different role than a software developer. A good admin also understands the business, and is a knowledgeable process consultant. The admin might orchestrate some offshore help to handle tickets for easy tasks, but overall the admin is going to lead the customization process for Salesforce and generally do it fairly quickly, without writing much or any code. 

So, to recap, software development is rife with risk and failure. To address that challenge, offshoring adopts the traditional software model, where teams of developers work to build software. It throws the Agile development process into the mix, though the original Agile concept was predicated on teams in close proximity with users, and hopes that applying a large number of cheap resources will avoid failure.  

Salesforce looks at the same development challenge and addresses it by building pre-configured applications on a highly customizable platform, and encouraging the advent of a new role, the administrator, who is able to perform many tasks with configuration (“clicks”) that would normally have required code.

When Salesforce and Offshoring Overlap

If you’ve implemented Salesforce in your organization, we’d argue that you’ve already implicitly accepted an approach that is quite different from offshoring, at least in the departments that use Salesforce. But we recognize that most organizations also have in-house systems that were developed and are maintained by offshore teams. One of the most common tasks in organizations with Salesforce and other in-house systems is data exchange between Salesforce and the other systems.

Here’s where Salesforce’s flexible object database and API, which are generally strengths, can cause your business to spend money and time that isn’t necessary. Salesforce’s database is not like traditional relational databases like Oracle or SQL Server - a developer can’t just open a connection to the database and push SQL INSERT and UPDATE statements into Salesforce.  All updates to Salesforce must be made via the Salesforce API. Salesforce also has its own query language, SOQL, which is similar to SQL, but not quite the same. Overall, programming interfaces for Salesforce isn’t harder than any other programming language, but it is different. There is a learning curve, and Salesforce resources are more expensive than, say, LAMP stack programmers. 

Still, since your Salesforce administrator is not a developer, and he or she can’t code the interface on your offshored system, your first instinct when presented with an integration issue might be to use your rooms full of developers in India or the Balkans to code up a solution that pushes and pulls data from your in-house system to Salesforce. Never mind that those coders aren’t Salesforce experts - they can learn it and then do it, at a low hourly rate.]

So, to develop the interface, your developers need some kind of specification document that tells them the data to retrieve from the in-house system, what transforms that data requires, and what the target in Salesforce looks like. Your Salesforce administrator may be involved, or you may outsource the whole thing. Either way, the Salesforce configuration will be a tiny percentage of the overall budget for the project - most of the work will be building the extract, transformation and load (ETL) to Salesforce, and the ETL that goes the other way, if necessary to solve your business problem.

When going from your in-house system, you would be engaging experts who know the system and would be able to create the ETL process somewhat easily. But you’ve added risk - risk of failure, risk of missing deadlines, and risk of the process not meeting requirements - by asking a team to do something using a new technology. 

In our view, that risk is unnecessary. Integrate.io, a proven tool that is easily configured, can work with your in-house system and Salesforce, perhaps with little or no coding, to create functional, robust data exchange with minimum risk.

Scenarios Where Integrate.io is Better Than a Development Project

The core of Integrate.io is a configurable data integration pipeline, that is programmable via a drag-and-drop interface. This pipeline connects dozens of different data sources and can be used to select, cleanse and validate data from one system prior to inserting it into another.

Let’s consider your in-house system for a moment, which contains data that your organization wants to see in Salesforce, and ask two questions:

1. Is the data accessible via standard technology?  Is it in a table of a database, or is there an already created REST API that can be called to get at the data?  Or is the data the product of complicated calculation that is carried out by the system “on the fly” as it is presented to the user?
2. Is the data suitable for the task? Even if the data is accessible, it might not have the desired granularity or format for insertion into Salesforce.  It may, for example, be purchase order detail when all the Salesforce users want is total ordered for the month. Or there may not be a clear shared key.

A way to visualize the suitability/accessibility relationship is in a 2x2 chart. In the chart below, the green areas are places where we think Integrate.io pipeline alone might be a complete solution. 

Using the purchase order example, a high accessibility and high suitability project would be one where summary data was written into an Oracle table with a monthly grain, with a key that is shared with Salesforce. An Integrate.io data pipeline can easily extract that data and push it into Salesforce. Using Integrate.io instead of custom development is a no-brainer in this case.

A low accessibility and low suitability project would be one where some kind of proprietary oddball database was being used, and purchase order summaries are calculated on the fly for reporting. Let’s consider options for this scenario.

1. An end-to-end solution coded by your offshore in-house developers. They move the data directly from the in-house solution to Salesforce, using the Salesforce API. 
2. A more robust solution where the in-house devs generate a PO header table within the system. The developers then create a REST API that allows access to the table.
3. Another robust solution that pushes the data into a table in a data warehouse, for use both by Salesforce and analysts.

Option (1) is, in our view, the riskiest and most expensive of the three. Not only do your offshore developers have to create a solution with technology they don’t use every day, they will be responsible for any issues that crop up with their end-to-end solution. This means that you must trust your offshore development team to learn the Salesforce API, deliver their first Salesforce project within time and budget constraints, and retain the Salesforce developers needed to maintain the integration.  

Both options (2) and (3) are ones that make data from a relatively inaccessible system more available to the entire organization. And, not coincidentally, they make the data easily available to Integrate.io, where it can be pushed into Salesforce. Similarly, if data has to come back to the in-house system from Salesforce, the in-house team can build a REST API, or poll a table in a data warehouse, rather than building an end-to-end solution.

These two scenarios - high accessibility and high suitability versus low accessibility and low suitability, are the extremes. Much more likely is a scenario where the data is in one of the many industry standard databases that we support, but it’s not in a format that is immediately usable. In this case, here are two options you can consider.

1. If the data is all in tables in the database, and a transform will yield usable data for Salesforce, you can use the Integrate.io data pipeline tool to transform the data before it is sent to Salesforce. 
2. If the data is the result of a calculation that isn’t stored, your offshore team can write a relatively simple program or trigger to push that data into a table in the database. Then, Integrate.io can pipe that data into Salesforce.

Similarly, if data must come back from Salesforce, Integrate.io can either push it directly into the target database, or it can be pushed into a staging table from which the database can be updated using a program written by your offshore team.

On the Salesforce side of the equation, generally the development work for integrations of a few data elements is relatively straightforward. Administrators can create fields in existing objects, or custom objects related to existing objects, via the Salesforce web-based setup pages. These fields or objects can be placed on existing Salesforce pages, or on new pages, also without coding. Security is also a configuration, not code, exercise. In short, as long as someone who knows Salesforce is doing the work, the Salesforce configuration is the easiest part of this whole process.

Conclusion

In any scenario where the offshore team is working on what they know best, we believe that failure and schedule risk are lessened in an integration project. The combination of offshore developers customizing an existing system, Integrate.io extracting, transforming and loading the data to the target system, and existing Salesforce admins configuring Salesforce, is in our opinions the best recipe for success.

Integrate.io is a tool that may have a number of uses in your organization, and you may want to cultivate in-house expertise. However, we also have a staff of US-based, native English speakers who are experts with our tools, and can quickly build data integration pipelines for your application. Our delivery timeframe is usually days or weeks, not months. Contact us to get started on the platform, a free 14 day trial, and to learn more about how Integrate.io can simplify your Salesforce integration.

Related reading: How to Use Salesforce to Salesforce to Enable Your Data Sharing Strategy