Blog Posts Process Management Process Modeling

Process Management Architecture: Overview of Methods, Features, and Capabilities

Blog: Gary Samuelson Information Systems Anatomy


I hope you find this post informative as a general overview of process management architecture. My intent is to help clarify the requirements and differences between process-management and general application design. Importantly, understanding the technical impacts of each significant process-oriented feature to overall enterprise systems and supporting infrastructure.

The goal is finding the best approach towards managing the effort of creation, and follow-on technical debt, associated per each significant feature. Development velocity should remain predictably consistent while avoiding potential paralysis during analysis and construction. Run-time performance must also remain high, with a focus on understanding and preparing for BPM’s potentially heavy computing requirements.

Business Process Management Architecture: Core Features & Concepts

Business process management (BPM) requires specific functional and non-functional features typically absent from general enterprise architecture:


Perspective: Contrast Process Architecture against a Plain Old Application

We’ll first take a look at reasonably complex though ordinary client-facing application architecture. We’ll later compare this design with an updated version showing the addition of process-management features.

The only somewhat less-ordinary feature in this first design is its browser-based (JavaScript) implementation of a component-oriented, single-page-application (SPA) pattern. Since most client applications are heading towards this level of complexity, I’ll assume this isn’t a stretch for the “ordinary” state of UI technology.

In this architecture, the user-facing device represents a web-browser run-time container. Though, not ignoring proprietary applications (Win, iOS, Android, etc.), native components may implement the UI. Both browser and proprietary user devices both relying on some sort of application and content delivery.

The client initiates interaction by connecting to the server and downloading the application (HTML or OS-proprietary). A Web-UI provider, at the presentation layer, delivers the application and all necessary layouts, UI widgets,  endpoints (e.g. ReST),  and/or heuristics for URL (resource) discovery.

During initialization, the application begins interaction with dependent business services. Noting that I moved a few modules typically represented as “application services” (security and access) into the business layer to help simplify their representation and interaction with our primary customer-facing application.

From this design we can see that interaction begins at Information Services and then, acting as a facade, service-orchestration fans out to support Business-transaction, Rules, Security/Access, and Compliance. Though business transactions represent domain-object persistence, we don’t yet have process-management, so “orchestration” at this stage is basically pulling together services, representing a static/graphed configuration, outside the context of a process-oriented model.

Ordinary Application Architecture


Adding Process Management

We now introduce the need for communication between customer and employee via a service provisioning pattern:

A client purchases services which are then provisioned (rendered or delivered) by the worker.

Keeping our plain old application (above) in mind, we need to add in some collaboration and orchestration between the client-facing and back-office systems so the two parties, customer and worker, can both communicate and collaborate while utilizing technical business services.

This service-provisioning relationship is typically managed by a one or more integrated line-of-business applications. System boundaries bridged via direct (e.g. ReST, SOAP) and loosely coupled event services. Internet associated security risks managed by isolating unwanted intrusion via firewall, filtering, and monitoring technologies.

With the addition for process management, we’re now able to reasonably represent our customer and worker collaboration as modeled business activities (BPMN or CMMN diagrams). And, with business models, we have a means towards improvement given the communication medium for business-intent (value) behind our worker and system represented provisioning (facilitator).

Adding Process Awareness



Upcoming Articles:

Implied by the above list of “core features and concepts”, this article is the first in a series.

1. (this article)  Process Management Architecture Overview
2. The Process Task as a Metaphor and Container for Service Capabilities
3. The Process Task View on Methods for Aspect Oriented Programming (AOP) and Context Dependency Injection (CDI)
4. Context of The Market-oriented View
5.  Security and Methods for Managing Risk for Cross-functional Systems
6. Complex Processing for Business and Service Events
7. Business Transactions
8. Business-oriented Domain Model
9. Actionable Knowledge (process data-mining, dashboard)
10. Methods and Approach for Adding Process Awareness to Legacy Applications


Leave a Comment

Get the BPI Web Feed

Using the HTML code below, you can display this Business Process Incubator page content with the current filter and sorting inside your web site for FREE.

Copy/Paste this code in your website html code:

<iframe src="" frameborder="0" scrolling="auto" width="100%" height="700">

Customizing your BPI Web Feed

You can click on the Get the BPI Web Feed link on any of our page to create the best possible feed for your site. Here are a few tips to customize your BPI Web Feed.

Customizing the Content Filter
On any page, you can add filter criteria using the MORE FILTERS interface:

Customizing the Content Filter

Customizing the Content Sorting
Clicking on the sorting options will also change the way your BPI Web Feed will be ordered on your site:

Get the BPI Web Feed

Some integration examples