<<Many SOA projects seem to lack focus on the data, and that's a mistake. After all, it's service-oriented architecture. But the fact is you need to start with the data first, than work up to services, than the agile layer (process, orchestration, or composite). If you follow those basic steps you'll find that the solution is much easier to drive.
The real issue here, best I can tell through my contacts with other practitioners, is that the data in many enterprises is typically not well understood, and there are many barriers in place that get in the way of understanding that data. While some of these are technical, the core issues are around ownership and turf. Thus, SOA architects perhaps understand the data at the structural level but don't have a deep understanding of the core purpose of the data, how it relates to other data, how the data is bound into entities, as well as security issues, integrity issues, and the binding to existing functions or transactions. If you don't understand all that, than you really are not getting the data understood at a level of details good enough for your SOA. Like a bad foundation put down for a house, you'll have trouble later. Trust me. While many SOA architects don't begin with the data, perhaps focussing instead on the processes or services, I think the data is actually the logical place to start as you understand your "as is" moving to the "to be." Seems old school to some, but I've seen a common pattern in that those SOA projects that have a good understanding of the data, and data governance infrastructure, seem to be successful out of the gate. Those that don't, have a tendency to go back to the data at some point, or perhaps damage the value of the project. While I think it's obvious that metadata matters for SOA, many out there are still learning. Just some advice from a guy who's done this once or twice.>> You can read this at: http://weblog.infoworld.com/realworldsoa/archives/2008/09/why_metadata_ma.html?source=NLC-SOA&cgd=2008-09-23 Gervas
