Nope, but a capability on a service can be implemented via a business process.
Service is the container, process is the mechanism. Steve 2008/9/29 nibeck <[EMAIL PROTECTED]>: > Steve, in this context, how do you differentiate a Process form a > Service? Doesn't a service usually have a matching business process? > > _mike > > --- In [email protected], "Steve Jones" > <[EMAIL PROTECTED]> wrote: >> >> 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" >> > <jones.steveg@> 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 >> > >> > >> > >> > >> > >
