Friday, April 5, 2013

Multi Tenants in Decision Center IBM ODM 8.0.x

A friend and colleague today asked me a very good question so as I spent one hour on it, I think it makes sense to share the information with IBM ODM 8.0.x users.

The request is what are the best practices and governance approach to follow for supporting multiple 'tenants' in IBM ODM Decision Server? In Decision Server there are different user groups, each group may be responsible of multiple projects, but users in the group could not see projects of other groups.

Obviously this is supported by the product out of the box, but it is important to follow some practices.

First it is important to understand the synchronization architecture as describe in Synchronization architecture. As a long time best practice it is important to synchronize a rule project from Design to Decision Center (DC) when the BOM is stable, but in fact there is an alternate approach is to define empty project in Decision Center as soon as your development effort starts. The rule project name has to be defined as it represents the top synchronization point between Rule Designer and DC.

The first synchronization has to be done by and administrator role, as stipulates in Publishing projects to Decision Center: "you must have administrator rights to Decision Center to publish a project initially to it". This is logic as permission settings are done by super users once the project is in the rule repository. Basically a developer creates a rule project, with the final expected name, gives his workspace to an administrator, and lets the administrator creating the rule project into Decision Center and set the permissions. Let see how to do that.

The Decision Center needs to support different groups of users, with the constraint that users part of one group could not see other rule projects managed by other groups, and even administrator role within a group could not see other projects. There is only a super administrator of the Decision Center server. It is for example rtsAdmin. Most of the time you do not need to manage projects. You need user who may be part of the rtsAdministrators group and other group of users.

Suppose you have 3 groups of users defined in LDAP or WAS Federated Respository: UserGroup1, UserGroup2, and UserGroup3. (Use WAS admin console > Users &Groups management > Manage groups.

For each group define users with the Decision Center predefined role of 'rtsUsers' so they can login to DC and author rules. As in each group there is one administrator, for example Adam is part of UserGroup1 and has rtsAdministrator role, define the following group assignment.

This administrator is the person who can create projects in Decision Center for the first time. The table below presents an example of user allocations.

User Group Permission
Adam UserGroup1, rtsAdministrators Create rule project and set permissions
Bea UserGroup2,rtsUsers Author Rules
Eli UserGroup1,rtsUsers Author Rules
Val UserGroup2, rtsAdministrators Create rule project and set permissions

 Recall that to use Decision Center project security as well as its permissions mechanism, all groups (except rtsAdministrator) must be declared in both the application server and Decision Center. To do so use the Installation wizard: Configure > Administration. Installation Settings Wizard > Step 3: Setup Groups. Then use the New button.

 Add UserGroup2:

Now suppose that each group has the following rule project ownership:
Group Rule Projects
UserGroup1 LoanApplicationValidation-rules, & LoanApproval-rules
UserGroup2 RiskAssessment-rules & DynamicTaskRoutingRules
UserGroup3 Pricing-rules

After synchronizing the first time the LoanApplicationValidation-rules rule project from rule designer:

Adam (administrator of user group1), connects in Decision Center and sets the 'branch security' using UserGroup1. Configure > Security . Edit Branch Security. (Select 'Enforce and configure security..." toggle)

From now only users in UserGroup1 can access the ruleset LoanApplicationValidation-rules. Until the branch security is not set on a rule project, this project is visible by all rtsUsers or rtsAdministrators users. Therefore it is recommended to enforce security, as soon as a project is synchronized from Rule Designer to Decision Center. There is a time window when other users may see this project as part of the list of possible projects in the Home tab. This is not a problem if you follow the practice of creating a simple, mostly empty project.
As each project already present in Decision Center has its security permission set, other user in other group does not see rule projects not controlled by his/her group.

Thursday, February 14, 2013

Reference data management

I have worked with a long time colleague and friend to present some patterns for integrating reference data management within a decision management product, like IBM ODM 8.0.1. This is a new developer works article.

Strategies for managing reference data in a business rules application using IBM Operational Decision Manager

Feel free to give me comments.

Sunday, December 16, 2012

Part 2 for BPM and ODM integration

In this second article I describe different out-of-the-box BPM and ODM integration capabilities and recommends an approach that provides better performance and flexibility for a long-term production solution.
Best practices for designing and implementing decision services, Part 2: Integrating IBM Business Process Manager and IBM Operational Decision Management

I hope you will like it.

Monday, July 2, 2012

June BPM journal article

Here is an important article published within IBM BPM journal for decision service design. I have to share this set of best practices because it is often confusing and misleading.

I hope it will help your implementation.

Friday, February 10, 2012

Redbook on WODM 7.5

A new redbook was just release about WebSphere Operational Decision Manager, which is JRules renamed, and integrated with the event processing of Websphere business event.
The book can be seen here
The two products are now using the same language construct delivered by JRules business rule language definition framework. Event processing rules complete the current if <> then <> rule structure and open the door to interesting applications. The next step is to make architects thinking about Event Driven Architecture by instrumenting application to generate event of interest, and adopt a publish and subscribe model. Not yet there. The good news is that from a SOA service is not that complex to generate events so an event processing engine can correlate, aggregate them.
I have the chance to review this redbook, and I love the fact that it is not just BPM. I'm tired to get 'industry expert' mixing rule engine with BPM and saying everything is a business process problem...
Also rule processing (event or inference) should be part of the service in SOA, with a different life cycle of development and maintenance. The schema presented on that subject in the book are highlighting. Great job to Pierre Berlandier and Duncan Clark for their hard work.

Tuesday, December 27, 2011

BPM used as monolithic L4G

With my last months studying BPM products, I'm quite impressed by product marketing fliers and other 'best pratices'/ training materials putting emphasis to the fact that traditional, code driven, approach to develop business application is bad, and with BPM it is better to have a unique artifact in a central repository, for managing all the elements of a business application such as UI, information model, service definitions, connectors, business rules, process logic.
I'm confused by the lack of applying basic design and architecture best practices such as separation of concern, and artifact life cycle. With monolithic process application, any change to the information model, or the UI enforce migrating all the process instances running on the runtime server. This is interesting to note that SOA reference architecture, defines, UI services separated from process, from data, and rules services. Which makes perfectly sense for re usability, components life cycle, flexible, sustainable architecture.
Do not apply bad patterns because of such BPM product, use BPM for workflow orchestration, visibility into your process, monitoring the business activities inside the process, and think about valuable architecture and design, and do not blindly follow marketing sirens.

Monday, November 14, 2011

New post on Book companion web site

I start now to add content to the book - companion web site. So point to agilebrdevelopment
Have fun