Evaluating Integration Technology

Businesses that acquire an integration tool understand the tool's importance in productivity.  The rationale behind the acquisition will combine both technical criteria (for example, performance) and non-technical criteria (vendor financial health).  This post lists technical criteria for selecting an integration tool.

Some business will choose Informatica because it's the market leader.  Others will choose an open source product like Talend Open Studio because it's open source.  Some will look for a bargain in a product like Pervasive Data Integrator.  Still others will look around, see a lot of computers running Windows and SQL Server, and choose Microsoft SSIS.

Non-technical rationale is often the basis for making an acquisition.  It can be used to define a list of integration tool candidates provided to technical staff for detailed study.  The list serves to narrow the scope of the detailed study.

Despite the availability of demo software, it's often difficult for technical staff (developers, DBAs) to evaluate integration tools.  That's because a test lab needs to be set up to see how well a particular tool fits with the platforms, processes, and people of a business.

Once a lab is setup, several examples representative of the kinds of tasks expected of the integration tool should be developed.  These can be sample projects like loading RDBMS table or reading from web services.  Seeing exactly how each tool fares as the projects are implemented is the best way for staff to form an opinion.

When working on the projects, build a spreadsheet using the following integration tool attributes.  The attributes will organize the evaluation team's knowledge of the tools and provide a reference.

1. Runtime.  How does the integration tool run?  Does it come with it's own processing environment, libraries, and job scheduler?
2. Deployment.  How does the code deploy to the target runtime?  Is it copied, packaged, or published?
3. Packaging.  How is the code configured for different runtimes?  What is the grain of the packaged items?
4. Extension. Can the product be extended to add new data sources and components?  How are new libraries added.
5. Design.  Does the tool process the data in stages, pipelines, or functions?  Essential to know for beforehand design work
6. UI.  All integration tools should be graphical.  Check the UI's responsiveness.  Is an Eclipse-based IDE worth extra consideration because it's used elsewhere in the business?

These 6 attributes are key to understanding how a particular integration tool will fit into a business.  Set up a test lab and classify the different integration tools accordingly.  While there are no heuristics that will apply to all businesses, there are enough differences in the market to make the products more or less useful for a particular business.