On 13/01/07, Ashley at Metamaxim <[EMAIL PROTECTED]> wrote: > > > > > > > > Steve > > Thanks for your comments. > > > In most organisations I've worked with there is either a controlling party > > who dictates > > 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. > > I think if there is "a controlling party" then you are probably not going to > use the kind of approach I suggest. You need a "script" for the controlling > party. > > However, I would have to ask whether things are organised this way "in most > organisations" because it is the most efficient way of doing things from the > business point of view, or because current approaches make a more > decentralised approach to business processes difficult to achieve?
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. > > > 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? > > I hope you don't think what I am advocating is a "technology implementation > approach" because, whatever else it may be, it is not that! This is a "pure" > modelling technique, at least as "pure" as a domain model class diagram. 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. 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 rather than at the moment we are arguing about tech v tech. > > > 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". > > I agree. The ideas I am proposing are a contribution to the mix and not a > panacea. The question you raise (how to decide which is the right way) is > key. But I guess you have to know what the alternatives are before you > decide how to choose between them. But before you worry about that you have to have a context within which to make that decision. The problem now is that its tech v tech, rather than being business _to_ tech, we need something that works above this level and can put the decisions within a rational context. > > Rgds > Ashley > > >
