When evaluating Data Integration, what aspect do you think is the most important to look for?

Hello,

My experiences says :

1. Project budget;

2. Needed connection(s) available(s) (natively preferred - without third party drivers to do that) - think about web services requirements and cloud storage;

3. Easily and quickly to understand and start developing;

4. Quantity of professionals in market who knows how to maintain it (human resources are volatiles);

5. Performance for get, transform and stock the data (internal and big data if needed);

6. Capacity to stock the last well execution of a scheduled job - and to retrieve from the unsuccessfully point;

7. Versioning available (Git, Source control, embedded one) for simultaneous development and easy way to deploy it in multiples environments.

Sure that many other questions needs to be answered, but the very first is always ROI.

Regards,

Arthur

I would be looking for things like:
- types of connections supported
- data transformation capabilities
- throughput
- can it support micro batching
- can a process be triggered by a data source
- security
- how does it work in a Hybrid scenario (assuming the organization isn't cloud-born)
- licensing and support costs (even open source has support implications - even if it's being patched by your own devs)
- expertise in the product, and product roadmap/life -- if it's difficult to get expertise in using a product or at least support until your own team is competent a problem can incur a lot of delays. If a product is approaching end of life - then skills with the product will disappear, you'll eventually need to change your solution

- Ease of use - The solution should offer the same level of usability to both IT and business users.
- Support for both batch and transaction-based integration
- Workflow automation - I would not want to spend my time scheduling and monitoring recurring jobs. Therefore, there should be support for time-based and event-based scheduling.
- Connectivity - Any business today works with a plethora of legacy and modern data sources. So the solution should offer out-of-the-box connectivity to a range of source and target databases.

Flexibility - can you code complex business domain rules using VB or C++?
Connections - what data sources it connects with and how it connects to them.
Stability - will it crash in development mode?
Reuse - can you create and re-use modules in multiple projects and deploy to server tasks?

For advanced data integration flows that ingest time series and similar type of measurement data that comes of a physical process (anything IoT), you stand to benefit from a characterization and resampling flow. Most ETL tools are database oriented instead of model characterization and model prediction oriented. When dealing with sensor networks of any kind, ETL system are not the right tool for the job.

Ease of modelling and deployment, connectors availability out of the box,,workflow automation,ETL capability,audit and control, transaction and batch processing, continuous Synch,low code,visual interface.

Connections - what data sources and targets it can connect to.

Flexibility - can you code transformation rules on Java, C#, Python.

Data Quality features.

Usability of tracing and monitoring instruments.

Stability of work and ability of "try-except" transformations.

Ease of use for ETL
Advanced ETL features for flexibility
Easy to test/debug
Reusable
Templates/Pre-built functionalities

Ease of use for ETL
Advanced ETL features for flexibility
Easy to test/debug
Reusable
Templates/Pre-built functionalities

When evaluating data integration, think about versioning and audibility. 

Other ETL/ELT tools preach it, however ODI lives and breaths it. Also, look at reusability. 12c especially has lots of cool reusable parts that will make development easy and quick. 

Security should also be at the top of the list. 

Can you lock someone down to a single job or even a portion of that job? ODI you can. 

Are you looking for a data warehouse tool of just something to copy a file from one place to another? Even though ODI can do both I would say that you would be killing a fly with an atom bomb if you just need to shuffle files around. 

Think about what you need to "hook" into now and in the future. 

ODI you can create custom connections, so even if you forgot about something most likely you can connect to it. I have even hooked it to iTunes reports.

Data profiling, easy to use, connectivity capabilities to different kind of sources (unstructured data, flat files, common rdms, soap and json ) advanced data transform capabilties

Less code more productivity

Data Quality, Data governance, Data profiling, and advanced ETL functions embedded, multiples and native connectivity with structured and unstructured data.

There are 2 types of data integration.  The one you need to use some sorte of ETL to load the adjusted data into another database and the one you use virtualization data tool to adjust the data but keep them in their original places.

Costs are totally different and you need to really think through your business needs in order not to buy salespeople speech.

Then, you need to think a cohexistence between validated data and non validated data.  You will probably need them both since the timing to adjust data can be long depending on system and processes reviews

You will also need a data catalog to keep track of data and have some governance on the data you have

And finaly, you will need to think of a sustained solution.  You will probably prioritize the data to be integrated and cleansed and types of data and connectors may change along the time (don´t make the mistake to think your data and connectors currently need will remain unchanged in the years to come)

Capacidade em atender ambientes híbridos considerando plataformas, banco de dados, sistemas operacionais e aplicações variadas que rodam de forma isolada mas requerem algum tipo de comunicação e integração. Pode ser aberta do tipo OpenSource, fazer uso extensivo de API´s, fáceis de usar oferecendo performance, compatibilidades, segurança nas autenticações e manutenção gerenciada (DevOps). 

Ease of connecting to multiple source system. Inbuilt testing facility in between the ETL pipeline.

User friendly GUI .

Should include templates for generic task such as SCD1, SCD2 , Delta Load 

1. Flexibility. A DI tool should be like water to fit the shape of each glass every time. Ability to learn.!
2. Ease of development, installation, implementing topology architecture.
3. Reusability of coding.
4. Ease of maintenance, management and operation.
5. Learning curve.
6. Ability to talk with related products (Data Quality, Replication, etc.) fully integrated and out-of-the-box.

Ease of data extract, Ability to support complex Integration between desperate systems, Ability to feed data to different downstream systems, Ability to perform data quality check and Availability of ETL out of box functions..

Ease of use (modeling), flexible options for transformations and custom code, data source agnostic, efficient processing engine, real time monitoring and solid debug tools, good reuse options (refactoring segments of a process to new projects or flows, etc.) good but flexible governance and good documentation (or strong Google search results).

Data quality, data governance, possibility for advance data transformations in a much more easier manner

Data Quality, Governance, Data profiling, Flexibility and ease of use

Reusability, Flexibility, Data Governance, Data Quality, Connectivity

Easy to use, Easy to manage

Data Quality, Data Volume, Frequency Of Update (Schedule) and Cross Object communication In an overview.

There could other factors as well but primarily I will go to evaluate this.