We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

                        Business Ecology Initiative & Service-Oriented Solution

                        Michael Poulin

                        A Subject of a Business Process Modelling

                        Vote 0 Votes

                        We are familiar with an input and the outcome of a Business Process, some people include actions/activities into a Business Process, which I disagree with, but what is the subject?

                        Merriam-Webster dictionary defines a term "subject" as "a person or thing that is being dealt with in a particular way"; Wikipedia recognises many different domains where a subject has a slightly different meaning but, in general, it is "any topic currently under consideration".

                        Thus, what we deal with or what is the major topic (s) under consideration when we model a Business Process? Input? - No. People or process worker? -No. Actions/activities/suppliers/sub-processes? - No. Triggers? - No. Outcome? - Yes. Consumers? - Yes. Process Business Logic? - Yes.

                        So, before we are starting to model a Business Process, we have to set/find/understand three things: 1) the category(ies) of the future consumers; 2) the outcome these consumers need; 3) the Business Execution Context, which is a set of laws, business regulations and rules, influencing factors such as consumer and process worker habits and culture, and some other society rules. However, when these three things are decided, we do not deal with them anymore; they become our criteria of modelling. The only one candidate remains - it is a Process Business Logic.

                        A Process Business Logic is a very special characteristic - it is the only one that allows to distinguish one process from another. All other characteristics may be used in or shared by several processes and only process logic is unique. As a consequence of this uniqueness, there is no such thing as a modified/changed/improved process. If we change a process business logic, we create a new Business Process. If we change any process' characteristic but business logic, we will not be able to differentiate this 'changed' process from the original one in any other ways than via the process business logic; since the process logic has not been changed, we still have the same process. If we need to improve a process, we have to replace it with more efficient/sufficient. However, if we want to change the outcome, we can change the process' intermediary values and, if the process logic permits this, the outcome might change.

                        In common practice, when a modeller works on a Business Process, s/he has to spend a lot of attention on actions/activities, process workers, action dependencies, sub-processes and so on. The subject of the Business Process modelling automatically shifts into the secondary role. This is the problem because it leads to an erroneous process.

                        Here is a real world example. If you are familiar with the Internet banking of a British bank Lloyds, and if you are not, let me tell you, the bank offers its on-line consumers an ability to make payments from their accounts to the external entities. The payment may be set in two ways: "as soon as possible" and "scheduled in the future". With "as soon as possible", the bank decides when to execute the payment; usually it is the next work day. However, a process feature "scheduled in the future" is trickier.

                        The process modeller at the bank has not probably considered that "scheduled in the future" is not 100% under the bank's control anymore; it is under the control shared with the consumer as well because the consumer decides when to pay and... can/may change the mind. Yes, s/he can change the mind but cannot undo the scheduled payment (I am not even talking about correcting the payment date or target if something happen on the consumer's side before the payment date). Believe it or not, nobody in the bank can do this. Why? Because the process modeller was not concentrating on the process logic and its internal inter-step dependencies; the modeller did not consider aforementioned simple logical scenario. The uncontrolled consumer was excluded from the logic while the modeller started to address other, secondary characteristics of the process model.

                        Ideally, a process modeller has to model four things only: an input interface, an event/trigger receiver, a process business logic and a set of interfaces for obtaining intermediary business values. Everything else is a detail of the process implementation. We do not need a modeller for this; we need a development and operational managers to organise process implementation and execution. Particularly, if we finally understand that the order/logic of activities has its own exclusive value that no collections of actions can provide, when we will be able to separate the business process from the suppliers of the process' intermediary values. From the viewpoint of the process business logic, a concrete worker, supplier or a sub-process does not matter - they are replaceable behind the process interfaces; the only requirement for them is to preserve their SLA.

                        Thus, an outcome, consumer, execution context and process business logic are elements of the Subject of Business Process. A modeller of a Business Process should deal with these elements first of all and additionally work on the process triggers receivers and interfaces to the surrounding environment; everything else is not modelling but realisations and has to be taken care of by appropriate specialists.



                        Website counter

                        Leave a comment

                        In this blog, Michael Poulin writes about business and technology ideas, concepts, methodologies and solutions leading to service-oriented enterprise, the primary instrument for obtaining business objectives in fast-changing environments.

                        Michael Poulin

                        Michael Poulin is an enterprise-level solution architect working in the financial industry in the U.K. and the United States.

                        He specializes in building bridges between business needs and technology capabilities with emphasis on business and technical efficiency, scalability, robustness and manageability. He writes about service orientation, application security and use of modern technologies for solving business problems. He contributes to OASIS SOA standards as an independent member and is listed in the the international "Who's Who of Information Technology" for 2001. View more


                         Subscribe in a reader

                        Recently Commented On


                        Monthly Archives



                                              Buy a car

                                              Application Essentials



                                              Variety show



                                              Real estate