There is no dearth of information available in IBM Business Process Manager support site about best practices. The best practices recommendations in the support site are highly recommended. However this article is not aimed at repeating those technical aspects of the best practices, but rather would highlight some of the issues which had to be dealt from an architectural, design and requirement gathering perspective.
In-flight instance management
One of the most challenging aspects of BPM architecture is in-flight instance management. It is a bitter truth that people learn about the best practices involved in managing in-flight instances after their first successful project release, which is too late. There are various aspects of design elements which need to be applied to take care of in-flight instances.
Process Modeling – “Encapsulate what varies”
A process model must be an abstraction of the business process. Going by these lines, it is critical to identify the part of the process model which is going to change frequently. Of course, this needs some serious business thinking. It is good idea to encapsulate the variations in process model into a sub-process. Any changes in future would not affect the top level business model but rather changes in sub-process. So if there are major changes in sub-process from version1, then a new version (version2) of sub-process can be replaced with changes from version1. Again, this won’t have any effect on the parent process. But parent process should have a variable based routing mechanism. For instance, a variable named version number should be declared in the parent process, and this variable should be incremented for each release. Based on the version number in parent process, either version1 sub-process or version2 sub-process can be invoked.
Process Data Structure – “Open for extension, closed for modification”
Another design element which is quite crucial for in-flight instance management is process data structure. IBM Business Process Manager recommends no drastic changes to process data structure, and this will directly affect the in-flight instances. The process data structure should strictly represent the domain model, but not necessarily with all attributions, but only with key elements and identifiers. Any element removed from the data structure would break the in-flight instances. So, detailed attention is required in designing process data structure. In short process data structure should be closed for modification but open for extension.
Testing of migrated instances
With having the best in-flight instance handling mechanism, it is no guarantee that the migrated instances would work without proper testing. It is a good idea to mimic the production environment to a stage environment and test all the migrated instances. The IBM Business Process Manager production database must be replicated in stage so that the process instances would be left in the same state as in production. This would give a good insight of the actual behavior of migrated instances in stage before going LIVE.
Coaches
One principle which has to be religiously followed when it comes to IBM Business Process Manager coaches is DRY (Don’t Repeat Yourself). It can be as simple as a header logo of a company which should be embedded as a custom HTML component rather than embedding in every coach. If a coach needs to be duplicated then it is rather a good practice to change the encapsulating general system service which holds the coach. For instance, if a same coach needs to be presented with different data set, then the services have to be duplicated to load the respective data set, without duplicating the coaches.
The same principle applies for authorization of HTML elements. It is advisable to encapsulate the common HTML elements in a custom HTML component and invoke the custom component from different coaches.
Some of business requirements may mandate for extreme customization of coaches. IBM Business Process Manager recommends the usage of Yahoo User Library (YUI). In my personal opinion, jQuery may not be bad option at all.
Process Instance Search
A ubiquitous requirement for any BPM solution would be a process instance search framework. From a user point of view, it is quite important and fundamental functionality since without a specific instance intended for the user, the user will have no activity to work on. Zeroing on a particular process instance would depend on the business data which often does not reside in the IBM Business Process Manager database. But IBM Business Process Manager comes to rescue in terms ‘Shared Search’ feature. However this comes with additional caveats. The user would require exposing some search parameters (business data) in process and these would be available in search criteria. This imposes several limitations, and it is not often that all business data would be available in process data structure which can be exposed as a search parameter.
This drives technical folks to circumvent the search functionality. A better suggestion would be to build a custom search framework. So here it is imperative to associate the process instance identifier of IBM Business Process Manager with the business data which can reside in an application schema. So if business data can be filtered, its associated process instance identifier can be fetched and in turn it can be associated with BPM artifacts.
Source - http://bpmstech.blogspot.com/2011/05/lombardi-best-practices.html
In-flight instance management
One of the most challenging aspects of BPM architecture is in-flight instance management. It is a bitter truth that people learn about the best practices involved in managing in-flight instances after their first successful project release, which is too late. There are various aspects of design elements which need to be applied to take care of in-flight instances.
Process Modeling – “Encapsulate what varies”
A process model must be an abstraction of the business process. Going by these lines, it is critical to identify the part of the process model which is going to change frequently. Of course, this needs some serious business thinking. It is good idea to encapsulate the variations in process model into a sub-process. Any changes in future would not affect the top level business model but rather changes in sub-process. So if there are major changes in sub-process from version1, then a new version (version2) of sub-process can be replaced with changes from version1. Again, this won’t have any effect on the parent process. But parent process should have a variable based routing mechanism. For instance, a variable named version number should be declared in the parent process, and this variable should be incremented for each release. Based on the version number in parent process, either version1 sub-process or version2 sub-process can be invoked.
Process Data Structure – “Open for extension, closed for modification”
Another design element which is quite crucial for in-flight instance management is process data structure. IBM Business Process Manager recommends no drastic changes to process data structure, and this will directly affect the in-flight instances. The process data structure should strictly represent the domain model, but not necessarily with all attributions, but only with key elements and identifiers. Any element removed from the data structure would break the in-flight instances. So, detailed attention is required in designing process data structure. In short process data structure should be closed for modification but open for extension.
Testing of migrated instances
With having the best in-flight instance handling mechanism, it is no guarantee that the migrated instances would work without proper testing. It is a good idea to mimic the production environment to a stage environment and test all the migrated instances. The IBM Business Process Manager production database must be replicated in stage so that the process instances would be left in the same state as in production. This would give a good insight of the actual behavior of migrated instances in stage before going LIVE.
Coaches
One principle which has to be religiously followed when it comes to IBM Business Process Manager coaches is DRY (Don’t Repeat Yourself). It can be as simple as a header logo of a company which should be embedded as a custom HTML component rather than embedding in every coach. If a coach needs to be duplicated then it is rather a good practice to change the encapsulating general system service which holds the coach. For instance, if a same coach needs to be presented with different data set, then the services have to be duplicated to load the respective data set, without duplicating the coaches.
The same principle applies for authorization of HTML elements. It is advisable to encapsulate the common HTML elements in a custom HTML component and invoke the custom component from different coaches.
Some of business requirements may mandate for extreme customization of coaches. IBM Business Process Manager recommends the usage of Yahoo User Library (YUI). In my personal opinion, jQuery may not be bad option at all.
Process Instance Search
A ubiquitous requirement for any BPM solution would be a process instance search framework. From a user point of view, it is quite important and fundamental functionality since without a specific instance intended for the user, the user will have no activity to work on. Zeroing on a particular process instance would depend on the business data which often does not reside in the IBM Business Process Manager database. But IBM Business Process Manager comes to rescue in terms ‘Shared Search’ feature. However this comes with additional caveats. The user would require exposing some search parameters (business data) in process and these would be available in search criteria. This imposes several limitations, and it is not often that all business data would be available in process data structure which can be exposed as a search parameter.
This drives technical folks to circumvent the search functionality. A better suggestion would be to build a custom search framework. So here it is imperative to associate the process instance identifier of IBM Business Process Manager with the business data which can reside in an application schema. So if business data can be filtered, its associated process instance identifier can be fetched and in turn it can be associated with BPM artifacts.
Source - http://bpmstech.blogspot.com/2011/05/lombardi-best-practices.html
No comments :
Post a Comment