Column 2 : BRM

{ Category Archives } BRM

SAP BPM 2008: Business Rules Management

I was up bright and early today to hear Soum Chatterjee from SAP Labs give an introduction to their business rules product, the recently-acquired Yasu (which Chatterjee claims stands for Yet Another Start-Up). I’ve had a bit of a look at it in the context of the NetWeaver BPM demos that I’ve had, but wanted to hear about their roadmap for the product.

He started with some very fundamental information on business rules, and made an interesting comment (considering who writes his paycheck): maybe embedding rules in the code of systems like SAP’s ERP was not a great idea. Of course, neither was having rules embedded in database triggers or non-automated methods such as documenting them in procedures guides or just having them in people’s heads. In these cases, we might see lack of flexibility, lack of visibility and lack of enforcement/standardization as well as having the business rules scattered around the organization where they can’t be properly managed. The solution, of course, is SAP NetWeaver BRM Consider that the audience is mostly SAP customers who are very used to the idea of business rules embedded within their ERP code, some of these ideas are pretty radical, but he does a good job of laying out the value proposition of business rules, not just a product overview. He put it in the context of BPM, where the ability to change the rules within processes provides maximum agility.

From a rules product standpoint, they have a suite including:

A composer for modeling rules, in an Eclipse-based environment that can be used by a business analyst. It uses a natural language-like representation of the rules, and provides conflict resolution and other up-front analysis of the rules being modeled. Rules can be represented as a decision table, classic if-the-else code, or as a graphical rule flow (which is a sort of decision tree). I’ve also seen this integrated into the process modeling environment in their BPM product.
A rules manager for deploying and managing rules.
A rules engine to execute the rules. Rules can be consumed as web services (and therefore by their BPM or any other composite application modeling environment) and ABAP business applications.
A repository for storing the rules assets.
A rules analyzer for optimization (not released yet).

They’ve focused on fast methods of testing and refining rules, particularly by a business analyst. They also have a lot of change management and governance built in.

He covered how BRM and BPM will work together:

Complex rule-based decisions (pricing, credit decisions, etc.)
Responsibility determination (rule-based task assignment)
Recognition of business events
Routing rules
Parameter thresholds and tolerance (constraints)

Rules can be modeled in the rules composer or in the process composer. He showed us a (canned) demo of the rules composer that would have been a lot more compelling if he had narrated it in a bit more detail: I was sitting at the front of the room so could see the screen, but I’m sure that those at the back of the room couldn’t read it and there wasn’t enough narration to follow along with what was happening in the screen playback. Eight minutes into the video (only halfway!), we move from code-based rules to decision tables, which is a bit more interesting from a demo standpoint, but I really doubt if anyone who didn’t already know something about rules modeling would have gained a lot of information from watching this. It also made the composer look a lot more difficult that it actually is, as evidenced from an audience question about whether they expected business users to use this (in a disbelieving voice).

He finished up with the product roadmap:

This year, they’ve delivered the business rules composition and execution environment, available for invocation from the various SAP product lines, and integrated with the BPM composition environment.
In 2009, there will be more complex decision sequences, integrated support for rule refinement and validation, end-to-end change management, and improved business user participation and collaboration in rules authoring and change management.
In 2010, the plan (which of course can change) is to have real-time rule-based responses to business events, advanced rules analysis capabilities with alignment to business goals, and better modeling capabilities for business analysts.

2008 11 19 Sandy Kemsley SAPevents Comments (1)

Business Rules Forum: Kevin Chase of ING

I’m squeezing in one last session before flying out: Kevin Chase, SVP of Implementation Services at ING, discussing how to use rules in a multi-client environment, specifically on the issues of reuse and reliability. I’ve done quite a bit of work implementing processes in multi-client environments — such as a mutual funds back-office outsourcing firm — and the different rules for each client can make for some challenges. in most cases, these companies are all governed by the same regulations, but have their own way that they want things done, even if they’re not the ones doing it.

In ING’s case, they’re doing benefits plan administration, such as retirement (401k) plans, for large clients, and have been using rules for about six years. They originally did a pilot project with one client, then rolled it out to all their clients, but didn’t see the benefits that they expected; that caused them to create a center of excellence, and now they’re refining their processes and expanding the use of rules to other areas.

They’re using rules for some complex pension calculations, replacing a previous proprietary system that offered no reuse for adding new clients, and didn’t have the scalability, flexibility and performance that they required to stay competitive. The pension calculator is a key component of pension administration, and calculating pensions (not processing transactions) represented a big part of their costs, which makes it a competitive differentiator. With limited budget and resources, they selected ILOG rules technology to replace their pension calculator, creating a fairly standalone calculator with specific interfaces to other systems. This limited-integrated approach worked well for them, and he recommended that if you have a complex calculator as part of your main business (think underwriting as another example), consider implementing rules to create a standalone or lightly-integrated calculator.

In their first implementation phase, they rewrote 50+ functions from their old calculator in Java, then used the rules engine to call the right function at the right time to create the first version of the new calculator. The calculations matched their old system (phwew!) and they improved their performance and maintainability. They also improved the transparency of the calculations: it was now possible to see how a particular result was reached. The rules were written directly by their business users, although those users are actuaries with heavy math backgrounds, so likely don’t represent the skill level of a typical business user in other industries. They focused on keeping it simple and not overbuilding, and used the IT staff to build tools, not create custom applications. This is a nice echo of Kathy Long’s presentation earlier today, which said to create the rules and let the business users create their own business processes. In fact, ING uses their own people for writing rules, and uses ILOG’s professional services only for strategic advice, but never for writing code.

After the initial implementation, they rolled it out to the remainder of their client base (six more organizations), representing more than 200,000 plan participants. Since they weren’t achieving the benefits that they expected, they went back to analyze where they could improve it:

Each new client was still being implemented by separate teams, so there was little standardization and reuse, and some significant maintenance and quality problems. It took them a while to convince management that the problem was the process of creating and maintaining rules, not the rules technology itself; eventually they created a center of excellence that isn’t just a mentoring/training group, but a group of rules experts who actually write and maintain all rules. This allows them to enforce standards, and the use of peer reviews within the CoE improves quality. They grow and shrink this team (around 12-15 people) as the workload requires, and this centralized team handles all clients to provide greater reuse and knowledge transfer.
They weren’t keeping up with ILOG product upgrades, mostly because it just wasn’t a priority to them, and were missing out on several major improvements as well as owning a product that was about to go out of maintenance. Since then, they’ve done some upgrades and although they’re not at the current release, they’re getting closer and have eliminated a lot of their custom code since those features are now included in the base product. The newer version also gives them better performance. I see this problem a lot with BPMS implementations as well, especially if a lot of custom code has been written that is specific to a current product version.
They had high infrastructure costs since each new client resulted in additional hardware and the associated CPU licensing. They’ve moved to a Linux platform (from SUN Solaris), moved from WebLogic to JBOSS, and created a farm of shared rules servers.
Since they reduced the time and expense of building the calculator, they’ve now exposed other areas of pension administration (such as correspondence) that are taking much longer to implement: the pension calculator used to be the bottleneck in rolling out new products, but now other areas were on the critical path. That’s a nice thing for the calculator group, but had them start to recognize the problems in other areas and systems, pushing them to expand their rules capability into areas such as regulatory updates that span clients.

This last point has led to their current state, which is one of expansion and maturity. One major challenge is the cleanliness and integrity of data: data errors can lead to the inability to make calculations (e.g., missing birthdate) or incorrect calculation of benefits. They’re now using rules to check data and identify issues prior to executing the calculation rules, checking the input data for 30+ inconsistencies that could cause a failure in the calculator, and alerting operations staff if there needs to be some sort of manual correction or followup with the client. After the calculations are done, more data cleansing rules check for another 20+ inconsistencies, and might result in holding up final outbound correspondence to the participant until the problem is resolved.

He wrapped up with their key lessons learned:

A strong champion at the senior executive level is required, since this is a departure from the usual way of doing things.
A center of excellence yields great benefits in terms of quality and reuse.
Leverage the vendors’ expertise strategically, not to do the bulk of your implementation; use your own staff or consultants who understand your business to do the tactical work.
Use an iterative and phased approach for implementation.
Do regular assessments of where you are, and don’t be afraid to admit that mistakes were made and improvements can be made.
Keep up with the technology, especially in fast-moving technologies like rules, although it’s not necessary to be right on the leading edge.

Great presentation with lots of practical tips, even if you’re not in the pension administration business.

2008 10 30 Sandy Kemsley BusinessRulesForum Comments (0)

Business Rules Forum: Kathy Long on Process and Rules

Kathy Long, who (like me) is more from the process side than the rules side, gave a breakout session on how process and rules can be combined, and particularly how to find the rules within processes. She stated that most of the improvements in business processes don’t come from improving the flow (the inputs and outputs), but in the policies, procedures, knowledge, experience and bureaucracy (the guides and enablers): about 85% of the improvement comes from the latter category. She uses an analysis technique that looks at these four types of components:

Input: something that is consumed or transformed by a process
Guide: something that determines how, why or when a process occurs, but is not consumed
Output: something that is produced by or results from a process
Enabler: something used to perform a process

There’s quite a bit of material similar to her talk last year (including the core case study); I assume that this is the methodology that she uses with clients hence it doesn’t change often. Rules fall into the “guides” category, that is the policies and procedures that dictate how, why and when a process occurs. I’m not sure that I get the distinction that she’s making between the “how” in her description of guides, and the “how” that embedded within process flows; I typically think of policies as business rules, and procedures as business processes, rather than both policies and procedures as being rules. Her interpretation is that policies aren’t actionable, but need to be converted to procedures, which are actionable; since rules are, by their nature, actionable, that’s what gets converted to rules. However, the examples of rules that she provided (”customer bill cannot exceed preset limit”) seem to be more policies than procedures to me.

In finding the rules in the process, she believes that we need to start at the top, not at the lowest atomic level: in other words, you don’t want to go right to the step level and try to figure out what rules to create to guide that step; you want to start at the top of the process and figure out if you’re even doing the right higher-level subprocesses and tasks, given that you’re implemented rules to automate some of the decisions in the process.

The SVBR (Semantics of Business Vocabulary and Business Rules) standard defines the difference between rules and advice, and breaks down rules into business rules and structural rules. From there, we end up with structural business rules — which are criteria for making decisions, and can’t be violated — and operative business rules — which are guides for conduct or action, but can be violated (potentially with a penalty, e.g., an SLA). Structural rules might be more what you think of as business rules, that is, they are the underpinning for automated decisions, or are a specific computation. On the other hand, operative business rules may be dictated by company policy or external regulation, but may be overridden; or represent a threshold at which an alert will be raised or a process escalated.

She recommends documenting rules outside the process, since the alternative is to build a decision tree into your process flow, which gets really ugly. I joked during my presentation on Tuesday that the process bigots would include all rules as explicit decision trees within the BPMS; the rules bigots would have a single step in the entire process in the BPMS, and that step would call the BRMS. Obviously, you have to find the right balance between what’s in the process map and what’s in the rules/decision service, especially when you’re creating them in separate environments.

The largest detractor from the presentation is that Long used a case study scenario to show the value of separating rules from process, but described it in large blocks of text on her slides which she just read aloud to us. She added a lot of information as she went along, but any guideline on giving a presentation tells you not to put a ton of text on your slides and just read it, for very good reasons: the audience tends to be reading the slides in case of listening to you. She might want to consider the guides that are inherent in the process of taking a case study and turning it into a presentation.

A brilliant recommendation that she ended with is to create appropriate and consistent rules across the enterprise, then let the business design their own process. Funny how some of us who are practitioners in BPM (whether at the management consulting or implementation end of things) are the biggest critics of BPM, or specifically, we see the value of using rules for agility because process often doesn’t deliver on its promises. I’ve made the statement in two presentations within the last week that BPMS implementations are becoming the new legacy systems — not (purely) because of the capability of the products, but because of how organizations are deploying them.

Business Rules Forum: Pedram Abrari on MDA, SOA and rules

Pedram Abrari, founder and CTO of Corticon, did a breakout session on model-driven architecture, SOA, and the role that rules play in all of this. I’m also in the only room in conference center that’s close enough to the lobby to pick up the hotel wifi, and I found an electrical outlet, so I’m in blogger heaven.

It’s a day for analogies, and Abrari uses the analogy of car for a business application: the driver representing business, and the mechanic representing IT. A driver needs to have control over where he’s going and how he gets there, but doesn’t need to understand the details of how the car works. The mechanic, on the other hand, doesn’t need to understand where the driver is going, but keeps the car and its controls in good working order. Think of the shift from procedural to declarative development concepts, where we’ve moved from stating how to do something, to what needs to be done. A simple example: the difference between writing code to sum a series of numbers, and just selecting a range of cells in Excel and selecting the SUM function.

The utopia of model-driven architecture (MDA) is that business applications are modeled, not programmed; they’re abstract yet comprehensive, directly executable (or at least deployable to an execution environment without programming), the monitoring and analytics are tied directly to the model, and optimization is done directly on the model. The lack of programming required for creating an executable model is critical for keeping the development in the model, and not having it get sucked down into the morass of coding that often happens in environments that are round-trippable in theory, but end up with too much IT tweaking in the execution environment to ever return to the modeling environment.

He then moved on to define SOA: the concept of reusable software components that can be loosely coupled, and use a standard interface to allow for platform neutrality and design by contract. Compound/complex services can be built by assembling lower-level services in an orchestration, usually with BPM.

The key message here is that MDA and SOA fit together perfectly, as most of us are aware: those services that you create as part of your SOA initiative can be assembled directly by your modeling environment, since there is a standard interface for doing so, and services provide functionality without having to know how (or even where) that function is executed. When your MDA environment is a BPMS, this is a crystal-clear connection: every BPMS provides easy ways to interrogate and integrate web services directly into a process as a process step.

From all of this, it’s a simple step to see that a BRMS can provide rules/decisioning services directly to a process; essentially the same message that I discussed yesterday in my presentation, where decision services are no different than any other type of web services that you would call from a BPMS. Abrari stated, however, that the focus should not be on the rules themselves, but on the decision service that’s provided, where a decision is made up of a complete and consistent set of rules that addresses a specific business decision, within a reasonable timeframe, and with a full audit log of the rules fired to reach a specific decision in order to show the decision justification. The underlying rule set must be declarative to make it accessible to business people.

He ended up with a discussion of the necessity to extract rules out of your legacy systems and put them into a central rules repository, and a summary of the model-driven service-oriented world:

Applications are modeled rather than coded
Legacy applications are also available as web services
Business systems are agile and transparent
Enterprise knowledge assets (data, decisions, processes) are stored in a central repository
Management has full visibility into the past, present and future of the business
Enterprises are no longer held hostage by the inability of their systems to keep up with the business

Although the bits on MDA and SOA might have been new to some of the attendees, some of the rules content may have been a bit too basic for this audience, and/or already covered in the general keynotes. However, Abrari is trying to make that strong connection between MDA and rules for model-driven rules development, which is the approach that Corticon takes with their product.

2008 10 29 Sandy Kemsley BusinessRulesForum
SOA
Software design Comments (2)

Business Rules Forum: Gladys Lam on Rule Harvesting

For the first breakout this morning, I attended Gladys Lam’s session on organizing a business rule harvesting project, specifically on how to split up the tasks amongst team members. Gladys does a lot of this sort of work directly with customers, so she has a wealth of practical experience to back up her presentation.

She first looked at the difference between business process rules and decisioning rules, and had an interesting diagram showing how specific business process rules are mapped into decisioning rules: in a BPMS, that’s the point where we would (should) be making a call to a BRMS rather than handling the logic directly in the process model.

The business processes typically drive the rule harvesting efforts, since rule harvesting is really about extracting and externalizing rules from the processes. That means that one or more analysts need to comb through the business processes and determine the rules inherent in those processes. As processes get large and complex, then the work needs to be divided up amongst an analyst team. Her recommendations:

If you have limited resources and there are less than 20 rules/decisions per task, divide it up by workflow
If there are more than 20 rules per task, divide by task

My problem here is that she doesn’t fully define task, workflow and process in this context; I think that “task” is really a “subprocess”, and “workflow” is a top-level process. Moving on:

If there are more than 50 rules per task, divide by decision point; e.g., a decision about eligibility for auto insurance could be broken down into decision points based on proof of insurance, driving history, insurance risk score and other factors

She later also discussed dividing by value chain function and level of composition, but didn’t specify when you would use those techniques.

The key is to look at the product value chain inherent in your process — from raw materials through production, tracking, sales and support — and what decisions are key to supporting that value chain. In health insurance, for example, you might see a value chain as follows:

Develop insurance product components
Create insurance products
Sell insurance products to clients
Sign-up clients (finalize plans)
Enroll members and dependents
Take claims and dispense benefits
Retire products

Now, consider the rules related to each of those steps in the value chain (numbers correspond to above list):

Product component rules, e.g., a scheduled payout method must have a frequency and a duration
Product composition rules, e.g., the product “basic life” must include a maximum
Product templating rules, e.g., the “basic life” minimum dollar amount must not be less than $1000
Product component decision choice rules, e.g., a client may have a plan with the “optional life” product only if the client has a plan with a “basic life” product
Membership rules, e.g., a spouse of a primary plan member must not select an option that a plan member has not selected for “basic life” product
Pay-out rules, e.g., total amount paid for hospital stay must be calculated as sum of each hospital payment made for claimant within claimant’s entire coverage period
Product discontinuation rules, e.g., a product that is over 5 years old and that is not a sold product must be discontinued

These rules should not be specific to being applied at specific points in the process — my earlier comment on the opening keynote on the independence of rules and process — but represent the policies that govern your business.

Drilling down into how to actually define the rules, she had a number of ways that you to consider splitting up the rules to allow them to fully defined. Keeping with the health insurance example, you would need to define product rules, e.g., coverage, and client rules, e.g., age, geographical location, marital status, and relationship to member. Then, you need to consider how those rules interact and combine to ensure that you cover all possible scenarios, a process that is served well by tools such as decision tables to compare, for example, product by geographic region.

This is going to lead to a broad set of rules covering the different business scenarios, and the constraints that those rules apply to different parts of your business processes: in the health insurance scenario that includes rules that impact how you sell the product, sign up members, and process claims.

You have to understand the scope before getting started with rule harvesting, or you risk having a rule harvesting project that balloons out of control and defines rules that may never be used. You may trade off going wide (across the value chain) versus going deep (drill down on one component of the value chain), or some combination of both, in order to address the current pain points or support a process automation initiative in one area. There are very low-level atomic rules, such as the maximum age for a dependent child, which also need to be captured: these are the sorts of rules that are often coded into multiple systems because of the mistaken belief that they will never change, which causes a lot of headaches when they do. You also need to look for patterns in rules, to allow for faster definition of the rules that follow a common pattern.

Proving that she knows a lot more than insurance, Gladys showed us some other examples of value chains and the associated rules in retailing and human resources.

Underlying all of the rule definitions, you also need to have a common fact model that you use as the basis for all rules: this defines the atomic elements and concepts of your business, the relationships between them, and the terminology.

In addition to a sort of entity-relationship diagram, you also need a concepts catalog that defines each term and any synonyms that might be used. This fact model and the associated terms will then provide a dictionary and framework for the rule harvesting/definition efforts.

All of this sounds a bit overwhelming and complex on the surface, but her key point is around the types of organization and structure that you need to put in place in your rules harvesting projects in order to achieve success. If you want to be really successful, I’d recommend calling Gladys.

2008 10 29 Sandy Kemsley BusinessRulesForum Comments (1)

Business Rules Forum: James Taylor and Neil Raden keynote

Opening the second conference day, James Taylor and Neil Raden gave a keynote about competing on decisions. First up was James, who started with a definition of what a decision is (and isn’t), speaking particularly about operation decisions that we often see in the context of automated business processes. He made a good point that your customers react to your business decisions as if they were deliberate and personal to them, when often they’re not; James’ premise is that you should be making these deliberate and personal, providing the level of micro-targeting that’s appropriate to your business (without getting too creepy about it), but that there’s a mismatch between what customers want and what most organizations provide.

Decisions have to be built into processes and systems that manage your business, so although business may drive change, IT gets to manage it. James used the term “orthogonal” when talking about the crossover between process and rules; I used this same expression in a discussion with him yesterday in discussing how processes and decisions should not be dependent upon each other: if a decision and a process are interdependent, then you’re likely dealing with a process decision that should be embedded within the process, rather than a business decision.

A decision-centric organization is focused on the effectiveness of its decisions rather than aggregated, after-the-fact metrics; decision-making is seen as a specific competency, and resources are dedicated to making those decisions better.

Enterprise decision management, as James and Neil now define it, is an approach for managing and approving the decisions that drive your business:

Making the decisions explicit
Tracking the effectiveness of the decisions in order to improve them
Learning from the past to increase the precision of the decisions
Defining and managing these decisions for consistency
Ensuring that they can be changed as needed for maximum agility
Knowing how fast the decisions must be made in order to match the speed of the business context
Minimizing the cost of decisions

Using an airline pilot analogy, he discussed how business executives need a number of decision-related tools to do their job effectively:

Simulators (what-if analysis), to learn what impact an action might have
Auto-pilot, so that their business can (sometimes) work effectively without them
Heads-up display, so they can see what’s happening now, what’s coming up, and the available options
Controls, simple to use but able to control complex outcomes
Time, to be able to take a more strategic look at their business

Continuing on the pilot analogy, he pointed out that the term dashboard is used in business to really mean an instrument cluster: display, but no control. A true dashboard must include not just a display of what’s happening, but controls that can impact what’s happening in the business. I saw a great example of that last week at the Ultimus conference: their dashboard includes a type of interactive dial that can be used to temporarily change thresholds that control the process.

James turned the floor over to Neil, who dug further into the agility imperative: rethinking BI for processes. He sees that today’s BI tools are insufficient for monitoring and analyzing business processes, because of the agile and interconnected nature of these processes. This comes through in the results of a survey that they did about how often people are using related tools: the average hours per week that a marketing analyst spends using their BI tool was 1.2, versus 17.4 for Excel, 4.2 for Access and 6.2 for other data administration tools. I see Excel everywhere in most businesses, whereas BI tools are typically only used by specialists, so this result does not come as a big surprise.

The analytical needs of processes are inherently complex, requiring an understanding of the resources involved and process instance data, as well as the actual process flow. Processes are complex causal systems: much more than just that simple BPMN diagram that you see. A business process may span multiple automated (monitored) processes, and may be created or modified frequently. Stakeholders require different views of those processes; simple tactical needs can be served by BAM-type dashboards, but strategic needs — particularly predictive analysis — are not well-served by this technology. This is beyond BI: it’s process intelligence, where there must be understanding of other factors affecting a process, not just measuring the aggregated outcomes. He sees process intelligence as a distinct product type, not the same as BI; unfortunately, the market is being served (or not really served) by traditional query-based approaches against a relatively static data model, or what Neil refers to as a “tortured OLAP cube-based approach”.

What process intelligence really needs is the ability to analyze the timing of the traffic flow within a process model in order to provide more accurate flow predictions, while allowing for more agile process views that are generated automatically from the BPMN process models. The analytics of process intelligence are based on the process logs, not pre-determined KPIs.

Neil ended up by tying this back to decisions: basically, you can’t make good decisions if you don’t understand how your processes work in the first place.

Interesting that James and Neil deal with two very important aspects of business processes: James covers decisions, and Neil covers analytics. I’ve done presentations in the past on the crossover between BPM, BRM and BI; but they’ve dug into these concepts in much more detail. If you haven’t read their book, Smart Enough Systems, there’s a lot of great material in there on this same theme; if you’re here at the forum, you can pick up a copy at their table at the expo this afternoon.

2008 10 29 Sandy Kemsley BAM
BI
BPM
BusinessRulesForum Comments (23)

Business Rules Forum: Vendor Panel

All the usual suspects joined on a panel at the end of the day to discuss the vendor view of business rules: Pegasystems, InRule, Corticon, Fair Isaac ,ILOG (soon to be IBM) and Delta-R, moderated by John Rymer of Forrester.

The focus was on what happening to the rules market, especially in light of the big guys like SAP and IBM joining the rules fray. Most of them think that it’s a good thing to have the large vendors in there because it raises the profile of and validates rules as a technology; likely the smaller players can innovate faster so can still carve out a reasonable piece of the market. Having seen exactly this same scenario play out in the BPM space, I think that they’re right about this.

The ILOG/IBM speaker talked about the integration of business rules and BPM as a primary driver — which of course Pega agreed with — but also the integration of rules, ETL and other technologies. Other speakers discussed the importance of decision management as opposed to just rules management, especially with regards to detecting and ameliorating (if not actually avoiding) situations like the current financial crisis; the use of predictive analytics in the context of being able to change decisions in response to changing conditions; and the current state of standards in rules management. There was a discussion about the difference between rules management and decision management, which I don’t believe answered the question with any certainty for most of the audience: when a speaker says “there’s a subtle but important difference” while making hand motions but doesn’t really elaborate, you know that you’re deep in the weeds. The Delta-R speaker characterizes decision management as rules management plus predictive modeling; I think that all of the vendors agree that decision management is a superset of rules management, but there are at least three different views on what forms that superset.

As a BPM bigot, I see rules as just another part of the services layer; I think that there’s opportunity for BRM in the cloud to be deployed and used much more easily than BPM in the cloud (making a web services call from a process or app to an external rules system isn’t very different than making a web services call to an internal rules system), but I didn’t hear that from any of the vendors.

That’s it for the day; I know that the blogging was light today, but it should be back to normal tomorrow. I’m off to the vendor expo to check out some of the products.

2008 10 28 Sandy Kemsley BusinessRulesForum Comments (5)

Business Rules Forum: Mixing Rules and Process

I had fun with my presentation on mixing rules and process, and it was a good tweetup (meeting arranged via Twitter) opportunity: Mike Kavis sat in on the session, Miko Matsumura of Software AG caught up with me afterwards, and James Taylor even admitted to stepping in for the last few minutes.

Mixing Rules and Process

View SlideShare presentation or Upload your own. (tags: rules brm)

I’ve removed most of the screen snapshots from the presentation since they don’t make any sense without the discussion; the text itself is pretty straightforward and, in the end, not all that representative of what I talked about. I guess you just had to be there.

2008 10 28 Sandy Kemsley BPM
BusinessRulesForum Comments (4)

Business Rules Forum: Ron Ross keynote

The good news is that it’s a lovely sunny, breezy and cool day: perfect fall weather for Toronto. The bad news is that I’m in Orlando, and was hoping to wear shorts more than sweaters this week. However, I’m here to attend — and speak at — the Business Rules Forum, not sit by the pool.

Ron Ross started the conference with a keynote called From Here to Agility; agility, of course, is one of the key reasons that you consider implementing business rules, whether in the context of BPM or other applications. It’s pretty well attended — probably 200 people here at the opening keynote, and likely a lot of vendors off setting up their booths for later today.

He started with a couple of case studies, both of companies that could really use rules due to the lack of agility in their legacy systems, and of companies that have successfully implemented rules and achieved their ROI on the first project. He then looked at what might be motivating people to attend this conference and what they can expect; a bit of an unnecessary sales pitch, considering that these people are already here.

He talked about the importance of decisioning, and how it’s a much better opportunity for business improvement than process; I’d have to agree that it’s a much greater contributor to agility, but not necessarily a better opportunity for improvement overall. I’ll have to think that through before my presentation this afternoon on mixing rules and process. He did have some convincing quotes from Tom Davenport’s “Competing on Analytics”, such as Davenport’s conclusion that automated decisioning will be the next competitive battleground for organizations.

The goals to creating business agility:

No artificial constraints in the representation of business products and your capacity to deliver them to customers — this is primarily a cultural issue, including a vocabulary to define your business practices, not a technical issue.
All operational business practices represented as rules.
All rules in a form such that they can be readily found, analyzed, modified and redeployed by qualified business people and product specialists.

Examples of operational business decisions:

How do we price our product for this transaction?
What credit do we give to this customer at this point in time?
What resource do we assign to this task right now?
Do we suspect fraud on this particular transaction?
What product configuration do we recommend for this request?
Can we confirm this reservation?

Note that these really are low-level, moderate complexity operational decisions, not strategic decisions: thousands or even millions of these decisions may be made every day in your business processes, and having agility in this type of decision can provide significant agility and competitive differentiation.

James Taylor and Neil Raden will be here later to talk about enterprise design management (EDM), but Ron gave us some of the basics: closed-loop decisioning that captures data about decisions, analyzing that data, then uses those results to make changes in a timely manner to the operational decisions. The “in a timely manner” part of that is where business rules come in, of course. That round-trip from analysis to deployment to execution to capture is key: we talk about it in BPM, but the analysis and deployment parts often require a great deal of an analyst’s time in order to determine the necessary improvements.

He went on to talk in more detail about why a focus on “business process” isn’t enough, since it doesn’t make the business adaptive, create consistent and reusable rules, or a number of other factors that are better served by business rules. To achieve business agility, then, he feels that you need:

Business-level rule management: having the business make changes to rules
Business-level change deployment: having the business in charge of the governance process for changing and rolling out changes to rules
Business-level organizational function to support the previous two activities

Looking at the problem decisions in existing legacy systems, look at the redundant, overlapping and conflicting rules; these could manifest as data quality problems, frequent change requests, or customer service problems. In many cases, these conflicting rules may be running on different platforms and address different channels. The key is to externalize these rules from the legacy systems into a decision service: a business rules management system that maintains the rules repository and is available to any application via a standard web services interface. This allows for a gradual transition from having these rules embedded within the legacy systems to centralizing them into a common repository that ensures consistent results regardless of channel or application. This provides consistency across channels, selective customer treatment and competitive time-to-market as well as rather painless compliance since your policies are embedded within the rules themselves and the rules management system can track what rules are executed at any given point in time.

Now, think of your BPMS as your legacy system in the context of the above paragraph…

Logistics: no wifi (there is wifi in the conference area but BRF didn’t spring for the password), requiring a trip to the lobby or my room in order to post — obviously, that will delay things somewhat. No power at the tables, which is not a big deal since I don’t use a lot of power with the wifi off. My blogging will be a bit light today until after my presentation this afternoon.

2008 10 28 Sandy Kemsley BusinessRulesForum Comments (6)

Ultimus: V8 technical demo

I ended up wrapped up in a discussion at the break that had me arrive late to the last session of the day; Steve Jones of Ultimus is going through many of the technical underpinnings of V8 for designers and developers, particularly those that are relevant to the people in the audience who will be upgrading from those old V7 systems soon.

A nice way to integrate with web services, where the WSDL can be interrogated and a data structure matching the interface parameters created directly from that; most other systems that I’ve seen require that you define the process parameters explicitly then map from one to the other. Of course, there’s lots of cases when you don’t want a full representation of the web services interface, or you want to filter or combine parameters during interface, but this gives you the option for setting up a lot of web services really quickly.

The integrated rules editor allows you to drag and drop process variables — including recipients — onto a graphical decision tree; you don’t have the full power of a business rules system, but this may be enough for a lot of human-centric processes where most of the complex decisions in the process are made by people rather than the system.

For interfacing with any of the external components, such as the email connector or a form, it’s possible to drag and drop data fields from the process instance schema or org chart/ActiveDirectory directly to assign variables for that component, which is a pretty intuitive way to make the link between the data sources and the external calls. They’ve also eliminated some of the coding required for things like getting the current user’s supervisor’s email address, which used to require a bit of code in V7.

Ultimus provides a virtual machine with the software pre-installed as part of their training offerings, which is a great way to learn how to work with all of this; I don’t understand why more vendors don’t provide this to their customers.

I looked back to some old notes from early 2007 when I had a demo of Ultimus V7; my impression at that time is that it was very code-like, with very little functionality that was appropriate for business analysts; V8 looks like a significant improvement over this. They’re still behind the curve relative to many of their competitors, but that’s not completely surprising considering their management upheavals over the past year. If you’re a pure Microsoft shop, however, you’ll likely be willing to overlook some of those issues; Forrester placed Ultimus in the leaders sector (in an admittedly small field) in their report on human-centric BPM on Microsoft platforms. In the broader market of all BPM vendors, Gartner placed them in the visionaries quadrant: good completeness of vision, but not quite enough ability to execute to make it into the leaders quadrant, although this latter assessment seemed to be based on the performance of the previous management team.

Steve spent a bit of time showing the V8 end-user interface: reconfigurable columns in task lists, including queries and filters; shared views to allow a personal view to be shared with another user (and allow that other user to complete work on your behalf); and the ability to run reports directly out of the standard user environment, not a separate interface.

They’ve also done some performance improvements, such as moving completed process instances to a separate set of tables (or even archived out to another database) for historical reporting without impacting the performance of work in progress.

That’s it for me for the conference (and the week); tonight, we’ll be down by the Riverwalk drinking margaritas while listening to a Mariachi band. Tomorrow is an Ultimus partner day and I’ll be on an early morning flight home. Next week, I’ll be at the Business Rules Forum in Orlando, where I’m giving a presentation on mixing rules and process. The following week, I’m headed to Miami for the Software AG analyst/blogger roundtable and a day at their user conference, a late addition to my schedule.

2008 10 23 Sandy Kemsley BPM
SOA
Ultimus Comments (1)

Ultimus: V8 Technical Deep Dive

Chris Adams is back for a somewhat longer session — I think that he zipped through the previous overview session in about 5 minutes to make up time on the schedule — to give us a lot more detail on the V8 product features. Some of this will only be of interest to Ultimus customers, but I find that it gives some good insight into how the product works and the directions that they’re taking.

First, he discussed what’s already in the released 8.x product:

Flobot connectors are now reusable. “Flobots” are the Ultimus connectors to other systems, with about 10 types available out of the box including web services calls (and I now have a very cool Flobot USB key); previously, you had to reconfigure each connector for every use. For example, for the email connector, you had to set up all parameters for the email connector (ports, authentication, etc.) each place it was used in the process, and change it whenever there was a change to, for example, the recipient. Now, they’ve allows for a reusable connector that has some or all of the parameters predefined to allow that to be more easily used in the process.
XML data storage replaces the V7 spreadsheet data structure that was previously used (which previously limited each data element to 255 characters, a limit that I sense from the audience was a sore point). My first reaction was “you used to keep your process instance data in a spreadsheet?”; sometimes you only find out about weirdnesses in a product when you hear about their upgrade out of that state.
A new Ultimus rules engine replaces event conditions, with a graphical representation of the rules. Rules actions can be related to steps in the process, or call .Net code or web services. Previously, the event conditions were kept in the spreadsheet data structure, and you had to reference the spreadsheet cell address rather than a schema variable name within rules. Now, you can add rules to processes directly in-line using the process parameters in the rule definitions.
Native ActiveDirectory support, so that you can (for example) assign a step to a group that exists in AD. You can still use their org chart functionality to create groups directly in Ultimus.
Attachments to process instances have been moved off the BPM server, and into SharePoint. You can use another content repository, but they do SharePoint out of the box and feel that it’s the best integrated solution.

Coming up in 8.2 in December:

BPMN support, although you can still convert back and forth to the Ultimus shapes if you’re more familiar with them. He showed a screenshot that looked pretty rudimentary, but it’s not released yet so I’ll reserve judgement until I see the final version.
Increased visibility into process incident history, to be able to step through exactly what happened in any particular process instance, including which rules that fired. You can actually playback
Enhanced development environment by adding Ultimus awareness to Microsoft Visual Studio for a single environment.
Fully exposed APIs, that is, access to the same APIs that the out of the box system is built on to allow you to build the same functionality into your own custom applications, with any function that you see in a pop-up menu also available through an API.

He showed us some architecture diagrams showing their new open architecture, including the client services for building custom client applications, BI services for custom reporting applications, and Flobots for external connectors.

2008 10 23 Sandy Kemsley BPM
SOA
Ultimus Comments (0)

IBM to acquire ILOG

IBM and ILOG announced today that IBM will be acquiring ILOG for €10/share, or about $US340 million in total.

IBM’s goal is to integrate ILOG’s business rules technology into their existing BPM and SOA offerings:

When completed, the acquisition of ILOG will strengthen IBM’s BPM and SOA position by providing customers a full set of rule management tools for complete information and application lifecycle management across a comprehensive platform including IBM’s leading WebSphere application development and management platform.

The funny part is that the IBM press release take two paragraphs to explain what BPM is, and how business rules are used in the context of BPM, indicating just how niche these technologies still are in the broader business scope.

This may not be good news for ILOG’s other BPM partners; one less independent BRMS company means less choice when it comes to putting your processes and rules together.

Tagged IBM, ILOG

2008 07 28 Sandy Kemsley BPM
SOA Comments (1)

Business Rules Forum

The Business Rules Forum is coming up on October 26-30 in Orlando, and I’ll be back there again this year to speak. You can find my coverage of last year’s event here, and my presentation on BPM, BR and BI is available here. I found last year’s event definitely worthwhile, although I was left with the feeling that we still had a long way to go in terms of creating the necessary about of synergy between BPM and BR. A lot has happened in a year, and this year I’m speaking on mixing rules and process:

There are many techniques for combining rules or decisioning capability with business process management (BPM), ranging from using simple expression engines embedded within a BPM system to a full integration between separate BRM and BPM systems.

This session takes a close look at what rules functionality that the BPM systems offer, and the key characteristics that identify which rules and decisions should remain in the domain of the BPM system, and which should be entrusted to a full-strength business rules management system. What you will will learn:

The current state of BPM and BRM

How BPM and BRM interact

Where your rules belong

You can find the conference brochure/schedule here, and online registration here. The organizers have offered my readers 10% off the conference registration if you use the promotional code 8SPSK when you register, and you can also get an early bird discount if you register by September 19th. I don’t get a referral fee from this, it’s just there as a courtesy for any of you who are interested in attending, although in the spirit of full disclosure, my travel expenses to attend are covered by the conference since I’m a speaker.

2008 07 28 Sandy Kemsley BusinessRulesForum Comments (2)

Business Rules Management and Business Process Management: Turning Policies into Action

Recently, I wrote a white paper for Corticon Technologies on the synergy between BPM and BRM. From the introduction:

The mantra of today’s business environment is “build for change”, driving many process improvement initiatives. Businesses must realize, however, that the decisions within the business processes are at least as critical in the search for agility, since the decisions change more frequently than the processes. Combining business rules management and business process management provides that agility by allowing the decisions, and their underlying rules, to be changed independently from the processes, often in real-time by business managers.
This white paper examines the intersection of business rules management and business process management: what they are, how they interact, and why this is important to the agility, accuracy, cost and compliance of your business processes.

You can find the white paper on their site here (available as a link from their Solutions / Business Process Management page), no registration required.

Tagged corticon

2008 07 14 Sandy Kemsley BPM Comments (0)

Oracle BEA Strategy Briefing

Not only did Oracle schedule this briefing on Canada Day, the biggest holiday in Canada, but they forced me to download the Real Player plug-in in order to participate. The good part, however, is that it was full streaming audio and video alongside the slides.

Charles Phillips, Oracle President, kicked off with a welcome and some background on Oracle, including their focus on database, middleware and applications, and how middleware is the fastest-growing of these three product pillars. He described how Oracle Fusion middleware is used both by their own applications as well as ISVs and customers implementing their own SOA initiatives.

He outlined their rationale for acquiring BEA: complementary products and architecture, internal expertise, strategic markets such as Asia, and the partner and channel ecosystem. He stated that they will continue to support BEA products under the existing support lifetimes, with no forced migration policies to move off of BEA platforms. They now consider themselves #1 in the middleware market in terms of both size and technology leadership, and Phillips gave a gentle slam to IBM for over-inflating their middleware market size by including everything but the kitchen sink in what they consider to be middleware.

The BEA developer and architect online communities will be merged into the Oracle Technology Network: Dev2Dev will be merged into the Oracle Java Developer community, and Arch2Arch will be broadened to the Oracle community.

Retaining all the BEA development centers, they now have 4,500 middleware developers; most BEA sales, consulting and support staff were also retained and integrated into the the Fusion middleware teams.

Next up was Thomas Kurian, SVP of Product Development for Fusion Middleware and BEA product directions, with a more detailed view of the Oracle middleware products and strategy. Their basic philosophy for middleware is that it’s a unified suite rather than a collection of disjoint products, it’s modular from a purchasing and deployment standpoint, and it’s standards-based and open. He started to talk about applications enabled by their products, unifying SOA, process management, business intelligence, content management and Enterprise 2.0.

They’ve categorized middleware products into 3 categories on their product roadmap (which I have reproduced here directly from Kurian’s slide:

Strategic products

BEA products being adopted immediately with limited re-design into Oracle Fusion middleware
No corresponding Oracle products exist in majority of cases
Corresponding Oracle products converge with BEA products with rapid integration over 12-18 months

Continue and converge products

BEA products being incrementally re-designed to integrate with Oracle Fusion middleware
Gradual integration with existing Oracle Fusion middleware technology to broaden features with automated upgrades
Continue development and maintenance for at least 9 years

Maintenance products

BEA had end-of-life’d due to limited adoption prior to Oracle M&A
Continued maintenance with appropriate fixes for 5 years

For the “continue and converge” category, that is, of course, a bit different than “no forced migration”, but this is to be expected. My issue is with the overlap between the “strategic” category, which can include a convergence of an Oracle and a BEA product, and the “continue and converge” category, which includes products that will be converged into another product: when is a converged product considered “strategic” rather than “continue and converge”, or is this just the spin they’re putting on things so as to not freak out BEA customers who have put huge investments into a BEA product that is going to be converged into an existing Oracle product?

He went on to discuss how each individual Oracle and BEA product would be handled under this categorization. I’ve skipped the parts on development tools, transaction processing, identity management, systems management and service delivery, and gone right to their plans for the Service-Oriented Architecture products:

Strategic:

Oracle Data Integrator for data integration and batch ETL
Oracle Service Bus, which unifies AquaLogic Service Bus and Oracle Enterprise Service Bus
Oracle BPEL Process Manager for service orchestration and composite application infrastructure
Oracle Complex Event Processor for in-memory event computation, integrated with WebLogic Event Server
Oracle Business Activity Monitoring for dashboards to monitor business events and business process KPIs

Continue and converge:

BEA WL-Integration will be converged with the Oracle BPEL Process Manager

Maintenance:

BEA Cyclone
BEA RFID Server

Note that the Oracle Service Bus is in the “strategic” category, but is a convergence of AL-SB and Oracle ESB, which means that customers of one of those two products (or maybe both) are not going to be happy.

Kurian stated that Oracle sees four types of business processes — system-centric, human-centric, document-centric and decision-centric (which match the Forrester divisions) — but believes that a single product/engine that can handle all of these is the way to go, since few processes fall purely into one of these four categories. They support BPEL for service orchestration and BPMN for modeling, and their plan is to converge a single platform that supports both BPEL and BPMN (I assume that he means both service orchestration and human-facing workflow). Given that, here’s their strategy for Business Process Management products:

Strategic:

Oracle BPA Designer for process modeling and simulation
BEA AL-BPM Designer for iterative process modeling
Oracle BPM, which will be the convergence of BEA AquaLogic BPM and Oracle BPEL Process Manager in a single runtime engine
Oracle Document Capture & Imaging for document capture, imaging and document workflow with ERP integration [emphasis mine]
Oracle Business Rules as a declarative rules engine
Oracle Business Activity Monitoring [same as in SOA section]
Oracle WebCenter as a process portal interface to visualize composite processes

Similar to the ESB categorization, I find the classification of the converged Oracle BPM product (BEA AL-BPM and Oracle BPEL PM) as “strategic” to be at odds with his original definition: it should be in the “continue & converge” category since the products are being converged. This convergence is not, however, unexpected: having two separate BPM platforms would just be asking for trouble. In fact, I would say that having two process modelers is also a recipe for trouble: they should look at how to converge the Oracle BPA Designer and the BEA AL-BPM Designer

In the portals and Enterprise 2.0 product area, Kurian was a bit more up-front about how WebLogic Portal and AquaLogic UI are going to be merged into the corresponding Oracle products:

Strategic:

Oracle Universal Content Management for content management repository, security, publishing, imaging, records and archival
Oracle WebCenter Framework for portal development and Enterprise 2.0 services
Oracle WebCenter Spaces & Suite as a packaged self-service portal environment with social computing services
BEA Ensemble for lightweight REST-based portal assembly
BEA Pathways for social interaction analytics

Continue and converge:

BEA WebLogic Portal will be integrated into the WebCenter framework
BEA AquaLogic User Interaction (AL-UI) will be integrated into WebCenter Spaces & Suite

Maintenance:

BEA Commerce Services
BEA Collabra

In SOA governance:

Strategic:

BEA AquaLogic Enterprise Repository to capture, share and manage the change of SOA artifacts throughout their lifecycle
Oracle Service Registry for UDDI
Oracle Web Services Manager for security and QOS policy management on services
EM Service Level Management Pack as a management console for service level response time and availability
EM SOA Management Pack as a management console for monitoring, tracing and change managing SOA

Maintenance:

BEA AquaLogic Services Manager

Kurian discussed the implications of this product strategy on Oracle Applications customers: much of this will be transparent to Oracle Applications, since many of these products form the framework on which the applications are built, but are isolated so that customizations don’t touch them. For those changes that will impact the applications, they’ll be introduced gradually. Of course, some Oracle Apps are already certified with BEA products that are now designated as strategic Oracle products.

Oracle has also simplified their middleware pricing and packaging, with products structured into 12 suites:

He summed up with their key messages:

They have a clear, well-defined, integrated product strategy
They are protecting and enhancing existing customer investments
They are broadening Oracle and BEA investment in middleware
There is a broad range of choice for customer

The entire briefing will be available soon for replay on Oracle’s website if you’re interested in seeing the full hour and 45 minutes. There’s more information about the middleware products here, and you can sign up to attend an Oracle BEA welcome event in your city.

Tagged BPEL, BPMN

2008 07 01 Sandy Kemsley BPM
BPM standards
CEP
ESB
Enterprise 2.0
SOA Comments (16)

Business Rules webinar replay

Apparently the replay information for the BPM-BRM webinar that I did on April 24th went out last week to all the registrants, but not to me; you can replay it here. I’ve uploaded the slides to SlideShare and embedded them below, but as one person told me, I tend to put up a few words on a slide then talk at about 300 words per minute, so probably better to listen to the replay.

| View | Upload your own

2008 05 05 Sandy Kemsley Comments (1)

Business Rules Webinar Q&A

It was a busy week last week at TUCON and I completely forgot about the questions from the Business Rules Forum Q&A from the webinar that I did on the 24th. I’m not sure if the replay is available yet, I’ll post a link when I hear about it.

Here’s my answers to the questions that came up during the presentation, although I responded to some of these at the end. Where the question wasn’t clear, I took a stab at an interpretation; if I missed the point, please add a comment to this post with your clarification and I’ll follow up.

Explain the relationship between business models and BPM.

Not sure of the exact intent, but I think that this is asking about the relationship between business (process?) modeling and BPM. Business models of various sorts, including business process models, are often created by an organization to provide a high-level, business-oriented view of their operation. From an enterprise architecture standpoint, these are the models in the highest level of the architecture that may be created by, and are always understandable by, a non-technical business analyst. In the case of business process models, these are created to model the flow of a business process, usually in a flow-chart or swimlane type of diagram. In many cases, these are created in a standalone modeling tool — either a simple desktop application like Microsoft Visio, or a more comprehensive tool such as IDS Scheer’s ARIS — but may also be modeled directly in the process modeling environment of a BPM suite (BPMS). In this latter case, a process model can be directly translated to an executable process.

Is there any benefit to implementing a BRM without a BPM?

Yes, there are many cases of using a BRMS separately from BPMS: the rules/decisions may be accessed directly as part of a manual process, where a user enters in the required parameters and is given a decision back in return, or they may be called from other applications such as a CRM.

Please mention vendors or products by name, even if caveats apply.

and

Can you name products that support what has been presented?

and

What are the methods & technology tools used for BRM & BPM?

I can’t recall if we were talking about BPMS or BRMS vendors here, so I’ll try to cover both. To hit the major vendors, take a look at which ones are included in the reports by the big analysts. Gartner includes the following BPMS vendors in its Magic Quadrant for BPMS, published in December 2007: Adobe, Appian, Ascentn, AuraPortal, BEA, Captaris, EMC, Fujitsu, Global 360, IBM, Intalio, Lombardi, Metastorm, Microgen, Oracle, Pegasystems, Savvion, Singularity, Software AG, SunGard, TIBCO and Ultimus. Forrester splits up the market into four categories with several vendors in each, which I’ve listed in a previous post.

On the BRMS side, Forrester recently issued a report on BRMS vendors in which they evaluated CA, Corticon Technologies, Experian, Fair Isaac, Haley Limited, ILOG, Innovations Software Technology, InRule Technology, Intelligent Results, Pegasystems, and SAP.

There are other vendors of both types, but this covers the major players. Also notice that Pegasystems plays in both markets — and in fact is a leader in both — since its BPMS is based on a rules engine.

Who are some of the vendors with tight integration between BPM and BRM?

Pegasystems is the obvious starting point, since they use a rules engine as an underlying platform for their BPMS. Many BPMS vendors don’t want to talk about a tight integration with a third-party BRM since that implies a weakness in their own rules capabilities. All BPMS vendors, through their support for invoking web services, can integrate loosely with BRM.

In your opinion, have any BRMS suites achieved robust BPM capabilities?

Only Pegasystems, to my knowledge. It’s more likely that a BPMS will achieve BRM capabilities rather than the other way around, in my opinion.

How could you change a business rule and have it only affect new BPM processes and not in flight process instances?

There are two ways to do this. First, if all parameters that drive the rules are known at the beginning of the process, the process instance could invoke the rules immediately after it is created, and store the decision results until they are required; since the rules are executed at the time that the process instance is created, the instance will not be affected by any changes to rules while it is in progress. Second, a process can call a specific version of a rule, assuming that the BRMS supports rules versioning. That way, any process instances created from a specific version of a process definition can call a specific version of a rule, even if the rule has changed since then. Newer process definitions could be changed to call a later version of the rule.

You said that a BPMS will call a BRMS (typical scenarios). How would the BRMS know the scope of what needs to be checked? For example, if you have the rule "some applicant of each loan application must have a credit score of 600". When the business process for loan applications calls the BRMS, how does it determine the set of applicants that need to checked?

I think that the question is about where the BRMS gets its information that is used as parameters for the decisions. This would typically be passed to the BRMS from the calling application, in this case, the BPMS. The BPMS may need to make calls to other systems in order to get this information, then forward it to the BRMS: remember that part of the role of the BPMS is to orchestrate multiple systems and pass data along between them, including the BRMS.

Do you normally see that the same business users are maintaining both the processes and rules or are they normally different business users?

If you’re talking about the business analysts that would be designing the processes or rules, it is best if they are the same — so that they can decide what happens in a process versus what happens in a rule — but often are different people due to the training requirements. If these are separate roles, then the process analysts need to learn enough about rules to know when to request that a rule set be created for them to call from their processes.

How would you define the relationship between BPM, BRM and RBA (Run Book Automation)?

I’m not that familiar with RBA, but it is focused on IT and systems processes, not business processes. At TUCON last week, however, one of the presentations was on how they used TIBCO products for IT processes, although he didn’t refer to it as RBA.

Do you agree that BRM and BPM have to be married with the SME from the business side and the SME from the IT side to be successful?

I’m unclear on what this question means. "SME from the business side" means, to me, someone who is an expert on the business being performed; I’m not sure what "SME from the IT side" means. Both BRM and BPM are most successful when there is collaboration between business and IT: the business analysts doing the high-level modeling of the rules and processes to ensure that they meet the business requirements, and IT making sure that the technical underpinnings (such as calls to web services) are in place.

Do you have a list of feature set for BRM and BPM for product evaluation?

and

Could we get a list of recommended BPMS and Rules Management systems and why they are recommended?

Gartner and Forrester both publish comparative reports on BPMS and BRMS, I suggest that you start there.

What is the difference between BRM and procedures / governing document / policies? Give examples of BRM.

Policies, procedures and governing documents are the "rules" by which the business operates, but may not be automated in any way: many organizations just have people refer to a policies and procedures guide to tell them what to do in a manual process. BRM allows you to codify those policies and procedures so that they can be automated, and are executed the same way every time.

What about open source offerings? Have you worked or reviewed any of those?

Drools (from jboss) and NxBRE are two open source BRMS offerings. jBPM (also from jboss) and Intalio are both open source BPMS offerings. I recently did a review of Intalio but haven’t yet published what I saw; I haven’t worked with any of the other products. Many open source offerings don’t have the full functionality of their commercial counterparts so may not be included in the analysts’ comparative reports; the recent Gartner Magic Quadrant for BPMS is the first one in which Intalio has been included, for example.

Can you provide a simple example of how BPM and BRM are applied in practice?

A typical example that I’ve seen is in claims processing. There are many specific policies and procedures that must be followed to process a claim, and many BPM implementations just leave the decisions based on those policies to a person who is participating in the process: for example, give the work step to a person and have them decide the type of the claim and what region should be processing it. By adding BRM, these decisions can be automated based on data that is already known

Do you feel BPM can be used as a tool to integrate compliance management systems? e.g. OSH, Environment, Quality etc.

I’m not a compliance specialist, but I see many organizations using both BPM and BRM to help with their compliance efforts, since both can help to standardize processes and allow for easy auditing of what was actually done. As for integration with compliance management systems, that would depend on those systems and whether they provide a web services interface or other API.

What are some of the software packages you can purchase for extracting business rules?

The major BRMS products typically include tools for mining business rules from existing systems; you’ll need to check their functionality against the particular systems and platforms from which you want to extract rules to see if they’ll work for you.

How are the BRMS incorporated with any testing tools?

Many of the BRMS vendors have simulation and testing tools as part of their suite, specifically to test if the rules are complete and non-contradictory.

2008 05 04 Sandy Kemsley BPM
BusinessRulesForum Comments (0)

BPM and business rules webinar

This fall, I’ll be back at the Business Rules Forum to make a presentation on business rules and BPM, but next week you can catch me online on a Business Rules Forum webinar speaking on the same subject:

Process improvement is a top priority for executives today, but business process management (BPM) alone doesn’t provide the whole answer. Although BPM does enable process improvement, it often doesn’t provide sufficient agility for today’s business processes.

To build for change, it is necessary to integrate business rules with BPM. This integration allows you to manage the decisions within your business processes, and easily modify those rules without recoding or changing the business processes.

In this webinar, you’ll learn about the business process management lifecycle, and how business rules can be integrated within it to greatly improve process agility. It also discusses how you can apply business rules consistently across multiple business processes and other applications.

Regular readers know that I’m a big fan of mixing business rules and BPM for maximum agility in your processes, and this webinar is an introduction to why you would want to do that, and how it works.

2008 04 15 Sandy Kemsley BPM
BusinessRulesForum Comments (4)

Change the Rules webinar

I’m doing a webinar tomorrow with David Straus of Corticon and Jim Sinur of Global 360 called Change the Rules without Changing your Business Processes: Using Business Rules Management to Turbo-Charge your BPM Solution. Tune in and hear how I sound after my run-in with the flu that ate Las Vegas.

2008 02 11 Sandy Kemsley BPM Comments (0)

Gartner BPM: Business Rules Management State of the Art, Marc Kerremans

Marc Kerremans’ presentation on business rules management started out looking at where rules exist in an organization, and how they are used. In many cases, rules are still embedded within applications — such that changing a rule requires changing the underlying code — or are implemented in a manual and sometimes ad hoc manner. Gartner defines business rules as “implicit and explicit business policies that define and describe a business action”, where implicit rules are those embedded within applications.

He discussed how rules can differ greatly within a single organization based on factors such as geography and the associated local regulations, and how a business rules management system — which manages rules explicitly and externally from business applications — can add value in managing all of the complex rules across an organization.

He also looked at who owns and manages business rules:

Line of business managers determine the most volatile rules that may need to be changed to meet business agility needs, define the rules required, and author/change less complex business rules.
Systems architects author more complex rules, and test rules to assure that the system is performing as required.
Business analysts discover and author new rules based on their analysis of the business health, and create and simulate rule scenarios.

Since 2004, BRE and BPM have evolved from distinct and separate markets to an integration of BRE in many BPMS, to the current state of business rules management systems (BRMS) that go beyond simple business rules engine functionality. Typically, a BRMS contains:

Rule execution engine, including execution, sequencing and chaining of rules, and event-based execution.
Rule repository, where rules are stored for access by design tools and at run time. This includes security and version control to prevent unauthorized changes to the rule definitions.
Rule modeling and simulation, for what-if analysis. This will show effects such as dependencies between rules, and performance tracking.
Monitoring and analysis of historical and real-time rule usage, including reporting and audit trails.
Rule management and administration, working in concert with the repository, to manage security, promotion between development, test and production environments, and track changes and performance.
Rule templates to provide a quick start for specific vertical industry rule sets, and horizontal rules sets such as compliance.
Rule integrated development environment, which provides a graphical, model-driven environment for authoring, testing and debugging rules. This may include wizards for easy creation of rules by business managers/analysts, and collaboration tools.

As with BPMS, not all vendors will cover all of the full range of functionality equally well. There are some open source BREs that provide only the engine functionality, such as JBOSS and NxBRE. Most of the commercial vendors, such as Corticon, Fair Isaac and ILOG, are either migrating to the full BRMS functionality or are already there. There’s also an overlap of BPMS that provide BRE functionality: Pegasystems is the most commonly-cited player here since their BPMS is actually built on a rules platform, but other BPMS vendors provide rules that can be separated from the processes to at least allow reuse across multiple processes, although not across non-BPMS applications.

Agility is the primary reason that organizations look to BRM, which can manifest as awareness (accessing and presenting the right information through rules-based event monitoring), flexibility (rule modeling and simulation to handle expected change), adaptability (rapid rule modification to handle unexpected change) and productivity (executing the right policies and procedures).

There are other reasons for implementing BRM besides agility, of course: improving the quality and consistency of business decisions, improving revenue opportunities by fine-tuning pricing rules on the fly, improving customer satisfaction through greater customization, and better regulatory compliance and governance through the use of audited rules and increased visibility into how decisions are made.

Kerremans went through a number of best practices for getting started with BRM, such as analyzing rule volatility, and establishing a process for making changes to rules. As much as possible, try to work with natural language representations of rules so that business managers are comfortable with the authoring environment, although some level of structure to the language (”rules speak”) will be necessary.

He also discussed the different types of rules technology, including inference-based and event-based rules engines, before finishing up with some recommendations on developing a business rules management strategy. As with BPMS, many larger organizations will end up with multiple BRE tools to cover their entire strategy, so don’t assume that you’ll be working with only a single vendor in this space.

For you business rules aficionados, note that I’ve change the business rules category on this blog to BRM, instead of BRE.

2008 02 06 Sandy Kemsley Gartner BPM Comments (3)

Column 2