There aren't any direct constraints around having a process oriented business architecture and then implementing in a service oriented way. if you are using high level business process definitions (such as having a "Shop" process for a retailer or "Fly" for an airline) then you are really talking about similar things. Its when you get into the "step" based processes (A follows B, if D then C else E) that I'd argue that you have ceased to be SO and are instead PO.
I would argue as well that a process oriented business view isn't a good idea anyway (http://service-architecture.blogspot.com/2008/03/networked-economies-require-services.html) as the shift towards value networks (over value chains) means looking more at interactions and collaborations than a process view really allows. So yup you can do a Process Oriented Business Architecture and then implement using SOA. Part of the question though is whether that is the most sensible approach. Steve 2008/10/4 Dennis Djenfer <[EMAIL PROTECTED]>: > > > Michael Poulin wrote: > > Stanimir and Denni, > though I used to say that service and process are interchangeable, I have > to admit - I did a compromise, and have to support Steve in this discussion. > > At the level of enterprise business model, there are only business services > and, depending on their granularity, different processes can appear between > services if needed. For example, if Accounting Service is split into > Receivable, Payable, and General Ledger, they may interact in one process; > if Receivable Payable are joined, it is another process between the join and > General Ledger. > > A business architecture that uses a service oriented style would look like > that. I maintain that a service oriented business architecture is not a > pre-requisite for a service oriented application architecture (i.e an > application portfolio + a service portfolio) and a service oriented > technical architecture. > > I'm not arguing about which approach is the best (should the business > architecture be modeled in a service oriented way or not), I'm just saying > that I'm not finding any constraint in SOA RM that makes it impossible to > use a process oriented view in your business architecture and a service > oriented view in (or parts of) your application architecture and your > technical architecture. If there are any such constraints, I would > appreciate any pointers. > > // Dennis Djenfer > > > That is, service goes first, process goes second. > > - Michael > P.S. Stanimir, may I ask what 'stani' stands for? > ----- Original Message ---- > From: Dennis Djenfer <[EMAIL PROTECTED]> > To: [email protected] > Sent: Monday, September 29, 2008 9:57:37 PM > Subject: Re: [service-orientated-architecture] Re: Linthicum on Metadata & > SOA > > A service could be a container for a process, or a process could use a > service, or a service could be used by an application, or a service could be > a container for business object, or something else. I don't see where the > constraints are that says a service should have a certain scope or be > modeled in a certain way. Sure, we can argue about which modeling approach > is the best, but isn't it still a service oriented architecture if we are > able to map our architecture to the concepts in the SOA-RM? > > // Dennis Djenfer > > > Steve Jones wrote: > > 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 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 > > > > > > > > > ------------ --------- --------- ------ > > Yahoo! Groups Links > > > > ________________________________ > > No virus found in this incoming message. > Checked by AVG - http://www.avg. com > Version: 8.0.173 / Virus Database: 270.7.5/1697 - Release Date: 2008-09-29 > 07:40 > > > > ________________________________ > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > > Version: 8.0.173 / Virus Database: 270.7.5/1704 - Release Date: 10/2/2008 > 9:35 PM > > > >
