I again with Stive on that a "process oriented business view isn't
a good idea anyway".
Let me turn the discussion from the "may use PDA or SOA", together
or separately into another line of questions: which one to use -
service- or process-centric approach - and what for.
In my research, I have found that at the top of the enterprise, the
business is service-oriented. The deeper into the realisation the
business gets, the more it becomes process-oriented and operational.
At the point of meeting with Technology, business representatives do
not remember any more that the business is service-oriented and push
Technology into the process-oriented world. This totally masquerades
real business tasks, services, functions and features by volatile
and disposable operations and sequential business activities that
not even visible at the top business level. This also misdirects the
IT from the real business problems and needs leaving it to create XP
and Agile techniques just to keep up with constantly replacing
operations and sequential business activities.
From another hand, if Technology capabilities would be applied to
the business services, functions, and features, defined in the
enterprise or LOB business model, and some high level business
processes running between business services, functions, and
features, then IT can finally serve the Enterprise instead of
Business people and contribute to the Enterprise business goals much
more effectively than today. IT has to target reasoning (WHAT, WHY,
WHO) in the business instead of current operational activities (HOW)
that may be simply replaced by the automated solutions such as a
Straight Through Process - STP - in the finance.
- Michael
----- Original Message ----
From: Steve Jones <[EMAIL PROTECTED]>
To: [email protected]
Sent: Monday, October 6, 2008 8:58:16 AM
Subject: Re: [service-orientated-architecture] Re: Linthicum on
Metadata & SOA
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] se>:
>
>
> 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] se>
> To: service-orientated- architecture@ yahoogroups. com
> 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
>
>
>
>
none; } #ygrp-sponsor .ad a:hover{ text-decoration:
underline; } #ygrp-sponsor .ad p{ margin: 0; } o{font-size:
0; } .MsoNormal{ margin: 0 0 0 0; } #ygrp-text tt{ font-size:
120%; } blockquote{margin: 0 0 0 4px;} .replbq{margin:4} --> End
group email -->
