Process optimization through IT
The implementation of optimized processes typically has two dimensions: The organizational / business-level implementation and the IT implementation.
Organizational / business-level implementation: This includes the (re-)assignment of process responsibilities, reordering / redefinition of tasks and the introduction / modification of a reporting / KPI system. Everything centers around organizational and management aspects: The process is modified as a result of a modified behavior of the people involved.
IT implementation: IT systems offers many capabilities for making a process more effective or more efficient:
- Reduction of redundancies
- Faster retrieval of information
- Aids when filling in forms
- Enforcement of process steps or ordering of activities
- Geographical independence of activities
- Full automation of individual tasks that have been manual before
- Automatic synchronization of systems
- Audit trails / process history
- Automatic reporting, KPI dashboards
There are three alternatives for IT implementations:
- Standard software (e.g. ERP, CRM) with customizations
- Classical application development (e.g. Java, ABAP, Python)
- Process automation using a process engine
Process engines
Process engines are software systems that use process models as central implementation artefact. Instead of using classical program code (e.g. Java, ABAP, Python), process engines use process models in BPMN 2.0 format or other process modeling languages. This programming model has the advantage that business requirements are much more closely captured in the implementation. Process engines are sometimes also called “workflow engines” or “BPM suites”.
Typical advantages of process engines are (when compared with classical software development):
- Shorter implementation cycles
- Easier modification of processes
- Process monitoring and reporting as standard features
- Coordination of process statuses along process models
Business process modeling vs. technical process modeling
We often hear the question: So now I have captured the processes in my department using process models. What do I need to do to run it in a process engine? Can we do it ourselves or do we need to get IT involved for that?
If you have chosen BPMN 2.0 for business process modeling, you have already done an important first step. This is also the modeling language of choice for technical process models.
The business process model typically only describes which tasks have to be performed, where decision points are, where tasks can run in parallel, where information is produced or required, where the interaction with the customer happens and who is responsible for performing the tasks. The clear focus lies on topics that are important for the organizational / business-level implementation of processes.
For the IT implementation you have to go one step further: It must be specified which data is passed on in the process (variables / data objects), how these relate to inputs and outputs of tasks (data mapping), which IT functions or forms are required for the tasks, which user management should be used and how exactly decisions will be taken (decision point logic). Furthermore, there might be questions around access rights, security aspects or transactional properties.
You might have already heard that you simply need to enrich/annotate a business process model with technical details in order to make it executable. Unfortunately, this only works in very simple scenarios, e.g. leave requests or HR onboarding.
Especially the automation of core processes is often much more challenging than that. Certain parts of a process might not be handled in a per-process-instance mode but rather in a batch operation. Often, a sophisticated exception handling logic must be put in place as well. Fundamental questions about which part of the process needs to be automated at all and which part of the process might already be implemented in a different system.
Our Certified Partner camunda is a BPM services company that established a pragmatic way how to deal with the process models on the different levels.
Can a process directly be implemented by the business department? In simple cases yes. For most cases, we recommend getting the IT department involved - often this is even required.
Selection criteria for process engines
There are plenty of process engines on the market. Depending on the use case, the following criteria might have more or less importance:
- Modeling language: Does the system use BPMN 2.0 or a proprietary language? How well is business process modeling supported?
- Interfaces to existing systems: How easy is it to integrate with existing systems? Are there adapters that be readily used?
- Forms: How easy is it to develop forms? How can forms logic, validations, etc be defined?
- Extendability: How easy is it to deploy additional components with the system?
- Implementation technology: Which technical know how is required to implement a process (e.g. XSLT, Java, proprietary technology)? Which companies are offering related services?
- Development environment (IDE): Can the standard IDE be reused? Is there the possibility to “debug” processes? How about test infrastructures?
- Performance: How well does the system scale with thousands or millions of process instances?
Please note: When implementing a process using a process engine is often a development project - just like other application development projects. Established approaches such as agile / iterative methodologies might be applied as well.
Zero-Coding vs. Less-Code
During the past years, there has been quite some discussion around “Zero-Coding” vs. “Less-Code”. “Zero-Coding” means that a graphical process model can be made executable by using predefined building blocks and configuration dialogs. The building blocks (services, adapters, transformation components, etc) cover many typical scenarios and can be orchestrated in the form of the process model. This requires data mappings in order to relate inputs and outputs of tasks.
This approach is very efficient whenever the building blocks cover all the requirements. However, this is often not the case. If not, it is an interesting question how this additional functionality can be realized. In the worst case, customization by the engine vendor would be required.
As the number of realization scenarios is potentially big, the configuration in “Zero-Coding” projects might be very complex. Sometimes this configuration even turns out to be more effort than classical software development.
Therefore, the “Less-Code” is an interesting alternative that should be considered. The main idea is that basically the same development environment and technology is used like with classical software development. For instance, Eclipse, NetBeans or IntelliJ are used as IDE, Git or svn as source code management system and Java as language for developing custom components.
“Less-Code” means that the process engine is deployed as part of the overall application. The engine covers as much of the business logic as possible. Data mappings, implementation of additional building blocks, etc happens like it was classical software development. To put it in a nutshell, it combines the best of two worlds.
jBPM and Activiti
jBPM and Activiti are the two most well-known process engines falling under the “Less-Code” category. Both are Open Source projects and both are using Java as basic technology. jBPM is driven by Red Hat. The Activiti project was founded by the two former main jBPM developers. It is mainly sponsored by Alfresco.
Both jBPM and Activiti are “embeddable engines”. This means that the components integrate nicely with an existing Java application development environment. This is in stark contrast to most other process engines that run as standalone systems. Here, an integration often requires web services for communication between the engine and the actual activity implementation - as opposed to plain old method calls in the case of embeddable engines.
In previous versions, jBPM used a proprietary interchange format (jPDL). Signavio can generate this format out of BPMN diagrams. An integration with modeling environments is even smoother since jBPM natively supports BPMN 2.0 XML. The most up-to-date version is jBPM 5. The older version jBPM 3 is still widely used in productive settings.
Activiti opted for BPMN 2.0 XML as interchange format since its beginning. On top of that, Activiti uses a small number of additional execution-relevant attributes using an own Activiti XML namespace. That way, Activiti allows for very elegant XML code when integrating with Java components or when using forms in a process, for instance.
Both engines support the most important BPMN language constructs.
Activiti can be downloaded and used for free as a community edition. If you are interested in a productive use of Activiti, the camunda fox engine is highly recommended. This product is basically a stabilization of the Activiti code base with a couple of valuable extensions (see also “BPM roundtrip engineering”). These additions can speed up projects significantly and guarantee a more robust system for productive use. Most importantly, licensing camunda fox is one of the few options to get professional support for Activiti - a must for the automation of core processes.
Fox shows an impressive performance: Several hundred thousand process instances per hour can be handled easily. You can also operate fox in a clustered environment or in multi-tenancy mode.
While jBPM has been in productive use for several years now, Activiti is gaining a lot of momentum lately. This is also reflected in the high number of new productive deployments.
This trend from jBPM 3 or Intalio to Activiti is especially true for many European countries. In the United States, jBPM continues to have a very strong presence in new process automation projects. This difference might be due to the fact that the main developers of Activiti are based in Europe, while many of the jBPM protagonists are located in the US.
Process modeling: What is the best tooling?
Business departments and IT department need to work hand in hand for a successful BPM implementation project. This might even require to have multiple BPMN models with different levels of granularity.
This directly leads to the question of a suitable tooling for the project.
Some “Zero-Coding” vendors suggest that the development environment should also be used for the business process modeling. However, these integrated editors often lack support for typical business process modeling requirements as they mainly focus on the technical implementation.
Typical disadvantages of implementation-centric modeling environments are:
- The development environment is too complex for business users
- Software installation is required
- Modeling is limited to a few processes - relating several models / processes is not possible
- Discussion / collaboration functionality is not available
- The usability is oriented towards the technical implementation rather than the easy creation of diagrams
- Attributes / attachments are rather suited for technical aspects - not for business concerns
- Process analysis functionality is not included
- The publication of process models in the whole organization is not supported
Two modeling tools and BPM roundtrip engineering
It is highly recommended to always use a modeling platform that was designed to be used by business users - also in process automation projects. Automation projects are not pure IT projects: Agreeing on the business processes play a central role!
On the other hand, Signavio is not a full-fledged development tool like e.g. the eclipse-based Activiti Designer. This editor directly integrates with the IDE and helps to correctly use Java components as part of the process.
We often see the use of two modeling tools: Signavio is used for the business-oriented modeling and discussion of processes. A second, more implementation-centric tool is used for detailing the implementation parameters. An interchange between the two tools is realized through BPMN 2.0 XML.
The Activiti project offers the Activiti Designer as eclipse plugin. This editor offers typical features like code completion. Both the Activiti Designer and Signavio use BPMN 2.0 as a modeling language. This enables a smooth import / export between the tools.
There is even support that goes beyond simple import / export: Sophisticated synchronization components help to keep the process model repository and the code repository in sync.
The camunda fox product (the professional version of Activiti including code stabilization, support and additional components) sees such a roundtrip mechanism as its core. BPMN 2.0 XML is used “on the wire” but the sync components enable versioning and even realizing stakeholder-specific views on the process models: The non-execution relevant parts of the process can be hidden so that the XML code that appears in the development environment is nice and clean.
The Signavio Process Editor was optimized to enable the roundtrip:
- All execution-relevant attributes for jBPM and Activiti are supported (even those that go beyond the BPMN 2.0 standard)
- All execution-relevant information that are defined in the engine-specific XML namespace are kept during modification in the graphical editor
- A “developer friendly” XML is generated that makes it easy to read and edit it in a standard text editor
- Graphical comparison of different process model versions
- Direct access to the Signavio Mashup API for process monitoring
...and how does Signavio integrate with other engines?
Signavio supports the BPMN 2.0 in full (including XML import, export and synchronization). BPMN 2.0 is the international standard interchange format for process models. Numerous companies back the standard, e.g. SAP, IBM, Oracle.
Signavio has already been integration into many workflow products as an OEM component. Here, the Signavio Process Editor serves as “Zero-Coding” environment. Even if different models should be created on the business and IT level, they can all be maintained in the same tool.
We already realized many scenarios where Signavio was used with other process engines. We have strong relationships with many engine vendors in order to ensure a smooth integration. For instance, a recent study shows how Signavio works with SAP Netweaver BPM.
Signavio is the ideal platform for business process modeling. The Signavio Process Editor is the best starting point for the automation of business processes - no matter what engine is used for the technical implementation.
Please contact us if you are interested in a particular scenario.
Summary
- The camunda fox engine (the “professional Activiti”) is a powerful platform for the automation of processes
- Thanks to the tight integration, Signavio is the first choice for all jBPM and Activiti / camunda fox projects
- Even those automation projects that use another engine benefit a lot from business process modeling using Signavio
Signavio is the ideal starting for all process automation projects - who matter what engine is used. Read more about jBPM: http://www.jboss.org/jbpm Read more about Activiti: http://activiti.org/ Read more about camunda fox: http://www.camunda.com/fox/product/overview/