Business process management (BPM) integration

The primary function of a BPM solution is to assist business analysts in modeling and optimizing their organization’s processes to improve the functioning of human-centric business processes.

The strength of a BPM solution lies in its ability to orchestrate between different systems, people, and processes; it’s meant to provide a solution to a business audience, like a packaged application, with the following capabilities:

• A BPM tool (for business): typically web-based, to model complex Business Processes involving human and system (commonly called task) business rules using BPMN annotation.
• A Business Rules engine: where complex routing conditions within the Business Process can be outsourced and parameterized separately.
• A Business Process Simulator: to measure process efficiency, in terms of average time to complete a process and the cost of a process (how many people will get involved, and how long will they spend to complete the task?).
• A Business Process Development tool: for IT developers to “enrich” the provided business process, with specific IT artifacts.
• A Business Process Runtime Engine: to execute the “enriched” Business Process using BPMN annotation. The runtime engine also provides a built-in persistence store to keep in-flight processes state to prevent failure.
• A Task List: used for humans to retrieve the business process tasks assigned to them, or a business role that they belong to.
• A Business Process Reporting tool: for business performance checking (for example, the performance on a call center) and auditing purposes (for instance, who made a litigious approval 3 months ago on a business case?).

The only technical aspect of BPM is the capability to “enrich” the Business Process Model with technical artifacts to make the process executable. This includes constructs such as variables/payload, a user interface to present human tasks in the BPM tasklist, callouts, etc. Some traditional vendors are positioning BPM as an integration layer because their solutions were built on top of an existing SOA stack. However, the overhead introduced by the native BPM requirements is too high, making it unsuitable for integration or API initiatives where connectivity and performance are key.

BPM is ideal for long running business processes that involve heavy human interactions across multiple lines of business. BPM is also important for business tracking — knowing who did what from a historical perspective. Here are some examples:

• Case management
• New hire interview process
• Expenses approval

While BPM is an important part of continuous business transformation, many organizations struggle with implementing it effectively. The question is often whether BPM is a technological problem or a cultural one — are business processes dependent on the technologies they use or the people who use them?

The answer is both; the key is to not think about BPM separately from how your services and processes work, but rather how to make them work together. In other words, to be successful with business processes, you need to have all your systems and applications exposed as services via APIs.

The first challenge for organizations adopting BPM is that they must have good Business Role Management, either via Role Management tools, or just some simple internal practices (like Excel), that BPM can leverage to distribute tasks. A lot of implementation failures stem from this because BPM is not able to distribute the task to the worker in a consistent way. And this requirement is too often underestimated and all the business benefits vanish.

The second major challenge is the business process “enrichment” itself. On paper, it seems promising to have a single modeling language suitable for business and IT to streamline the process delivery lifecycle; in practice, however, the story is different. The person designing business processes typically does not know the technical assets of the IT infrastructure, so tends to abstract system tasks into one single box (like “create order”) which, after all, is fully understandable.

However, when the IT developer inherits this process and they are responsible for enriching it, this “create order”‘box might end up being replaced with ESB-like mediation logic embedded inline with the business process. This muddles the business perspective.

At this stage, the process can be executed. However, because of the verbose enrichment, the process owner can no longer understand the process, making it difficult to iterate and optimize. This is the “one-off agility” phenomenon that we often see in BPM projects. While it’s commonly thought that there’s only one way to execute process management, there is, in fact, a more effective way using a strategy called API-led connectivity.

Taking an API-first approach provides a natural abstraction for system tasks like “create order,” which can and should be implemented outside of the BPM.

Traditional SOA stack vendors that also provided BPM products relied on a web services (SOAP, WSDL, XML) interface for System Tasks. These services were typically hosted on their SOA product. However, enterprises have acknowledged that web services APIs are too heavyweight for enterprise-wide consumption. For instance, a web service created for BPM (create order) cannot be used by a mobile developer working on a lightweight framework. Instead, enterprises have embraced the more modern concept of APIs.

A modern API has taken on some characteristics that completely change the game:

• They adhere to standards: typically HTTP and REST, these standards are developer-friendly, easily accessible, and understood broadly.
• They are treated more like products than code: they are designed for consumption for specific audiences, and they are documented and versioned in a way that users can have certain expectations of its maintenance and lifecycle.
• They are more standardized: they have a much stronger discipline for security and governance, as well as monitored and managed for performance and scale.
• They have their own software development lifecycle (SDLC): as any other piece of software that is productized, the modern API includes designing, testing, building, managing, and versioning.

An API-first approach depends on the modern API to act as a building block for streamlined business processes. With this approach, it is important to keep BPMN as business-oriented as possible, and IT should be focusing on providing accessible APIs to support business processes. This is the only way to keep the business process model intact over subsequent changes.

While Anypoint Platform does not include a BPM product, API-led connectivity using Anypoint Platform is a natural fit for any BPM initiative:

• Anypoint Platform provides connectivity to both legacy and SaaS systems with an entire library of connectors.
• The platform provides tried and tested interoperability with majority of BPM vendors.
• Using an API/RAML as contracts between business and IT allows clean and clear duty separation.
• The API mocking capability allows business users to complete business process modeling and simulation, while IT implements the API and backend capability in parallel.
• Since business processes need to subscribe to APIs, it enables a mechanism for dependencies tracking.

Anypoint Platform can be the universal connectivity layer to support any BPM solution — learn how by downloading the Business Process Management (BPM) whitepaper.

Try the free CSS tidy lets you easily beautify stylesheets for your websites.