BPM Architecture

In an earlier blog I highlighted some key concepts around Business Process Management (BPM), in this blog I will focus on architecture capabilities for an infrastructure to support BPM.

The core elements of an architecture to support BPM includes modeling, simulation, repository, orchestration (human and system), and events. Additionally there are a number of relationships with other technologies including EAI, various aspects of SOA, portals, dashboards, analytics, and of course, enterprise applications. In this blog I will describe some of these elements of this architecture in terms of the capabilities required from a supporting infrastructure for BPM.

  • Modeling – process modeling is a fundamental requirement of BPM. A modeling subsystem must be able to participate in the lifecycle of a business process and it must provide views to support both business and technical users.  The modeling infrastructure must enable round-tripping, not only offering seamless exchange of models from business to execution, but also incorporating simulation and run-time data for continuous improvement of the business process.
  • Simulation – is a theoretical execution of the modeled business process. Typically the business specialist sets the parameters for the simulation describing an environment that mimics a real-world scenario (for example, number of concurrent users, profile of delay between process steps, etc.). The simulation tool (usually an extension of the modeling tool) runs the scenario, and the efficiency of the business process can be predicted within the boundaries of supplied parameters.
  • Unified Repository – the infrastructure must provide a unified repository to support coordinated modeling between business and IT models and the generation of the executable representation. Ideally these representations are merely views of the same physical model for immediate visibility of changes between stakeholders. Transformation between model representations is sometimes necessary,
  • Process Execution – refers to the control of the flow of a business process, and not to the actual running of the application/system functions that underlie the tasks and activities. As part of the control of the flow of various types of process, process execution also involves the invocation of business rules to support decisions in the flow.
  • Business Rules – are expressions of business policy that can be used to guide the flow of a business process. Business rules are distinct from routing rules which are technical considerations, such as determining the best SOA Service instance to invoke based on availability. Routing rules are typically applied by the SOA infrastructure and should not be confused with business rules.
  • Events – is basically a communication between the process and the outside world. Start and End events are always present in a complete business process description, identifying the trigger from the outside world that initiates the process execution, such as receipt of an e-mail, and the circumstances that define the end of the process and termination of its flow.
  • Monitoring – The performance of a process may be monitored for real-time and/or off-line analysis for comparison against previously determined performance indicators.