6. My new operational system will do that

One of the “hardy perennials” when it comes to technology is that some new system already in the works will address the problem. In the case of decision automation this can take the form of “my new package includes that process/decision” or “my new package already has analytics in it for decision-making”. So why is this not a valid excuse?

Well firstly most packages do not, in fact, automate decisions - they automate processes and largely assume manual decision-making. Now why would you want to establish processes using the new system that involve time-consuming, costly, imprecise manual decisions? Why implement a brain-dead process? You should plan to inject decision automation now to streamline your processes, make the most of the data you have and reduce future data quality and completeness problems. Some package vendors claim to let you automate decisions but often this involves using scripting or coding and so fails the basic test of maintainability and agility that a business rules management system would pass with flying colors.

As for analytics, the problem here is one of definitions. Yes most packages will have some analytics but most of these will be reporting or descriptive. Few will be predictive and fewer still will allow you to really use these analytics effectively (by exposing them to business rules). As a result they will, at best, allow users of the system to get useful analytic information. It’s not that this is a bad thing, it’s just not decision automation. Business rules and other decision automation technologies will not let you manage your data, automate your processes or do the things your package will. Equally your package won’t let you automate decisions with precision (by embedding predictive analytics), consistency (across this package and all your other touchpoints) or agility (by making it easy to change the rules independently).

If you have a new operational system going in, now is a great time to adopt business rules and decision automation. It will mean the system is more efficient, easier to customize and more effective right from the get-go.

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

7. Why do I need more technology to handle business logic?

This excuse comes up both in forward-looking companies that have made an effort to standardize on a set of technology and on technology-resistors who like to stick only with technology they have been using for years. Let's drill into some of the specific excuses that fall in this broad category.

• I can do "decision automation" already.
  Well yes. In code (that the business can't read), script (that IT cannot manage) or what, exactly? Is the logic that makes decisions externalized and managed? Can you find it and reuse it? Managing business rules in code is a little like managing data in programs (rather than databases) - just because you can does not mean you should.
• I can get all the agility I need from SOA
  With the rise of SOA this is a common one. Clearly you get an order of agility from SOA. It allows you to more rapidly assemble composite applications and it allows you to change the implementation of a service independent from those services/processes/applications that use it. What SOA alone will not do is make it easy to change the way a service behaves. For this you need a technology like business rules.
• I can do all this "rule maintenance" with parameters
  Some IT groups feel they can get all the agility they need from parameterized code or database-driven design or sometimes from stored procedures. They think that coding in Java and using parameters will be faster and easier. It might, if your problem is really straightforward or your rules don't change very often. Most users of business rules management systems also have some rules that seemed too straight forward to put in the rules system. Typically they look back on this and say "I wish I hadn't done that". For all but the most trivial situations business rules are going to be easy to manage, easier to change, easier to share with the business and easier to deploy into production.
• I already have a standard technology stack
  Sometimes known as the "that's just not how we do it" syndrome. This comes down to a simple decision - are you really never going to add another technology to your stack? You really think that your current stack is going to be the best way to build systems forever? Of course not. Anyway, it's not as though business rules are "bleeding edge". Every major analyst firm considers them a class of tool, they are on the plateau of productivity in Gartner's Hype Cycle and thousands of companies, many of them brand-names and/or huge companies, are already using business rules. Get over it, sometimes you just need to accept that a new technology has made its case and should be in your stack.
• I can't use something without best of breed features in <some area>.
  Sometimes people forget that business rules management system vendors are in the business of making it easy to write, manage and deploy business rules. They are not in the business of being the "Best of Breed" IDE, Version Management System, Requirements Management System, Application Container or whatever. Most business rules management systems don't feed the cat or take out the garbage either but they still have a great ROI.
• If I was meant to use business rules, my platform vendor would provide them.
  A variation on the "my stack is complete" argument, this excuse gets used by IT departments devoted to a particular development stack. Essentially they argue that if business rules were really useful, their platform vendor would provide them. Well I have news for you - most if not all of the platform vendors partner with rules vendors, embed at least a lightweight rules engine and have acknowledged that business rules have a role to play in modern systems development.

There are more, of course, but they all come down to the basic value proposition issue. There is a return on investment that is demonstrable for business rules. There are problems for which business rules represent the best solution. It does not matter how attached you are to your current approach or tools, they can always be improved and including a business rules management system might well be one of the ways they can be.

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

8. We're doing fine as we are; why fix what isn't broken?

What this normally means is that there are no obvious decision-centric problems in the current IT portfolio. I am reminded of a story I heard a long time ago. An IT leader was called in and asked to give a report on the status of development. He proudly pointed out that the vast majority of systems were on time, on budget and to specification. To this the CEO said "I know and if things don't improve I am going to outsource the whole department".

Why did he say this? Well, the problem was that by the time the systems were done, even though they were on time, they no longer did what the business needed. Sure, they did what the business needed when the spec was written but times change. The IT folks thought they were "doing fine", the business did not.

Let's assume though that this is not your problem - that you really don't have a huge backlog and that users aren't working around systems that don't quite work the way they need to any more. Well then the core decision automation benefit that is being overlooked is agility. Even if everything is going fine, how quickly and cost-effectively could you respond to a competitive issue, new regulations, a new channel, or some other major change? Decision automation technology like business rules helps reduce the odds that a change will derail you.

One last thing. Sometimes it seems "too hard" to rip the rules out of the 14 legacy applications that currently have them hard-coded (in theory all identical implementations of the rules). This concern that it will be hard to automate a decision where the logic is too deeply embedded in code no one understands, or in the brains of people that are too core to the business to take them away from what they are doing, is real. However the alternative is to cross your fingers and hope the system holds together. Not, perhaps, the world's greatest risk management strategy. Take it incrementally, don't bite it all off at once but do start now while you still don't need to. Once you need to, it may be too late.

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

9. I would like to invest in business rules and decision management but my manager just doesn't get it

This excuse typically arises because "decisions" are too generic to get management attention. Instead, focus on how automating decisions can help with more precise pricing, customer retention or cross-sell offers, better consistency when coping with staff turnover or multiple channels, better agility when trying to change to respond to competitors or new marketing campaigns. Think about the problem you believe business rules and/or predictive analytics can solve. Technology never sells itself, you need to sell the benefits of using the technology.

The best way to do this is to tie the automation of decisions to some business process and to specific business decisions within the process. Then you can show how automating those decisions could improve the precision, consistency or agility of the process and why that matters to the business.

What about technical management? You can also try a more technical sell around agility as well as leveraging other investments. Why would you want to go on creating a new generation of legacy systems? Does anyone enjoy spending a huge percentage of the IT budget on maintenance work? How much fun is it to know it is going to take so long to make that next change to the system that it won’t go live until another change request is queued up? This kind of technical agility can be delivered by business rules.

As for leveraging investments, think about the data warehouse(s) and operational systems you have. Would automating a decision let you turn that business intelligence into something actionable? If you could automate and improve a decision like cross-sell or next best offer in your call center, would that enhance the value of your CRM system? If you have built a 360 degree view of your customer, or even a 270 degree view, are there decisions that could, if automated, leverage this data effectively? Showing how a decision management approach can both solve a need and leverage other investments can be particularly effective with management.

There are lots of way to "sell up" but the key to acceptance is the ability to explain the benefits of business rules to non-technical folks. Business managers would probably enjoy applying business rules to various problems, if they fully understood the benefits without hearing techno-speak. Try and visualize the kind of process you could have if only you automated some of these decisions.

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

Over the next two weeks I am going to expand on my revised list of top 10 reasons for not automating decisions. In best TV style these are in reverse order.

10. We tried before and never got any results

There are two root causes for this excuse - over-hyping and previous failures, especially of expert systems, and the misuse of the technology in pilots. Over-hyping of decision automation was rampant in the time of expert systems. There were many expert-system fiascoes but although business rules definitely evolved out of the whole expert systems world, business rules management systems are not expert systems.

• Expert systems were attempts to lay out not just a way to approach control of decisions and actions (which is basically what business rules do), they also imposed entire ways of solving a business function. So you would buy a vendor's offering that said something like "This software decides whether to approve or decline a loan. You can tweak it and tune weights, but we've established the way you will do business." Many companies chafed at that kind of restriction.
• Expert systems also used specialized software and dedicated (expensive) hardware that didn't fit in with companies' systems. Nowadays business rules software has become much better about using standards to fit in with existing hardware, software, and data instead of requiring specialized proprietary components.
• Expert systems were often extremely difficult to work with, especially for the "experts" whose knowledge was being embedded while a BRMS allows "power" users to easily change rules through decision tables or point and click templates.
• Expert systems typically suffered from performance and integration problems where today's BRMS offerings are fast and easy to integrate.

Expert systems are not business rules management systems. Don't let a bad experience with the one blind you to the value of the other. More problematic is misuse of the technology, typically in a pilot or first project. So what can cause pilots to go wrong when trying business rules technology?

• Many pilot projects over constrain the technology, forcing a procedural design on to a declarative approach.
  They try and use Use Cases and other design approaches without thinking about how to separate out and manage business rules as first class objects. Treating business rules as just another programming language might work but probably won't - it requires a shift in thinking.
• Some fail because they are trying to solve too much of a problem.
  Don't try and solve the whole problem, try and prove the technology works for a reasonable component. Also, be mindful of what is and is not the decisioning component of the problem. Don't try and use the rules engine for the wrong parts of the problem.
• Don't wait until the pilot has started to get the appropriate resources scheduled and trained and don't do it without expert resources to help the process stay on track, in scope, and done following best practices.
  Business rules can be very straightforward to use but they are not the same as approaches you may have taken in the past. Get the right training and help.
• Don't start until you have determined the specific problem you are trying to solve.
  You should have justified why that is the best project to start with (such as being the best for rules technologies, being reproducible, having corporate visibility), and checked the scope.

Don't let an expert system failure in your past, or a misjudged pilot, blind you to the value of business rules. Lots of companies are getting great results from business rules and you can too. You can get the business and IT to collaborate on managing the decision logic and you can inject the results of analytics into decisions to improve them and you can manage decisions as corporate assets. You can prove that this will work with a pilot. You can also mess it up. Don't.

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

A couple of days ago Oracle made an announcement about an Event Driven Architecture. This architecture clearly includes business rules as part of how you process events and shows how event processing and business activity monitoring go together. What struck me as interesting, though, was the absence of a discussion in the announcement of analytics. Why, given Oracle's deep data and data mining technology stack, was this not part of the solution for event processing?

In an event-processing scenario, business rules are clearly key. They allow you to define how to respond to events, to manage large numbers of potential responses for potential events and to expose this logic to business users. All nice features for event processing. Analytics, especially predictive analytics, are also valuable. How can I use analytics in an event-processing scenario?

• I can process a stream of events as input data to a predictive model to see if the event data predicts a potential failure or problem or opportunity.
  In this example the data for the model is built up by a sequence of events. The prediction can then be used by rules that process the event. Thus event 100 might provide enough data to make a prediction (say that a particular piece of equipment is going to fail) and a rule might use that to process the event differently (scheduling a preventative maintenance call for instance).
• I can treat an event differently based on predictions I have about the future behavior of the source of the event.
  Other data I have, about a customer say, may enable me to predict their likely behavior. Perhaps I can predict their retention risk. Based on that prediction I might treat the event differently, scheduling a proactive call to profitable customers who show at high risk of churn when a specific event happens while simply noting the event for those at low risk of churn.
• I might use a regularly scheduled update to a predictive model to trigger an event
  Every time I update a model, say of customer risk, I might check to see if I have moved from one risk segment to another and, if I have, I might push an event on the the event bus. This might then be combined with other events to change downstream behavior.

Analytics can really enhance event processing, especially in conjunction with business rules. Don't miss the opportunity. I wrote about this on my other blog here. 

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

Corporate Performance Management is a term created by Gartner back in 2001 meaning "all of the processes, methodologies, metrics and systems needed to measure and manage the performance of an organization". Yet when I read about corporate performance management I mostly read about dashboards, reports, KPIs and so on. This to me is all about performance monitoring.Where's the management in all that? Well in the people I suppose - they can behave differently, manage their environment differently, based on the monitored performance.

• I cannot help but feel this is missing an opportunity. What if the systems being so carefully instrumented to provide these great reports and dashboards, were also easy to change?
• What if the people who see the dashboard and understand the importance of the KPIs could respond to them by logging on to a system and changing the way the systems, and thus the company, behave?
• What if the reports that predict forthcoming problems had matching algorithms running automatically to drive change in systems?
• What if your alerts were to tell you how your systems had responded not to ask you to respond?

All this is doable, you just need to think about how to use decision technologies to manage decisions in parallel with thinking about the technologies that let you monitor it. I wrote an article on this topic - Shifting Your CPM Into Action - enjoy.

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

I saw this article in Computerworld on ROI Key to Melding BI, Business Processes in which the IDC event on Business Intelligence and Business Process was discussed, along with some companies who presented. This drive to bring BI, especially "Operational BI" to bear on business processes, especially those automated with BPMS, is getting a fair amount of traction recently.

If you want to bring BI to bear on business processes, especially those you are automating, you need to be clear what it is you want to do. Now presumably you want to improve the process - let's take that as a given, Do you want to use analysis of how you execute the process to improve the process or do you want to use your store of information about products, customers, suppliers etc to improve it? The first of these is what most BPMS vendors will do for you - they will help you see how you execute the process, what trends might be identified and help you use that information to improve the ongoing execution of the process. A nice feedback loop. But what if you want to use the data you have in your corporate data infrastructure?

Essentially you have two choices at this point - one suitable for manual processes  (or at least manual steps within a process) and one for automated steps. If you are thinking about manual steps then you can use traditional BI delivery vehicles. Thus when someone gets a work item on their work list you can make it easy for them to view and analyze the data that might help them make a good decision or take the right actions. But what if you have automated steps? What if you want to inform an automated step within your business process with analysis of your information? Clearly your software is not going to "look" at a report or "use" Excel. It needs some other way to get insight. This is where executable predictive analytics come in. Predictive analytic models are executable pieces of code or rules that take data in (customer payment history, location data, product pricing history or whatever) and put insight out (which product is most likely to appeal to this customer, how risky is this supplier etc). These models are built with the same kind of algorithms you here about in data mining and sophisticated BI but they are focused on delivering something that can be executed not something that can be viewed.

Now you can just go ahead and embed these kinds of analytics in a BPMS using SOA or some other way to bring pieces of code into the process. However, experience with using these kinds of analytics is that they are almost always combined with rules - rules about how to use the new prediction or when to take note of it and when not to. Rules for instance about not making cross-sell offers during complaints or about when to prioritize an apparently risky supplier because of its speedier turnaround. Because of this the most effective way to bring these kinds of analytics to bear on a business process is to develop a decisioning infrastructure, based on a business rules management approach, use this to build decisioning services that can be embedded in your business processes, and then enhance these decisioning services with the embedded predictive analytics. Not only does this allow you to mix analytics and rules effectively, it also allows you to constantly enhance your decision-making without having to change the business process (something I wrote about here).

I posted on this here and about it here on my other blog and discussed how this approach might deliver on key BI issues here. In addition I wrote some about the differences between BI and EDM (EDM or Enterprise Decision Management being the phrase used to describe rules and analytics together) and on why simply giving more people access to BI does not cut it. 

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

This article by Leslie Ament in DM Review caught my eye today - Success Strategies in Leveraging Customer Intelligence. I got hold of the report (you can buy it from Aberdeen here) and there is a lot of good stuff but one thing in particular struck me.

Automate decisions with rules-based interactions. In contrast to average performers, leaders have developed decision-tree workflows and/or rules-based “best-fit” selections for interacting with customers in real-time across multiple channels. Use of predictive analytics and customer behavior modeling have enabled organizations to build matrixes of most probable outcomes (churn risk, propensity to buy, best offer) based upon unique sets of customer behaviors and prior transactions. As a result of these consistencies, companies can recommend the best possible, customer-centric action to take in each interaction – including cross-selling, special offers, or service initiatives.

This is a great justification for taking an EDM approach to customer interaction management. By automating interactions using business rules you can deliver consistent and agile treatment across multiple channels. By using analytics to refine those rules and allow for new ones (by adding predictions that can be used to better tailor interactions) you can improve the precision of this treatment. For instance:

1. Define rules for the various cross-sell offers you have and what the minimum criteria are for offering them
2. Define rules for when to make cross-sell offers e.g. not during complaints
3. Use analytics to mine your data on past behavior to develop a customer segmentation that divides up your customers based on fact not belief
4. Turn this segmentation into rules - a decision tree is often perfect
5. Define rules for pricing, perhaps using a decision table to look up pricing based on segment, product and other risk or benefit factors
6. Think about predictions you could make - can you predict risk of churn or likelihood to make future orders? If you could predict these things, would you change or add to your rules?
7. If they would make a difference, go back to your data and do more analysis to see how you can build models to predict these things
8. Add those models into the decision logic and add or change the rules that use them - perhaps drop the price for those at risk of churn or offer a different cross-sell for someone likely to make a subsequent purchase
9. and so on...

Now if you are doing all of this in a business rules management system then you can get immediate results by deploying the rule service as soon as you have any rules. This will help call center staff (by making more targeted offers) as well as automated systems (by giving them some way to target offers instead of just offering a standard one). As you enhance the rules a good business rules management system will let you re-deploy the rules without having to re-compile or re-start the systems. It will also let you update the offer logic without changing the processes that have "make cross-sell" as an activity within them. If the business rules management system makes it easy to add analytic models then you can cut the time from data to improvement in decisioning too for best results. All this is particularly key for those of you in e-commerce and for those whose strategy calls for real personalization especially when you have many many customers.

For those of you into this kind of Precision Marketing, I would recommend my colleague Jeff Zabin's blog Pareto Rules

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

An interesting article on ebizQ today by Tae W. Oh - The Missing Link in SOA. A couple of quotes in particular struck me

"ever changing technology, customer demands, policies and governance, mergers and acquisitions, and economic pressures, business survivability requires an enterprise that is flexible, responsive, and above all, adaptive" (my emphasis)

Now the point of the article is to identify integration, especially integration and re-use without custom coding, as a "missing link" for successful SOA. And so it is. But the challenge of changing customer demands, policies and governance (regulation) involve not just integrating and assembling services but also changing their behavior. Thus if I have a service that uses my underwriting policies to return decision about pricing of a new policy for use in various processes I want to be sure that I can re-use it in new processes but also that I can rapidly change the logic used in the service when my policies change. I need to be able to take the business rules within a service and make them as easy to change and re-deploy as possible. An SOA approach makes this possible by encapsulating the logic into a service and by ensuring it has a well defined interface. These are necessary. They are not, however, sufficient. I must also have a way to manage the business rules implemented by the service.

Decision Services, such as the example above, are often ones for which integration and re-use are key issues. They are also ones that tend to have large number of business rules to apply, rules that change often, complex rules or rules that should be maintained by someone who understands the business. Unless the technology used to build these services allows for effective collaboration around business rules, the services will not be sufficiently agile.

The article goes on to say:

Enhancing Business Agility: consistently changing demands and business strategy require business agility or you risk being taken over by your competition. The need for business agility is no new paradigm, but with the acceleration of technology and business cycles, along with the expectation of IT to accommodate this faster pace, agility is becoming extremely important for businesses to remain viable

And with this I could not agree more. You may need SOA and BPM to deliver agility, you need integration to be easy and automatic to handle any kind of complexity, but you need business rules if you are really going to deliver business agility in terms of changing the way your company responds and makes critical decisions.

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

Interesting article in Optimize the other day by Betsy Burton and Mark McDonald of Gartner on Smarter Use of Business Intelligence. This article had some nice charts of CIO priorities for 2006. The top 10 business priorities are shown below.

I found this list particularly interesting as the top 6, as well as 8 through 10, are all key benefits of an Enterprise Decision Management (EDM) approach for those companies with large numbers of customers and relatively complex interactions with them.

1. Consider that decision automation in an EDM approach is focused on improving the business processes that consume the decisions as well as reducing the cost of executing the decision - that's the first 2.
2. Most decisions automated are about customer interactions and are designed to bring precision and consistency to the decisions taken about those interactions, something key to 3.
3. The agility focus of EDM is one way companies can be more competitive (responding faster than their competitors) and this addresses 4, 5, 9 and 10.
4. The use of a business rules management system to act as a decisioning platform so that intelligence (in the form of predictive analytics) can be embedded into every decision is surely a good basis for 6.
5. Last, but not least, EDM's focus on precision (better offers, more precise targeting etc) typically leads to revenue growth.

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

Much as I often agree with Ismael Ghalimi over at IT Redux, his recent post on Why a BPMS needs a Business Rules Engine has several points with which I disagree. There's an interesting comment thread now clarifying his position (and mine) but it made me think about agility and, in particular, a recent Gartner piece on Achieving Agility: The Agile Power of Business Rules. The key reason for not embedding business rules into a business process management system and for not always synchronizing the updates of rules and processes is to deliver on the agility promise.

The Gartner piece, by Jim Sinur and Dave McCoy, has lots of good recommendations but the key is that any time you hard-code business rules or try and use a business rules approach without automating the management of business rules, you will drive down your effective business agility. So what is Agility? Well Wikipedia defines Agility thus

“Agility in business, often defined as the ability of a firm to sense and respond to business opportunities in order to stay innovative and competitive in a turbulent and quickly changing business environment. An agile firm (one that demonstrates agility) has the capabilities and processes to respond to unexpected environmental changes.”

When we think about how a business might respond to changes we can define two kinds of response – changing a process or changing how a decision is made within a standard process. Let’s consider each of these in turn.

• Process Agility
  Some kinds of change require me to change a process in response. For instance, if a particular locality introduces regulations into a previously unregulated process I might have to add a compliance step. If I open a new call center to handle a particular class of customers (to compete with someone who does this perhaps) then I must add a new branch and new steps to the processes that handle customer interactions.
  When core processes, such as order to cash, are changed there is typically a significant impact on the organization as a whole. The changed process and the changed definitions in a BPMS are unlikely to be all there is to it. Organizational change, and perhaps new auditing, will likely be required. This kind of change then is hard to make really agile and will always be fairly time consuming.
  Processes around the “edge” of a company with lower volumes, less repeatability and more manual steps do need to be easy to change as they are likely to change often. How I handle calls from my very largest customers, for instance, might be entirely defined by a custom contract which requires a distinct process to be created for each such contract.
• Decision Agility
  Decision agility is required when change is required within a process that does not change the process itself. For instance, if I change the rules for determining price discount eligibility I will likely not change the process at all – at the same point in the process I will determine the discount, apply it and continue. Yet the decision as to what discount to offer will change. Being able to quickly change the decisions within a process, with or without a matching process change, is key to decision agility. This tends to matter most in core business processes which, while they are fairly stable in terms of steps and outcomes, can have significant variation in decision-making over time.
• Process and Decision Agility
  Both kinds are required and they are often used together. Clearly if I add a new sub-process to handle a new class of customers I will likely also change the decision logic for segmenting customers so as to put the right customers into this new sub-process. If I decide to change the way I handle risk management decisions I might create new needs for external verification or report, which will need their own processes and so on. Not all decision changes require process changes but it is pretty usual for all process changes to impact a decision – only fairly manual processes where everything is handled by people and worklists are likely to be an exception.

It is this need for a range of response options that means you cannot afford to make rule changes and process changes synchronized all the time.

Posted by jtaylor in Business Process Management • Business Rules | Permalink | Comments (1) | TrackBacks (2)

This article on robots caught my eye today - Robots Clean Floors—and Save Lives, Panel Says - and combined with my work with Tommy on the DARPA Grand Challenge (see my post about Tommy winning an award) it made me think about the need to make decisioning technology part of the next generation of robots. So why is this?

• Robots are increasingly being used where people are used today. This means taking human judgment and expertise and embedding it in a robot so that it can behave autonomously at least at some level. This is a great use of business rules and is being worked on already by folks like Paul Perrone of Perrone Robotics. These rules include
• Route planning
• Obstacle detection
• Obstacle avoidance
• Route re-planning
• Pattern recognition is a key issue for robots and predictive analytic models, especially things like Neural Nets, are great tools for turning incoming data from lots of sources into something that can be identified as a pattern and thus an object to be manipulated or avoided.
• Robots must make large numbers of decisions in real-time to be effective. This is what decisioning technologies have been developed to do, albeit in an information handling rather than a real-world handling context.

There's some great discussion of the challenges of building an autonomous robot, and some video of Tommy, on the Sun site in the JavaOne Keynote Video- Paul and Tommy are on around 41minutes in. Tommy and Paul are also the subject of a forthcoming documentary - details at Robot World Media - and there is a presentation on the integration of business rules into a robotics platform here - Download file

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

I was reading the end of Zygmunt Jackowski's article Bridging the IT-Business Gap With BPM and SOA (Part IV) and really liked the way he differentiated between Business Services and Component Services (and IT operations like CRUD methods etc). When I talk about how business rules, and other decisioning technologies can be applied, it is this top level of Business Services where the greatest value can be achieved. This is not to say that using business rules to code component services cannot be valuable - it can - but the real value of business rules comes in how it helps you develop business services.

 He uses the example of Processing Visas and it seems to me that with in this process there is a key decision-making business service - "Approve/Decline Visa". Indeed whenever I see a description of the kinds of activities or services that are being assembled into a composite application or process, there is at least one business service that can best be described as a "decision service". These kinds of services, that take critical business decisions within a process, are ideal for automation using business rules.

So how can you tell that a service is ideal for automation using business rules. Well there are perhaps four classic reasons:

• The service requires lots of "rules" to be considered for each decision.
  Managing large numbers of rules in code is typically very difficult but a business rules management system handles this much better.
• The service has very complex, inter-dependent rules.
  Inferencing business rules engine, those that can use an algorithm to establish which rules to evaluate and those that have powerful syntax constructs can really take the sting out of developing this kind of service.
• The service changes all the time.
  Constant maintenance of code to respond to changing promotions, regulations, competitors pricing etc is costly and time consuming. Using business rules to automate these kinds of services can dramatically decrease the cost of ownership for these services both by making it easier for non-technical folks to make controlled changes and by making it easier to change rules on the fly without destabilizing the service.
• The service has rules that require business expertise to understand.
  If the rules in a service are hard to understand without a strong background in the business context then it will be hard for programmers to code them correctly. Empowering the business experts to interact more directly the service by automating it in business rules can eliminate or at least dramatically reduce these issues.

Decision Services are easy to find in most processes and thinking of these business services this way will make it easier to develop and maintain them and much more possible to engage the business in their development.

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

The latest issue of Teradata Magazine came to me today. This had a special section on Active Enterprise Intelligence and had three interesting articles - The active advantage, The moment of truth and Active data warehousing: from nice to necessary.

The gist of these articles is that "active data warehousing brings sophisticated insights to day-to-day business decisions". I agree but I think there is a need to add a decisioning infrastructure, especially one based on business rules integrated with predictive analytics, to turn a typical enterprise data warehouse into an active one. Most data warehouse / BI projects are focused on delivering insight to people, typically off-line (albeit using increasingly up to the minute data). To bring the kind of insight people get from these projects to operational systems you need a couple of things:

• For sure you need a data management/data warehouse infrastructure that can support the kinds of users, mixed workload and volumes/response times involved. After all you are going to be driving a much higher volume of decisions once you apply this to operational decisions.
• You need a rules management infrastructure so that you can define what actions to take in response to events or requests and so that the folks who understand the business can be part of defining how to respond
• You need to be able to bring predictive or executable analytics to bear in these rules and processes so that the probable future predicted by the data you have to date can be allowed for
• You need to get the time from new data to new decision to be the smallest possible by carefully thinking about where and when to execute models, rules, data analysis etc.

On this last point I have long been a fan of Richard Hackathorn's view of latency. He uses the concept of the value-time curve. This curve is designed to show that the longer you take to respond to new data, the less value there is in your response (assuming you make an equally good decision).

Dr Hackathorn describes response latency as consisting of the sum of "capture latency, analysis latency and decision latency". As he says "As quicker actions are taken, we move up the value-time curve, increasing the value gained". While he believes that it is hard to reduce decision latency due to cultural issues, I have seen many companies use business rules approaches to automate decisions, at least in a high percentage of transactions, and so reduce their decision latency close to zero. This is why I think a decision/rules management infrastructure is so important when trying to deliver active data warehousing.

Lastly, the comment was made in one of the articles that "an EDW supporting active data warehousing serves as the brain of the enterprise". I would say more that an EDW serves as the memory of an enterprise and that the associated decisioning infrastructure serves as both brain (deciding what to do) and as part of the nervous system (making it happen).

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