Blogged on it http://service-architecture.blogspot.com/2008/09/doa-your-soa.html
Steve 2008/9/25 Steve Jones <[EMAIL PROTECTED]>: > I don't think Rob is arguing that point. You can start an SOA by > identifying service in many different ways, the only really important > bit is that your goal is the identification of services. If you are > trying to identify processes first, and then identify services that > map to activities on the process then you are dong POA (IMO), if you > are starting by identifying all the data and then identifying the > services that you want to manage the data then you are doing DOA > (IMO). > > Steve > > > 2008/9/25 Dennis Djenfer <[EMAIL PROTECTED]>: >> Which constraint of the Service Oriented Architecture Style says that you >> need to identify your services in a specific way? Why can't you start the >> identification of services with processes? or business entities? or legacy >> systems? or business functions? or something else? >> >> // Dennis Djenfer >> >> >> Rob Eamon wrote: >> >> +1. >> >> Starting with data is a data/object-oriented approach, not an SO >> approach. Data is important most certainly, but in SO the service is >> king and that's where one should start. The inputs/outputs are driven >> by desired capabilities of the service, not the other way around. >> Identify the services first, then define the data formats and >> semantics. >> >> Haven't we had several "data first" approaches in the past? SQL was >> going to be the savior of the data-starved business person. OO (data >> with behavior) was finally going to deliver the agility craved by >> enterprises. Integration still predominantly focuses on replicating >> data. >> >> The desire for data first is understandable I suppose. We have a long >> history of "I just need that customer data" or "we need to send the >> order data over to system X". This is still the >> predominant "requirement" for most IT projects it seems. "Get that >> data from there over to there." >> >> But SO is supposed to be different. There is data involved but the >> focus isn't on just moving it around. The focus is on "what do you >> need to do?" In an SO approach, the answer cannot be "I need to get >> the customer data." Data access is not a "capability." >> >> An SO approach will redirect such "requirements": >> >> A: "We need the customer data from system X." >> >> B: "Okay, what are you going to do with it? What led you to the >> conclusion that you need customer data from system X?" >> >> A: "Well we're doing this marketing campaign. We're sending direct >> mailers to customers matching various demographics. We need system X >> customer data to do that." >> >> IMO, even when folks say that they need access to data, they will >> have started out with some "service", action or capability in mind. >> They want to do something. They don't want the data just because it's >> there. >> >> IMO, a data first approach undermines SO rather than promotes. >> >> -Rob >> >> --- In [email protected], "Steve Jones" >> <[EMAIL PROTECTED]> wrote: >> >> >> 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 >> >> >> ------------------------------------ >> >> Yahoo! Groups Links >> >> >> >> ________________________________ >> >> No virus found in this incoming message. >> Checked by AVG - http://www.avg.com >> Version: 8.0.169 / Virus Database: 270.7.2/1689 - Release Date: 9/24/2008 >> 6:51 PM >> >> >> >> >
