There is a lot to be said for breaking up a hard problem into specific aspects of the problem, developing a solution for each aspect, and then merging the results back together for a complete solution... but this approach can lead to peril if those who are working on the individual aspects forget (or are ignorant about) what the "holistic" problem is that they're working to solve.
Unfortunately the tools that we use sometimes distract us from the "holistic" problems that we're trying to solve. We've got great tools for detecting and reacting to business events, great tools for defining and executing business rules, and great tools for defining and managing business processes... but when dealing with problems that involve events, rules, and processes we often find ourselves confused by the overlapping features of our tools. In a pinch, we can build a Process with our Rules tool, or a Rule with our Process tool... and either tool can consume and generate Events. Knowing what to build with which tool can be quite a challenge.
Detect, Decide, Process...
Most business problems begin with an event of some sort. Something happens. Something changes. The business needs to respond. Rules govern the businesses response to the event... Processes guide the response when it's non-trivial. Everything's connected.
Events may occur "out of the blue", or they may be generated by a running Process, or they may be generated in response to evaluating Rules.
Rules may be evaluated "on demand", in response to an "out of the blue" Event, or they may be evaluated as a step within a Process.
Processes may be launched in response to an Event, or as the outcome of a Rule. Process flow may wait for or be altered by Events. Rules may determine Process flow or they may "kick off" a Process.
Development methodologies also come into play... I am a Process Bigot, so I employ a Process Driven methodology to arrive at a solution. Many of my colleagues are Rules Bigots and attack every problem using a Rules Driven methodology. The Business Event folks just laugh at us and follow their own methodologies.
Not a topic for the faint of heart ;-)
Those of us who build business solutions for a living eventually make sense out of all of this overlap in our tools... but I suspect that our business clients just shake their heads and trust us to use the right tools for the right jobs. Explaining our rationale for implementing some Rules in our BPM suite and some Process in our BRM suite leaves them with a queasy feeling in their stomachs and insures that they'll never ever try to build a non-trivial solution on their own.
Fear to "build it themselves" may be a good thing for short term consulting revenue, but it's very bad for everyone in the long run. We've got to make things simpler (at least conceptually) or we'll never make a real dent in solving all of the business problems out there that need solving.
Unfortunately the tools that we use sometimes distract us from the "holistic" problems that we're trying to solve. We've got great tools for detecting and reacting to business events, great tools for defining and executing business rules, and great tools for defining and managing business processes... but when dealing with problems that involve events, rules, and processes we often find ourselves confused by the overlapping features of our tools. In a pinch, we can build a Process with our Rules tool, or a Rule with our Process tool... and either tool can consume and generate Events. Knowing what to build with which tool can be quite a challenge.
Detect, Decide, Process...
Most business problems begin with an event of some sort. Something happens. Something changes. The business needs to respond. Rules govern the businesses response to the event... Processes guide the response when it's non-trivial. Everything's connected.
Events may occur "out of the blue", or they may be generated by a running Process, or they may be generated in response to evaluating Rules.
Rules may be evaluated "on demand", in response to an "out of the blue" Event, or they may be evaluated as a step within a Process.
Processes may be launched in response to an Event, or as the outcome of a Rule. Process flow may wait for or be altered by Events. Rules may determine Process flow or they may "kick off" a Process.
Development methodologies also come into play... I am a Process Bigot, so I employ a Process Driven methodology to arrive at a solution. Many of my colleagues are Rules Bigots and attack every problem using a Rules Driven methodology. The Business Event folks just laugh at us and follow their own methodologies.
Not a topic for the faint of heart ;-)
Those of us who build business solutions for a living eventually make sense out of all of this overlap in our tools... but I suspect that our business clients just shake their heads and trust us to use the right tools for the right jobs. Explaining our rationale for implementing some Rules in our BPM suite and some Process in our BRM suite leaves them with a queasy feeling in their stomachs and insures that they'll never ever try to build a non-trivial solution on their own.
Fear to "build it themselves" may be a good thing for short term consulting revenue, but it's very bad for everyone in the long run. We've got to make things simpler (at least conceptually) or we'll never make a real dent in solving all of the business problems out there that need solving.
No comments:
Post a Comment