Synchronization and asynchrony of processes

    The world can learn a lot from programmers. He is already learning, but not in the wrong way. For example, I took processes and algorithms, but did not notice such an approach as asynchrony.

    Any programmer understands what synchronism and asynchrony are. That's how much this is understood by the programmer, so it is incomprehensible to ordinary process developers.

    Synchronous actions of a process are those that are executed in the main thread, within one process instance. The key difference between synchronous mode: the next action starts only when the previous one is completed. Accordingly, until one action is completed, the process is stake.

    Asynchronous actions are those that run in parallel with the main thread, either in the same process instance or in another process altogether. The key difference between asynchronous mode: parallel execution of two or more branches of the process.

    Synchronous processes, like programs, are much easier to write and debug, so this approach to process design is very common. There is a lot to do with asynchrony, especially with the designation of points of transition to parallel execution and return back to the mainstream. There are no promises in life.

    For example, the same procurement process on request. It is drawn as a standard sequence of actions: a request has appeared, the supplier selects the supplier, requests the terms and cost, agrees with the seller or the internal control department, forms an order with the supplier, requests the counterparty’s assessment in the legal department or in the accounting department, creates an application for payment, waits for this payment, monitors the order, then organizes or tracks the posting in the warehouse, so that, in the end, close the application. The process is completely synchronized.

    Now imagine - in our information system, the service of evaluating suppliers is not connected. So, the legal department needs to collect information from open sources. This means that the assessment takes time. Given the queue of applications to lawyers, three days will pass.

    What will happen to the process at this time? According to synchronous logic, it will stand stake. The supplier, being a true element of the system, will not move a finger until he receives the supplier’s assessment - especially if sanctions are provided for working with unverified counterparties.

    Can we add asynchrony here? Of course. At that moment, when the supplier chose the supplier, he can send an application for the evaluation of the counterparty to the legal department, and while he will negotiate, agree on prices and terms. By the time he is ready to place an order, and the evaluation will arrive in time. The process will end earlier three days.

    Of course, lawyers can be outraged - what will we evaluate the supplier for, if you have not clearly decided there yet, will you order it from him? What should they answer?

    The solution suggests itself, we have already indicated it above - to connect the supplier assessment service. Now we even better understand why it is needed - to give asynchrony and speed up the process. Although, the service will probably be just synchronous. What do you think?

    If the service is not connected, then this assessment can be justified by the work of "future use". If your information system has a place to record the assessment data, then the next time you need to work with this supplier, you no longer have to contact the legal department. Of course, an assessment has an expiration date, but it can be used within certain reasonable limits.

    In asynchrony, the absence of guarantees is usually scary, that is, the risk of a negative result in one of the parallel branches of the process. What if reconciliation fails?

    Here you need statistics. If you are working with an existing process, then approximately, or accurately, imagine how often certain actions end negatively - for example, coordination. It is from this probability that one should proceed by starting parallel execution.

    Asynchrony directly begs for all coordination processes. If you work there only in synchronous mode, and even follow the lead of the coordinators, then long, interdependent chains are built up, generating bureaucracy and mutual responsibility.

    A typical example: "I will agree only after he agrees." Or "I will look at this contract only after the financiers." Although, according to statistics and common sense, such statements are not justified, and are only a way to shift responsibility.

    The main thing here is not to worry, and not to tackle everything at once. Try to select asynchronous mode first one branch of coordination. It may be necessary to revise the task, the coordination parameters - so as to eliminate interdependence.

    For example, let the finance department, standing in the contract approval chain, look only at the terms of payment. Let him have his own clear assessment criteria. It is better if they are formalized in the form of a model contract - for example, 100% postpay for suppliers, 100% prepayment for buyers. In this case, contracts that meet the criteria will slip at a time. And financiers will have no reason to wait for an assessment from the same lawyers.

    The only thing that is important: asynchronous processes are very difficult to implement without automation. If processes, their execution and tracking are implemented only on paper, then adding parallel branches will turn them into chaos. Need automation.

    The principle of "Auto Task" is best suited for such automation. Although, you can get by with the standard means of drawing processes that are in modern platforms, you only have to tinker.

    Standard "drawing" of processes will require you to identify the entire process, all branches and relationships. If the process is complex and long, then you will encounter a problem - it will simply cease to fit on the screen, in width. If you studied at the institute as a programmer, then remember this rule for designing algorithms: no more than three parallel vertical branches. The rule was not just invented - if there are more branches, it will be problematic to understand the algorithm scheme.

    Auto-tasks eliminate this problem - there is no image of the process at all, because there is no such entity - a process. There are tasks. If you really want to, you can assemble a process from them. But not the other way around. A kind of deductive method of drawing processes.

    In addition to asynchrony, there is an even more powerful optimization method - process buffering. About him - another time.

    Also popular now: