To _mike: Why a services has to have a matching business process? If it is a business service, why it needs a business process? Why a service does not include a business process as its implementation but only has to match it externally?
- Michael ----- Original Message ---- From: nibeck <[EMAIL PROTECTED]> To: [email protected] Sent: Monday, September 29, 2008 5:53:46 PM Subject: [service-orientated-architecture] Re: Linthicum on Metadata & SOA 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 service-orientated- architecture@ yahoogroups. com, "Steve Jones" <jones.steveg@ ...> 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 service-orientated- architecture@ yahoogroups. com, "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 > > > > > > > > >
