I wonder what you mean by "POA lacks the higher business organisational
layers"? When you model business processes at the highest level you usually
creates a business process map that contains three types of business
processes:
- Planning och governance processes
- Operational processes
- Support processes (IT, HR, etc)
The map usually contains 25-30 processes, which I think covers all aspects
of the business on the highest level. What am I missing?
// 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, 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
