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.
April 25, 2010
One of the often-repeated reasons for not starting a reuse program is the upfront investment required for building the initial set of reusable assets. This is a legitimate impediment that can be addressed by taking advantage of existing code in your team. When you evaluate existing assets for their reuse potential, there are a lot of factors to consider. Here are a few salient ones:
- Fit within product line: is the asset of relevance to one or more applications in your domain? You want to invest in assets that encapsulate business functionality that can be utilized in multiple business processes and applications. Similarly, if there are assets with business relevance but in a area that your organization intends to divest out of – you will be less inclined to use them.
- Coupling: How tightly or loosely coupled are the pieces within an asset? sometimes the asset itself might be mixed in – tightly coupled – with a lot of extraneous code. Business logic might be mixed with data access, presentation, and even specific calls to external systems. Every one of these aspects introduces coupling that will need to be assessed thoroughly.
- Integration: what is the effort required to integrate the reusable asset with applications? The asset might be very difficult to integrate because of platform specific requirements or because of language needs.
- Business Assumptions: are there assumptions that the asset makes about business rules or business activities? if so, are these assumptions still relevant? will the rules need externalization/refactoring? Often, business assumptions are lost due to lack of alignment between business concepts and abstractions in code.
In a followup post, I will elaborate on robustness, scalability, deployment, documentation & samples. Without thinking through these aspects it is risky to introduce new assets for reuse. You will quickly discover that your consumers are unforgiving when it comes to asset quality. Additionally, a huge learning curve will drive away potential and existing developers and technical leads from evaluating assets for use with new applications.
October 12, 2009
If BPM is part of your technology landscape then it sure can be leveraged for success with systematic reuse. Given that objective, what capabilities should the BPM layer provide? I am not talking about the BPM engine’s core capabilities. I am referring to capabilities that will enable the BPM assets be integrated with your applications, services, and even batch processes. Here is my list. It should:
- Provide a foundation for hosting business processes that are critical for both revenue generation and operational excellence
- Provide a modeling and execution environment for designing and implementing business processes. The modeling environment should facilitate easy integration of existing assets.
- Provide a reusable data structure for initializing, manipulating, and enriching business process state. This data structure should also facilitate simpler data transformation when dealing with entity services. See my earlier post for more on this recommendation.
- Provide meaningful APIs that ease developer learning curve when interacting with the business process layer. The real value add here could be to seamlessly integrate your BPM API alongside your other reusable assets. E.g. state management, metrics, logging, and other domain-relevant capabilities are all relevant here.
- Offer simple APIs to initiate business processes, create/assign tasks, check status of a long running process from a variety of applications. You can certainly service-enable your business processes so this can be accomplished.
- Provide the ability to access and orchestrate activities requiring interaction with entity services, business services, and business rules.
- Reduce application to application coupling by publishing standard set of business events from various milestones in the business process. Interested subscribers can react to the same event differently. New subscribers can be added via configuration as well.
- Ensure business processes can map back to domain entities, events, and relationships
- Reduce time to market for developing new processes as well as implementing changes to existing processes. Likewise, it should reduce learning curve for developers to identify, reuse, and orchestrate business processes from a library of processes components. This library shouldn’t be BPM-specific and needs to be integrated with the other reusable software assets.
This isn’t all encompassing by any means. What can be added or changed to this list?
Like this post? Subscribe to RSS feed or get blog updates via email.
September 19, 2009
Tip #18 -Separate Request Origination From Processing
Often times you have a core piece of processing logic that weaves together a variety of components and services in order to fulfill use cases. The processing logic might be a sequential procedure, a stateful business process, or a stateless service capability. You typically implement complex processing within the context of projects that has a defined manner in which the processing logic will be invoked. It is useful to decouple request origination from processing. The idea is that you want to reuse the processing logic in a variety of scenarios and don’t want to depend on the specific nature of how requests are sent for processing from a particular application. For example, let’s say you implement an order processing service that looks up the order details, executes business rules to validate order information, and runs inventory and credit check and notifies a shipping module. This might be built for an application that sends requests using a web-based form. You can isolate the logic that constructs order processing requests that assumes the execution environment and user type etc. That way the order processing modules can be used via asynchronous messaging, for business-to-business integrations, composite services, etc. Additionally, if you want to invoke processing via bulk upload using an excel file or text extracts you can construct the request accordingly and submit it to the same processing modules. If your processing logic is too tightly bound to a web-based form being the input your reuse potential is diminished. If not, do plan to refactor the tightly coupled logic.
Like this post? Subscribe to RSS feed or get blog updates via email.
: : : : :