Even though a business process describes HOW it doesn't mean that you
start by answering that question. When I model a business process I
always start with WHO (who is the customer) and WHAT (what is the
goal/result). The next question is which event(s) initiates the business
process. When those question are answered it is possible to start
describing HOW.
// Dennis Djenfer
Michael Poulin wrote:
Here is a couple steps of my logic about SOA-POA
1. SOA answers questions in the following order: WHAT, WHY, WHO, and HOW
That is SOA includes Target/Purpose, Reason, Resource and Method. SOA
services may be of different granularity and can work together in a
hierarchy or another organisational structure. The latter is the
process; SOA includes POA. Opposite is not true despite services may
be used as realisation of process' actions
2. POA answers the same questions in different order, which results in
different, more difficult and error-prone approach: HOW, WHO, WHAT,
and seldom WHY. That is POA includes Method, Resource, fuzzy
Target/Purpose, and the Reason os usually "because we are doing things
in this way". It is very difficult to re-target and adjust a process
in the context of other processes because they do not require
cohesiveness and common goal sharing.
3. SOA is the means that capable to reflect business organisation in
full. At the top of the enterprise, business is service-oriented by
its nature in the market. SOA capable of reflecting Business at any of
its layers; POA lacks the higher business organisational layers.
Moreover, Business is not organised by processes, it performs,
executes via processes, it implements business services, functions,
and features via processes. At the bottom of business realisation,
processes are the most volatile, volnurable and discardable. I call
them Operational Support Processes and do not include them into POA,
they do not constitute Architecture but its implementation.
- Michael
----- Original Message ----
From: Gervas Douglas <[EMAIL PROTECTED]>
To: [email protected]
Sent: Tuesday, October 7, 2008 11:43:45 AM
Subject: [service-orientated-architecture] Re: POA vs. SOA (was
Linthicum on Metadata & SOA)
--- In service-orientated- architecture@ yahoogroups. com
<mailto:service-orientated-architecture%40yahoogroups.com>, Ashley at
Metamaxim <ashley.mcneile@ ...> wrote:
>
> Dear All
>
> I would like to try and sharpen my understanding of the distinction
> between SOA and POA, if only because some of discussion on this seems to
> be somewhat too metaphysical for my taste.
>
> I take it that everyone will agree that any business has some ordering
> constraints on its activities that are necessary for its operations. For
> instance, a Bank must "perform a credit check" before it "authorises a
> loan" (although, perhaps, some Banks have thrown this one out of
> late!!). Where there is a necessary constraint on the ordering of
> activities such as this, there is *necessary process*.
>
> In any real business though, there is also *contingent process*. This
> means an ordering of activities that reflects an arbitrary decision
> about practice, but has no business necessity. For instance, when I get
> in my car, I always "fasten my seatbelt" before I "start the engine". I
> could equally well do these the other way round.
Thank you for raising this topic, Ashley. The rise of Workflow and
thence BPM (not to mention Business Process Engineering before) seems
to have got some people thinking that every activity in business can
be classified as a process or part thereof. Unfortunately people
often work in what at first sight seems too random and unstructured a
manner to always fit into such neat rigidities. I am not denying the
importance and value of processes or their associated disciplines, but
merely wish to observe that people often draw on IT resources in such
a way that evades easy categorisation. I believe Keith's HIM (human
interaction management) was a significant attempt to apply rigorous
analytical methods to this phenomenon.
This raises the question of how such a methodology fits into a SOA
structure.
Gervas
>
> This leads to two possible interpretations of "SOA vs. POA":
>
> 1. The SOA view of the business is one that abstracts away the process
> view (both *necessary* and *contingent* process). This means that it is
> simply a *view* of the business and says nothing about the way the
> business itself (or its IT) is organised. The POA view, on the other
> hand, is one that focuses on the processes.
>
> 2. An SOA business is one that eliminates, as far as it can, all
> *contingent* process constraints from the way it conducts its
> activities, leaving only the *necessary* constraints. This leads to a
> minimum of "process" in the way the business defines and conducts its
> activities. A POA business, on the other hand, makes no such elimination
> and is therefore much more rigid.
>
> The first definition is just about views or abstractions; whereas the
> second is a "real" distinction in the way a business defines, implements
> and conducts its activities. In particular, the elimination of
> "contingent process" will tend to disentangle activities from their
> contingent process contexts so that they become "services".
>
> I take it that when people advocate "SOA over POA", they are using the
> second definition. Is this correct?
>
> Are there other definitions of the SOA vs. POA distinction, different
> from the two that I have tried to articulate above?
>
> Rgds
> Ashley
>
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.173 / Virus Database: 270.7.6/1712 - Release Date: 2008-10-07 09:41
