Open Framework, Information Management Strategy & Collaborative Governance | Data & Social Methodology - MIKE2.0 Methodology
Wiki Home
Collapse Expand Close

Members
Collapse Expand Close

To join, please contact us.

Improve MIKE 2.0
Collapse Expand Close
Need somewhere to start? How about the most wanted pages; or the pages we know need more work; or even the stub that somebody else has started, but hasn't been able to finish. Or create a ticket for any issues you have found.

Architecture Patterns for Distributed Business Process Automation

From MIKE2.0 Methodology

Share/Save/Bookmark
Jump to: navigation, search

Architecture Patterns for Business Process Automation describe how different components in the SAFE Architecture interact to solve a general set of problems for automating a set of manual business processes.

= The Problem and its Symptoms

Illustrating automation of long-lived business processes

Manual business processes dominate most organisations. These manual processes, often the main avenue of performing work, have no ability to scale. Lack of end-to-end visibility into processes result “black holes” across organizational or departmental boundaries that breed a non-disciplined organisation. To monitor the business activity, generating reports and Key Performance Indicator(s) is a heroic effort.

Most of these processes are unnecessarily manual, providing opportunities to significantly improve business capabilities. Automation of business processes helps to address some of the following issues:

  • An inability to scale to meet growing business volumes without significantly increasing staff.
  • Time lags between completed tasks that result an ineffective supply chain.
  • Data quality issues that result from the manual entry of data
  • The lack of a capability to effectively analyse and optimise current business process inefficiencies.

comparer forfait rio b and you portabilité du numéro calcul IMC rio orange

Design Pattern for Distributed Business Process Automation

Business process automation architecture pattern.jpg

The design pattern below illustrates Business Process Automation for an event-based architecture. It describes a scenario where a singular event (such as a customer order) generates a long-lived business process with multiple system interactions.

  1. An event occurs within an application that results in an invocation of the Service Requester adapter interface being invoked by the application.
  2. Within the Service Requester data out of the application is transformed from the application specific format and validated against a CMM Message structure.
  3. The Service Requester publishes out a CMM Message, which includes both the data payload and header information.
  4. A Mediator process receives the event, and based on its definition determines that it represents a long-lived business process.
  5. The Mediator process assigns a transaction ID (such as an order ID) to the received message and stores it in a transient data store. Throughout the life of this business process, state is now tracked through inspection against the transient data store.
  6. The Mediator submits a message to the workflow engine, which dynamically generates a workflow process by pulling from a library of available “process templates”. These templates can be described as existing business processes that can be assembled together to build a larger business process .
  7. The workflow engine drives the long-lived process, often involving integration to multiple systems. System interactions are preferably via loosely coupled asynchronous integration. Messages are published out to consuming systems, which are typically single systems in business process automation (as opposed to the multiple systems often seen in data synchronisation).
  8. Service Providers subscribing for the CMM message receive the message.
  9. Service Providers transform the message from the CMM format into the application-specific format and invoke the adapter interface into the application to submit the data.
  10. Service Providers pass status back up to the workflow engine.
  11. The workflow engine owns the overall process and is responsible for its “completion”. The workflow engine manages state and controls interactions with all Service Providers.
Other relevant aspects of a typical process include:
Illustrating dynamic process instantiation.jpg
  • The workflow process may involve both automated and manual (driven by users) tasks. Both behave in the same fashion, working off the transient data store and through the workflow system. Manual tasks are most typically used for exception handling and for interfacing to systems that have yet to be integrated through an automated mechanism (swivel chair integration).
  • Manual tasks are completed by users through the interface they have to the workflow system. Task routing may used to distribute tasks across a number of users. The capability to see the status of the end-to-end business process is driven off the transient data store, which holds the effective “state” of the process. Statuses are commonly viewed at both the level of consolidated reports and individual events.
  • The workflow engine may invoke some simple business rules and will typically invoke Business Services for more complex functions.

This design pattern is focused on process integration and is not focused on aspects of Business Process Management such as process optimisation. It takes a best practices approach to workflow-driven process integration by allowing interconnected systems to interact in a loosely coupled manner whilst avoiding point-to-point interactions - process integration, data transformation, and application integration are kept separate and are managed through the workflow management system. New processes can be implemented without touching the existing systems and can leverage process library templates and data is managed to fulfil the required set of business processes.

Wiki Contributors
Collapse Expand Close

View more contributors