Modern SOA infrastructure is analogous to our global telecommunications infrastructure. These days, just about everybody (my teenage daughter included) has a cell phone that they can use to connect to someone in Berlin, Bangkok or Beijing. The infrastructure is highly reliable, interoperable, and easy to use. However, unless the individual placing the call can speak German, Thai or Mandarin, they won’t be able to communicate with the person on the other end of the line.
Systems in an SOA have a similar challenge. They may be able to connect using highly reliable and standards-based infrastructure, but that doesn’t mean that they can communicate. They have connectivity interoperability, but they don’t have data interoperability. And without data interoperability, your applications and services are not communicating.
SOA is being widely adopted as a means for getting heterogeneous systems to interact and the appeal is obvious. SOA promises productivity through reuse and the adoption of standards for interfaces between systems such as WSDL, XML, etc. It promises a central point of visibility for governance where all business processes can be managed through a common set of infrastructure components. Perhaps best of all, it promises agility in that systems can be changed at a much lower cost because of the use of standard interfaces.
SOA What? For all the significant benefits cited above, the promise of SOA comes up short because it is focused on connecting systems together but does not address the challenges of data interoperability. For that, one needs to look past the promise of SOA to the practical concern of communicating using a data interoperability layer. Use a common model to facilitate communication and now you're really talking.