Builder.com writer Brian Schaffner has a great article on 10+ things you should know about service oriented architecture (SOA).  I've read a lot of articles on SOA, but Brian has hit on some important ideas that I don't read in a lot of vendor articles.  For instance he writes that SOA doesn't have to include web services and that jumping to SOA can be difficult.

What got my attention, though, is his item number 7:

#7: SOA requires a keen understanding of business data

Because SOA is focused on business processes, it's important to understand the data that's relevant to those processes. For instance, an ordering process has several key data artifacts, such as the order, the customer, the shipping information, the invoice, the payment, and the receipt. What's even more important is being able to describe these artifacts in a standard way so that each service that participates in the process can understand the data equally.

For organizations with an existing information architecture, this may not be a big issue. However, for large organizations with limited or nonexistent information architecture, this issue can be a show-stopper when it comes to implementation. Because large organizations have such a variety of data, it is usually recommended to take an evolutionary approach to defining the information architecture, as opposed to a big-bang approach. This means that instead of spending four years defining the ultimate data model, it's better to spend a small amount of time during service development to define just the data that's relevant to that service. As each service or process is implemented, the associated information architecture can be evolved to include the necessary data artifacts.

He gets it right - no 4-year projects to define the ultimate data model, and that these models are most valuable when developed incrementally.

Of course, his definition and my definition of "small" are probably different, but I believe he and I are in agreement here.