On 13/01/07, Ashley at Metamaxim <[EMAIL PROTECTED]> wrote: > > > > > > > > Anne > > > An execution plan entails both implicit and explicit definition of state. > > The implicit state refers to where you are in the > > process, and the explicit state refers to the data that the process is > > manipulating. I'm suggesting that a better way to define > > the process is to let the explicit state dictate what should be done next. > > Excellent answer. > > I agree with this view. There is the possibility of embedding the rules that > govern business process (what actions/events are possible, desired and/or > allowed next) in the business objects themselves, using modelling based on > the states of these objects. If this is done, the "orchestration" rules are > distributed (to the objects) and there is no end-to-end business process > definition at all. Instead, business processes are emergent. There is a > paper on this modelling approach at http://www.metamaxim.com/pages/news.htm > (see top entry, dated Dec 2006).
Which works in some scenarios, but not in quite a few business scenarios. In most organisations I've worked with there is either a controlling party who dicates the steps, a co-ordinating party who gets people to do things or the process is based on a routing decision in the last received point, this might be based on information contained but most of the rules are external to that information/object and are based on the service/person that is currently in control of the process. The later group are often quite effectively monitored by processes but are implemented quite often based around business goals. (http://service-architecture.blogspot.com/2007/01/why-sales-isnt-process-driven.html). The big problem I see here is that there is still, in a service architecture, a desire to have process "external" to the concept of services. I'd argue that it would be better to see process as a potential implementation strategy _for_ a service and that distributed services can co-operate to deliver a business goal (BDI style). > > The modelling approach described here is clearly very different from BPEL > and, for that matter, anything in UML. Now there I certainly won't disagree, and there are clearly huge gaps in the current approaches on the business side. But is the solution really to start with a technology implementation approach or to move away from that towards a more abstract modelling approach that helps us to understand the business and then decide on the correct implementation strategy? One size won't fit all but there isn't much effort being put into approaches that help decide the right way, currently there are lots of people proposing their "one way". > > Rgds > Ashley > >
