Business process management | Art of Software Reuse

Reusable Capabilities When Hosting Business Processes

November 7, 2011

Many teams are pursuing BPM and SOA based initiatives to automate, streamline, and standardize business processes. As more solutions start to embark on BPM-based solutions, there is a need for a common set of software components that aid in hosting and managing business processes. The following are capabilities that need to be present in such a solution:

Common messaging architecture & utilities for facilitating the development and maintenance of stateful business processes & stateless services.
Support business process orchestrations that join across multiple services (data services, business services, legacy services, etc.). This is essential for orchestrating complex
Handle workflow and system business process events via a configuration driven Event Handler Service, enabling reuse of event handler processes
Provide ability to reuse sub-processes across larger business processes.
Runtime metrics including reporting and the ability to perform diagnostic troubleshooting
Reusable schemas for request dispatching, event handling, generic transport listeners, metrics, and error handling
Supports synchronous and asynchronous request/reply & fire/forget message exchange patterns
Provides the ability to create reusable components for assembling new business processes
Standard client interfaces across multiple transports such as HTTP and EMS
Ability to query various data sources, rules engine, as well as write custom java code to integrate with existing functionality
Provides interface for executing administrative functions
Provides developer tools for WSDL generation, unit testing, deployment, & viewing metrics

Leave a Comment » | BPM, Design, Reuse | Tagged: Business process management, systematic reuse | Permalink
Posted by vijaynarayanan

Pursuing BPM? Avoid Reuse Inhibitors

December 20, 2010

Implementing business process re-engineering and/or automation involves several moving parts from a technology perspective – stateful business process data, interfaces for external systems/user interfaces to interact with process information, and rules that determine several aspects of process behavior.

Here are some practices to avoid/minimize when pursuing BPM projects:

Building monolithic process definitions – as the number of process definitions increase there will be opportunities to refactor and simplify orchestration logic. As projects start to build on existing processes, there will be an increasing need for modular process definitions that can be leveraged as part of larger process definitions.
Placing business rules that validate domain objects in the process orchestration graphs. This will effectively tightly couple rules and a specific process hurting the ability to reuse domain-specific rules across process definitions. Certain class of rules could change often and need to be managed as a separate artifact.
Invoking vendor specific services directly from the process definition. Over time this will result in coupling between a vendor implementation and multiple process definitions. This also applies to service capabilities hosted on legacy systems. Hence, the need to use a service mediation layer.
Defining key domain objects within the scope of a particular process definition. This will result in multiple definitions of domain objects across processes. Over time, this will increase maintenance effort, data transformation, and redundant definitions across processes and service interfaces.
Integrating clients directly to the vendor-specific business process API. This will result in multiple clients implementing boiler plate logic – better practice will be to service enable these processes and consolidate entry points into the BPM layer.

This isn’t an exhaustive list – intent is to to highlight the areas where tight coupling could occur in the business process layer.

Leave a Comment » | BPM, Design, Reuse, SOA | Tagged: abstraction, BPM, Business process management, business rules, decoupling, service mediation, SOA, systematic reuse | Permalink
Posted by vijaynarayanan

5 Reasons for Building Tactical Services

October 7, 2010

Tactical services introduce higher than necessary coupling between service providers and consumers and have brittle contracts that forcing service implementation changes on consumers. They do not reuse standard schemas and datatypes increasing data transformation and integration costs and could tightly couple service business logic and transport-specific logic.

In short, tactical services inhibit reusability, increase maintenance costs and reduce the overall effectiveness of service oriented architecture (SOA) efforts.

So, why do teams end up with tactical services? Here are five reasons:

Lack of time to design proper service interfaces – service contracts are rushed to clients exposing needless internal details, introducing redundant business object definitions, and providing inconsistent behavior
Lack of a conceptual data model – if there isn’t a conceptual data model, capturing key domain concepts and their relationships – it is natural that multiple service operations start to define concepts in their unique way.
Insufficient coordination between teams building service capabilities within the domain – when teams don’t talk to each other, many opportunities to reuse schemas, service semantics, behavior, and utilities are lost. As the number of teams increase, there is a greater need for service governance and alignment across projects.
Lack of coherent strategy tying business process management, business events, and messaging within the context of service development. Business processes could be service enabled and standard business schemas can be used to notify interested consumers. However,without an overall strategy – teams will look at these independently thereby increasing implementation costs and missing opportunities for greater alignment.
Insufficient technical leadership – when confronting multiple projects that are either occurring within a short time window or back to back, it is critical to demonstrate leadership. Why? there needs to be strong voice evangelizing use of business facing services, loosely coupled interfaces, and mediating service requests.

Leave a Comment » | Design, Planning, Reuse, SOA | Tagged: Business process management, schemas, Service-oriented architecture, SOA, software reuse, tactial services | Permalink
Posted by vijaynarayanan

Reuse Core Components in Biz Processes and Services

April 19, 2010

There are a variety of components – that can encapsulate business logic (either simple algorithm/calculations or even complex orchestrations). These components can be invoked from business process orchestrations as well as stateless services. These reusable components could be business rules integrated as decision services or legacy services wrapped using a more decoupled interface. Business events such as a new account being opened or a new security getting added to a portfolio could trigger a core piece of logic – e.g. get statement preferences – that can be used to fulfill both these needs.

For instance, in the diagram below that two business processes and a stateless service invoke a common component via a request dispatcher (or a router module).

If you tightly couple a piece of logic that is applicable across business processes or service capabilities you can refactor it to create a new resuable component. This is all the more reason why it is a good idea to go through a service mediation layer when leveraging legacy services from business processes. If you decide to reuse the legacy service in a new orchestration it will be straightforward to plugin a new consumer.

Leave a Comment » | BPM, Design, Reuse, SOA | Tagged: BPM, Business process management, service capabilities, Service-oriented architecture, SOA, software reuse | Permalink
Posted by vijaynarayanan

Getting Organized for SOA Success

June 27, 2009

There are many organizations – large and small – undertaking SOA initiatives. As much as the technical infrastructure, message processing, service governance, and web service monitoring are important for your SOA you cannot afford to ignore the organizational aspects. In this post, I want to not focus on your entire enterprise but your department or a group of development teams undertaking SOA initiatives. When aspiring for SOA success you have to have more than developers and technical leads on your side.

So who else needs to be involved? You need your requirements analysts, your data modelers, and production support staff all singing the SOA tune albeit in their unique voices. This post will talk about requirements analysts. wrongtarget

Many developers underestimate the impact of requirements analysts (also referred to as system analysts or business analysts). Some analysts mix requirements with design offering specific solutions to business needs. Requirement specifications end up becoming design documents. Why is this a limiting factor for SOA? Because, you want to identity candidate services, reuse existing service capabilities, refactor legacy and modern assets and govern these service capabilities as part of your SOA strategy. Imagine, sifting through a requirements document that specifies implementing functionality as stored procedures or batch jobs. Without care, this can influence your thinking – knowingly or unknowingly binding you into solutions that are not in line with your SOA goals.

You want your requirements analysts to specify the business processes the application needs to automate, enhance and the business capabilities required. You can then deduce the business services, the enterprise data services, and the BPM workflows that need to be developed. If your analysts are receptive you should persuade them to use a modeling tool that can specify an analysis model using a vendor neutral notation that can be imported into a BPM engine and converted into an execution flow. All said and done, the deeper point isn’t BPM or analysis model but about the what of the system. Using the what you can design the how. That is where SOA comes in addressing questions around what services you will build, which ones you can integrate with, which ones to decommision, and which ones to change. Requirements should clarify and not prematurely solve technical problems.

Ask your analysts to provide world class requirements including functional and non-functional ones. Persude them to stay away from providing technical solutions so you can figure out how to automate your firm’s processes within the context of your SOA efforts. This isn’t easy and won’t be possible with every project but that shouldn’t prevent you from trying!

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

: : : : :