Agenda
BPM in the Cloud - Advantages
- Multitenancy
- Dynamic Scaling
- Elastic Resource Capacity
Identity Management for BPM Solutions
Cloud-to-on-premise Connectors
BPM Topologies
BPM in the Cloud Architecture
Showing posts with label BPM. Show all posts
Showing posts with label BPM. Show all posts
Thursday, August 15, 2013
Why process mining is important to BPM?
A different perspective on process mining approach - my latest post published on BPMLeader.com
Why process mining is important to BPM?
Why process mining is important to BPM?
Friday, February 24, 2012
BPM System Architecture
The BPM System Architecture is
the workhorse of an organization’s BPM vision to fulfill its strategic BPM
needs and objectives. This article aims to provide insights into the BPM System
Architecture and how it should be devised and evolved to fully support a
seamless, scalable and dynamic platform for process implementation. Most
organizations in today’s world would purchase a packaged BPM suite which has
abundant features out of the box that support’s the entire BPM lifecycle,
rather than an in-house built custom BPM platform. The need for a BPM System
Architecture is even more imperative for a packaged BPM suite, since the
packaged products must be judiciously aligned within the scope of the
enterprise architecture (EA) of an organization. A home grown BPM platform
would have a lesser challenge in terms of fitment into enterprise architecture
since it would have evolved within the EA scope right from the beginning.
The packaged BPM suites would
seem to be more exciting and successful when implemented on a small scale like
proof of concepts. However when these suites are stretched for a full fledged
implementation, its short comings may lead to a colossal failure. A BPM suite can handle 10 process
implementations with ease, but when it comes to hundreds and thousands of
processes, a trivial mistake or a minuscule short coming in the BPM suite would
proportionately increase the rate of failure.
It is imperative that a BPM
System Architecture is built so that a packaged BPM suite can be seamlessly
integrated into an Enterprise Architecture. This article will provide insights
and glimpses of BPM reference architecture.
Process Data versus Business Data
The process data is the one which supplements the process, but not crucial for the actual completion of the process. KPI, SLA and metrics are few examples of process data. A KPI or SLA might be based on a business data but as such it may not be required for process execution. Business data is the actual driver of the process and would take it to completion. In an Insurance industry the business data would look like, an insurance id, a claim id, insurance expiry date etc. Business data is critical for process execution and the process directly depends on the business data for the process to complete.
The BPM System Architecture
should clearly differentiate between the process data and the business data.
The business data would most probably reside in an independent repository
(database) and would be accessed via an abstraction layer like SOA. The process
data would be derived from the business data by the BPM suite and would reside
in the BPM suite database.
The BPM System Architecture must
clearly define the business data identifiers that a process should be aware of.
For instance, an insurance process must be only aware of insurance id. Anything
beyond that would be a nightmare to sync the process and business data. If the
process data is defined with insurance id and insurance expiry date, then any
changes to the insurance expiry date in the external systems must be synced
with the process data, which would be a nightmare if the number of business
attributes in the process data grows. Instead the process should only be aware
of the insurance id and when the process requires the insurance expiry date, it
needs to be pulled up from the external system using the insurance id. In other
words, the best practice to define process business attributes is to define it
with unique business identifiers. An insurance id would be a unique identifier
and all relevant details pertaining to the insurance policy can be pulled from
the insurance id.
Process data like KPI and SLA
can be derived again from business data. If an SLA needs
to be defined on the insurance expiry date from the process, with the insurance
id, the insurance expiry date required for SLA
computation can be pulled from the external system and SLA
can be derived. The SLA data for the insurance expiry
date can reside in the process repository.
The BPM System Architecture should
define a framework (like an integration component) which would act like a nerve
centre to pull business date from the process with the help of unique business
key attributes.
Long running process
Failure of process instance cannot be always avoided. But what would be unavoidable, is of course the graceful recovery of the process instance. A process instance can fail for variety of reasons ranging from unavailability of system resources, data issues, network outages and technical glitches. The more prominent of these are the data issues.
A process instance in a telecom infrastructure provider would typically execute for months. If the telecom provider has a process implementation, to lay trans-Atlantic cables from continental United States to Europe, such a process instance can get executed for multiple months. In due course of time, if the process instance fails, the situation may not demand to create the process instance altogether from the beginning of the process and it is more likely it may not be possible at all, since the business data has undergone changes in due course of the process traversal. In such scenarios the process instance no matter what has to be gracefully recovered.
Failure of process instance cannot be always avoided. But what would be unavoidable, is of course the graceful recovery of the process instance. A process instance can fail for variety of reasons ranging from unavailability of system resources, data issues, network outages and technical glitches. The more prominent of these are the data issues.
A process instance in a telecom infrastructure provider would typically execute for months. If the telecom provider has a process implementation, to lay trans-Atlantic cables from continental United States to Europe, such a process instance can get executed for multiple months. In due course of time, if the process instance fails, the situation may not demand to create the process instance altogether from the beginning of the process and it is more likely it may not be possible at all, since the business data has undergone changes in due course of the process traversal. In such scenarios the process instance no matter what has to be gracefully recovered.
Let us assume that for the
process described above, the process instance gets stuck at an activity where
the process instance expects the length of the cable between pier A and pier B
to be of certain length, whereas the business data for cable length is out of
that range for what the process instance expects. For the process instance to execute, the
business data for cable length needs to be updated in the source record. The
BPM System Architecture should have a mechanism to refresh the process with
latest business data after the update and should recover gracefully.
Also, all long running processes
which are vulnerable to failures and are critical to business wherein the re-creation
of the instance is not possible, the actual business process must be
supplemented with a background recovery process. The background recovery
process must be designed in such a way that it must be capable enough to
replicate any process instance and can hold the same state as the failed
process instance before the failure. The input to the recovery process must be
the business key attribute and the activity of the process from where the
process instance has to start. This input activity would be the same as the
failed process instance step. In order to design such a recovery process, it is
absolutely essential to separate the business data and process data. Without
this it would be very difficult to create a process instance from a specific activity
within the process, since the newly created process instance should reflect the
exact state of the failed process instance. This is only possible by
associating the business data of the failed process instance to the newly
created instance.
A large scale BPM implementation would require a unified user interface for the business user community. The out of the box portal packaged in the BPM suite may not be flexible enough for extreme customizations. Also, process instance search is a ubiquitous functionality which would act as a first interfacing point for the user.
The BPM System Architecture is
responsible for a process instance search framework. The challenge to build
such a framework would be to integrate both the process and the business data
in one single view. A process instance can be searched with a business
attribute as a parameter and also the search can be performed with process data
such as SLA.
One possible technical solution is to combine the process data and business data together as Database view, by which expensive database joins can be avoided between multiple tables of the business data schema and process data schema.
BPM Exception Handling
Exception handling is one of the prime aspects of software design which attributes to the robustness of the application. Exception handling gains more significance in BPM space, since exceptions had to be dealt both at a system level and at a business level.
The significance of exception handling at a process modeling step cannot be ignored. There is a need to handle ACID transactions in BPM, with a business solution and it has to be captured in the model with business semantics. For instance, a classic example of flight, hotel and rental car booking when deemed as a single atomic transaction cannot always be dealt at a system level. If flight booking and hotel booking are two different applications in two different domains (if flight carrier and hotel are different companies), then system transactions cannot be propagated and even if it seems to be possible, system level locks for transaction may not be possible to be obtained since the whole transaction may exceed beyond days to complete. The ideal way to deal with this situation is to have three distinct transactions as business process and even if one fails the other transactions must be canceled using a business process. If flight booking has been confirmed and if hotel booking transaction fails, then flight booking should also be canceled, wherein flight cancellation must be modeled as a separate business process.
It becomes imperative for a BPM solution to handle system level exceptions gracefully. Since process instances can span across business days, in case of system exceptions the process state has to be persisted and should be able to recover from the state where it was left. This may not be possible always for each and every process instance. Sometimes there is a good chance that a process instance may get into an irrecoverable state. In such scenarios, it may not be desirable for the users to create a new process instance altogether. The alternatives for irrecoverable instances due to system exceptions are few, and one probable solution could be to create a new process instance and associate the
application process data with the new instance, and programmatically navigate process the instance to the workflow step where it failed.
Another alternative is to create an exception business process. Any system level exception occurring in any of the application business process would trigger the exception business process, which would notify the user about the exception. Also exception process can notify a repair/admin team about the exception. Having a repair queue of exceptions can help the repair/admin team to get first hand information about the exception without the need for notification from the business users about what had happened. Also, irrecoverable process instances can be dealt internally within the IT team, without burdening the business users.
Process Versioning
A process undergoes lot of changes in a BPM lifecycle with multiple iterative implementations. The BPM System Architecture must be potent enough to handle multiple versions of process instances. Most of the modern BPM suites come pre-packaged with utilities to migrate the process instances from an obsolete version to higher versions. However, a process instance in an older version may not be always possible to migrate to a higher version, due to external system dependencies, when the external system itself would have undergone a version change along with the process. This is again in-line with the process data versus business data debate. The battle lines between process data and business data have to be carefully drawn in such way that any data on external system should not be a part of process data. A better way to hold reference to external application data is to hold reference to the unique business key attribute of the external system.
Conclusion
These are the some of the many items that must be considered for a BPM System Architecture. If the segregation between process data and application data can be achieved then having the BPM System Architecture would bring the additional flexibility in terms of solution design.
One possible technical solution is to combine the process data and business data together as Database view, by which expensive database joins can be avoided between multiple tables of the business data schema and process data schema.
BPM Exception Handling
Exception handling is one of the prime aspects of software design which attributes to the robustness of the application. Exception handling gains more significance in BPM space, since exceptions had to be dealt both at a system level and at a business level.
The significance of exception handling at a process modeling step cannot be ignored. There is a need to handle ACID transactions in BPM, with a business solution and it has to be captured in the model with business semantics. For instance, a classic example of flight, hotel and rental car booking when deemed as a single atomic transaction cannot always be dealt at a system level. If flight booking and hotel booking are two different applications in two different domains (if flight carrier and hotel are different companies), then system transactions cannot be propagated and even if it seems to be possible, system level locks for transaction may not be possible to be obtained since the whole transaction may exceed beyond days to complete. The ideal way to deal with this situation is to have three distinct transactions as business process and even if one fails the other transactions must be canceled using a business process. If flight booking has been confirmed and if hotel booking transaction fails, then flight booking should also be canceled, wherein flight cancellation must be modeled as a separate business process.
It becomes imperative for a BPM solution to handle system level exceptions gracefully. Since process instances can span across business days, in case of system exceptions the process state has to be persisted and should be able to recover from the state where it was left. This may not be possible always for each and every process instance. Sometimes there is a good chance that a process instance may get into an irrecoverable state. In such scenarios, it may not be desirable for the users to create a new process instance altogether. The alternatives for irrecoverable instances due to system exceptions are few, and one probable solution could be to create a new process instance and associate the
application process data with the new instance, and programmatically navigate process the instance to the workflow step where it failed.
Another alternative is to create an exception business process. Any system level exception occurring in any of the application business process would trigger the exception business process, which would notify the user about the exception. Also exception process can notify a repair/admin team about the exception. Having a repair queue of exceptions can help the repair/admin team to get first hand information about the exception without the need for notification from the business users about what had happened. Also, irrecoverable process instances can be dealt internally within the IT team, without burdening the business users.
Process Versioning
A process undergoes lot of changes in a BPM lifecycle with multiple iterative implementations. The BPM System Architecture must be potent enough to handle multiple versions of process instances. Most of the modern BPM suites come pre-packaged with utilities to migrate the process instances from an obsolete version to higher versions. However, a process instance in an older version may not be always possible to migrate to a higher version, due to external system dependencies, when the external system itself would have undergone a version change along with the process. This is again in-line with the process data versus business data debate. The battle lines between process data and business data have to be carefully drawn in such way that any data on external system should not be a part of process data. A better way to hold reference to external application data is to hold reference to the unique business key attribute of the external system.
Conclusion
These are the some of the many items that must be considered for a BPM System Architecture. If the segregation between process data and application data can be achieved then having the BPM System Architecture would bring the additional flexibility in terms of solution design.
Tuesday, February 14, 2012
IBM Business Process Manager - Mastering Pitfalls
IBM Business Process Manager erstwhile Teamworks Lombardi is one of the top selling BPM suites in the market. IBM Business Process Manager has some excellent features and some innovative concepts which enhance BPM development. However it is imperative for an organization to know about its key features and some of the disadvantages it brings along with its features. These short comings can be easily overcome and one easiest way to do that is to become aware of the short coming itself.
Branching and Merging in IBM Business Process Manager
IBM Business Process Manager has a shared development model. Unlike the traditional software development, the IBM Business Process Manager code base is maintained in a Process Center environment. A Process Center environment is not a source control by itself; however the IBM Business Process Manager artifacts are stored in the Process Center. The code base for a process application is maintained in a Process Center.
The run-time instance (executable) of the process application (code base) is known as Snapshot. A Snapshot can be deployed into any of the IBM Business Process Manager run-time process servers. The code base for a process application cannot be branched nor merged. Although, branching can be done by creating a Workspace in IBM Business Process Manager, there is no way to merge the branches.
This important aspect of this short coming in IBM Business Process Manager is that the Agile projects have to be planned meticulously. If a project plan mandates parallel development for a same process application, then there is no way in IBM Business Process Manager to merge the parallel branches into a single trunk.
Process instance data cannot be modified
Long running process instances are vulnerable to failures. Some of the failed instances may be irrecoverable due to data issues. For example, a particular variable in a business process needs to be set to a certain value to take a certain path in the business process flow. The business process data due to system issues or code issues might have got a wrong set of data and it would become necessary to read and update the business process data when the process is active. IBM Business Process Manager has an API to read the data, unfortunately does not have a good way to update the data, since the process data is stored as BLOB.
To circumvent this problem, the usage of business process data has to be minimized. Only business key attributes or in layman terms, primary key attributes in the application data needs to be mapped to the business process data. By mapping the primary key data as business process data, a loose coupling between the business process and the application data is achieved, thereby the application data would have more freedom to change without the necessity of keeping the business process data in sync. There is a huge debate on what needs to map to business process data and what has to go into the application data, which itself becomes a separate topic to explore and it is well outside the context of this article.
IBM Business Process Manager stores most of the process related data as BLOB's
A typical software application’s life cycle regions include Development (DEV), System Integration Test (SIT), User Acceptance Environment (UAT) and Production (PROD). After every release to production, a good practice is to mirror the entire PROD data into different regions. This is no exception for BPM applications, and IBM Business Process Manager presents itself another challenge to implement this setup. Since process data in IBM Business Process Manager are stored as BLOB’s, there is a challenge for DBA’s to replicate the BLOB’s in lower region databases.
Also if the application data model and the IBM Business Process Manager data model are two different schemas, then there is an additional challenge in maintenance of data states after the production refresh. It becomes imperative for DBA’s to understand the complete data model of the Process Manager to synchronize the tables required to reflect the state and to ignore the tables which represents the run-time dynamics.
Also refer, BPM Data Model Architecture.
Workspace cannot be deleted
The need for Workspace arises when the code needs to be branched out of a particular Snapshot. For example, if there is a defect in a production release and the current Development release has progressed into the next version of Snapshot, a branch of production Snapshot is required and Workspace comes for rescue. Any version of the Snapshot can be branched out to a Workspace, however it cannot be merged to another Workspace as discussed already. Workspace created cannot be deleted from Process Center leaving a scar for potential misuse. Multiple Workspace would lead to confusion and there is always a possibility of developer choosing a wrong Workspace.
Creation of Workspace cannot be avoided, but with proper naming convention and standards, a potential misuse or accidental usage of a wrong Workspace for a wrong version can be avoided.
Process applications in Process Center cannot be deleted
Process applications in Process Center cannot be purged. This is mostly a sanity related aspect of maintaining the code base in the Process Center. Over a period of time the Process applications tend to grow and there would be a need to purge some of the obsolete Process Applications which would be no longer required. Unfortunately there is no way in IBM Business Process Manager, a Process application can be purged. A better way to avoid this situation is to have tighter governance and strict privileges within the developer community on who can create a Process application.
Monday, June 6, 2011
BPM Data Model Architecture
One of the primary assets of a BPM suite is how it manages the process data. Execution, monitoring and improving the process would heavily depend on the process data which the process engine manages. Process data in BPM suites are persisted as two flavors. Some suites store them as BLOBs and some products save the data in a relation data model. This article explores the two possible routes BPM vendors undertake.
A BPM suite when stores the process data using relational data model would give the technical users great insight and transparency into the process data. Also, users will have the ability to track the process data against each step of execution of the process. Tracking and reporting of historical process data would be a cake walk and the required data can be just pulled using a SQL query.
Having a relational data model for process data also means, that a third party Business Intelligence tool can be plugged into the process database for advanced BI activities. Also, versioning and in-flight instance management of process could be better handled by the BPM suite. The performance of the process engine itself would be greatly enhanced, since the engine is not required to parse the BLOBs to act on the process data, rather it has to just fetch from the database.
Typically, in relational data model, a process is represented as a database table. When a new process is created, a new database table will be created and would be associated with the process. So as the number of business processes keeps growing, so are the database tables, and so does the data model which also grows when the processes keeps increasing. Unlike, when the process data is stored as BLOBs a huge monolithic block of a single database table grows, with data model being frozen, highly impacting the database performance.
Moreover, the BPM product architecture would be highly scalable for the future demands of BPM features. For example, if a new or existing feature of a XPDL (XML Process Definition Language) schema needs to be implemented; having the process data in database instead of BLOBs would greatly enhance the ease of implementation.
Process data stored as BLOBs does not hold any significant advantage over relation data model. So, why some BPM suites went with this approach? It may be best answered by the BPM product vendors who choose to store process data as BLOBs.
A BPM suite when stores the process data using relational data model would give the technical users great insight and transparency into the process data. Also, users will have the ability to track the process data against each step of execution of the process. Tracking and reporting of historical process data would be a cake walk and the required data can be just pulled using a SQL query.
Having a relational data model for process data also means, that a third party Business Intelligence tool can be plugged into the process database for advanced BI activities. Also, versioning and in-flight instance management of process could be better handled by the BPM suite. The performance of the process engine itself would be greatly enhanced, since the engine is not required to parse the BLOBs to act on the process data, rather it has to just fetch from the database.
Typically, in relational data model, a process is represented as a database table. When a new process is created, a new database table will be created and would be associated with the process. So as the number of business processes keeps growing, so are the database tables, and so does the data model which also grows when the processes keeps increasing. Unlike, when the process data is stored as BLOBs a huge monolithic block of a single database table grows, with data model being frozen, highly impacting the database performance.
Moreover, the BPM product architecture would be highly scalable for the future demands of BPM features. For example, if a new or existing feature of a XPDL (XML Process Definition Language) schema needs to be implemented; having the process data in database instead of BLOBs would greatly enhance the ease of implementation.
Process data stored as BLOBs does not hold any significant advantage over relation data model. So, why some BPM suites went with this approach? It may be best answered by the BPM product vendors who choose to store process data as BLOBs.
Friday, June 3, 2011
Quest for Search functionality in BPM
It is quite often that we come across requirements in BPM/SOA projects to implement search functionality. Search is a ubiquitous functionality and is becoming an integral part of every software suite. A lot of product suites have in built search capabilities, but are limited, not customizable and extensible and quite cumbersome needing off the shelf implementation for the advanced search functionalities. Again implementing search functionality on a BPM SOA can be quite complex since the purview of such projects are not specific to single applications tied to specific platforms.
Traditionally, developers have implemented search functionalities using powerful APIs like Lucene, Compass etc. Venturing into search APIs for BPM SOA projects would quickly turn the implementation into nightmare. And on top of this the data to be searched might live on the bus or MOM.
What would ideally constitute good search functionality?
1. Should require less effort to implement and shouldn’t involve any core search APIs to be embedded in the applications. In other words, developers should not do any specific coding related to search functionality.
2. A stand alone search engine not tied to a specific system. The search engine itself should reside and function as a separate application.
3. Should be interoperable with other systems - RESTful, JSON, SOAP based queries for searching.
4. Should support XML search, Word/PDF handling and basic text search.
If your requirements sound similar to the above points, the Apache Solr might be your next search engine. Checkout Apache Solr.
Traditionally, developers have implemented search functionalities using powerful APIs like Lucene, Compass etc. Venturing into search APIs for BPM SOA projects would quickly turn the implementation into nightmare. And on top of this the data to be searched might live on the bus or MOM.
What would ideally constitute good search functionality?
1. Should require less effort to implement and shouldn’t involve any core search APIs to be embedded in the applications. In other words, developers should not do any specific coding related to search functionality.
2. A stand alone search engine not tied to a specific system. The search engine itself should reside and function as a separate application.
3. Should be interoperable with other systems - RESTful, JSON, SOAP based queries for searching.
4. Should support XML search, Word/PDF handling and basic text search.
If your requirements sound similar to the above points, the Apache Solr might be your next search engine. Checkout Apache Solr.
Thursday, June 2, 2011
Is it a right time for Federated BPM?
“BPM is an organization wide initiative” was the most famous premise a few years back. But for all practical reasons, organizations started BPM and SOA initiatives in pockets. Over the time, organizations ended up with few BPM domains with different governance models. There can be variety of compelling reasons for an organization to have different BPM domains, and some of the decisions might have happened without choice.
Mergers and Acquisitions (M&A) was one of the primary reasons for BPM selling like hot cakes. But with M&A came a different challenge, with merged or acquired organizations already having a BPM infrastructure, a choice was needed to be made for migration of the business processes into a single unified platform. This proved to be expensive and risky, and so without choice organizations settled for multiple BPM domains. Also, diversification of vendors had caused many organizations with diverse BPM domains, with different BPM product stacks.
Federated BPM is the need of the hour. With federated BPM, one of the existing BPM domains in the organization has to act as a master and rest of the BPM domains as dependent domains. Usually the domain with the most visible and top level business processes would be chosen as a master domain. All the top level business processes would be triggered from the master domain and subsequently routed to dependent domains.
Federated BPM is more of an enterprise architectural strategy which comes with a lot of challenges. Users might need a unified process portal platform, universal BAM and reporting capabilities, process metrics with KPIs and SLAs collated from different domains, uniform security implementation and many more. The challenges presented by Federated BPM architecture are many, but is it worth it, is it a right time for Federated BPM?
Mergers and Acquisitions (M&A) was one of the primary reasons for BPM selling like hot cakes. But with M&A came a different challenge, with merged or acquired organizations already having a BPM infrastructure, a choice was needed to be made for migration of the business processes into a single unified platform. This proved to be expensive and risky, and so without choice organizations settled for multiple BPM domains. Also, diversification of vendors had caused many organizations with diverse BPM domains, with different BPM product stacks.
Federated BPM is the need of the hour. With federated BPM, one of the existing BPM domains in the organization has to act as a master and rest of the BPM domains as dependent domains. Usually the domain with the most visible and top level business processes would be chosen as a master domain. All the top level business processes would be triggered from the master domain and subsequently routed to dependent domains.
Federated BPM is more of an enterprise architectural strategy which comes with a lot of challenges. Users might need a unified process portal platform, universal BAM and reporting capabilities, process metrics with KPIs and SLAs collated from different domains, uniform security implementation and many more. The challenges presented by Federated BPM architecture are many, but is it worth it, is it a right time for Federated BPM?
Wednesday, May 25, 2011
Exception handling in BPM
Exception handling is one of the prime aspects of software design which attributes to the robustness of the application. Exception handling gains more significance in BPM space, since exceptions had to be dealt both at a system level and at a business level. Bruce Silver has added one more dimension to exception handling in BPM, in his article, wherein exceptions had to be dealt at the process modeling itself.
The significance of exception handling at a process modeling step cannot be ignored. There is a need to handle ACID transactions in BPM, with a business solution and it has to be captured in the model with business semantics. For instance, a classic example of flight, hotel and rental car booking when deemed as a single atomic transaction cannot always be dealt at a system level. If flight booking and hotel booking are two different applications in two different domains (if flight carrier and hotel are different companies), then system transactions cannot be propagated and even if it seems to be possible, system level locks for transaction may not be possible to be obtained since the whole transaction may exceed beyond days to complete. The ideal way to deal with this situation is to have three distinct transactions as business process and even if one fails the other transactions must be canceled using a business process. If flight booking has been confirmed and if hotel booking transaction fails, then flight booking should also be canceled, wherein flight cancellation must be modeled as a separate business process.
It becomes imperative for a BPM solution to handle system level exceptions gracefully. Since process instances can span across business days, in case of system exceptions the process state has to be persisted and should be able to recover from the state where it was left. This may not be possible always for each and every process instance. Sometimes there is a good chance that a process instance may get into an irrecoverable state. In such scenarios, it may not be desirable for the users to create a new process instance altogether. The alternatives for irrecoverable instances due to system exceptions are few, and one probable solution could be to create a new process instance and associate the application process data with the new instance, and programmatically navigate process the instance to the workflow step where it failed.
Another alternative is to create an exception business process. Any system level exception occurring in any of the application business process would trigger the exception business process, which would notify the user about the exception. Also exception process can notify a repair/admin team about the exception. Having a repair queue of exceptions can help the repair/admin team to get first hand information about the exception without the need for notification from the business users about what had happened. Also, irrecoverable process instances can be dealt internally within the IT team, without burdening the business users.
In my opinion, a BPM solution should handle both business and system exceptions. Handling every exception at a process model level would clutter the process diagram with fine grained details defeating the very purpose of a business process diagram. The need for hour is a finer distinction between business and system exceptions should be made even before a process is set to get modeled. A business exception may not look like an exception at all from a BPMN perspective, since most of the business exception would be handled by a new business process altogether, instead of the intermediate handler event.
The significance of exception handling at a process modeling step cannot be ignored. There is a need to handle ACID transactions in BPM, with a business solution and it has to be captured in the model with business semantics. For instance, a classic example of flight, hotel and rental car booking when deemed as a single atomic transaction cannot always be dealt at a system level. If flight booking and hotel booking are two different applications in two different domains (if flight carrier and hotel are different companies), then system transactions cannot be propagated and even if it seems to be possible, system level locks for transaction may not be possible to be obtained since the whole transaction may exceed beyond days to complete. The ideal way to deal with this situation is to have three distinct transactions as business process and even if one fails the other transactions must be canceled using a business process. If flight booking has been confirmed and if hotel booking transaction fails, then flight booking should also be canceled, wherein flight cancellation must be modeled as a separate business process.
It becomes imperative for a BPM solution to handle system level exceptions gracefully. Since process instances can span across business days, in case of system exceptions the process state has to be persisted and should be able to recover from the state where it was left. This may not be possible always for each and every process instance. Sometimes there is a good chance that a process instance may get into an irrecoverable state. In such scenarios, it may not be desirable for the users to create a new process instance altogether. The alternatives for irrecoverable instances due to system exceptions are few, and one probable solution could be to create a new process instance and associate the application process data with the new instance, and programmatically navigate process the instance to the workflow step where it failed.
Another alternative is to create an exception business process. Any system level exception occurring in any of the application business process would trigger the exception business process, which would notify the user about the exception. Also exception process can notify a repair/admin team about the exception. Having a repair queue of exceptions can help the repair/admin team to get first hand information about the exception without the need for notification from the business users about what had happened. Also, irrecoverable process instances can be dealt internally within the IT team, without burdening the business users.
In my opinion, a BPM solution should handle both business and system exceptions. Handling every exception at a process model level would clutter the process diagram with fine grained details defeating the very purpose of a business process diagram. The need for hour is a finer distinction between business and system exceptions should be made even before a process is set to get modeled. A business exception may not look like an exception at all from a BPMN perspective, since most of the business exception would be handled by a new business process altogether, instead of the intermediate handler event.
Friday, May 20, 2011
DSL for workflow testing
Constant changes, reduced cycle times, lean structure and of course limited resources are norm of today's software development life cycle. Testing of software applications has taken a hit in modern age that customers no longer insist on separate testing teams; rather rely on unit testing and regression testing by developers.
Automation testing came to rescue but met with limited success. One of the primary reasons was automated testing focused on application testing rather than enterprise wide testing. Also, automation testing required a separate dedicated team to develop scripts. For the most part, testers have been testers, not programmers, quoted by Carl J. Nagle comes to my mind, which literally means a dedicated team of programmers are required to develop automation scripts. Needless to mention about increasing investment on resources and the upfront cost involved in procuring the automation tool itself.
BPM (workflow) testing is a nightmare. Especially, if the process holds lot of human tasks, the effort required for regression testing manifolds with time and human errors from testers cannot be ruled out completely. I've thought about an inexpensive alternative with the help of Domain Specific Languages for workflow testing. Let me illustrate with an example,
Typically a QA tests the following in a BPM Application Portal.
* Logins into Portal
* Searches for tasks based on some artifact keys.
* Saves/Completes some assigned tasks.
* Creates process instances.
* Waits for some tasks.
These are the few of the many items that a tester or a Business Analyst does, not necessarily in the same order except for the first item.
Now the Domain Specific Language (DSL) which is to be built abstracts only high level tasks the user performs and gives the ability to the user to write his own scenario for automated testing.
For example, if the user wants to search a task, create an artifact like Payroll and then complete the task, he would simply write as,
login_into_portal_as_user(scott)
tasks[] = search_for_tasks(‘Assigned’, ‘Available’)
iterate all tasks
if task is ‘Payroll’
create_paystub (current_date, pay_amount, employee_details)
complete.task
end
The above DSL code is very granular, but with further analysis and level of testing required we can build the DSL functions at coarse grained level, which would limit and simplify the number of lines a tester/user have to use to build scenarios.
One of the objectives for building custom DSL is that anybody from non developer community can write test case scenarios making use of DSL. The above mentioned syntaxes are just examples and can be made much simpler or close to readable English.
DSL's can definitely complement performance testing tools as well. The DSL testing code need not be in the above format; even as XML would do and having DSL on top of any other workflow testing tool means that the services alone will be tested for functionality.
DSL for testing at a BPM Portal level would better comprehend what an actual tester does. Web flow / UI Level automated testing comes with some disadvantages too, due to the fact that DSL objects are highly dependent on HTML source.
DSL’s are evolutionary and the functionality that have to be tested using DSL should be built brick by brick. Dynamic scripting languages are good candidates for building DSL, reason being faster development time opposed to using a high level language. Ruby + ‘Watir’ (pronounced as water and is a Ruby gem) are a good choice for building a DSL with automated UI level test scripts.
DSL for workflow testing requires constant maintenance with BPM application itself getting modified. DSL also requires a skilled programmer to develop and maintain the DSL itself. Still, with the above disadvantages, developing DSL would be much cheaper and viable option for BPM initiatives.
Automation testing came to rescue but met with limited success. One of the primary reasons was automated testing focused on application testing rather than enterprise wide testing. Also, automation testing required a separate dedicated team to develop scripts. For the most part, testers have been testers, not programmers, quoted by Carl J. Nagle comes to my mind, which literally means a dedicated team of programmers are required to develop automation scripts. Needless to mention about increasing investment on resources and the upfront cost involved in procuring the automation tool itself.
BPM (workflow) testing is a nightmare. Especially, if the process holds lot of human tasks, the effort required for regression testing manifolds with time and human errors from testers cannot be ruled out completely. I've thought about an inexpensive alternative with the help of Domain Specific Languages for workflow testing. Let me illustrate with an example,
Typically a QA tests the following in a BPM Application Portal.
* Logins into Portal
* Searches for tasks based on some artifact keys.
* Saves/Completes some assigned tasks.
* Creates process instances.
* Waits for some tasks.
These are the few of the many items that a tester or a Business Analyst does, not necessarily in the same order except for the first item.
Now the Domain Specific Language (DSL) which is to be built abstracts only high level tasks the user performs and gives the ability to the user to write his own scenario for automated testing.
For example, if the user wants to search a task, create an artifact like Payroll and then complete the task, he would simply write as,
login_into_portal_as_user(scott)
tasks[] = search_for_tasks(‘Assigned’, ‘Available’)
iterate all tasks
if task is ‘Payroll’
create_paystub (current_date, pay_amount, employee_details)
complete.task
end
The above DSL code is very granular, but with further analysis and level of testing required we can build the DSL functions at coarse grained level, which would limit and simplify the number of lines a tester/user have to use to build scenarios.
One of the objectives for building custom DSL is that anybody from non developer community can write test case scenarios making use of DSL. The above mentioned syntaxes are just examples and can be made much simpler or close to readable English.
DSL's can definitely complement performance testing tools as well. The DSL testing code need not be in the above format; even as XML would do and having DSL on top of any other workflow testing tool means that the services alone will be tested for functionality.
DSL for testing at a BPM Portal level would better comprehend what an actual tester does. Web flow / UI Level automated testing comes with some disadvantages too, due to the fact that DSL objects are highly dependent on HTML source.
DSL’s are evolutionary and the functionality that have to be tested using DSL should be built brick by brick. Dynamic scripting languages are good candidates for building DSL, reason being faster development time opposed to using a high level language. Ruby + ‘Watir’ (pronounced as water and is a Ruby gem) are a good choice for building a DSL with automated UI level test scripts.
DSL for workflow testing requires constant maintenance with BPM application itself getting modified. DSL also requires a skilled programmer to develop and maintain the DSL itself. Still, with the above disadvantages, developing DSL would be much cheaper and viable option for BPM initiatives.
Tuesday, May 17, 2011
IBM Business Process Manager Best Practices
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.
I have already posted an article on Best Practices for BPMS Design and Architecture, and the article is generic rather than tool centric. I would highly recommend reading the same and all the best practices and guidelines mentioned in that article, are applicable to IBM Business Process Manager as well.
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.
Exception Handling
http://bpmstech.blogspot.com/2011/05/exception-handling-in-bpm.html
Conclusion
This is of course not a definitive list of items. But due to limited time, I’ve published my thoughts, but there is more to come.
I have already posted an article on Best Practices for BPMS Design and Architecture, and the article is generic rather than tool centric. I would highly recommend reading the same and all the best practices and guidelines mentioned in that article, are applicable to IBM Business Process Manager as well.
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.
Exception Handling
http://bpmstech.blogspot.com/2011/05/exception-handling-in-bpm.html
Conclusion
This is of course not a definitive list of items. But due to limited time, I’ve published my thoughts, but there is more to come.
Monday, May 16, 2011
BPM Initiative
Venturing into the BPM space would make much more sense for an IT division of a company if certain practices were already considered and implemented. This would not only guarantee successful Return on Investment, but also helps win the confidence of business users. But the fact is, not too many organizations are willing to consider, and even if they consider fail to implement. Organizations get carried away by fancied product vendors, who in turn sell their tools and not concepts. So what are these practices an organization needs to plan before jumping into BPM?
Process Blueprint Stack
It is imperative for an organization to build a process blueprint stack at first, before even thinking to buy a BPM tool. Well, building a process blueprint is no simple task, and it requires enormous effort and collaboration from various stake holders of the organization. Process blueprint helps in identifying the processes to be automated and at one level below it identifies the business processes itself. Also, process blueprint not only helps identifying the critical processes but also ascertains the future demands from the business.
Building Standards and Best Practices by forming CoE
Standards and best practices ensure consistent and uniform delivery from IT. This should be regulated by forming a Center of Excellence (CoE). CoE must help the delivery teams and ensure standards are met and delivery is aligned with organization goals and principles. CoE should not do policing on teams that deviate from standards; instead CoE should try to build processes, policies and frameworks such that teams fall in trap for standards. In case of deviations, CoE must analyze the deviation and make sure they fill the hole in the policies to ensure no such deviation takes place in future.
Governance
One of the primary responsibilities of CoE is governance. Without proper governance nothing fruitful can happen and BPM is no exception. Governance with respect to BPM CoE is all about process ownership. Process ownership can be maintained by building a Responsibility Assignment Matrix charts (RAM). RAM charts helps in identifying the process owner with the process status.
Training the stakeholders
A very important and fundamental aspect of a successful BPM initiative lies in training the BPM stakeholders. Training the stakeholder on BPM concepts and making them aware of the BPM tool which the organization has acquired helps in bridging the conceptual gap. It basically ensures that BPM stakeholders talk in one language. For instance, the business requirements or software specification requirements can have BPM aspects like SLA, KPI, task routing instead of details in vanilla software terms which would cause ambiguity. Also, product promotion should be championed across the organization to make users well aware of the BPM tool. This would also help the business on what they can expect from a prospective BPM solution.
Lombardi Best Practices published as a separate post.
Process Blueprint Stack
It is imperative for an organization to build a process blueprint stack at first, before even thinking to buy a BPM tool. Well, building a process blueprint is no simple task, and it requires enormous effort and collaboration from various stake holders of the organization. Process blueprint helps in identifying the processes to be automated and at one level below it identifies the business processes itself. Also, process blueprint not only helps identifying the critical processes but also ascertains the future demands from the business.
Building Standards and Best Practices by forming CoE
Standards and best practices ensure consistent and uniform delivery from IT. This should be regulated by forming a Center of Excellence (CoE). CoE must help the delivery teams and ensure standards are met and delivery is aligned with organization goals and principles. CoE should not do policing on teams that deviate from standards; instead CoE should try to build processes, policies and frameworks such that teams fall in trap for standards. In case of deviations, CoE must analyze the deviation and make sure they fill the hole in the policies to ensure no such deviation takes place in future.
Governance
One of the primary responsibilities of CoE is governance. Without proper governance nothing fruitful can happen and BPM is no exception. Governance with respect to BPM CoE is all about process ownership. Process ownership can be maintained by building a Responsibility Assignment Matrix charts (RAM). RAM charts helps in identifying the process owner with the process status.
Training the stakeholders
A very important and fundamental aspect of a successful BPM initiative lies in training the BPM stakeholders. Training the stakeholder on BPM concepts and making them aware of the BPM tool which the organization has acquired helps in bridging the conceptual gap. It basically ensures that BPM stakeholders talk in one language. For instance, the business requirements or software specification requirements can have BPM aspects like SLA, KPI, task routing instead of details in vanilla software terms which would cause ambiguity. Also, product promotion should be championed across the organization to make users well aware of the BPM tool. This would also help the business on what they can expect from a prospective BPM solution.
Lombardi Best Practices published as a separate post.
Best Practices for BPMS Design and Architecture
This article reflects my experience and discussions with other BPM and enterprise architects. I will attempt to justify my claims, however, there are, necessarily, many matters of opinion. The best practices are specifically aimed at BPMS architectures built on J2EE platform; however a lot of common practices are applicable to BPM products and architectures outside the J2EE platform. This article assumes that a BPM product has already been in place and architecture has to be built around it, to make full use of the product along with the other enterprise applications.
Goals of BPM Architecture
Since this architecture is being built on top of J2EE platform, all the best practices for J2EE enterprise applications holds true and not repeated in this article. Common best practices like robust OO design, extensibility, scalability, reusability and maintainability are precursors for a good BPMS architecture.
Process Data
The process data which are defined and carried by the process should be light weight as far as possible. For instance, if an employee detail is needed for the process, it is advisable to have a key for employee record and fetch the aggregate details whenever necessary. This would avoid the heavy data flow across the process and also no obsolete data would be retained in the BPM system, thereby BPM can avoid the expensive sync up calls between different applications.
Integration
Integration is the nerve center of any BPMS architecture. Since BPMS itself is tied to a product, integration layer should be a separate component outside the BPMS deployable artifact. Even better the integration layer can be deployed as services. This would pave way for future SOA interactions. Also, any business logic changes in the external systems wouldn’t affect the BPM layer, there by increasing scalability and maintainability of the BPM application.
Integration Layer
It’s imperative that BPM should interact with lot of other external systems. It is desirable to have a separate integration layer rather than clubbing all the integration logic and external calls into BPM adapters itself. The external calls can be wrapped as a separate artifact or even better can be deployed as a separate application in stand-alone server. As the BPMS application grows the number of external calls will increase proportionately. If this is the case, having integration layer as a separate server will be much more scalable. The additional responsibilities for integration layer would be orchestration, data transformation, presentation layer support etc.
BPM Process Data in Presentation Layer
There is a need to present the process data in applications external to BPMS. Applications external to BPMS may not be in the same platform as the BPMS product. So the process data in BPMS have to be exposed as services. A process task might be presented in an external portal / may be in a mobile application. BPM architecture should be scalable enough to support the presentation of BPM process data as services.
Process as Service
A lot of BPM products provide capability to expose the process as a service itself. The service thus exposed should be checked for WS-1 compatibility or the latest interoperability standards. If not, it is better to have a custom developed service which would invoke the corresponding process. The in-house developed service will have more advantages in terms of flexibility, re-usability and maintainability.
Process Versioning
It is quite often that a deployed process undergoes some changes after ever release. How to make sure that any subsequent deployments would not break the in-flight instances of previous versions of the process? Well the solution for this problem cannot be addressed with one aspect. The issue of in-flight instances continues to haunt many successful programs. In-flight instance management should be dealt at an architecture and process design level. This is definitely a broader topic and the solution differs from product to product, and this calls for a separate post.
Application Data Model
There is a need to segregate the data model of the BPM product with the BPM application data. The data model of the application has to be separate from BPM product schema. Sometimes, BPM artifact data like process id, process data names have to be referred in the BPM application code. So there is a need to persist BPM process data along with the application data in application schema. Hard-coding of artifact names should be avoided in the application code and these have to be configured from a database. For instance, if process name is referred in application code, then it is advisable to have a database table with all process names and a reference from the application code can be fetched from the database table.
Exception handling
Exception handling is covered in a separate post.
Goals of BPM Architecture
Since this architecture is being built on top of J2EE platform, all the best practices for J2EE enterprise applications holds true and not repeated in this article. Common best practices like robust OO design, extensibility, scalability, reusability and maintainability are precursors for a good BPMS architecture.
Process Data
The process data which are defined and carried by the process should be light weight as far as possible. For instance, if an employee detail is needed for the process, it is advisable to have a key for employee record and fetch the aggregate details whenever necessary. This would avoid the heavy data flow across the process and also no obsolete data would be retained in the BPM system, thereby BPM can avoid the expensive sync up calls between different applications.
Integration
Integration is the nerve center of any BPMS architecture. Since BPMS itself is tied to a product, integration layer should be a separate component outside the BPMS deployable artifact. Even better the integration layer can be deployed as services. This would pave way for future SOA interactions. Also, any business logic changes in the external systems wouldn’t affect the BPM layer, there by increasing scalability and maintainability of the BPM application.
Integration Layer
It’s imperative that BPM should interact with lot of other external systems. It is desirable to have a separate integration layer rather than clubbing all the integration logic and external calls into BPM adapters itself. The external calls can be wrapped as a separate artifact or even better can be deployed as a separate application in stand-alone server. As the BPMS application grows the number of external calls will increase proportionately. If this is the case, having integration layer as a separate server will be much more scalable. The additional responsibilities for integration layer would be orchestration, data transformation, presentation layer support etc.
BPM Process Data in Presentation Layer
There is a need to present the process data in applications external to BPMS. Applications external to BPMS may not be in the same platform as the BPMS product. So the process data in BPMS have to be exposed as services. A process task might be presented in an external portal / may be in a mobile application. BPM architecture should be scalable enough to support the presentation of BPM process data as services.
Process as Service
A lot of BPM products provide capability to expose the process as a service itself. The service thus exposed should be checked for WS-1 compatibility or the latest interoperability standards. If not, it is better to have a custom developed service which would invoke the corresponding process. The in-house developed service will have more advantages in terms of flexibility, re-usability and maintainability.
Process Versioning
It is quite often that a deployed process undergoes some changes after ever release. How to make sure that any subsequent deployments would not break the in-flight instances of previous versions of the process? Well the solution for this problem cannot be addressed with one aspect. The issue of in-flight instances continues to haunt many successful programs. In-flight instance management should be dealt at an architecture and process design level. This is definitely a broader topic and the solution differs from product to product, and this calls for a separate post.
Application Data Model
There is a need to segregate the data model of the BPM product with the BPM application data. The data model of the application has to be separate from BPM product schema. Sometimes, BPM artifact data like process id, process data names have to be referred in the BPM application code. So there is a need to persist BPM process data along with the application data in application schema. Hard-coding of artifact names should be avoided in the application code and these have to be configured from a database. For instance, if process name is referred in application code, then it is advisable to have a database table with all process names and a reference from the application code can be fetched from the database table.
Exception handling
Exception handling is covered in a separate post.
Subscribe to:
Posts (Atom)