Expertise
Services
;)
In the previous article, we highlighted the most important points that you have to take into account when you choose standalone BPM solution for your project: “8 Complexities of Choosing BPM Software”.
Today's article will be extremely useful for those who didn’t find a satisfying BPM solution on the market and looking for alternative ways to solve the problem. That’s why I want to share with you some hands-on experience with BPM or Workflow management software development.
Before we start, I would like to introduce the most important terms and definitions that we will frequently use further.
BPMN (Business Process Model and Notation) - a standard language (set of visual elements) for business process visual definition. De facto it is the most powerful and advanced standard for business process design. To learn more about BPMN standard and its format you can visit the official BPMN website.
Business Process (Workflow) - represents a business process definition in the BPM system. In the common case, it contains a process diagram created according to BPMN or other standards, security options, and other process-related information that can be used by the BPM engine for its execution. Shortly, It is a blueprint of your process.
Case - it is an instance of the business process. For example, if you have a business process “Sales” which describes the process of sales in your company, every particular sale will be the Case of this Business Process. Normally, every single Case should have its own set of records in your data storage (database).
Task - it is the smallest and unbreakable unit of work in the scope of the process. Tasks can be executed by particular users or automatically by the BPM engine. Also, particular tasks can be assigned to particular users and/or user groups.
Business Process Data Model - a model which can be used by some Business Process. Each Case has its own instance of the model represented by the case-related records in the data storage.
Forms - lets users modify the instance of the Business Process Data Model and apply changes to data storage. Forms can be customized according to tasks and their business requirements.
From the terms described above, you can make a conclusion that BPM software is too complex to be created easily. And you will be partially right. But only partially. The complexity of the implementation totally depends on your requirements. And my main target is to show you the roadmap and points of shortening that can be used to make your development more fast and simple.
First of all, let’s decompose the BPM problem into smaller parts to make it more understandable for the following engineering. According to my experience, the best way to break up this monolith is to divide it into three pieces.
| BPM Diagram Processing |
| Data model operations | Form customization |
The integral parts are still tightly related to each other, but now it is much more clear what you can do with them next. To find out what’s next I propose to take a closer look at every component separately.
The main idea of the BPM concept is a state machine theory. You have a visual language that consists of a set of diagram elements. Those elements have a standard behavior and can represent the sequential and conditional graph of your Business Process.
In the picture below you can see an example of the Internet purchasing process that is created according to BPMN standard.
As you can see, the diagram has nothing complex neither for creation nor for understanding. Of course, the creation of a diagram processing algorithm requires from your developers some experience, and possibly it will take some struggle for the first time.
To make it a bit easier for understanding, let's point out the main tasks you have to resolve to make the diagram processing working.
This list can be extended because the complexity of the BPM engine totally depends on the visual language you choose for process definition. And here you have two options:
As I said above, BPMN is the most advanced language for business process design. It provides all the elements that you can ever need in process modeling. There are a lot of nice UI libraries that you can use for modeling with BPMN. Also, some of those libraries can be extended by your custom elements to spice it up with your additional features. The popularity of BPMN makes it widespread and well-understood by most business experts around the world.
Nevertheless, there are some disadvantages that are worth to be mentioning. BPMN notation contains so many elements that you, possibly, would never use most of them, and it can over-complicate your application. Some rules from the BPMN standard are quite wordy and can be easily simplified.
As you can see, using BPMN can be redundant in many cases. From the other side, it is a must-have when you plan to create a standalone BPM engine.
As an alternative to BPMN, you can create your own diagramming language. It can make your processing engine more lightweight and transparent. It will contain only items that you need and can be much easier for understanding by your users.
But what are the problems hiding here? The visual language is not standardized, so you will have to provide a nice guideline and documentation. Possibly, you would have to create your own diagram editor. If you have no experience in business process design, you can find yourself in serious trouble if you make a conceptual mistake in your diagramming language.
This scenario will work for you only if your application is narrow specialized and when you perfectly understand the business process customization requirements. It can be a nice choice to simplify the user experience of your application and make it more user friendly.
* TIP: Before trying to use the custom diagramming language I would strictly recommend you to learn more about business process modeling, at least in theory.
The next part after diagram processing is the data model operations system. The main responsibility of this module is to operate with business data in your BPM engine. Any time, when the user or BPM engine starts a new case, submits the task, processes the case, or does any other operation according to the process, the business data model has to be read from the data storage updated properly and saved back to the storage.
According to my experience, there are two strategies for data processing in the BPM software: use of User-Defined Data Models and use of Application Domain Models.
|
User-Defined Data Models |
VS |
Application Domain Models |
This option supposes using dynamic user-defined data models in your BPM processes that provide awesome agility for the BPM software. It is a very generic and complex way of data operations and most of all it can be used for standalone BPM solutions. Let's take a look at steps that you have taken to make it work:
As you can see, the structure of this module is quite complex. It requires your developers to have very powerful hard skills, especially the knowledge of your data storage technology.
This option is much easier than the previous one. The main idea is using the already existing data models (Business Models, DTOs, Domain Models) of your application. It will let you use already existing infrastructure for CRUD operations as you normally use in your application for non-BPM operations.
This option can perfectly fit your needs if you have to automate workflows in the narrow specialized application that is not supposed to be working with dynamic data structures.
We have a process that can operate some business data, so we need the instrument to collect data from the user to make our engine usable by people. For those purposes, it would be nice to have the possibility to create customized forms that will be able to display case-related data models.
Let’s take a look at the most important things you have to implement in this scope:
Obviously, those requirements can be extended, the number of available components and their complexity can be different from project to project. Also, the UI technology which you are going to use for implementation can bring you some additional possibilities and limitations.
As you can see, BPM engine implementation is not so trivial task. It requires not only common software design experience but also an experience in BPM software development. It consists of three big components that are quite complex by themselves and tightly related to each other. It makes it almost impossible to implement any of them without the previous overall design of the whole system together.
Also, we can conclude that there is no silver bullet or common solution that can fit all needs of any business. The big generic BPM solutions always tend to data over processing that significantly decreases the performance of such system. The smallest ones, workflow processors, are more lightweight and faster than their bigger colleagues but the scope of usage is limited by specific business domains.
