Nice overview article of Complex Event Processing (CEP) and SOA by David Cameron on TMC. Just one snag - he thinks that Business Rules are "... best suited to problems where the process steps are linear and predictable and don’t require contextual information about timing and sequence of event patterns". Now I agree with him that event processing does require some additional specialized technology but at the end of the day you have to make a business decision what to do. The justification for using business rules to manage this decision and automate it is the same as taking control of decisions in repeatable processes - business owners can control the response, the response can be changed more quickly and consistency of response across situations can be better enforced (precision, consistency, agility). I am looking forward to the next article but meanwhile check out the section on Event Processing on my other blog.

UPDATED: It was pointed out to me that David wrote an article on ebizQ as well "Using CEP to Address the Five Challenges of SOA". In thishe says

"Ultimately services make decisions by applying the logic programmed into them to the data they are given. But what if that logic changes frequently so that it becomes difficult to maintain inside the service? "

Indeed, what if? Well then you should be using business rules to develop these services so that the logic in them can be changed by business users in a controlled manageable way. Check out this post or this one for more on rules and how they can deliver agility.

Posted by jtaylor in Business Activity Monitoring • Business Agility • Business Rules • Decision Technologies • Event Processing • SOA | Permalink | Comments (1) | TrackBacks (0)

I saw this article on CIOInsight last week - Technology: Predictive Analytics Lets Companies See into the Future. This was one of the better articles on the use of predictive analytics. The marketing example is a classic use of predictive analytics in an operational setting - segmenting customers and then treating them differently in very high volume. Another of the examples talks about the need to apply rules on top of the analytics. There is also some good discussion on how it can be hard to collect the data and hard to analyze. I think the article missed one point- none of this is any good it you cannot apply it to your actual systems. Indeed it wrapped up by talking about the "outcomes of strategic maneuvers". But these outcomes will be changes in operational behavior for the most part and this requires a slightly different focus than the analysis/reporting/visualization typical of many predictive analytic solutions. Indeed the last question asked is in many ways the key one:

How can we integrate predictive analytics more tightly into our business processes?

Well you need to do a couple of things:

• Separate out the decisions you want to improve
• Make sure those decisions are automated using an appropriate technology like business rules
• Make sure you are generating predictive insight in a way that can be consumed by these decisions

I went through one process for succeeding at this hereand I wrote about how to use business rules to bring analytics into processes here.

Posted by jtaylor in Business Intelligence • Decision Technologies • Predictive Analytics | Permalink | Comments (0) | TrackBacks (0)

Interesting new online magazine on SOA launched today in conjunction with Prentice Hall - SOA Magazine. I have talked with Thomas Erl, the site editor before, and I think this will be a good resource for SOA materials and a nice adjunct to the book series. I think there is a lot of synergy between decision technologies and SOA and you can find more on this subject in the SOA Section of this blog or the SOA Section of my other one.

Posted by jtaylor in SOA | Permalink | Comments (0) | TrackBacks (0)

This interesting little article on risk banding in UK banks came my way today. This reminds me of the early days of the FICO score where it would simply be displayed on the customer service screen as a "grovel index". While this is interesting it seems to me it is not very useful. It would be much more effective if all the systems the call center representatives used incorporated it into their decision-making so that, for instance, different offers or cross-sells were suggested for different risk bands. Perhaps these banks are using decision technologies to do this but, if they are not, they are missing a trick.

Posted by jtaylor in Decision Technologies • Predictive Analytics | Permalink | Comments (0) | TrackBacks (0)

I was reading Phil's article The Difference Between IT and Business Enablement and it made me think about how to deliver business enablement whether or not you are using BPM software and whether or not you are building systems on top of an SOA. Business enablement to me means putting the business users, those who understand the business and how it needs to change, in a position to make the changes they want and need without IT being a roadblock. This may (or may not) mean they can change the production system without a release cycle but it certainly means that the business does not have to explain their requirements to IT but can, for those requirements relating to the business, define how they want the business to respond themselves. Phil calls this "driving requirements down into the SOA layer". I think that rules are somewhat different from other kinds of requirements (see this section of my other blog for more) and so business enablement is not so much about managing requirements differently so much as identifying that requirements are not the same as process definitions or the same as business rule definitions. Business users don't need to manage requirements like "have 99.9% reliability" themselves to be "enabled" but they do need to be able to add a branch to a process to handle a new customer type and to add the new rules to define when someone is in this segment. In fact business enablement requires the ability to manage processes or rules or both to deliver real agility (see this post on the different kinds of agility). Phil also points out there must be "no confusion caused by transforming a high level picture to a low level executable". This is an area where business rules management systems excel. For instance, see what Bruce Silver had to say about what BPMS can learn from BRMS particularly in terms of empowering business users to really own business rules not just see them. Bear in mind the dirty little secret of business user rule maintenance though!

So, if you want a way to empower your business users, consider using business rules to build services or to renovate pieces of legacy systems. Business rules management systems will let you give some (or a lot of) power to your business users and enable them to control how existing systems, and new processes, behave. In many ways this is the only way to use an SOA to add real agility as I noted here before.

There are some more links about business rules and SOA and about how business rules can add agility to business processes on my blog and lots of interesting BPM stuff on Bruce's, Tom's and Sandy's.

Posted by jtaylor in Business Agility • Business Process Management • Business Rules • Legacy Modernization • SOA | Permalink | Comments (0) | TrackBacks (0)

One of the common questions I get from people once they understand the potential value of attacking decisioning problems is "how do I get started". Here's a quick summary of the approach I take that seems to work well:

1. Remove decision process from production applications and processes
   If you let the decision stay embedded in the system or the process then you will never manage to improve it. This does not mean disconnecting it from where it is used or ignoring how it is used by systems or processes, it just means identifying the decisions as unique aspects of a system, decision services if you will, and focusing on them as something that can be managed and improved separately.
2. Analyze decisions' potential for improvement
   Not all decisions are equally ready to be automated.By and large there needs to be some upside to doing it better or some downside to doing it worse - a risk or reward. In general these decisions will have:
   - Lots of rules
   - Rules that change often
   - Rules that are complex or interact in complex ways
   - Rules that require domain expertise to understand and manipulate effectively
3. Automate the high-volume decisions
   There is not much value in automating low volume decisions. Focus on applying automating and decisioning technology on those "blue-collar" decisions that are part of your day to day business and so come in relatively high volume. These are well suited because small improvements in the decision can have a big impact as you make so many of them.
4. Give business users control of how the decision is made but keep the user interface simple
   Business users don't want to maintain rules any more than they want to write code. If you want them to take control of these decisions, and you do, then you will need to keep the interface simple (to them - it can be full of jargon and abbreviations for example as long as they are your business users' jargon and abbreviations). Indeed as the complexity of the science used in making the decision goes up (see below), you will need to focus more and more on keeping the interface simple for those that control the business decision.
5. Apply predictive analytics to improve the decision
   Using the data you have or that you start to capture once you have automated the decision to create predictive analytics can make a huge difference to the effectiveness of the decision. You might be able to develop analytically-derived rules or add predictions that allow for completely new kinds of rules (treat people likely to churn differently for example). This is the real "operational BI" you are looking for.
6. Design for production
   Once you automate these transactions they will need to meet your operational/transactional standards. This is not offline reporting but front-line transactional stuff. Design it that way.
7. Provide change management and evolutionary guidance
   Automating the decision helps but getting good at evolving and improving it is what really delivers benefits. Don't think you are done when you first get the automation in, that's just the beginning. Make sure your plan includes how you will assess performance, how you will make changes and how you will create a constant improvement cycle.

This works. Really.

Posted by jtaylor in Business Agility • Business Rules • Decision Technologies • Predictive Analytics | Permalink | Comments (0) | TrackBacks (0)

I was reading a nice white paper the other day on Customer Experience Management - RightNow is making it available here and it is based on a survey of folks on the RightNow website. The paper defined customer experience as "The customer’s perception of interactions with a brand". It notes that perception is critical, that an interaction can be almost anything and that brand is "a promise to be fulfilled". The survey identified some key things companies could do to improve the customer experience and it seemed to me that the judicious use of decision technologies could help with a number of these:

• Personal attention, reward for loyalty
  Part of the promise of decision technologies is the use of business rules and analytics to deliver more personalized interactions. Taking all that information you have gathered about a customer and using it to change how their call is routed or handled, what offer or price they get and so on. Combine thiswith the power of business rules to manage loyalty programs (which tend to be very dynamic and so hard to code in something that does not support change well) and you can see how decision automation can deliver on this.
• Friendly and caring employees
  Now I have to confess that there is not much I can do here! That said, if you remove the need for your staff to constantly refer things for approval by empowering them to take decisions (using decision technology) then they will seem more caring. As one respondent said, it does not really matter how nice someone is if they can't actually do what needs doing. Automation of analysis of data can also help by allowing customer-facing staff to focus on the interaction with a customer not on wading through reports on their screen to try and figure out what a customer might need.
• High-quality goods or services
  Unless you have information based goods or services there's no help here. If you do then rules can make it easier to manage the dynamic nature of information-based products.
• Excellent customer service
  This might mean making it possible for customers to self-serve or it might mean empowering your call center to make potentially complex decisions involving risk by automating key decisions but either way you can and should use decision technologies to improve customer service.
• Well-trained and helpful employees
  As far as the well-trained bit goes you are on your own. Decision technologies can make them more helpful though, by ensuring that anyone who interacts with a customer can make key business decisions correctly, appropriately and quickly

So there you have it. Automate decisions, improve customer experience. There's more in the marketing and CRM sections of my other blog.

Posted by jtaylor in Business Rules • Decision Technologies • Predictive Analytics | Permalink | Comments (0) | TrackBacks (0)

Two interesting articles on the synergies between Business Process Management Systems (BPMS) and Business Rules Management Systems (BRMS) in the BPM Institute newsletter today:

• SOA Adoption Should Stimulate Demand for BPM, BAM and BRM By Tom Dwyer of Yankee Group
• Business Process, Business Rules and the Agile Enterpriseby Tom Debevoise

Tom Dwyer's piece does a nice job showing why the use of BPM, BAM and BRM make sense in an SOA environment while Tom Debevoise's outlines the kind of internal process and portfolio management approaches you need to take advantage of BPM and BRM in delivering agility. The power of these technologies to deliver real business agility, especially in a well thought out SOA, is huge.

Posted by jtaylor in Business Activity Monitoring • Business Agility • Business Process Management • Business Rules • SOA | Permalink | Comments (0) | TrackBacks (0)

Keith used a similar title in a different post last week - Complying with rules is not the same as working to rule- and it made me think about the phrase "working to rule". Now "work to rule" is defined in the American Heritage Dictionary thus:

"A job action in which employees do no more than the minimum required by the rules of a workplace in order to cause a slowdown."

Clearly this is not a good thing - by following all the rules all the time workers expect to make things go slower rather than better. If "working to rule" is bad then why is it good to build a system that works the rules, enforces them and generally makes sure they are followed? Well at a basic level the automation of rules, so that they can be enforced all the time instead of selectively, is key. A work to rule slows things down because we are in fact intolerant of the time it takes to enforce all the rules. Sometimes this is because the rules are unnecessarily onerous butsometimes it is because we do not like the rules or because we prefer to rely on our own judgment (see "Blink" for more on this topic). So how does enforcing all the rules all the time help? Well it will depend on your situation but examples include:

• The rules will check all data that might be relevant to a decision in a systematic way, even data that does not seem important. If the data could make a difference it will be evaluated. Skipping these rules might speed things up but will contribute to people's tendency to consider too narrow a range of factors.
• One of the ways to "work to rule" identified in Labor Notes is "Never go by memory, check your reference material" and another is "Never use your own judgment—ask!". These are examples where automation of the rules can really help as no-one has to go by their memory (the reference material is checked by the rules) and no-one needs to trust their own judgment too much - see this refund story for an example. After all the people on the front line cannot be expected to have the whole picture nor can they be expected to go through checking everything while a customer waits. Automating the rules can make it easier all round, in contrast to having your staff work to rule.
• Sometimes the rules are designed to ensure a lack of bias - for instance in lending - and you really want to make sure those rules are enforced all the time.

In many ways the fact that "working to rule" means slowing things down explains why you should automate business rules not write them in policy manuals.

Posted by jtaylor in Business Rules • Compliance | Permalink | Comments (2) | TrackBacks (0)

This article Event-Based Analytics: Getting it Right came by my desk today. The key example used is for credit card fraud detection. Now Fraud detection is something I blog about fairly often (see here for example), and is something of a specialty of my employer (Fair Isaac) and much of the article resonated with me. All of Ajay's examples, however, are about event-based decisioning that uses both analytics and rules. The analytics may do the heavy lifting in the scenarios he outlines, but the application of the conclusion of the analytic must be executed by business rules suitable to the situation. For instance, each credit card issuer will have different rules about how to apply the result of the (neural network) analytic model that predicts the likelihood of fraud for a given transaction. A marketer might use rules about the context to decide how to use an analytic that predicts risk of churn and so on. Rules and analytics make for effective decisioning and event-based decisioning is on the rise. It's just not only about analytics.

Posted by jtaylor in Business Rules • Decision Technologies • Predictive Analytics | Permalink | Comments (0) | TrackBacks (0)

I was recently reading "The Joy of SOX" (reviewed here) and it lead me to read up some on COBIT (Control Objectives for Information and related Technology - produced by the Information Systems Audit and Control Associationor ISACA). COBIT is "a generally applicable and accepted framework for good IT governance and control practices". As I was flicking through this I cam across one particular section. Under "Acquire and Implement" there is a "Manage changes" objective (for those of you following along in the spec this is AI6). This control objective talks about "the business requirement for IT of responding to business requirements in alignment with the business strategy, whilst reducing solution and service delivery defects and rework".

The section goes on to talk about how this means having change procedures, actually following them and measuring things like disruptions and emergency fixes. This is all well and good but it struck me that the details were predicated on all changes requiring IT to write code. Regular readers (Sandy and the other one) will know I don't buy this and that I work with customers who want to go further towards getting business users able to make changes for themselves (like egg for instance). This is not to say that I think you don't need good change control and release/version management when business users are making the change - you do - but that assuming that improving the process by which IT makes changes is only one way to increase agility while retaining control. If you take the approach, as COBIT does, that IT must make all changes to the system then the best you can do is that this process is managed, measured and constantly changed to reflect changing business realities. For me a REALLY mature organization would manage change but putting the people who understand and can best assess the impact of a given change in charge of making it. This means IT making IT changes and the business making business changes.

Don't aim too low.

Posted by jtaylor in Business Agility • Business Rules • Compliance | Permalink | Comments (2) | TrackBacks (0)

I was talking with an analyst about possible uses of business rules and other decisioning technology and an example came up where a customer was using ETL (Extract Transform Load) technology and business rules. The particular customer is using an ETL product to data cleanse all incoming transactions from over 50 supplying systems and is then applying a business rules engine as a ‘routing engine’ for transactions. The complexity of the business rules goes way beyond what the ETL tool could offer on data transformation, hence the mixed ETL-BRE implementation. A particularly important aspect was the manageability of the rules as they expect to implement up to 150,000 accounting rules! The ETL handles the standardization of the data and the mapping into a Generic Object to which the rules are applied. The resulting object(s) are then picked up by the ETL tool and loaded in the General Ledger and data warehouse.

So when might you want to combine ETL technology with decisioning technology:

• When you have a very large number of transformation rules such that rule management, not transformation, is the biggest issue
• When you want to have the same rules run in transformation processes and other business processes
• When you want to have business experts not technical ones maintain some of the rules
• When you want to use analytics, especially predictive analytics, as part of your transformation process

ETL tools do a great job of transformation most of the time. When they run out of steam, think about business rules.

Sorry for the low rate of posting - been a quiet week in terms of things to blog about.

Posted by jtaylor in Business Rules • Decision Technologies | Permalink | Comments (0) | TrackBacks (0)