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

Editor's note: This guest post from Gary Samuelson is the first in a series. Gary is a thought leader in BPM and architecture, and we're privileged to be able to share his work here! Original article linked as well.

Introduction

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 on 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 with 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:

• Task: A modeling element, from the BPMN/CMMN notation, representing a unit of work. The task also provides a container metaphor and classification for a group of one or more services (human and system) dedicated, from a valued output perspective, towards the completion of a dependent business process. The process model (from BPMN) defines the context and placement, via the task's value-add dependency.
  
  
• The Process Task as an AOP Concern: From an aspect-oriented (AOP) perspective, a Task is similar to a collection of one or more "concerns" reflecting value-based business requirements. The AOP view is important in that both the Task and containing Process Model essentially crosscut business functional domains (aka functional silos) in much the same way an AOP "aspect" defines common logical features for reuse and subsequent "injection" (CDE) across system components and modules.
  
  
• Business Context: The business process model defines exactly when, why, and how resources (objects) are consumed and processed. This methodology establishes clarity as we now have a market-oriented view of what the business has (resources) and does (process).
  
  
• Security: Process implies usage requirements as in "who" needs to do "what" with information/objects under our care and control. What follows then are meaningful definitions for authentication and authorization ? in that individuals and groups have their business place, function, and accessibility to information. This is a role-based access control view (policy definitions).
  
  
• Business Event: An "event" can be many things but, in the context of this article, an "event" is a message container wrapping the details reflecting an observation. An observation should represent a condition taken from the state of things at an instance, or slice, in time. Events are both emitted from and received by both subjects and objects. An event can also trigger a task or process instantiation (something new created though based on preexisting class). Events are fundamental in BPM given their role in channeling communication. Events represent the "glue between situations in the real world and processes that will react" (Weske 2012).
  
  
• Complex Event Processing (CEP): Also simply be referred to as "event processing'. CEP provides transformation, routing, and delivery services for business event messages. Consequently, CEP represents a fundamental infrastructure component for business process management systems (BPMS). The "complex" feature, in event processing, adds additional value by taking messages from multiple sources during "time windows" whereby their attributes are brought together in search of patterns, causality, and correlation.
  
  
• Business Transactions: BPMN 2 supports transaction notation. And the term'?business transaction" implies a context boundary around one or more tasks within a process model (i.e. atomicity). Due to potential lengthy duration requirements, business transactions require special handling requirements, the goal being to avoid freezing up an otherwise robust transaction processing system (OLTP) by locking large tracks of data representing business domain objects (Bernstein 2009).
  
  
• Business Domain Model:  This topic is a little confusing due to overlapping definitions (and potential misuse). For the context of this article, the business domain is synonymous with "enterprise ontology". "Business model" is a close second in describing our ontology (i.e. schema). Problem with all of these terms is the overlapping "domain-driven" methodology which holds great importance to an object's behavior. For BPM, our domain model leans more towards the anaemic side of design in that it's primarily used to define message content as opposed to fully describing object behavior.
  
  
• Actionable Knowledge (process data mining): The process of presenting information to provide immediate pathways to thoughtful action.

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.

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 one or more integrated line-of-business applications. System boundaries are bridged via direct (e.g. ReST, SOAP) and loosely coupled event services. Internet-associated security risks are managed by isolating unwanted intrusion via firewall, filtering, and monitoring technologies.

With the addition of 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 workers and system-represented provisioning (facilitator).

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