My previous post has initiated unusually intensive debates about the nature of business process and unstructured of case adaptive management of business activities. I have found these debates even more interesting than the post itself.
Among others, we discussed a topic of transformation from ACM into BPM and back. Particularly, what types of events can lead to BPM or to ACM as well as how to switch between them.
My final understanding of this transformation may be expressed as the following:
1) An external event requires reaction
2) The reaction 'looks up' for priory existed precedents and analogous and, if it finds a suitable process, the reaction to this event is a business process (BP) with corresponding management. If such process is not found (this does not mean it does not exist), the adaptive cases (AC) with corresponding management is the way to go
3) In the case of BP, the process runs until it completes or until it breaks, we need to react to this event and we return to the point 2), which can end-up with AC
4) In the case of AC, we try to act based on our logic or set of rules and instructions but we do not know what action might be recommended by these rules for each next step, especially in the situations with complex business logic. We try-valuate each next step until we either complete our response to the event or find an existing process that fits with our current AC step. This the latter situation, AC switches to BP and we return to the point 3).
Described is a relatively simple algorithm but it not without a caveat. The question is how effective may or should be our try-valuate search for the next step in the unstructured collection of possible actions? This question reminds me that the same challenge exists in many other spheres of knowledge, i.e. in pattern recognition and in regular project management.
For example, I have found that Alexander Samarin has a wise recommendation on how to proceed with AC actions: "Planning of future actions at runtime is mandatory. Such a planning may comprise several scenarios, may have different horizons (next action only, a few next actions, all further actions, etc.)" OK, planning is good but how to adjust your steps if you do not know what to expect in the next step, in the future, because any plan, especially in the unstructured case, will require some corrections?
I've found the answer to this question in the mathematic theory of approximation. However, instead of 'drying' you with formulas, let me refer to my article "SOA Strategy and Spline Tactics" published almost a year ago. The basic idea of the article is that to properly adjust your current step you have to know the future as much as possible (no magic). So, when you plan a next step, you do it in small steps as far as you feel confident to some degree. Then you do this next step but it is much shorter than you have observed/modelled/analysed with the chain of small steps. For example, you were able to make 9 small steps but you final 'activity' step includes only 5 first small steps. Then you start again with small steps but having some knowledge about the future (the last 4 small steps out of the previous 9 ones). Overall, you 'try' the future until your confidence is reasonable and justifiable but then you do the most confident step forward, and 'try' the future again. You small steps may not necessary repeat your previous small steps because now you know your starting situation much better than before.
The only thing I can tell you now is to wish you a good luck in New Year!
Michael - I like how you are methodically drilling into the structured process / unstructured action divide.
“OK, planning is good but how to adjust your steps if you do not know what to expect in the next step, in the future, because any plan, especially in the unstructured case, will require some corrections?� – that is the multi-million dollar question!
As you said in the prior thread “a process is the least flexible instrument because of its fixed internal logic�. Services of course have this same problem, their implementation is hidden by interface, unless you go with the ‘shared understanding’, which seems to be baked into the ‘Approximation’ approach.
If I get this right, the 'try-valuate' notion implies the system can't definitively calculate a next step (more information required) and 'Approximation' enables a fuzzy trial and error approach.
The spline points are a 'tentative' exercise of trimming a graph until you 'confidently' chain the right service/step and continue forwards. Effectively, Approximation is a subroutine of sorts that allows fuzzy assignment through some 'shared understanding'.
David,
in the math theory of classical spline-functions, the ideal 'behaviour' or approximation of spline is possible only if you know the correct starting and ending conditions, i.e. you know the entire future with regard to any internal point of the spline curve.
Since we do not know this future, we try to extrapolate our behaviour allowing some (limited in value) mistakes in every intermediary point, i.e. some fuzziness (while I do not use a Fuzzy Logic theory in here). When the your behaviour cannot be extended within defined error-limits, you have to stop. This is what I mean by 'try-valuate'. Then I step back to the point where I still make a movement ahead (from my previous point) but have some knowledge about close future already (because I was there a moment ago). Then, I adjust my starting conditions and repeat all exercise again and again.
Getting back to the "calculation by system", in the math pattern recognition, all I described a system does automatically. In real life, it is not that simple to automate in full because still cannot model all influencing factors to consider for the decisions in the intermediary steps and in the major steps. This is why I addressed this article to management practice rather than to a tool or system developers.
Beside this, your understanding is correct.
David,
in the math theory of classical spline-functions, the ideal 'behaviour' or approximation of spline is possible only if you know the correct starting and ending conditions, i.e. you know the entire future with regard to any internal point of the spline curve.
Since we do not know this future, we try to extrapolate our behaviour allowing some (limited in value) mistakes in every intermediary point, i.e. some fuzziness (while I do not use a Fuzzy Logic theory in here). When the your behaviour cannot be extended within defined error-limits, you have to stop. This is what I mean by 'try-valuate'. Then I step back to the point where I still make a movement ahead (from my previous point) but have some knowledge about close future already (because I was there a moment ago). Then, I adjust my starting conditions and repeat all exercise again and again.
Getting back to the "calculation by system", in the math pattern recognition, all I described a system does automatically. In real life, it is not that simple to automate in full because still cannot model all influencing factors to consider for the decisions in the intermediary steps and in the major steps. This is why I addressed this article to management practice rather than to a tool or system developers.
Beside this, your understanding is correct.
Free Porn Download
Backroom Casting
Full Oyun Ä°ndir
Tek Link Oyun Ä°ndir
thanks admin