For those of you that have been following me know that I'm very much an advocate of SOA. The architectural pattern of SOA is helpful in defining an enterprise architecture that much more agile, and thus pays for itself once the business has to shift and needs IT to follow.
SOA, however, is complex and requires that the architect understand all aspects of the "as is" architecture before moving to the "to be." This means decomposing the existing architecture down to a primitive state, and rebuilding it up again at sets of services, with a process configuration or composite applications layer to define and redefine business functions. I think most get that.
What's missing within most typical SOA projects is the focus on the data, and that is killing SOA. Since the "S" in SOA, means service, most architects focus on the service definition, abstracting the existing data into collections of services, but don't pay much attention to the data within the architecture. Not good.
The truth is that the foundation of a healthy and functional SOA is the data, and you have to deal with the underlying data first, understand it, perhaps reorganize and abstract it, before defining the services that will sit on top of the data. While this is architecture 101, the fact is that those driving SOAs these days have little understanding of the importance of understanding and defining the data, and thus the architecture ends up being a bunch of well defined services that sit on top of very dysfunctional data. The end result is performance issues, data integrity issues, and even the lack of agility which is why you build SOAs in the first place.
The truth is that most failed SOA projects can be traced to the lack of a data level understanding, and while this is still an issue in this day and time is beyond me. There are many technology and tools out there to assist you, and we've been doing data for a long long time. Nothing new here, just data. However, if you ignore it your SOA will be still born.