Data integration advice

[staticbob]

Guys,

I have to look at 4 software vendors to evaluate their "Data Integration technology and capabilities". All companies have off the shelf solutions that will need to integrate with an existing compny system if we chose their solution. Both systems (the new and existing) are SQL server based.

The front ends and other stuff about the 4 potential solutions are all pretty well matched, so the win may come down to ease of data integration.

Can somebody give me some pointers of the things I should be looking for in each company. Some offer a data exchange API, but I'm not sure what work would be needed to get this to function. Others offer mapping interfaces etc etc. I need to evaluate the technical competence and cost of each company as far as data integration is concerned. Any heads up appreciated.

Bob

[sapator]

I would go with money, source code given and help provided when needed.
Especially the help you can get is critical.Are you working on a big company or a smaller firm?

[leinad31]

How mature are the systems that will be integrated? That's the question not covered by most SOA references.

IMO, ROI of integration layer is only worthwhile when systems being integrated are mature or are not in constant flux, e.g. legacy systems and data warehouses/marts, and benefits of scale are there (you are not integrating just 1-1 but rather 1-very_many). Otherwise, the effort needed to keep integration up to date along with cost (not just immediate purchase cost) would outweigh the benefits as you would only be adding another layer of abstraction that keeps changing (and retested, monitored, maintained, tuned, debugged, etc) instead of just being reused as it is.

If you don't have system maturity and you don't have scale then explore other integration technologies, or maybe just refactor what you already have.

[staticbob]

Guys, thanks for the responses.

@sapator - the company I'm working with is a large national organisation, we're looking at about 2000-3000 users of the in house system being developed. I'd consider it a big company, yes. Money isn't really an issue with this, although on-going development costs/integration does need to be kept under control.

@leinad31 - the in-house systems are new. In beta testing right now. This is the first module of 8 being developed, each will need this integration with the off the shelf package I need to evaluate. I understand what you are saying about maturity of systems before integration, but thats not an option here, we need to integrate from day one. Obviously, the COTS package we are buying is more established. So, we dont have maturity but we certainly have scale.

In short, the choice has already been made that we will be buying a COTS package to fit this certain business need and we WILL need the SQL databases to integrate. My issue is how to evaluate the companies in the running to ensure we choose the best one for integration after other business requirements have been met.

Bob

[sapator]

I would stand for my opinion.
I had a personal experience on this and for me, getting help when you need it is my first consideration.

[leinad31]

If that is the case then I echo sapator's statement.

Go for the one with better support and training offerings. Setup is a one time activity and deployments can be scheduled... what's more crucial is recovery from a failure and ease of debugging since you are introducing another possible point of failure in your system. You want your staff better equiped to deal with urgent problems, and with additional support ready if needed.

Features and benefits presentations are marketing driven... they exagerate, they lie . Evaluation of their support capability is more realistic; better if you can ask around or get feedback from their other clients.

[staticbob]

Thanks, this did indeed come down to the company experience, product maturity and experience of the technical team. All had a "can do" approach to the data integration, but one was maybe 7-10 years further down the product development and support path than the other.

Bob