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 > >
