On 14/01/07, Ashley at Metamaxim <[EMAIL PROTECTED]> wrote: > > > > > > > > Steve > > > I'm talking not just about IT enabled processes but actual _business_ > > processes. Taking an extreme scenario look at the Army. The person > > in control gives a set of orders which the sub-ordinates follow to the > > letter. This is centralised control of process, other examples would > > be film directors, rescue services and many others. Also included > > would be any process where the process is "when you finish that step > > come and ask me what to do next". > > What I'm saying is that there are real business processes that are > > centralised via a controlling party. > > I agree. But I think that, even in these cases, if "what needs to happen > next" is primarily determined by the states of underlying objects, the type > of modelling in the paper is appropriate. If you add a "business process" on > top, with its own sequencing of events, you can run the risk of constraining > the flow of events in the business in an arbitrary and unnecessary way.
What would you describe as the "objects" in a military scenario who state determines the next step? I'd have a similar questions in other scenarios (e.g. American Footbal coaching with its fixed plays called from the side lines). > > Though I doubt whether this argument would be enough to convince the Army to > change its ways :-) Indeed, and I'd say that in fact this is a good reason why in fact the object modelled approach isn't viable in this sort of scenario. Controlled action is sometimes required, this requires very specific modelling and messaging approaches and very strict compliance procedures. This isn't something that is needed all the time but my point was that one size doesn't fit all. > > > Which for me is actually technology because its assumed that the > > solution is technology implementation. There needs to be design > > (hopefully!) but the assumption is that technology implementation is > > the end goal. > > I think you may be making the assumption that the models are models of a > computerised solution. They are not -- they are just models of the business, > and the rules and policies of the business. The fact that they are > executable is a by-product of the fact that they are formalised and have > behavioural semantics, but there is no implication or requirement that the > actual business solution be computerised. Fair enough then I mis-read it, but the paper is extremely technical in nature, and you did say its as technical as a "class diagram" (which IMO is technical). The key question therefore is what real business scenario would this work for, and to answer this you need something that works at a higher level of abstraction. > > I think that the key consideration before this kind of modelling is > undertaken is whether the degree of formalisation of the business entailed > is possible, appropriate and useful. I think that sometimes you can only > find out by trying. The problem with IT however is that we don't appear to have other ways! :) I like the models where the object are actually active participants in the process, but I think its going to be relatively limited in its application. > > > What I'd argue is that the paper you've written needs > > to be set in a wider context that selects the right technology > > implementation approach > > I don't have any problem with that. > > Rgds > Ashley > >
