A Conceptual Architecture Framework for Business Process management System (BPMS)

ABSTRACT
The Business Process management (BPM) is the new paradigm for developing enterprise solutions. The BPM is a multi dimensional problem space involving a myriad concepts, technologies and standards. Some of the critical areas include Business Process analysis, Business Process automation (BPA), Enterprise Application Integration (EAI), Service Oriented Architecture (SOA), Human workflow, Business Activity Monitoring (BAM) and so on. Each one of them addresses certain aspects of the overall problem space and have evolved into niche areas in their own right with applicable standards and technologies, and a host of products, platforms and tools in the market place. A Business Process management System (BPMS) in some sense is an amalgamation of these concepts, technologies and standards.

This paper defines a conceptual Architectural framework for a Business Process Management System (BPMS) that attempts to unify core abstractions drawn from these concepts, technologies and standards. These abstractions are characterized by a set of services in the framework.

The framework facilitates developing proprietary or standards based BPM system using alternate set of standards, technologies, platforms and tools that map to the core abstractions identified here. Standards based approach however, facilitates better interoperability among the multiple disparate components of a BPM system. The document in fact identifies contemporary technologies and standards and their role in the conceptual framework.

The architecture is further enriched by insightful experiences gained during the development of a BPM system as a part of the internal product development initiative.

Categories and Subject Descriptors
D.2.11 [Patterns]: A Conceptual Architecture Pattern for Business Process Management (BPM) System

General Terms
Standardization

Keywords
BPM, BPMS, Conceptual, Architecture, Pattern, Business Process, SOA, Automation, Framework, Adaptation, JCA, WS-BPEL, BPMN, XPDL, JCA, EAI, Events, JMX, Model, WSDL

1. INTRODUCTION
This paper defines a conceptual Architectural framework for a Business Process Management System (BPMS) that attempts to unify core abstractions drawn from various concepts, technologies and standards relevant to the BPM space. These abstractions are characterized by a set of services in the framework. The framework facilitates developing proprietary or standards based BPM system using alternate set of standards, technologies, platforms and tools that map to the core abstractions identified here.

2. The Framework
The diagram below depicts the conceptual architecture framework for a BPM system. The BPM architecture framework is represented by a two dimensional matrix – a matrix of interrelated abstract services. A set of operational/functional services along the vertical dimension and their life cycle management services along the horizontal dimension makeup the BPM system architecture matrix.

Figure 1 – BPM Service Matrix

Along the vertical dimension, the business process services represent the business process behavior or business process flow logic. The process automation services are distributed software services that enable automation of the business process using variety of software technologies and tools. The adaptation services facilitate seamless integration of the heterogeneous Enterprise Information Systems into the business processes.

Life cycle functions along the horizontal dimension cover the modeling, execution and monitoring of these operational services. The Modeling service represents a generic set of capabilities required to model an operational service through formal modeling notations providing a model driven thrust to the architecture (without necessarily the connotation of automatic code generation). The execution service represents a generic set of capabilities required to interpret and execute the model. The operations and maintenance service represents runtime monitoring capabilities of the operational services, various applications and systems that participate in the business processes. It is particularly worth noting that business process services are defined and controlled by business owners indicating a paradigm shift in enterprise architecture approach.

There are inherent relationships between the abstract services in the matrix. The business process, automation service and adaptation service models have a mutual correspondence. Modeling services establish these associations between the models at design time. Models are deployed in the execution environment. The overall process behavior is realized by the runtime interactions between models executing in their own execution environments. Operational services and the other applications and systems, while in execution state publish events. Operations and maintenance services consume the events and provide a consolidated status of the overall BPM system at different levels of abstractions for business owners and system administrators to monitor and manage the system effectively.

Each cell of the matrix represents a specialized problem domain within the larger BPM problem space and is characterized as an abstract service. Each one of them has evolved into independent and niche domains with their own technical complexities and challenges. There are relevant technologies and governing standards and a host of products, platforms and tools in each of these areas. A working BPM system can be realized by implementing the abstract services using appropriate set of technologies, standards and tools.

The decomposition of the BPM problem domain into distinct sub domains, their characterization and their interrelationships and of course a host of enabling technologies and standards in each domain form the corner stones of the conceptual framework. This serves as a strong foundation for developing a comprehensive, scalable and extensible Business Process Management System.

A very brief discussion about Zachman’s framework is in order since this framework seems to have some semblance with the Zachman’s framework. The operational services roughly map to functional dimension. The conceptual framework effectively combines the model driven approach to the functional dimension of Zachman’s framework with the life cycle management functions that are crucial in a Process Management system. In a sense the life cycle management functions can be seen as an extended dimension of each cell in the Zachman’s framework. It is possible to extend the conceptual framework to include the other dimensions as well. However it is not in the scope of this paper to discuss these aspects in detail.

The high level semantics associated with the core services are described in some detail in the following sections. This will guide the technical analysts and architects in evolving proprietary or standards based BPM system possibly leveraging third party products and tools as well.

2.1 Business Process Services
Business process services include a generic set of capabilities required to model, execute and monitor business processes.

The process modeling service represents a set of capabilities required to develop formal business process models (including human workflow models) that can be interpreted and executed by process execution services. A process model here is more specifically a process flow control model that represents the order of execution of business activities in some formal notations. The model captures the business activities with the associated concurrency, synchronization, conditional branching, recurring execution and communication semantics that are executable. A process analyst designs an efficient flow control of business activities with a clear understanding of what exactly each activity or a step in the process has to achieve. The desired outcome of each activity can be realized manually or by a suitable piece of software referred to as the automation services. The automation services help automate activities in a business process. In a manual process scenario, the process model serves as a formal documentation of the process, but activities are carried out manually conforming to the flow control specification in the model. Let us consider a simplistic order management process for discussion.

Figure 2 – Process – Service Interactions

The process model describes the order of execution of the activities and their flow control semantics (italicized statements). The actual work associated with an activity or the desired outcome of each activity is achieved through a corresponding automation service external to the process model. In the example under discussion, the automation services are – “Validate Order Service” that checks the validity of the fields, boundary conditions and constraints, “Get Approval Service” that posts a task to a human workflow engine, “Generate Invoice” service which takes the order details and generates invoice document and the “Reject Order” service which updates various databases and communicates to concerned parties about the order rejection.

In a typical implementation, the various steps in the process model are mapped to corresponding automation services at design time. This meta-information is used by the process execution services to invoke the corresponding automation service while executing a process activity or step. In practice the process execution service is implemented as an execution engine that interprets and executes the process model. Process engines are designed to run on variety of OS and execution environments such as Java EE, .Java SE, .NET, etc.

Business process modeling and execution services are becoming specialized areas driven by evolving standards such as BPMN, UML, WS-BPEL, BPDM, XPDL, etc or even some of the earlier standards such as XLANG, WFML and Petri-nets. These standards specify formal notations for process models enabling a model driven approach to the business processes. This is further complemented by process standardization initiatives such as ITIL for service industry, eTOM for Telecom industry and so on. Together, they facilitate development of standards based, industry specific, customizable process templates and, enhance interoperability among process life cycle functions.

2.2 Process Automation Services
Process automation services encapsulate a set of capabilities to model, execute and monitor the automation services. In a general sense, an automation service is any piece of software used to automate some activities of a business process. In the context of BPM, the automation services are SOA styled, generic, domain specific, distributed services that facilitate automation of business processes. For example, catalog and inventory functions implemented as software services with generalized interfaces can serve as basic building block for automating order management process in various business domains. In some cases, the automation services may have to use some functions or data in external applications and systems in an enterprise or facilitate human interactions with the process. In such scenarios an automation service acts as an intermediary between the business process and the external entities. Technically speaking, the process automation services and processes can evolve independent of each other in different time lines but have mutual dependencies in a BPM system.

From a modeling perspective, standards such as WSDL, CORBA are well suited for modeling automation service interfaces providing a model driven thrust to the approach. Process automation service models are executed by service execution platforms running on a variety of OS and middleware platforms. For example any web services platform interprets and executes the service model that complies with WSDL specification or a CORBA platform executes the CORBA IDL and so on.

One of the distinguishing features of these standards is the clear separation of the interface and the implementation providing multiple implementation choices for a given interface. The web services interface model for example specifies ports, operations and corresponding input/output messages. The specification allows service interface binding to variety of standard transport protocols such as SOAP, HTTP, MIME, TCP, to name a few. It can be extended to programming environments such as EJB, Java or even other proprietary environments. This extensibility in mapping the interfaces to variety of standards and custom implementation is extremely crucial in a BPM context. For example, a business analyst developing process templates for a specific domain, designs process models based on well defined generic domain service interfaces. Deploying them in customer environments may require mapping these interfaces to variety of proprietary protocols, languages, or even message oriented middleware, EAI platforms or proprietary applications in the customer IT environment. Automation services have to be highly adaptable to such diverse IT environments. It is the adaptation services that gracefully extend the capabilities of an automation service to handle the application and data integration class of problems which is one of the key requirements for a BPM system.

The significance of automation services in this architecture pattern is further justified by some standardization initiatives in the industry. For example OMG’s domain services initiative specifies abstract interfaces for services relevant to specific industry domains. CAD service interface for manufacturing domain, Clinical Observation Access Services for health care domain, Access subscription service interface for telecom domain are few examples for the kind of services being standardized. Similarly, TM Forum’s OSS/J initiative specifies interfaces (APIs) for several services relevant to the Telecommunication business such as order management, Inventory, billing mediation, service activation, trouble ticket and so on. The standardization of such services on one hand and standardization of business processes (eTOM, ITIL, etc) on the other, together provide great impetus to this architecture style. BPM systems supporting a library of such industry specific, customizable, standards based process templates and domain services accelerate the BPM adoption in the industry.

2.3 Adaptation Services
Typically enterprises have heterogeneous applications, systems, middleware platforms, communication infrastructure, and other tools. Enterprises moving from legacy styled architecture to BPM, expect to leverage the existing IT infrastructure to protect the IT investments already made. On the other hand, at design time, a business analyst designs industry specific standardized business process templates and corresponding automation service interfaces with no knowledge of the target customer IT environment. It is at the time of process deployment that the automation service interfaces have to rather seamlessly map to variety of applications, protocols, middleware platforms and other systems that exist as a part of customer IT infrastructure. It is through the adaptation services that this can be achieved.

Adaptation services represent generic capabilities to seamlessly adapt enterprise Information systems into the Business process infrastructure. They represent some of the key concepts, technologies and standards in the areas of Enterprise Application Integration (EAI), business events integration (Complex Event Processing-CEP), CORBA event services and Enterprise Service Bus (ESB). An automation service can achieve the automation of a process step using existing applications and systems via the adaptation services.

An automation service interface modeled around interface standards such as WSDL can be implemented over a variety of transports because of the separation of the interface from the transport bindings and end point specifications. They can be implemented as full fledged web services with binding to SOAP, SMTP, FTP, HTTP or MIME protocols on a variety of platforms. This can be further extended to support other binding options to address a larger class of problems. For example, web service ports can be bound to an object interface (e.g. java Interface) where the port type maps to the object interface class, operation maps to a class method and input/output messages map to the input/output parameters of the method. The object can implement any arbitrary logic required for the operation. A simple and cost effective implementation of a web service interface can be realized by objects in a simple OO environment with very minimal WEB services infrastructure.

This idea can be leveraged to address the integration needs. The object can be further structured to perform functions such as transform the WSDL messages to proprietary message formats (other than SOAP), communicate over variety of transports such as HTTP, TCP, FTP, SMTP, interact with external legacy applications and systems or even message oriented middleware platforms (JMS, MQ series, etc). In a generic sense, such an object qualifies to be called an “adapter” and links the automation services to the realm of Enterprise Application Integration (EAI) and related areas. Modeling tools can be extended to support formal adapter models comprising of interface binding for target applications and systems, message transformation models and transport binding. At runtime when a message is received at a service port or being sent to a remote service port, the service execution environment invokes the corresponding adapter which performs specified transformation and interactions as per the defined model. This brings into the conceptual framework, the idea of adapters bound to service ports that gracefully extends the automation services with application and data integration capabilities.

UML profile for EAI specification from OMG and the Java Connectivity Architecture (JCA) are a few of the applicable standards in this area. Adaptation services can be modeled around such standards. Platform vendors in the EAI space have used proprietary and standards based techniques to model adapters. The tools provide varied degree of design automation including generating required interface classes and generating code templates there by facilitating model driven approach to adaptation services. For example, an existing SAP adapter can be attached to a web service port with appropriate mapping of interfaces, to expose SAP functions to a business process. Similarly, a JMS adapter can be attached to a web service port with appropriate interface mapping, to send/receive messages to/from JMS end points and so on.

2.4 Operations & Maintenance Services
Operations and maintenance services represent a set of capabilities required to monitor and manage the operational services, their execution environments and a variety of applications and systems that participate in business processes. A single uniform approach to monitoring such heterogeneous entities requires asynchronous loosely coupled event driven techniques. Some of the relevant standards for developing runtime monitoring and management applications include, CORBA event services, JMS publish/subscribe services and JMX.

The operational services publish events during their execution life time. The operation and maintenance services consume these events and analyze and correlate the events and alert administrators in real time there by facilitating effective and efficient management of the BPM system.

Process operations and maintenance services represent a set of capabilities to monitor the business processes. The business process monitoring has similarities with Business Activity Monitoring (BAM) or Business Event Monitoring (BEM) domains. The business processes publish state transition events and error and exception events as it transits through various states. Management and monitoring solutions provide management dashboards that consume the events and analyze and correlate the events and alert the process owners about impending delays, bottlenecks and errors and exceptions.

Similarly, the automation services and the various applications and systems publish events that reflect their execution state. The events from business process, automation services and applications systems can be correlated to provide a holistic state view of the entire BPM system. Events can also be routed through the adaptation services enhancing the ability to integrate highly diverse types of event sources in the system into a single cohesive monitoring & management environment.

2.5 Enterprise Information Systems
This represents the heterogeneous IT infrastructure existing in an enterprise including legacy applications and systems, GUI application, data sources etc. The business processes, and automation services are designed to leverage the existing applications and systems through the adaptation services.

2.6 A Sample Scenario
A simplified real life case study is described here to demonstrate how a business process can be implemented in the conceptual framework.

The requirement is to implement an insurance enrollment process. Various external agencies upload files consisting of a batch of enrollment requests in CSV format to a remote server via FTP protocol. The batch requests are routed to the

Figure 3 – Enrollment Process Modeling Elements

business process instance which performs multi step automatic validations and manual correction workflow and finally forwards the valid enrollment requests into a main frame repository for further processing.

The diagram below shows the modeling elements of the business process, corresponding automation service interfaces and adapters and their interactions. All the models shown here are for illustration purposes only. The various modeling elements are identified with unique identifiers.

The significance of each modeling element and their design time association and runtime interactions are rather obvious. However the following important points can be noted.

• Following bindings are established among the modeling elements at design time – (P1,S1,A1), (P2,S2), (P4, S3), and (P5, S4, A2)
• While binding S1 and A1, a suitable transformation schema is defined and associated with A1. The Schema describes rules for transforming the incoming CSV file content into SOAP message format as defined in the WSDL associated with S1
• While binding S4 and A2, a suitable transformation schema is defined and associated with A2. The schema describes rules for transforming the incoming SOAP message received at S4 (for e.g. defined in the WSDL associated with S4) into proprietary message format. The transformed message is sent to the main frame application for further processing.
• The process step P4 posts a manual correction request task to P3 for an enrollment request that has failed the validation checks. The manual workflow system enables authorized users to view the enrolment request forms, make corrections and post the corrected enrollment forms back to the request repository.
• CSV file adapter and mainframe communication adapter are assumed to be existing.

3. Summary
BPM is a multi dimensional problem space. The proposed framework is developed around a core set of abstractions drawn from various concepts, technologies and standards associated with this space. Hence it makes a good foundation for developing extensible, interoperable, scalable BPM systems. The framework provides the following advantages.

• Business lead approach – The clear separation of business processes services from rest of technical/technology infrastructure enables business analysts and business owners to take a lead role in evolving the enterprise architecture.
• Model driven approach – Evolution of modeling standards in related areas facilitates model driven approach with obvious advantages from development and maintenance perspective.
• Extensibility & Interoperability- Isolating the business process, automation services and adaptation services and
  their life cycle management functions provides high degree of extensibility. A BPM system can be developed and deployed with alternate set of technologies, standards, platforms and tools. For example, a BPM solution can be deployed with a third party modeling tool, Java based process engine with .NET web services platform.
• Reusability – Clear separation of Business process, automation services facilitates developing customizable and reusable industry specific process templates libraries based on standardization initiatives such as eTOM and ITIL and service libraries based on OMG domain service specifications and other similar standardization initiatives.
• Scalability & Performance – Performance and scalability characteristics of business process, automation services and adaptation services are very different. Isolating these services help evolve independent performance and scalability strategies best suited for each service.
• Maintainability – Decomposing the larger BPM problem domain into smaller domains with each domain associated with its own set of technologies and standards can evolve independent of the other.

3.1 Copyright Notice
Copyright © 2005-2007 – Merit Systems Private Limited. All Rights Reserved. All products, trademarks and registered trademarks are properties of their respective owners.

M.K.Raghavendra
Merit Systems Private Limited
55/c, 42/1, Nandi Mansion,
40th Cross, Jayanagar 8th Block,
Bangalore 91-080-26542726
ragh@meritsystems.com