Bringing Events, Processes, and Services Together

November 6, 2010

When working on implementing business process automation solutions, the team needs to bring together several related concepts: chief among them are events, process instances, and service capabilities. I like to think of them in the context of an overall enterprise architecture being aligned with individual solutions and projects. Bringing these concepts together holistically has several benefits:

  • Better alignment between BPM & SOA initiatives (wrote earlier about the risks of not doing so)
  • Consistent interfaces for event producers and consumers (e.g. clients who initiate changes to data or alter a process will be able to reuse a standardized set of messages)
  • Simpler solution architecture – aligning data models across event processing and services will reduce data transformation needs. It will greatly reduce the need for data mapping and complex adapters.

Events can be internal or external and can impact business processes in several ways. An external event could initiate a business process (thereby a new process instance is created), or alter an existing process (execution is moved from some kind of wait state or an existing instance could be terminated). These events could be data, state, or a combination of the two impacting a business process. The business process instance might take an alternate path or spawn a new instance of another process as appropriate.

Process instances themselves can be implemented by leveraging several service capabilities. These service capabilities need to share a consistent set of domain-relevant interfaces. The process instances can then be loosely coupled with services thus enabling the service implementations to evolve over time. As state changes happen in a process instance, outbound events can be generated – these are publications or notifications that are of interest to potentially multiple consumers. Service capabilities can be leveraged for not just creating/changing data but also when encapsulating business rules for decision steps, as well as for publishing messages to downstream systems/processes.


Reuse-Friendly BPM Capabilities

October 21, 2009

I have been stressing the need for integrating various concepts for succeeding with systematic reuse. BPM is no different. In an earlier post I introduced reusable BPM integration capabilities. In this post I want to list additional capabilities that you can build as part of BPM initiatives:

  • Mature your integration function that helps consumers integrate, use, and discover business process assets. This includes activities, sub-processes, as well as end-to-end business processes. Provide sample source as well as integration documentation to applications that need to leverage your processes. Do remember developers may not understand the differences in interacting with a stateful business process!
  • Significant alignment with information architecture logical model. Your activities that invoke system steps leverage logical data schemas and data types. If you start to reuse sub-processes within your high-level flows this will become second nature.
  • Ensure that your BPM assets are aligned with key performance indicators (KPIs) – if your business wants to analyze time taken between a particular set of steps you might need to persist, report, compute on this data. Why not use a reusable component that can persist updates from any business process?
  • Business process models and orchestrations developed are more standards compliant and adhere to key BPM and SOA standards. The higher the interoperability of SOA assets, the easier it is to reuse them in your business processes.
  • Expand coverage of business processes hosted in the BPM layer – including processes that involve internal clients, external clients, data governance/compliance etc. You will start identify reusable assets over time. For example, two business processes might require fetching customer data or updating customer address or calculate customer worth to the company and so on. Every such need is an opportunity for reuse.
  • Comprehensive modeling and representation of all relevant business processes including placeholders for manual steps, batch jobs, etc. Even if your existing process isn’t transformed completely from manual to one that is fully automated in real-time identify these steps explicitly. At the very least, you can use reusable components that deal with batch jobs (kick off FTP session or create a temporary file and copy to a particular location etc.)
  • Expanded number of event driven services for your business process. The higher the number of events the greater the likelihood of additional consuming applications getting to reuse data and notifications.
  • Support standardized alerts associated with human workflow steps (delegation, escalation, routing, pause/resume task etc.). Your BPM infrastructure can provide configurable capabilities for these steps.
  • Create scripts that perform continuous integration including smoke tests, unit tests, performance tests etc. If your business process are service-enabled, you can run a battery of service requests to instantiate, update, remove process instances.

Like this post? Subscribe to RSS feed or get blog updates via email.

Slide 2

ØWe are completely focused on Enterprise Account Opening and supporting Account Opening – support complex business process orchestrations.
ØWe are not methodically building a collection of reusable building blocks of assets in the business process layer that will help us for the future
§Data service wrappers, PMWS wrappers, Work in progress (WIP) API,  event processing
ØWe have built a set of components to configure events for a business process, capture metrics and perform administrative functions.
ØNot all business process logic is in business process layer for Enterprise Account Opening
ØWeb service the de facto metaphor of integration. Business processes are accessed on demand using  request/reply
ØSchema Contracts
§Schemas, data types, web service contracts are minimally aligned with information architecture logical data model resulting in a missed opportunity to align ourselves deeper with the information architecture direction.
§There is significant of data type, business object reuse across services and event handler orchestrations
ØSeveral utilities for testing, deployment, and continuous integration capabilities
ØClient integration happens on a per-project basis. This often results in increased pressure on the development team leads, lack of knowledge sharing across projects with respect to service integration/behavioral issues

tweet this add to del.icio.us post to facebook


Create a standard event processing infrastructure

June 9, 2009

Business events – whether they are initiated by human users or system processes – either initiate, change the state of, communicate out of , or terminate business processes. A standard event processing can be used to capture events, enrich them, analyze them, and handle them via appropriate event handlers. This infrastructure could be used to log, track metrics, and most importantly determine the appropriate orchestrations to execute for successful event processing.

As this processing matures you can introduce business rules and business intelligence based event analysis, routing, and enrichment. Iteratively you can also build out a library of business events and associated event handlers that can be reused across multiple projects and initiatives. On a related note you will want your legacy systems to send and consume events in the same format as your strategic platforms. This will facilitate a seamless transition when you migrate functionality off legacy systems by reducing the need to redo event generation, processing, and decision logic.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :


%d bloggers like this: