This is where I disagree. You need to know the capabilities and the services first in order to the concern yourself with the data inputs and outputs. I completely agree that the definition of data formats is important and that interfaces should be designed to be consumer, rather than producer, friendly. Dave says below that people are getting it wrong by starting with "services or processes". Maybe a data centric view doesn't lead to Single canonical form, but it has done when I've seen organisations take this approach.
If you aren't starting with the services how can it be service oriented? Surely that would be a Data Oriented Architecture? To know where data is appropriate you have to understand the services and the capabilities. There are certain data reporting elements (post transactional) where unified views make sense and its important to understand those as well, but the important bit is to first understand the services. I'm not saying data isn't important but that a view that says "start with the data, then work up to the services, then the agile layer" implies that services sit between a data view and a process view, something that only makes sense in a technically oriented, rather than business oriented, view of SOA. Data is important and you need to understand it, but starting with it? Steve 2008/9/24 Anne Thomas Manes <[EMAIL PROTECTED]>: > "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 >>> >>> >> >
