You won't be doing Service-Oriented Architecture (SOA) for long before you encounter the concept of a Canonical Data Model (CDM). The idea is that you analyse your business processes, and derive a set of standard data types that you model using XML schema and use in your services - the Canonical Data Model. Perhaps you go one step further and bring in an industry model like IBM's IFW and use that as a starting point.
In the real world however, there is an estate of legacy systems that will tend to have a narrower view of data types than that proposed by the CDM. Some will only be interested in a particular aspect of the CDM types, some subset of the attributes, whereas others will have a different view completely. The issue is that there are different ways to model things.
The CDM approach assumes that all systems' data is mappable to the CDM types, so through CDM all systems will be able to communicate with each other through your SOA. Of course some optionality will need to be built in since not all systems will have the CDM data attributes.
Anything that is not in the CDM is not deemed of enterprise interest. Those quirkly little data attributes that exist in system X are not in the CDM because they are not of interest to anyone else. If they become of interest, then of course the CDM will need to be changed and this is where your optionality/extensibility model is key. You want to be able to add the quirkly little attribute without breaking the rest of your enterprise.
CDMs need to have room for minor change and growth, but it is assumed that anything more fundamental would not be required because the CDM models the company's business processes which are stable in theory.
And of course agile too, which feels a bit oxymoronic, but what do I know? :)