"Starting the the data" does not necessarily imply "single canonical form". Nor does it imply "data-centric SOA projects". Attempting to define a single canonical data model is an effort in futility. But I agree with Dave that focusing on data is the right place to start. Services are driven by their inputs and outputs. You need to define those data formats and their semantics if you expect to get any use out of your services.
Anne On Wed, Sep 24, 2008 at 10:46 AM, Steve Jones <[EMAIL PROTECTED]> wrote: > AAAarrrrggghhhhh > > This is a stack based view of Data->Service->Process > > From someone who has also "done this once or twice" all I see in > data-centric SOA projects is the creation of a single canonical form, > a great big fragile mess of data that becomes incomprehensibly > unmanagable and has all the agility of a Haahoo. Considering > processes to be the "top" of the stack is also a great way to create > pan enterprise complexity without clear organisational boundaries. > > Data is clearly important but its only important _in context_ which is > what the services should bring. Getting a pan-enterprise view of what > a particular piece of "data" means is practically impossible as you > get multiple meanings and multiple views which in effect means having > no view at all. > > Steve > > 2008/9/23 Gervas Douglas <[EMAIL PROTECTED]>: > >> <<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 >> >> >
