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 >
