My answer has very little to do with either technology specifically. If you want to avoid data integration headaches, you have to be consistent, meaning that every developer has to do things in a similar way, rather than defining their own set of data representations. To do this requires a process that is:
A) very easy for developers to useand
B) very quickly gives developers consistent representations
A simple example: if developer A and developer B both need to share information about user accounts, and one uses a variable length text field and one uses a fixed-length numeric field, you have created needless inconsistency, through the lack of a clearly defined process.
Taking this one step further, if your clearly defined process has future flexibility baked in, for example by making it possible for some future program to process today's N-digit account codes as well as tomorrow's N+M-digit account codes, you can carry that flexibility along into the specific implementation.
Dig Deeper on Topics Archive
Related Q&A from Larry Fulton
Data services expert Larry Fulton discusses what happens when a business has multiple sets of data representations and how to go about narrowing them... Continue Reading
Larry Fulton discusses how it is inevitable that access to the many data related capabilities emerging in support of SOA be equally accessible via an... Continue Reading
Larry Fulton discusses some possible data services headaches that may occur when implementing SOA in a business and how to go about handling them. Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.