How do I integrate Business Process Management solution into my architecture?

When implementing a new Business Process Management (BPM) solution into an existing enterprise architecture, organisations often face the following dilemma: how does the new fit to my current stack? How to plan such an implementation, when having a distributed, monolithic or a big, service-oriented architecture?

In order to best assess the status quo and set up boundaries between new and existing components in the IT architecture, it’s best to clearly understand the advantages and disadvantages of particular tech solutions.

We’ll assess the issue from Project Management, Architecture, Persistency and Microservices perspectives, we’ll also showcase some most common concepts related to BPM and present some integration scenarios. If you’re a System or an Enterprise Architect, this one will spark some thoughts for sure, so read on!

The Project Management perspective

From the Project Management perspective, the BPM solutions can be divided into two categories:

• A lightweight, flexible, developer-centered tools
• Large-scale, enterprise, comprehensive solutions focused on solving plenty of business issues at the same time.

Naturally, both approaches have their pros and cons. A lightweight solution is usually very adjustable. That means a good team that knows all the ropes of BPM will be limited only with their creativity, and plenty tangible business outcomes can be achieved. Not to mention ease of avoiding the vendor lock and availability of support, backed up by a solid community.

On the other hand large, enterprise tools usually mean vendor locking, limiting the development work around the BPM system and sometimes (seldom, but still) even resigning from specific requirements. Nonetheless, the choice is limited with scale.

That is why it’s crucial to properly assess the solution and how it fits the organisation. First and foremost, it must adhere to the company’s corporate and engineering culture. Moreover, it should reflect the communication structure, as well as the maturity level of project management. Only that way, the desired shape of the BPM system in the company can be met.

Approaching BPM

This initial choice can be approached from two angles. With the first one, some enterprises form a so-called ‘BPM centre of excellence’ or a ‘guild’ that encapsulates skills related to delivering platforms, tools, good practices and recommendations for any future processes that need to be automated. 

The second approach leaves space for the teams to individually use and adapt BPM as a part of their existing and future architecture. This method is used best with independent, self-sufficient, mature DevOps teams and with lightweight BPM systems that are easy to set up and use. A good example of such a solution is Camunda BPM, known to be ‘developer friendly’.

Step by step is a reasonable approach. It’s suggested to start small, with some simple business initiatives with an R&D team, and then promote this approach among other teams. This usually works particularly well with mid-sized companies or larger enterprises that are still lean and keen to embrace the agile approach and mindset. Frankly speaking, even the biggest organisations can benefit from forming a Centre of Excellence with some more centralised control.

How to plan a successful introduction of a new BPM system?

The simplest answers are usually the best, so let’s not reinvent the wheel: agile and iterative is the way to approach this elephant. Start with a Proof of Concept, to quickly implement something small but tangible, to deliver value and prove the benefits are achievable. 

After the PoC, it’s reasonable to work on a tangible business need. Pick a requirement that’s important but not essential, in order to stay on top of the risk. A small scale of this business need makes it easy to align the feature to best practices and build a solution that could be a reference point for future development within the organisation.

A quick win is very encouraging to both developers and the business side. Once the first small feature is proven in action, BPM can be then extrapolated towards other aspects of the organisation that could be managed based on processes, especially with those areas where technology can be a great leverage.

The Architecture perspective

Implementing the BPM engine in the IT architecture does not pass without effects. Surely, it brings plenty of benefits to the table. It strengthens the cooperation and alignment between IT and the business, as both sides need to understand their needs better. 

Moreover, it not only introduces out of the box solutions that allow to measure and track all the basic process-related KPIs, but also forms a live, executional documentation. Not to mention the ability to audit such a system is great, with a version control system included as a standard.

The list of the BPM benefits goes on. With such a system implemented in the organisation, it’s easy to keep up the momentum and add workflow-based solutions related to project and task management in a structured way. Also, these processes, once in place, can be easily replaced as a lot of the BPM logic (for example decision gates, flow of operations, metadata of tasks) can be changed, keeping the version control. 

BPM also further enhances the persistence of long-living processes, which is crucial when it comes to efficiency of microservice-based systems. BPM is also an additional layer of workflows, used to, for example, store data in the system only after full acceptance, which is very handy.

On the other hand, developers sometimes are afraid of large systems that look complicated at a first glance. It is important not to forget that BPM is not a silver bullet that solves every problem. There is a tendency amongst businesses to use it as a magic to perceive BPM as a magic wand, which only leads to frustration, so don’t follow that path. Whenever there are hardships and struggles with creating a structure of a process, there is no grounds for a BPM tool. In these scenarios, a case management or a custom built application would fit better.

Sometimes the organisations reach an assumption where with BPM in place, the business will not have to work hand in hand with the developers and will create the processes and solutions themselves. In some very simple cases and scenarios this could actually work, but that’s seldom the truth and a success in the long run. Efficiency comes with communication, collaboration and eliminating the bottle necks.

BPM integration scenarios

‘OK, but where do I start?’ you may wonder. When it comes to the ways of integrating the BPM solutions within the organisation, there’s numerous scenarios available. Here’s just three most common methods of tackling this challenge:

• Orchestration 

Orchestration is a kind of integration where two or more decoupled applications or services are integrated to automate a certain process. This approach allows organisations to extract business logic of each individual workflow, process, data or microservice. It also enhances visibility within processes and allows to avoid complex application dependencies and chaos that’s just hard to manage. A relevant example here would be implementing order fulfillment processes in the organisations from the Telco industry.

• The human aspects

The second approach is focused on putting the human aspects first. This human-centrism is a popular trend in the BPM industry that considers skills and activities of the employees on the top. The goal is to increase adaptability on the practice end of each process, as well as to make them flexible as per current requirements. These processes can include, amongst others, holiday acceptance, specific reminders or structured communication.

• A hybrid approach

Eventually, there’s a third way – the hybrid approach. This one includes integrating with for example the accounting, HR or other systems, including the human tasks and focusing on the human-facing parts of each process. Following this path leads to added value by work facilitation and significant time savings. A good example here would be related to processes such as making orders or the flow of documents and invoices within the organisation.

Persistent state management

Persistency means stability and duration of data or process across time and systems. With a level of scale and complexity that BPM introduces to an organisation, this aspect is a relevant topic for discussion.

Sometimes the business or developers are keen only on adding an additional layer of data or processes to store, monitor or manage a state of a certain data flow prior to final acceptance, signing off etc. What BPM does is it tracks and keeps this data in the domain system regardless, but only once they are confirmed with the business process that is auditable and trackable. Thanks to this fact, BPM systems are fluent in creating such flows and introduce persistence of data or processes at the final stage of acceptance.

Another relevant example relates to a long-lasting integration with asynchronous confirmation coming from many systems. Sometimes ESB-type systems are used to tackle that challenge, but BPM is a reasonable alternative that’s definitely worth bearing in mind.

Microservices and BPM – the new perspective

When it comes to BPM, microservices is one of the hottest trends at the moment. No wonder, as these technologies complement each other perfectly. For example, Camunda BPM can be used both with microservices orchestration and distributed systems, as well as to perform a certain process within the borders of a microservice.

This aspect deserves a separate article to cover it in a meaningful way, nonetheless in this piece we’ll briefly touch on how to avoid the most common pitfalls in microservice integration:

The first challenge is related to communication. Distribution of the systems introduces a level of chaos in the operations so do focus on openness and transparency of the processes. Secondly, resiliency, since asynchronicity requires handling timeouts. And last but not least, don’t forget to solve requirements to maintain consistency should failures occur.

Most popular components and concepts related to BPM

It is best to understand how the BPM works based on real-life use cases and success scenarios. Taking a closer look at some concepts related to BPM is a proven method of inspiration.

BPM can serve as a great platform for cooperation of analytics and the business. A good example of such a solution are IBM BlueworksLive or Camunda Cawemo. Both of these platforms introduce a tech stack focused on complete process automation, with powerful engines for workflows, decisions, operations and analytics. These business process and Decision Model and Notation (DMN) collaboration solutions directly translate into sustainable business-IT alignment. 

Another type of BPM tools are related to modelling processes by analytics and developers. Here the most popular solutions on the market, such as IBM Process Designer or Camunda Modeler, offer a wide variety of features related to process and decision automation. In these tools developers can model BPM workflows and DMN decisions, create executable models and share the results of their work in the form of reusable templates.

Camunda Platform is a relevant example of another type of concept related to BPM, meaning a process engine. It is a popular choice for both service orchestration as well as human task management. Plenty of companies use this engine for workflow and decision automation and for operating deployed models in production.

Other than the above, there’s still a lot of other solutions related to BPM, such as administrative applications (for example Camunda Cockpit or Tasklist, IBM Process Portal) or apps that serve for monitoring and optimization purposes (Camunda Optimize), as well as other tools that enable introducing definitions to the engine itself. As you can see, there’s plenty in store when it comes to BPM and DMN concepts and components. Every organisation can find a solution that suits them best.