This is a little vague as to the context. If you are talking about defining data service interfaces, I always recommend looking at consumption expectations - in other words, make the service easy to use. If for example you expect to have a lot of development of custom Web sites accessing customer data, make sure the abstraction makes that development easy, even if you have to provide an interface just for those developers. Remember, you will create a service once (ideally) but consume it many times.
If you are asking this more generally, remember that you can't make things simpler than they really are, and your business is going to change. Core data relationships that exist today will be different in a few years, so plan accordingly. A simple example, five years ago in the cable industry, a "customer" and a "premise" were virtually the same. Today, "customers" are frequently billed for multiple "premises", and this of course broke a lot of systems. As a basic rule, plan for change.
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.