I've got a method ;) I start with WHAT (the service)
then WHO (consumers and drivers) then WHY (event, justification, motivation, etc) only then do I worry at all about how. Steve 2008/10/7 Dennis Djenfer <[EMAIL PROTECTED]>: > 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, 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 > > > >
