A Minimum Shopping List for Data Integration, Data Services

Loraine Lawson
Slide Show

Top Ten Best Practices for Data Integration

Use these guidelines to help you achieve more modern, high-value and diverse uses of DI tools and techniques.

For all the talk about buying a data integration platform-as opposed to hand-coding or using data services-there's precious little vendor-neutral guidance out there for what you need to look for when you're doing either of those things.


Calla Knopman recently stepped up to fill in the void in a lengthy article-part of a series, actually-on Beye Network. Knopman is the managing member/founder of Knopman IT Consulting and has an impressive resume with 15 years of experience in various integration and data-related services. While she promises a vendor-agnostic look at the topic-and I absolutely think she delivers-I should note that she did work for IBM and VIP.


The focus is on what you need to do to support data services, but I think it's also a great primer for buying a data integration solution-especially if you're investing or interested in a service-oriented architecture. After all, data services are an extension of the same concept, except applied to the data as opposed to application services.


There are two things that are great about this article. First, she provides a shopping list of functions a data integration solution should support-at a minimum. Knopman's list includes:

  • SOA compliance
  • Metadata management
  • Support for industry standards, such as SOAP, WSDL, JAVA and XML
  • Ability to deliver data in real time and batch
  • Ability to handle structured, unstructured and semi-structured data
  • Support for publishing/subscribing and using Web services


There are other considerations she lists as well, but I'll let you read the full article for those. You get the general idea. She also warns that not all tools support these basics, even though they may market themselves as data integration solutions.


Second, she explains the foundational approaches to data integration options: ETL (extract, transform and load), EII (enterprise information integration), or EAI (enterprise application integration) and EDR (enterprise data replication), and how these approaches support data services. That should be helpful to IT leaders who can see how their existing tools fit into the overall picture. And, it makes the article more accessible to a broader, non-IT audience; although, she put that at the end of the article, so you'll have to make it that far first.


Another nice thing about this article is that she discusses some of the business problems you can tackle with a good data integration tool, which should point you in the right direction if you're making a business case for investing in a solution.


But be forewarned: You're probably going to need more than one tool to handle all the demands enterprises have for managing data these days. She warns:

Essentially, the correct data integration tools should be capable of transforming, migrating, consolidating, synchronizing and otherwise moving data through the enterprise. To be realistic, no single tool will handle each and every nuance of these complex projects, but it should provide the backbone to support them and reduce the implementation time by providing the communication protocols and synchronization processes.

Still, you've got to start somewhere and this first piece in the series goes a long way in pointing you in the right direction.

Add Comment      Leave a comment on this blog post

Post a comment





(Maximum characters: 1200). You have 1200 characters left.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.