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
