Category: (1) TAM Application Type
Application Identifier: 10.2
Maturity Level: 4
Business Process Management (BPM) is the evolution of earlier concepts called workflow management (also known as Process Flow Management). As operators understand the need to introduce much greater flexibility and day-day change into their business processes, BPM and workflow management techniques, pioneered in manufacturing industry, are becoming more and more visible in the communications industry.
Business flexibility is crucial for an operator as well as high levels of automation of its processes, not just of basic process flows but of complex and exception handling areas. One of the cardinal principles of Frameworx is to allow this by abstraction of business processes from application logic. The emergence of N-tier computing and component-oriented environments (such as COM and J2EE) allow for this principle in the same manner that the emergence of SQL and the two-tier client/server architecture enabled the abstraction of data management from application code. By separating business process management as an independent function, applications can be designed around existing processes, and thus to take advantage of shared business logic rather than reinventing and recoding it for each application.
There are considerable benefits to an operator in adopting this type of approach and would include:
Faster and more flexible response to implement new processes or amend existing ones to accommodate new products / services
To understand how BPM fits with an operator and its infrastructure, it is helpful to examine the individual components of BPM. While commercial implementations vary in their specific definitions and software composition, most fit within the basic framework described below. Note that although some systems offer the ability to automate activities and define business rules, those that lack the fundamental components below cannot realistically be used as a BPM system.
A BPM system is defined by the components of:
Execution Engine
Process Designer,
Process Definitions
Activity Monitor
User interface which may be a combination of a Windows client application, HTML based Work Portal, or an exposed API or Web service
The majority of BPM systems on the market today are component-oriented and allow each of the individual pieces listed above to be deployed independently on individual servers. Individual business processes are defined by the process owner in a Process Definition, (increasingly expressed in a standard language such as UML or some variation of XML). Each Process Definition may be composed of both manual activities and automated activities. Once defined and validated within the Process Designer, processes are instantiated by an Execution Engine. The Activity Monitor provides access to status and performance metrics on the execution of processes.
End-to-end process ‘orchestration’
It is unlikely that the implementation of a Frameworx based ‘lean’ migration program will be a ‘big bang’ type of approach implementing all new systems. Therefore, the Enterprise Integration Framework will need to integrate end-to-end processes across various ‘islands of automation’ ranging from existing legacy systems to new commercial-off-the-shelf technology. This approach is sometimes called ‘orchestration’ in process. An orchestration-based approach offers the ability to manage processes of greater complexity, (such as complex business service provisioning etc.) with far more efficiency than is otherwise possible with alternative approaches. The key to this is a modular approach to managing business rules, relationships, and activities.
Within a simple workflow automation paradigm, processes are defined “end-to-end” with all possible paths (or more commonly a single path) pre-determined. Thus ‘Step 5’ always follows ‘Step 4’ and precedes ‘Step 6’ even if different instances of an otherwise standard process may require a different sequence.
Orchestration allows for the sequencing of steps to be determined during the “run-time” instance of a process, with paths determined by evolving context resulting from each new step. Thus the potential number of paths and outcomes may otherwise be too complex to define in terms of pre-determined “If-Then-Else” rules, but may be easily resolved through human interaction and decision-making. This highlights the key architectural difference between automation and orchestration. Given the inherent complexity and constant changes within an operator’s business environment, effectively managing processes requires the agility to shift with changes in context, rather than always being bound to the same scripted flow. This requires the unique ability to define processes as a set of atomic, goal-based activities with the enforcement of basic parameters (e.g., time limits, data variables), while separating the execution logic activities from the higher-level process definition. Process orchestration is not limited to invoking software, but rather represents a shift from task-based to goal-oriented process definition. Web services and other forms of software automation are utilized through process orchestration, yet not to the exclusion of manual, human-driven activities.
This was created from the Frameworx 16.0 Model