Hi
Thank to all of you to attempt my last web seminars on ABRD, SOA, and Effective rules writing. You were around 850 to register and close to 400 to attempt. This is showing an interest in best practices around business rules and their implementation. Feel free to ask me more questions by email, and I will start to respond on this blog and on the isis blog to the more common questions.
Friday, July 18, 2008
Thursday, June 12, 2008
SOA and BRMS
Well I did not post since a while. I was working on an interesting subject related to Complex Event Processing. I will detail that in close future.
In the mean time coming back to our purchase Order sample, I will take the architect's hat, and outline the deployment of BRMS within a SOA approach.
In the mean time coming back to our purchase Order sample, I will take the architect's hat, and outline the deployment of BRMS within a SOA approach.
SOA has proven to be a great technology to make enterprises more agile. With their ability to separate business logic from its implementation, BRMS adds more capabilities to the SOA. SOA is a progressive architectural style for creating and using business tasks that are packaged as services. The main goal of these services is to expose loose coupled business functions to facilitate deployment, combination, and reuse within different applications. SOA supports the integration of heterogeneous systems, as soon as they are exposed over the internet using standard protocols like HTTP, XML, unified interface definition (WSDL).
Every business has rules, and business users want complete control and visibility over these rules. A BRMS decouples an application's business logic from its data access and from its flow control. Decision logic is exposed behind decision services which support some business task. Such services are ValidateCustomer, ValidatePurchaseOrder, CheckCreditHistory… Using BRMS those service delegates the processing to a rule set deployed within a Rule Engine. Those rule engine can be managed using a rule execution server which provides the pooling mechanism, rule set management and execution monitoring functions.
A business application leveraging MDM, BPEL and BRMS may look like
The SOA is organized in a set of business services used by the business application logic. This business application layer is modeled using use cases diagram or business process map, and may be implemented using BPEL orchestration, and/or a standard Model View Control web application. The business services leverage lower level services, which I packaged in a technical service layer. They support lower granularity service like accessing business objects (DAO for Creating Reading Updating Deleting data), master data like product definition, enumerated domain value, sub process flows, web services and rule execution server. In this logical view of the architecture I do not need to expose the Enterprise Service Bus which may need to be used as a communication layer between the application logic and the business services.
In fact this diagram even if it outlines one application, can be applied for multiple applications. The business and technical services can be reused to support other business cases.
Rule developer creates the rule projects structure, the data model used by the rules, the rule execution flow, prototypes some rules, and then gives the hand to the business analysts to complete the rule authoring activity. Business Analysts use the web based interface to manage the full life cycle of the rule. Rules are persisted in a rule repository. The deployment of a rule set can be done without stopping the core application, and can be controlled within the Monitoring and Control environment of the production platform. Using a BRMS the IT staff and business analyst can work closer together as they are using the same high level language to write business rule, they understand the rule flow, so the long term maintenance of the application is greatly enhance.
Within a SOA the BRMS is bringing an effective and efficient mechanism to manage the decision logic of any business application. The architect needs to design the decision service so they can be reusable, then the rule architect needs to design the rule execution flow to take into account some specificities of context of execution. Rule set reuse may infer some tests on the context of the caller. This context is exposed to the rule engine as a fact in the working memory, and the rule flow can have some initial tasks to test and apply different branching according to the state of this context.
I will dig into code detail later.Sunday, May 11, 2008
A sample to illustrate the ABRD approach
There are a lot of requests from colleagues, customers, readers of ABRD to get a sample covering the main activities of ABRD from A to Z. I'm working on a book with a friend of me, which will cover all the ABRD activities in detail, and provide detailed samples. But for the moment I will take a simple purchase order process. There are a lot of samples on the web around this process, but here I'm focusing on a simple version of it.
This Order Process may betypical B2B scenario, in which multiple stateful services interact with each other. Two sources for the order request: one online with an Internet customer submitting an order on a Web page, and one using an automatic purchase order issued by a well known authenticated customer-partner.
A decision point table is an important deliverable of the analysis. It can be built during the inception phase by the team responsible to outline the project high level scope. If it is not present the project team has to quickly develop it during the first iteration of the project.
We will detail the outcome of the rule discovery in a next post.
This Order Process may betypical B2B scenario, in which multiple stateful services interact with each other. Two sources for the order request: one online with an Internet customer submitting an order on a Web page, and one using an automatic purchase order issued by a well known authenticated customer-partner.
In ABRD using a business process centric approach for discovery – analysis – implementation we start by doing the analysis of the process, then we go to the data modeling, rule harvesting, and service design in parallel like the following diagram outlines it:
During the process modeling the rule and process analysts search for verbs which involve mental processing or thinking like check, qualify, compute, calculate, estimate, evaluate, determine, assess, compare, verify, validate, confirm, decide, diagnose.. to identify activity which has business decision and logic, applies some business knowledge... Those activities should be what we call "decision rich" and have the focus of the rule analyst to discover rule.
Purchase Order Process description
The process is initiated when a customer online submits a product order, or when an automatic purchase order issued by a well known authenticated customer is received on one EDI link. A customer validation step is executed using customer data and product request data. Based on the product data provided in the order, it is checked whether the product is on stock. If the product is available, the price for the shipment of the ordered product is determined and presented back to the customer. If the product is not available, a message is sent back to the customer by email or web page (if still online). This last case also triggers email to product manager to provision the stock for this product.
The total price of the order is calculated from the product price, the customer business condition, loyalty program… and the shipment price. When the charging and the shipment have been performed successfully, the order is filed and the process ends.
Process Analysis
Looking on this process and the description above we can extract the following decision point where business rule will apply:
| Decision Point Name | Description |
| Validate Customer data | Verify the customer information – data present or not, and black listed customers |
| Validate Purchase Order | Verify there is no fraud in the purchase orders or on a set of purchase order coming over a time period, , verify the data are correct |
| Calculate Total Price | As the price may account for a loyalty program, marketing campaign, stock level, and other business dimensions, business rules are relevant here to compute the price outside of a simple addition. |
| Get Shipment report | It may be possible to receive a set of events from the shipment company to aggregate and correlate to the same purchase order so that customer can be notified on a major type of events as well as the internal management team. |
A decision point table is an important deliverable of the analysis. It can be built during the inception phase by the team responsible to outline the project high level scope. If it is not present the project team has to quickly develop it during the first iteration of the project.
We will detail the outcome of the rule discovery in a next post.
Successful webseminar on ABRD
Hi
Thanks a lot, to all the attendees on last week web seminar , we got records of registered persons and connected ones. There are a lot of questions, and I could not respond to all of them. So I will use the BLOG to answer the questions related to Agile Business Rule Development and other architecture discussions.
For Europe we plan to do a second webseminar, I will announce it.
Thanks a lot, to all the attendees on last week web seminar , we got records of registered persons and connected ones. There are a lot of questions, and I could not respond to all of them. So I will use the BLOG to answer the questions related to Agile Business Rule Development and other architecture discussions.
For Europe we plan to do a second webseminar, I will announce it.
Friday, April 25, 2008
SOA maturity Matrix, Agile Chain Management System
Today I would like to present a very nice article in a IT french journal “Solutions logiciels”. This is related to sustainable architecture. I’m working with Pierre Bonnet, the author of this article, on this matter, and try to share experiences on BRMS, as one of the corner stones of the Agility Chain Management System, I will try to summarize the main points of this article in french as it is relevant over the world:
The IT infrastructure in a lot of companies suffers from a lack of investment to modernize the legacy, which adds complexity when development team deploys new applications. Business and IT managers are focusing in short term ROI putting on hold long term investments needed to build a long term sustainable architecture.
Added to these, we can foreseen three layers of IT staff: the senior with their knowledge of the current legacy systems and the business requirements, the intermediate layer with people skilled in client/server and EAI technologies, and the younger one with object oriented skill, and web, web services development backgrounds. Younger are involved in tactical projects, using agile methodology, but most of the time generate rigid systems not able to change and supporting a long term logical architecture. The seniors are starting to retreat leaving a deep gap in knowledge which is most of the time not transferred to younger population. These are future bombs in the IT organization. What to do?
IT management needs to start long term projects to rebuild the IT architecture for the next generation. Pierre proposes to start by looking at what is the current situation at the enterprise level and being able to build a plan to transform the IT architecture for long term needs. The second point is to take risk: we can manage an IT organization just by controlling the existing. The rapid changes in economy, new regulations, and technology progresses force managers to take risky choices. But the risk is also to look at change in IT staff population, skill transfer, and risk to deploy new application on a fragile architecture.
Finally his last point is about clearly communicating to business and executive management about the non quality contract of current IT system, the medium to long term degradation of the IT services, and so the company competitive advantage. The communication has to leverage a strong action plan leveraging a risk management plan.
Three principles support the argumentation:
1- The re-engineering of any IT architecture cannot being done in one shot. The diagram below presents a progressing path to migrate existing architecture to a sustainable one. Starting from a SOA to expose the existing legacy functions as services, then moving to the extended SOA where BPM, BRMS and MDM are used in conjunction to offer agility at the service level for change in referential data, decision logic, and business process. The end of the path references the use of those technologies for the enterprise architecture.
2- The Agility Chain Management System: Using the MDM, BRMS and BPM technologies, IT staff can start by externalize referential data and parameters using the MDM, business rules and decision logic using BRMS, and orchestrate services and support business process with BPM.
3- A Enterprise Level Methodology: the migration path enforces a strong use of methodology like TOGAF, Praxeme, CEISAR)
Pierre addresses in this article some very important points and principles to take care during a SOA migration. Currently we are seeing a lot of project focusing on re-vamping legacy function as web services but this is not the end of the story of a SOA. I like very much the path to the extended SOA and the maturity matrix as a tool to explain to IT management the long term vision. Project managers can position where their project stands on this matrix to clearly articulate what is the value of their project’s product for the long term IT vision.
I modified slightly the original maturity matrix to clearly mention that any project falling into the bottom-right corner is the beginning of decision service re-engineering using the MDM-BRMS-BPM technologies, that IT development team has to leverage for the long run. When people embrace those technologies they are seeing the value and how to leverage them at the enterprise level. As you can see green path is the way to go and the red path is going no-where as it falls back into a rigid application behind a web service...
As an example of this kind of project we can take a claim processing application where the development team and architect decided to migrate one of their service (Claim Coverage Verification) to use business rules to verify the coverage of the insured person around his claim. MDM was used to define all the referential data as the medical codes, the US states, zip code,.. and other application parameters. The legacy application offers some data and business services with a re-vamped web service approach, and the BPM was used to call the services, to dispatch the set of XML documents over the process steps, and to offer the GUI for the claim processors: the actors of the business.
Starting from there the team can enhance the migration of such application and design reusable, agile technical and business services.
Tuesday, April 22, 2008
Book your agenda: May 7 10.00 am PST. Web seminar on ABRD
Make Developing Business Rule Applications Easier
What: 60-minute best practices webinar
When: Wednesday, May 7
Who should attend: Architects, developers, application programmers, software engineers, IT senior managers, IT team leaders, and anybody who wants to learn more about developing business-rule applications
Learn about a rules-specific methodology designed for short turnaround times: Agile Business Rule Development (ABRD)
When you're building business rule applications, generic software-development methodologies just aren't enough.
Agile Business Rule Development (ABRD) is a step-by-step process for developing business rule applications. An iterative methodology, ABRD employs agile software-development values. Rule development is organized as a series of cycles: discovery, analysis, authoring, validation, and deployment. Your team stays on schedule, delivering outstanding business rule applications.
Attend this free one-hour webinar and learn how to:
- Leverage ABRD as first open-source methodology for business rules
- Implement and deploy rules in an SOA or BPM context
- Engage in rule discovery and analysis
Wednesday, April 2, 2008
Software Development Life Cycle for BR-BPEL application
The purpose of this article is to present an integrated software life cycle for development team who wants to leverage the capabilities offered by technologies such as BPM-BPEL and Business rules management system.
Each new business application development is triggered by a business needs to support or enhance and improve business efficiency. Even with an Agile approach, to trigger the project, architect, business users, project manager and project sponsor have to work together during the Inception phase, to define the business case, the requirements and justifications of the project. Once the project funded, the team may work on specification and requirement documents. I simplify a little here because in reality a lot more documents may be produced, but the goal here is to present how those requirements are supported in an Agile way using the BRMS and BPM products and not discussing about requirements management. So let state the specifications are our main entry point to detail the major work that needs to be done for developing the applications. The format of the specification can be user stories, or a more detailed description. (a good reference to write specifications and user case is Alistair Cockburn work ). Specifications are classically managed by a standard SDLC which includes design, build, test, and deploy of working code to the different staging platforms (development, test, or production).
The Agile approach enforces short iterations to deliver quick value to the business. The blue tasks in the diagram below represent a set of iterations that build the core of the business application.
The horizontal axe of this diagram represents time. The pools are used to contain activities executed in the different development environment. The top pool is the business analyst team which is triggering change to the application. When the development team is using BPEL and BRMS technologies, there are parts of the specifications which go directly to those components: Business processes will be implemented using BPEL and BPM process map, and business rules using BRMS. In the first release (you can see a release as a vertical slice of the above diagram) the agile value of each of these technologies is not clearly articulate. This is true that BPEL and BRMS help to develop in less time, and adopt an agile approach of development. But the main value proposition will come in longer term by the ability to efficiently support the two types of change requests the business user may ask:
• The business rules and policies changes: business want to improve the decision done by the rule engine
• The process tuning or improvements: the process needs to change due to legal constraints, better error and exception path management, or for better execution.
Business Rule changes will be done in the BRMS using a web based interface or IDE like JRules Rule Studio. The hot deployment capability of a rule set authorizes to deploy a newly updated rule set in a question of seconds. This helps a lot to support quick change on the decision logic attached to decision services called by the BPEL process instance. Rule Developer can do a lot of try and catch in a pre-production environment to improve the quality of the rule set, so the quality of the decision. Some IT organization implements the “champion – challenger” pattern to evaluate a new rule set against the production one. The champion rule set is in production and process transaction request with a certain level of metrics: metric can be number of automatic decision, or other business key performance indicator. On the pre-production server, the challenger rule set receives the same data flow, and metrics are compared. If challenger beats the champion it becomes the new champion in production.
Business process improvement requests are managed using the BPMS system, and a new process definition can be released to the different platforms. We can definitively see more change requests coming for business rules change, than on the business process: When we have a working process it is more sensitive to change it. Still business process changes will happen to support for example an improvement of the exception management, or to find some short-cut on the global processing so that the time to complete the process is better.
The core application can still evolve with a new release path. Change to the GUI, or data model will most likely be managed by a new release of the full application.
As a conclusion it is important to consider using an agile development methodology which support quick change when using BPM – BPEL – BRMS technologies, if you do not adapt your way to develop business application, you may lose the opportunity to be agile.
Each new business application development is triggered by a business needs to support or enhance and improve business efficiency. Even with an Agile approach, to trigger the project, architect, business users, project manager and project sponsor have to work together during the Inception phase, to define the business case, the requirements and justifications of the project. Once the project funded, the team may work on specification and requirement documents. I simplify a little here because in reality a lot more documents may be produced, but the goal here is to present how those requirements are supported in an Agile way using the BRMS and BPM products and not discussing about requirements management. So let state the specifications are our main entry point to detail the major work that needs to be done for developing the applications. The format of the specification can be user stories, or a more detailed description. (a good reference to write specifications and user case is Alistair Cockburn work ). Specifications are classically managed by a standard SDLC which includes design, build, test, and deploy of working code to the different staging platforms (development, test, or production).
The Agile approach enforces short iterations to deliver quick value to the business. The blue tasks in the diagram below represent a set of iterations that build the core of the business application.
The horizontal axe of this diagram represents time. The pools are used to contain activities executed in the different development environment. The top pool is the business analyst team which is triggering change to the application. When the development team is using BPEL and BRMS technologies, there are parts of the specifications which go directly to those components: Business processes will be implemented using BPEL and BPM process map, and business rules using BRMS. In the first release (you can see a release as a vertical slice of the above diagram) the agile value of each of these technologies is not clearly articulate. This is true that BPEL and BRMS help to develop in less time, and adopt an agile approach of development. But the main value proposition will come in longer term by the ability to efficiently support the two types of change requests the business user may ask:
• The business rules and policies changes: business want to improve the decision done by the rule engine
• The process tuning or improvements: the process needs to change due to legal constraints, better error and exception path management, or for better execution.
Business Rule changes will be done in the BRMS using a web based interface or IDE like JRules Rule Studio. The hot deployment capability of a rule set authorizes to deploy a newly updated rule set in a question of seconds. This helps a lot to support quick change on the decision logic attached to decision services called by the BPEL process instance. Rule Developer can do a lot of try and catch in a pre-production environment to improve the quality of the rule set, so the quality of the decision. Some IT organization implements the “champion – challenger” pattern to evaluate a new rule set against the production one. The champion rule set is in production and process transaction request with a certain level of metrics: metric can be number of automatic decision, or other business key performance indicator. On the pre-production server, the challenger rule set receives the same data flow, and metrics are compared. If challenger beats the champion it becomes the new champion in production.
Business process improvement requests are managed using the BPMS system, and a new process definition can be released to the different platforms. We can definitively see more change requests coming for business rules change, than on the business process: When we have a working process it is more sensitive to change it. Still business process changes will happen to support for example an improvement of the exception management, or to find some short-cut on the global processing so that the time to complete the process is better.
The core application can still evolve with a new release path. Change to the GUI, or data model will most likely be managed by a new release of the full application.
As a conclusion it is important to consider using an agile development methodology which support quick change when using BPM – BPEL – BRMS technologies, if you do not adapt your way to develop business application, you may lose the opportunity to be agile.
Subscribe to:
Posts (Atom)
