Column 2 : BusinessRulesForum

{ Category Archives } BusinessRulesForum

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 BRM 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 BRM
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 BRM 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
BRM 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 BRM 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
BRM Comments (4)

Bloggers at Business Rules Forum

I’m not the only one blogging from BRF: Paul Vincent of TIBCO posted here about yesterday’s workshops, and James Taylor is twittering and blogged this morning’s keynote session with a promise of more live blogging.

Other bloggers here, add a comment with your URL.

2008 10 28 Sandy Kemsley Comments (0)

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 BRM Comments (6)

The fall schedule

I have my fall schedule mostly sorted out, and here’s my confirmed lineup so far:

OMG BPM Think Tank, October 6-7, Chicago. I’m on the program committee, and will be leading a roundtable on achieving collaboration between business and IT in BPM on the first day.
PegaWorld, the Pegasystems user conference, October 19-21, Washington DC. I’m just there as an observer and analyst/blogger.
Ultimus user conference, October 22-24, San Antonio. I’ll be giving a keynote on the afternoon of the first day. And yes, I know that you can’t get from DC to San Antonio.
Business Rules Forum, October 26-30, Orlando. I’ll be giving a presentation on mixing rules and process on the 28th.
SAP BPM, November 17-19, Las Vegas. I’m giving a Jumpstart pre-conference session, an introduction to BPM, on the 16th.

Look me up if you’re at any of these events.

Disclosure: with the exception of the OMG event, my travel expenses are paid for by the conference organizers; in the case of the SAP conference, I’m also being paid to deliver this half-day training session.

2008 09 22 Sandy Kemsley BPMThinkTank
PegaWorld
SAPevents
Ultimus Comments (0)

Upcoming conferences

I’ve been sticking close to home for the summer, but my fall lineup is about to begin. So far, I’m definitely attending the following:

Business Objects Influencer Summit and SAP SME Day, August 12-13, Boston. This is an analyst/press event, not a public conference, but I’ll be blogging from there.
International Conference on BPM, September 1-4, Milan. I’m very excited to be attending this conference since it represents a lot of the academic research going on in BPM, not just what the vendors and analysts have to show. There are some great workshops lined up, such as BPM and social software; interesting sessions; and demos from some of the universities and research labs. You can find last year’s proceedings here.
The Appian user conference, September 8-10, Washington DC. This is the first time that I’ve attended an Appian conference, and I’m looking forward to seeing what all those new marketing dollars are buying.
The Gartner BPM summit, September 10-12, Washington DC. I’ve been to enough of these lately that I don’t need to attend the whole summit, but since I’m in DC that week for Appian’s conference, I’m adding one more day for Gartner. I think that it’s pretty clever for Appian to schedule like this: it should drive up attendance at their conference, since Appian customers/partners flying in for Gartner will figure that it’s only a couple of extra days to do both.
OMG BPM Think Tank, October 6-7, Chicago. I’m on the program committee, and will be leading a roundtable on achieving collaboration between business and IT in BPM on the first day.
Business Rules Forum, October 26-30, Orlando. I’ll be giving a presentation on mixing rules and process.
SAP BPM, November 17-19, Las Vegas. I’m giving a Jumpstart pre-conference session, an introduction to BPM, on the 16th.

Given that I fly everywhere on Star Alliance, this will bump me over the 35,000 miles for the year that gives me Aeroplan Elite status for 2009, without which I really don’t want to fly.

From a disclosure standpoint, my expenses are being paid for the Appian conference, the Business Rules Forum, and two SAP events; for the latter SAP event, I’m also being paid to deliver the half-day training session.

Tagged appian, business rules forum, Gartner, OMG, SAP

2008 08 01 Sandy Kemsley AppianForum
BPMThinkTank
Gartner BPM
IntlBPM
SAPevents Comments (0)

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 BRM Comments (2)

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
BRM 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
BRM Comments (4)

Meeting the bloggers at BRF

Last week at the Business Rules Forum gave me a chance to meet many people who I’ve never met face-to-face, but feel that I know from our exchanges of blog comments and emails: at one point, I was standing around talking to James Taylor, Rolando Hernandez and Scott Sehlhorst.

James was certainly the most prolific in blogging about the conference: he live-blogged the sessions that he attended (even mine), so you can compare with the posts on those sessions that I wrote. He has a wrap-up post with pointers to all of the blogs that he found with coverage of the event.

2007 10 29 Sandy Kemsley blogging Comments (0)

BRF Day 3: Good Business Rules in Process — Eliminate 65% of the Activities

I couldn’t quite drag myself out of bed for the 8am sessions, but I did want to hear Kathy Long of the Process Renewal Group talking about process and rules. She talked about how to derive rules from processes, and use them as guides to the process. There’s a number of process-related problems that can occur when the rules are not explicit: assumed policies, activities with experience as the only guide, and inconsistent (and therefore likely non-compliant) processes. The key things to consider when analyzing the guides for a process can be focussed around what happens at a given activity (are what knowledge is required, what decisions are required, what reports have to be generated) as well as a number of other factors; she presents a number of different questions to ask in order to drive out the rules and make them explicit.

She also made a distinction between policies and rules, where the key differentiator is that rules are actionable, whereas policies must be interpreted into more concreted business rules in order to take action. Within rules, there’s both structural rules (can’t be broken) and operative rules (which have a bit more wiggle room); this sounds a bit like the distinction between a fact and a rule that I heard in a session yesterday, which makes me unsure that there’s a really common vocabulary for some of these things.

Looking at some of their process analysis techniques, she presented categories of activities as real value-added (impact the customer’s requirements), business value-added (required to run business, such as regulations), and non value-added (that 65-85% of work that doesn’t contribute to either RVA or BVA). There’s a whole list of verbs — adjust, approve, expedite, inspect, verify and many others — that tend to indicate that activities are NVA and should be considered for elimination. Many of these are because something wasn’t done right the first time; a lot of the NVA activities can be cut if there’s ways to reduce the error rates in the RVA and BVA activities. This isn’t, of course, really about rules: it’s about process improvement. Sure, the appropriate addition of business rules can certainly lead to process improvement, but it’s also about the myriad other ways that we improve processes, such as establishing accountability and eliminating unneeded steps that are only there for historical reasons. Some thoughts that Long gave us to take away:

The greatest opportunity to improve a process is by changing the rules
Challenge all policies
Validate all compliance interpretations
Eliminate the use of assumed policies
Ensure that all rules are documented including the use of experience/knowledge
Create consistent rules across the enterprise
Structure rules so that they can be easily changed
Allow the business to design its own processes

I was surprised that she didn’t talk at all about some of the technology issues such as how BPM and BR can be used together to improve processes, but her focus was not at all on technology: her only case study was about improving a process based on a manual procedural change.

I have to head off for a mid-day flight home, so that was the end of my Business Rules Forum experience. I’ve actually learned a lot here, which has made my time here definitely worthwhile. However, I’m still left with the feeling that I mentioned on my first post back on Tuesday: we need to start having much more crossover between different technology areas such as BPM and BR. I’ve been writing since mid-2005 about the importance of looking at BPM and BR together, but in spite of the technology advances that have occurred since then to facilitate this, I’m not seeing much happening in the real world.

2007 10 25 Sandy Kemsley BPM Comments (2)

BRF Day 2: How Business Rules Re(Define) Business Processes: A Service Oriented View

For the last session today, I attended Jan Venthienen’s session; he’s a professor at Katholieke Universiteit Leuven. He talked about different representations of rules, particularly decision tables (at length, although in an interesting way). He talked about the problems with maintaining decision trees, then as he moved on to business processes, he showed how a business process with the rules encoded in the process as routing logic was really just a form of decision tree, and therefore difficult to maintain from a rules integrity standpoint. As rules are distilled out of and separated from the processes, the processes become thinner and thinner, until you have a single branch straight-through flow. I have the feeling that he’d like to reduce the process to a single activity, where everything else is done in a complex rule called from that step. I’m not sure that I agree with that level of stripping of logic out of the process and into the rules; there’s value in having a business process that’s understandable by business users, and the more that the logic is encapsulated in rules, the harder it is to understand how the process flow works by looking at the process map. The critical thing is knowing which rules to strip out of the business process, and which to leave in.

He’s doing research now to determine if it’s possible to specify business rules, then automatically derive the business process from the rules; an interesting concept. In order to do this, there must be rules that constrain the permission and obligations of the actors in the process, e.g., an order must be accepted before the product is shipped. This presents two possible architectural styles: process first, or rules first. In either case, what is developed is an architecture of rules, events and services, with a top layer of business rules and processes, a middle layer of services and components, and a bottom layer of enterprise applications.

2007 10 24 Sandy Kemsley BPM
BRM
CEP
SOA Comments (3)

BRF Day 2: Using Business Rules to Enable a Closed Loop of Compliance

I’m eager to learn more about the relationship between policies, procedures and rules, and how they relate to compliance, so I sat in on a presentation by Peter Still of RuleBurst. There’s a pretty high percentage of vendors on the speaker roster, but so far the quality has been good so no complaints.

The theme of Still’s talk is that the business rules approach will only gain critical mass if it stops being a technical implementation tool and starts being a business problem-solving tool. The current pitch from the business rules vendors is that this is a way to implement systems faster and cheaper, while allowing the business to access some tuning parameters, but this is really focussed on the technological capabilities and not the business value of business rules. This is such a perfect mirror of the BPM field, where BPM has just barely moved from a purely technical sell to something that’s now being sold more and more to the business side of an organization, so I can completely understand where the business rules market is and the challenges that lie ahead in shifting the focus of their marketing message. Worldwide market for business rules product revenue is $250M — not a lot when you consider the size of related markets — and it could be a lot larger if there was greater recognition of the business benefits of business rules.

A perfect business case for re-targeting the business rules message is compliance: it’s an enterprise-wide initiative with executive support where business rules can be included in the decisioning at key points of the process. Although business rules aren’t the complete answer to compliance since compliance is a very process-focussed initiative, rules can be a significant contributor to compliance efforts. One of the difficulties with compliance is that many regulations, such as Sarbannes Oxley, are pretty vague since they have to deal with such a broad range of companies, and it’s difficult to determine precise business rules to implement them. Compliance at a transactional level is a mostly automated application of BPM and business rules, but as you move up to risk management and higher-level compliance factors, there’s less automation although still opportunities for business rules to be wrapped in a compliance framework, such as using business rules to classify a risk although the management of that risk may be done manually. Still maintains that there’s a link between transactional and operational compliance, and believes that business rules can help with that link although that’s not recognized by most business rules vendors.

As with most other complex applications of technology, you can solve this with an integrated compliance and rules solution from a single vendor, or go for a best-of-breed approach. Still recommends the former approach, and invited us to drop by his booth to check out what RuleBurst has to offer in this area.

2007 10 24 Sandy Kemsley BRM
compliance Comments (0)

BRF Day 2: True Adventures in Business Rules

Paul Armborst of the Westfield Group presented on his experiences in implementing business rules for their various insurance applications over the past 6 years. He sees one of the key problems is in documenting business rules, with two main choices for how to do it:

Define the rules in a repository first (a rules management/modelling tool). Although this is the most likely approach for the first definition of rules within an organization, they’ll become out of sync as soon as they are implemented since the rules will be modified in the executing code or BRE rather than in the repository.
Define the rules directly in a business rules engine, then generate the documentation in some automated fashion (likely provided by the BRE vendor)

He sees that the best way would be a combination of both approaches: a throw-away repository to document rules as they are discovered, and an extract from the BRE to provide ongoing documentation.

He pointed out one of the problems with introducing business rules: “real” developers want to write Java code, not this airy-fairy business rules stuff, which is an argument that I see against BPM as well. As IT budgets get squeezed, however, development teams will start to look for ways to reduce the amount of code that they have to write and pass some of the tuning capabilities directly over to the business; both BRE and BPM provide these types of capabilities.

He discussed various methods of implementing business rules:

Decision tables, noting that the BRE vendor needs to provide some sort of analysis tool to detect gaps and overlaps in the rules, with the caveat that it’s possible to construct a decision table that’s too big to reasonably maintain.
Decision trees, which can provide the same functionality in a decision table, but in a graphical form; if the decision points are not in the right order, the number of nodes can multiply unnecessarily, and overly-large trees can be difficult to follow.

He also discussed stateful and stateless implementations of business rules: although stateless is simpler to implement, stateful allows for running only the rules that use data that has changed since the last evaluation of each rule.

There were some last comments on end user rule maintenance: all of their rules are written by developers, but they’re thinking about how to offer some rule creation and modification capabilities to end users. It’s important to have a BRE that allows some sort of restricted view for less technical users, but it’s also necessary for the techies to do some helpful things like naming objects in a manner that users can understand rather than, say, reverse Hungarian notation. Users who have access to create rules need to have some notion of the logic required to do so, and there needs to be some provision for testing.

2007 10 24 Sandy Kemsley BRM Comments (4)

BRF Day 2: Rules Management Without a Rule Engine

I moved over to the über-geeky “chief architect” track to hear Rik Gerrits of RuleArts and Petr Choteborsky of Microsoft, but 10 minutes into the session, Gerrits is still giving some fairly basic definitions of business rules management: where rules live, how they’re developed, and how they’re managed and used. He does make a point that business processes consume business rules but that they should be distinct in terms of methodology and implementation, as well as other motivations for business rules management such as compliance and efficiency improvements.

Choteborsky took over with a case study about Microsoft’s internal development (as in applications for their own internal use, like software licence authorization), and instantly endeared himself to the audience by saying that he was in corporate IT at Microsoft, and was just as much a victim of the Microsoft product groups as we were. They had issues with software development lifecycle documents and the rules that were embedded within those documents: multiple, conflicting instances of rules in different documents; rules not explicitly defined hence less agile; no common vocabulary leading to inconsistency and miscommunication. Over time, the business logic is lost, and the business requirements documentation becomes completely out of sync with the application and the user manual, so that the only true representation of the business logic is embedded within the application as coded.

He stepped through an example, showing how to break down the prose in a requirements document to determine what is a rule set (a group of related rules), what’s a rule, what’s a fact (unchangeable, therefore may be hard-coded), what is usability behaviour (which may include hidden rules and facts), and what is contextual information that describes capability without being something that will be explicitly coded. Very cool example, since he shows the tendency for the prose in what we think of as a fairly well-written requirements document to actually be a confusing mix of facts, rules, behaviour and context that doesn’t really provide adequate information about what should be written to be easily changeable versus what can be hard-coded into an application.

He went on to show how the same paragraph should be restructured as facts and rules (describe the pure essence of how business must be conducted, independent of implementation detail), requirements (UI and application requirements to implement the rules) and context (information that makes it easier to understand the facts, rules and requirements; redundant information that is not coded). The rules mantra (which I’m just learning today) is “rules build on facts, facts build on terms”, and he shows the terms sprinkled throughout the facts and rules.

They’re attempting to change their requirements documents to this form of structured requirements using business rules (for going-forward documents, not retrofitting the existing ones), but it’s a painful process: there needs to be some common vocabulary and a significant amount of training in some cases to have people start thinking in this way. There was a comment from the audience that once the vocabulary — particularly standardization of terms — was established, there’s usually a pretty good uptake from the business community since they really like language that can help them to define their business more precisely and unambiguously.

There was another comment from the audience that what he is calling a requirement is actually a specification, which is an argument that I’ve had about a zillion times in my years of software development: I completely agree with the comment, as did Choteborsky, but he stated that this was the common terminology in use at Microsoft today and he wasn’t trying to fix everything at once. I have to see the pragmatism in that, although there should likely be some sort of migration of terminology to be more accurate.

He went into more detail on terms, facts and rules, including descriptions of each, and the use of graphical term models and fact models. He also made a distinction between a rule and a policy: a rule can produce an action or decision, whereas a policy is more general but might sound rule-like. He stepped through the before and after of a fact model, where he went through and marked each object and relationship in the model as correct, sort of incorrect, or outright wrong, then found new relationship pathways and defined new terms in the model to make it a better reflection of the actual facts and provide a more logical structure for developing rules. He’s just using Visio for creating the fact models, although I’m sure that some more comprehensive modeling tools could make this process a bit easier. They’re starting to use RuleXpress (the RuleArts product) for terms, facts and rules, although the rules themselves are actually encoded within applications: rules management without a rule engine. As he pointed out, although some business rules may end up in a business rules engine, some end up directly in the code of an application, and some are never codified but become part of an operational manual. We see exactly the same thing in BPM, where a process model may include steps that are transferred to a BPMS, but also ones that are completely manual and never represented within a BPMS. Having a modelling tool separate from the execution environment provides greater flexibility in what can be modelled, but I suspect that the same issues of synchronization and round-tripping occur in rules modelling environments as exist in process modelling.

Choteborsky was a great speaker: knowledgeable, able to explain some fairly complex concepts, and funny (when one slide came up, he said “I don’t know why PowerPoint made the font on this slide bold and ugly, but I’ve learned that I don’t need to win every battle”). The great thing is that he presented a methodology for developing business specifications that everyone in the room involved in software development could take away and start examining for their own use.

2007 10 24 Sandy Kemsley BRM Comments (1)

Column 2