We need to look at the corporation functioning atomically, as a whole, and the improvement journey needs to consider business and technology evolution.
To work in a process-driven way is to achieve goals by using processes. By using processes, the organization teams can replicate the defined steps and frequently accomplish the expected results. The results of the execution are monitored, and improvements can be applied and quantified. Quick guidance for process-driven work would be:
- Identify problems and goals to solve and reach;
- Define or choose appropriate processes to achieve your goal;
- Execute and continuously improve the defined process to achieve better results;
The use of this strategy has been proved prosperous. A famous example is Toyota, one a famous manufacturer which was guided by fourteen principles they named the “Toyota Way.” Their process enabled Toyota factories all over the world to consistently produce cars with fewer defects, using fewer staff-hours and half the floor space when compared to their competitors.
Why is this an effective strategy? Because the delivery evolves and self-enforce its effectiveness, achieving better results over time
Process-Driven Applications
Now, let’s apply the presented concepts on a technical problem-solving. Architecting a process-driven application means designing applications which are business oriented in every way: since the design on of models, flows, rules, services, and integrations until the front-end omnichannel definitions. Means creating an application which not only application developers will be able to understand and contribute, but also, business analysts who control the core business logic which guides the application. To do this, traditional coding using IDEs like Eclipse or IntelliJ won’t be enough.
Process driven culture used on software design naturally brings the business experts closer to the technical team. It is a must-have item to practice BizDevOps.
Getting started
Here are some actions you can follow as guidance to start implementing this software design. To facilitate the understanding, from now on, we will refer to the decoupled process or rules services as knowledge services.
Culture: Team members, including the biz side, should absorb and live the culture and philosophy of BizDevOps. By doing this, a good relationship between the team grows, which improves communication and workflow.
- Present the BizDevOps culture to the technical team, business analysts and business experts;
- Instead of including solely business analysts, also consider adding software architects and business automation specialists into business requirements meetings;
- Make sure to instruct the Biz Team to involve appropriate business experts to implement or validate the implementation of business processes and rules;
Software Design: Along with other architecting decisions, here are some tips regarding the usage of process-driven apps approach:
- Identify and plan the implementation of decouple services to handle the business process and rules execution;
- If not explicitly by the biz experts in prior, during the software design phase, try to identify repetitive human tasks which may include system integrations in between them. They could be part of a business flow that can work independently as a service;
- Choose an appropriate Business Automation tool. Use the same communication language across services in the same business boundary;
- Use terms which biz team is familiar with and also, make sure the tech team also understands them;
- Plan the integration strategy used in between different services and the process and rules service (engine);
- Define the communication between client services and the knowledge services: What data is necessary to start a process? What is the required information to be validated by this set of rules? What is the expected output of the processing? Try to define along with biz team the volumetry of the defined processes and rules so that the Ops team can appropriately plan and build a stable execution environment for the knowledge services.
Executable Processes Design: The business automation group is responsible for implementing real executable processes and rules using modeling and notation specifications.
- The processes delivered by biz team are not necessarily executable;
- Use advanced process modeling to improve execution performance;
- Get better knowledge of the business automation runtime to select the appropriate configuration for each set of processes and rules (Synchronized execution? Does this design support a clustered environment? Should the information span across all the process lifecycle or is it enough to exist during request time only?);
- Use on the rules models and process design, the same terms, language, names, used on additional services. This action promotes understandability;
- It is possible to validate the implementation with the business team even if the boundary services and front-end are not finished at the end of a cycle. Different from traditional code, in this approach, biz people can validate the “source”(designed) asset implemented following microservices characteristics, we must organize the software design around business capabilities.
This blog post is part of the second section of the jBPM Getting started series: Digital Transformation Journey.
Keep Kalm 