We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Blog: James Taylor Subscribe to this blog's RSS feed!

James Taylor

I will use this blog to discuss business challenges and how technologies like analytics, optimization and business rules can meet those challenges.

About the author >

James is the CEO of Decision Management Solutions and works with clients to automate and improve the decisions underpinning their business. James is the leading expert in decision management and a passionate advocate of decisioning technologies – business rules, predictive analytics and data mining. James helps companies develop smarter and more agile processes and systems and has more than 20 years of experience developing software and solutions for clients. He has led decision management efforts for leading companies in insurance, banking, health management and telecommunications. James is a regular keynote speaker and trainer and he wrote Smart (Enough) Systems (Prentice Hall, 2007) with Neil Raden. James is a faculty member of the International Institute for Analytics.

August 2008 Archives

Copyright © 2008 James Taylor. Visit the original article at Precision Marketing Time (Lessons from the CMO Summit #4).

Last thoughts from the CMO summit based on comments made by various Aberdeen folks and speakers. Fundamentally, companies cannot allow their marketing to stand still. Marketing cannot afford to keep doing what it’s doing - lots of companies focus on acquisition for instance even when their data suggests that retention and selling to existing customers is more profitable. Marketing departments must challenge the status quo and the tendency to dismiss anything “not invented here”. They must take a metrics-based approach - replacing a subjective version 1.0 with a fact based process that measures outcomes.

Intuitive marketing must be replaced by scientific marketing and mass marketing with precision marketing. Dumb marketing systems with smarter ones.


Posted August 31, 2008 4:30 PM
Permalink | No Comments |
Copyright © 2008 James Taylor. Visit the original article at Shameless Commerce - Coming to Europe.

I am going to be in Europe in October and I am looking to productively fill a couple of days in my schedule. I am available Friday the 3rd, Monday the 6th and possibly Wednesday the 8th. If you are based in the London - Paris - Brussels - Munich - Frankfurt area and are interested in a day’s consulting, drop me an email james@smartenoughsystems.com.


Posted August 28, 2008 10:32 PM
Permalink | No Comments |
Copyright © 2008 James Taylor. Visit the original article at A reader asks - what makes a company ready (for EDM)?.

A reader had an interesting question this week. As a comment to Using decision management to deliver intelligent business performance he asked “What makes a company ready?”. I suspect my closing line “The products are, mostly, ready. Whether companies are is another question…” prompted this.

So, what makes a company ready for enterprise decision management - for taking control of its decisions, externalizing them, managing them and improving them? Well we went into this at some length in the Readiness Assessment chapter of Smart (Enough) Systems but I think there are five main things:

  • How good is your business and IT collaboration and alignment?
    Decision Services and decision management need the business and IT to work together to define and manage the decision logic. While technology can help, you need the organizational reality to match. In practice this is very varied in most companies so look for opportunities in areas where there is either a good working relationship or at least a willingness to try.
  • How available and clean is your data?
    Having good data and information management makes EDM a lot easier. It’s not an absolute requirement - some EDM projects are rules-heavy and analytics-light - but it sure helps. If this is a problem in your organization, take a decision-centric view of the data you need (what helps me make THIS decision) and try and just clean up that portion. Don’t boil the ocean.
  • How much analytic understanding and skill is there?
    Developing analytic models, doing data mining, leveraging the insight that can be gained from your data takes skills you may not have. If you don’t, consider outsourcing it (there are plenty of small analytic shops out there who can build models for you) and start with simple to use models like regression, decision trees and score cards. Don’t forget that just using analysis tools to examine historical data can be a big help when writing rules, for instance. You don’t have to start at a super-high level of sophistication.
  • How good are you at handling organizational change?
    Automating operational decisions will almost certainly cause some organizational change. If changing responsibilities and KPIs is a really difficult tasks at your organization, adopting EDM could be hard. Again, you can start local with an executive with lots of pain or some mental flexibility - just enough to make one decision-worth’s work.
  • Finally, do your managers and executives have an operational focus?
    EDM is about improving operational systems and processes by improving the decisions within them. If you managers and executives don’t care about day-to-day stuff, don’t track operations closely then you will be challenged when applying EDM. Find someone who knows how their business ticks and you will do better.

    I hope this helps. If you want a little more details, here are five posts I wrote on this topic on my ebizQ blog:

    If you like those posts, why not subscribe to that blog also?


    Posted August 28, 2008 1:25 AM
    Permalink | No Comments |
    Copyright © 2008 James Taylor. Visit the original article at links for 2008-08-27.


    Posted August 27, 2008 4:03 PM
    Permalink | No Comments |
    Copyright © 2008 James Taylor. Visit the original article at Next generation direct marketing with decision management.

    Elana Anderson had a great post on direct marketing while I was on vacation -Next Generation Campaign Management.

    She starts off with three great principles:

    • Listen to all information provided by customers and prospects — both explicit and implied.
    • Understand past and present information to determine the best possible marketing action.
    • Communicate in a compelling, timely, and relevant manner.

    All of these make perfect sense to me and show some of the weaknesses in less well thought out approaches I see out there. For instance:

    • I see too many people separating web behavior from offline or back-office behavior (failing therefore to consider all the information available).
    • I also see too many organizations either only allowing explicit preferences or deriving implicit ones - far too few effectively manage both.
    • I see a lot of understanding going on but not enough projection into the future to see what will be the best thing to do next
    • Too much focus on batch cycles and not enough on interactivity and real-time.

    She goes on to articulate four key criteria for next generation campaign management systems:

    • Are customer-aware.
    • Provide centralized decision making.
    • Enable cross-channel execution.
    • Integrate marketing operations.

    I would revise the second one a little as I am not convinced that it is enough for a campaign management system to provide centralized (campaign) decision making. I think your campaign management system needs to be integrated with centralized (business) decision making. For instance, customer support may share decisions with marketing; Pricing decisions are relevant to campaigns but not part of campaign management; Shipping and logistics decisions may constrain marketing options and so on. Customer-centric decision management makes campaign management way more effective for sure, I just think it should be a peer of campaign management not a part of it.


    Posted August 26, 2008 11:52 PM
    Permalink | No Comments |
    Copyright © 2008 James Taylor. Visit the original article at Neil Speaking at Brainstorm San Francisco.

    Neil has a new speaking gig - he is going to be speaking at Brainstorm San Francisco on “Applying Decision Management to Make Process Simpler, Smarter and More Agile”, October 1st in the morning. You can find the agenda here and register here.


    Posted August 26, 2008 11:25 PM
    Permalink | No Comments |
    Copyright © 2008 James Taylor. Visit the original article at SOA Survey for you.

    A student of Information Systems for Business Performance at University College Cork, Ireland is investigating how SOA can influence the IT capability of a firm and to what extent this strategy can become a major initiative for changing the underlying business approach of an organization. I offered to post the survey which should take no longer than 5-10 minutes to complete:

    Part 1: http://www.surveymonkey.com/s.aspx?sm=fmiRVCG0gBSazAo2TD5y1w_3d_3d

    Part 2:http://www.surveymonkey.com/s.aspx?sm=nhGoidn75v816XG39Tdkpg_3d_3d

    I will get and post the results when they are done.


    Posted August 25, 2008 5:01 PM
    Permalink | No Comments |
    Copyright © 2008 James Taylor. Visit the original article at Here’s why decision management matters to mobile marketing.

    Ginger Conlon had a little piece on mobile marketing that caught my eye. This post highlighted the growing importance of mobile devices as both a customer support channel and as a marketing vehicle. I completely agree with this assessment but I think it means that, for both customer service and marketing, we will have to change our thinking. Mobile devices are never going to allow the interaction quality of larger ones (though constant improvement means that we will have mobile devices better than todays desktops by then the desktops will also be better). As a result we must be more proactive when dealing with those users. In support this means we must serve up actions not just information to those devices. In marketing it means we must make a more complex decision so we can deliver a more tightly focused, timely and location-aware offer. Decision management - focusing on and then automating and improving these decisions - will be critical to taking maximum advantage of these devices. It won’t be enough to take what you do now and simply make it display on a mobile device, you will have to do more.

    This was written in advance and scheduled for posting while I am on vacation.


    Posted August 21, 2008 4:19 PM
    Permalink | No Comments |
    Copyright © 2008 James Taylor. Visit the original article at Using decision management for Governance, Risk and Compliance.

    A reader asked me to blog about GRC - governance, risk and compliance - this week and, in particular, the difference between IT governance and true business governance or what is broadly known as GRC. I have been thinking about this and will write some more posts when I get back from vacation but, for now, here are some links about using business rules and decision management to deal with the challenges of GRC:

    This was written and scheduled before I left for vacation. More when I return.


    Posted August 20, 2008 3:14 PM
    Permalink | No Comments |
    Copyright © 2008 James Taylor. Visit the original article at Using Decision Management to power the call center of the future.

    Chris Skinner wrote a nice little piece on the Future Call Center over on the swift community. He had some nice examples, though he was focused on how the future call center might be using video. What struck me, though, was that decision making is critical to his example. Neither the avatar nor the video-linked person can be effective without automated decision making. If they don’t know what decisions can be made, if they are not told what is allowed/not-allowed, if they don’t have access to the decisions about personalized offers then they cannot deliver the experience he discusses. Passive presentation of information will not cut it - the person is unlikely to be able to be sufficiently responsive without decision automation (it will take them too long to review everything and then decide manually) and the avatar can’t do anything unless it is programmed to make decisions.

    It also struck me that going overdrawn should have triggered a response - a decision should have been made about how to treat him when he went overdrawn and, for a good customer, this should have included a proactive promotion of the short term loan. Combining becoming more event-driven (a critical need for most financial institutions) with decision automation gives new meaning to proactive customer service (one of the recommendations of The Best Service is No Service, an excellent book).

    If making your call center more effective is on your list of things to do I have written a number of posts on using decision management in the call center.

    Note: This post was prepared earlier and posted this week while I am on vacation.


    Posted August 19, 2008 4:00 PM
    Permalink | No Comments |
    Copyright © 2008 James Taylor. Visit the original article at Here’s one way to institutionalize great service.

    David Rance had a nice piece on CustomerThink called Great Service Has to Be Institutionalized if It Is to Become the Norm. In this post he identifies decision making as important, which I think is true. Now his focus is on culture (very important) but mine is different. What if you used your systems to institutionalize great service?

    Think about it. You could define what you mean by great service, identifying the moments of truth (decisions) where your staff need to decide to treat customers well and specifying the “rules” for many of these interactions. Embedding these decisions into your CRM systems would mean that your staff would automatically make the decision that represented great service. Furthermore, embedding these decisions into your website, IVR system, kiosks and ATMs would mean that your automated channels would also automatically make decisions that deliver great customer service.

    Now I am not pretending you can automate your way to great customer service but I do think that failing to do so will handicap any effort to improve customer service and that automating customer service decisions can make a big difference. I wrote a piece a little while ago on decision management and loyalty and another about bad decision making in systems resulting in bad customer service.

    Note: This post was prepared earlier for use this week while I am on vacation.


    Posted August 18, 2008 4:00 PM
    Permalink | No Comments |
    Copyright © 2008 James Taylor. Visit the original article at On vacation.

    Well I am off to the mountains for a vacation with no email, no cell phone, no twitter and no blogging. I have queued up some posts for you so you won’t miss me too much but don’t expect a reply until after the 25th.

    Have fun


    Posted August 16, 2008 12:17 AM
    Permalink | No Comments |
    Copyright © 2008 James Taylor. Visit the original article at Here are some pressure points for business rules.

    Chris Berg wrote a nice piece on Pressure Points that seemed like it was worth highlighting. Chris outlines some great reasons for using business rules and he seems to Believe in business rules (as I do).


    Posted August 15, 2008 10:09 PM
    Permalink | No Comments |
    Copyright © 2008 James Taylor. Visit the original article at Decision Management job (kinda) at Wachovia.

    Got another question about a job today. This time Jim Fahy sent me this one:

    Director, Insight and Innovation Advanced Capabilities

    The Insight and Innovation group combines a customer analysis group; research and targeting; and the analytics reporting and technology team formerly housed in a corporate customer service excellence structure.  The customer and market insights that are created will drive the improved innovation, product development, brand differentiation and customer loyalty with the goal of propelling revenue growth and driving customer acquisition through a world-class insight and innovation center of excellence.  The Insight and Innovation Advanced Capabilities Director will provide strong leadership promoting teamwork and building on strong collaborative relationships with cross functional partners.

    The individual selected for this role will provide strategic thought leadership with regard to statistics/modeling and targeted marketing areas for Wachovia.  He/she will manage Insight and Innovation resources dedicated to targeted marketing modeling/optimization and advanced modeling efforts such as pricing, ROI and media mix modeling.  This professional will lead the development of cross-enterprise customer/prospect contact strategies in order to maximize Wachovia’s return on targeted marketing investment.

    Here are the details, contact Jim if you are interested.


    Posted August 14, 2008 6:39 PM
    Permalink | No Comments |
    Copyright © 2008 James Taylor. Visit the original article at Warranty decisions are one reason iRobot’s outsourced call center doesn’t work as well as it should.

    I have been an iRobot customer since Christmas. Much as I like their products, their customer service decision making leaves a lot to be desired. This particular post was prompted by their inconsistent warranty decision management. iRobot has outsourced its call center, as many companies have, and sound like they want to deliver excellent customer service. Certainly the folks from the Jay Group (their outsourcing partner) do. Yet the complete inability of iRobot to deliver consistent warranty decisions or to put their business experts in control of critical customer service decisions makes this impossible. As a result my customer experience has gone steadily downhill - for want of a decision the customer was lost. I would point out that some time ago I posted on iRobot’s silly return process and the contrast of this with its apparently award-winning CRM (here’s another post that picked up mine and that has a comment proving I was not an isolated instance). That time, as now, the problem is one of decision making. Clearly customer service and warranty decision making is not their strong point.

    So here I am, once again, engaged in dealing with iRobot’s customer service. This time my Dirt Dog has gone wrong. This robot was always my favorite - the one that had the clearest ROI - but some days ago it started misbehaving. After some intelligent back and forth debugging it by email, I got this from the customer service folks:

    Based on the information you have provided us, we have determined that your robot needs to be replaced. We have all the pertinent information, so at this time all we need from you is permission to set up the exchange and we can process the exchange through email.

    Because we are not requiring you to return your current unit to us, we ask that you dispose of the robot. This Dirt Dog has been permanently deactivated in our records

    Very nice customer service - rapid debugging, clearly a problem with the unit, don’t worry about sending it back we’ll replace it. Lovely. The new unit arrives but, sadly, never works right. Back to customer service.

    This time the debugging interaction is not so good. The first couple of responses have pretty clearly not bothered to actually read what I wrote in the problem statement and suggest trying things that I have already tried and that, anyway, don’t match the symptoms I am describing. Clearly this decision making is not really under iRobot’s control.Eventually I get a response as follows:

    Please place your Dirt Dog in a plain cardboard box. …
    In the box, please include a note with the following information …
    Please ship the box to the address below. We recommend that you ship this parcel via UPS or FedEx, because they provide you with tracking and insurance…

    So the first time my Dirt Dog went wrong it is replaced at no cost to me. The replacement never works but now I have to pay to send it back? When I ask the customer service folks this question they tell me:

    We do not offer to reimburse shipping charges for the return of items to us to be replaced

    But surely they do not always require things to be returned? I can’t imagine the policy has changed in the few weeks since I last interacted with them. Clearly iRobot has a consistency problem - the customer service folks are not able to make consistent warranty decisions.

    After a little research I discover that iRobot uses RightNow’s SaaS CRM offering to run their call center which they outsource to The Jay Group. I even found a podcast from the Voices of CRM series in which iRobot and the Jay Group describe their relationship. In the podcast the iRobot and Jay Group representatives make some interesting points:

    • They stress the need for dynamic troubleshooting of robots - the outsourced reps must know how
      Yet my experience is that the quality of debugging varies significantly between reps.
    • Engineers need access to these conversations to see what can be fixed and they talk of documentation about problems stored in the CRM application
      Yet the engineers don’t seem to be able to change the interaction directly, only indirectly through the documentation they provide
    • They outsource because the call center is not their core competency
      Which is fair enough but isn’t determining what’s wrong with a robot a core competency? How about defining the warranty policy and returns criteria? Surely those ARE core competencies?
    • The idea is to allow users to choose a channel and then interact consistently
      Well I have only used one channel but so far they are not managing consistency even within the channel
    • Finally they talk about automating returns at some point in the future to reduce wait times and improve efficiency
      But the conversation is about the process of generating return ids and managing the process, not about consistently correct returns decisions which seem likely to remain dependent on training of reps.

    It would be easy to blame the outsourcing for the inconsistent customer service but frankly I don’t think that’s the problem. It is clear to me that iRobot has not thought about how it wants to handle some critical decisions:

    • Deciding what is wrong with a robot
    • Deciding if a robot should be replaced
    • Deciding if a broken robot should be returned before it can be replaced
    • Calculating the refund due for a return (previous post)

    If it had then I would be getting consistent, and consistently accurate, responses from the Jay Group reps and I am not. Replacing an outsourced service with an in house one would not address the problem - the decisions would still be up to individual reps based on their understanding of what’s wrong and what the return policy is.

    The moral of the story is that, if you want consistently excellent customer service, make sure you retain control of and effectively automate the critical decisions that affect your customers - debugging, refund and warranty decisions, for example. My process experience would have been quite different if these decisions were being managed explicitly, especially if they were being managed in a way that allowed the domain experts (engineers for the debugging, business owners for refunds and return policies) to control the rules and policies in the decisions directly. Then the decisions would be driven by the actual policies and actual experiences, not through the reps interpretation of those policies and experiences.

    iRobot, automate these decisions!


    Posted August 13, 2008 4:00 PM
    Permalink | No Comments |
    Copyright © 2008 James Taylor. Visit the original article at A reader asks about scorecards and why people use them.

    A reader sent me an interesting question after watching the ILOG seminar on scorecards and rules in which I participated earlier this week (recording of this rules and scorecards seminar is available). Here’s a summary of what he said:

    One immediate comment I would have is that scorecarding seems to insert an extra unnecessary step. Rather than have an extra level of modeling and human intervention, you can directly include data and knowledge and the framework basically generates the model for you in such a way that it guarantees that the information content of the model is equal to the information content of the inputs. Scorecarding represents an opportunity for either loss of useful information, or addition of artificial information. Depending on how you assign attribute score values and how that is then mapped to probabilities, the scorecard would almost certainly have a different information content from the original inputs. That’s important, because the value of decisions is a function of this information about the future. If your model of the future is bogus, so is the value, and you certainly stand to lose value one way or another.
    There’s more on this topic here: Scorecards and Shareholder Value.

    I think Dave makes some good points in his post, though I think the ability of scorecards and decision rules to be validated by regulators is not one that should be underestimated. Hopefully some of my readers will post some comments here or there and we can get a debate going.

    Disclosure: I am an advisor to Provisdom.


    Posted August 12, 2008 5:57 PM
    Permalink | No Comments |
    Copyright © 2008 James Taylor. Visit the original article at Business Rules, Domain-Specific Languages and Models.

    I saw this piece on DSL and MDE, necessary assets for Model-Driven approaches and it made me think about DSLs. First, here’s the definition of a DSL from the article

    DSL is a programming language or executable specification language that offers, through appropriate notations and abstractions, expressive power focused on, and usually restricted to, a particular problem domain.

    I notice some pieces of advice about DSLs in this article that make me think business rules would work better. First he suggests that you:

    Implement DSLs in a way that they are directly executable on a specific platform. For making them executable on another platform the generator or interpreter needs to be rewritten

    Well a business rules management system handles this for you. In fact several commercial BRMS products allow you to execute as COBOL, Java or .Net from the same rules. Next he says:

    Make DSLs extensible by existing GPLs [General Purpose Languages], programmers can formulate the necessary additions in a language they know.

      Most BRMS products do this inherently, allowing business rules to access functions written in C# or Java or whatever. He goes to quote someone who:

      emphasizes that for tackling the complexity of software development a language is needed understandable by both developers and domain experts.

      This, of course, is a key value of using a business rules approach and a BRMS. Now thinking about DSLs and how often a business rules approach and a BRMS could (and should) be used instead made me remember an article on Business Natural Languages (a better name IMHO for DSLs) I saw some time ago in which Jay Fields said:

      The more business specific logic you can abstract out of an application the less programmer involvement you will need to alter the business logic.

      Then, more recently Jay had a post on Designing a Domain Specific Language in which he talked about building a system that allowed the

      director of finance for the client bank to edit, test, and deploy the business rules of the system without any assistance from IT

      Hmm. So far this all sounds like the kind of thing for which business rules are ideal. Not only are they declarative and clear for business users, they typically act against an object model in a way that allows more business-friendly names to be used - essentially hiding the objects and their complexity. If you like you can even use various web-based editors (with most commercial products) that hide even the structure of the rules themselves, allowing a point-and-click interface. Taking a business rules management system and building a domain-specific environment on top seems to me much more efficient than creating a whole DSL from scratch.

      DSLs come up a lot, especially in the context of model driven engineering or development or architecture (MDD/MDE/MDA). Personally I think business rules work better and do so without you having to write a bunch more code. Models and business rules, perfect together.


      Posted August 12, 2008 2:24 PM
      Permalink | No Comments |
      Copyright © 2008 James Taylor. Visit the original article at A reader asks about business rules in Oslo.

      A reader asked me last week about how I saw business rules engines fitting in with UML, SOA and Microsoft. The article discusses whether Microsoft’s Oslo strategy for SOA will be based on UML or merely offer support for it among many standards.

      First, let me say that I think it is increasingly clear that application development is going to change a lot in the coming years (and is already doing so). To the point where I don’t think it will really be what we call application development any more. From what I know of Microsoft’s strategy they are trying to make sure that they support their core audience (developers) while also adapting to this reality. UML is part of that, so is support for process-centric standards like BPEL and BPMN.

      Regardless of which modeling standards and approaches a developer uses, I think the case for externalizing and managing business rules remains compelling. Business rules, especially those implementing decisions, must be owned by the business and IT in collaboration and so code is a non-starter. A declarative, verbose, business-friendly approach to specifying business logic is a must today and will be even more so in the future. Microsoft has a fairly aggressive approach to its business process ecosystem and has included business rules vendors in that for a while. Their own support for rules and process and the support of their partners makes me think that rules, rule engines and rule management will be either part of the vision or at least very compatible with it.

      I blogged about how I see business rules fitting with model-driven approaches (I think they complement each other) and wrote an article about SOA, rules and decision services before. If you are interested I will also be speaking at the SOA Symposium in October on Decision Services.

      One last thing - domain specific languages. These come up a lot in Microsoft discusions and I am going to blog about them tomorrow.


      Posted August 11, 2008 8:32 PM
      Permalink | No Comments |
      Copyright © 2008 James Taylor. Visit the original article at More on the IBM/ILOG Relationship.

      I got a briefing last week from IBM as part of my researching of the IBM/ILOG acquisition (I blogged about this here). Back when I was at IMPACT it became clear that IBM was getting focused on events, rules and policies - they talked about Points of Agility, points in a business where variability is critical to success. Rules, analytics, business events and policies were all identified.  While today’s briefing could not cover any future plans, I did get an overview of IBM’s current relationship with ILOG.

      IBM has been partnering with ILOG for over 10 years in various parts of IBM. When IBM made the 2005 announcement of their SOA stack for WebSphere, including WebSphere Process Server, this relationship was stepped up a notch. IBM’s architects had a vision of the importance of business rules within the process and within the broader application development environment. Within WebSphere Process Server is a Business Rules Manager with some rules capabilities for rule sets and basic decision tables. This is designed to strengthen the value proposition around abstraction - with a BPEL engine, human task management support, state machines and business rules to deliver abstraction. This was always designed to support external rules management products, especially when a customer needed end to end rule management and support for the whole business rule lifecycle. The partnership with ILOG has been designed to make this straightforward. A couple of other areas of partnership include:

      I blogged recently about the role business rules has to play in IBM’s SOA methodology and my conversation today simply reinforced my view that IBM was already taking business rules seriously when it announced the ILOG acquisition. I look forward to finding out more as time passes.


      Posted August 11, 2008 5:48 PM
      Permalink | No Comments |
      Copyright © 2008 James Taylor. Visit the original article at First Look - Tibco ActiveMatrix Service Performance Manager.

      I got a briefing this week from my friends at Tibco about their Service Performance Manager product released a couple of months ago. The product is a big step along the road to what some call “autonomic computing” in that it provides dynamic and automated monitoring and correction of service levels in a service-oriented world.

      The product combines Tibco’s BusinessEvents (rule engine), SOA products, is integrated with ActiveMatrix and wraps this all up for monitoring and management of complex, service-oriented environments. SOA has, of course, made monitoring and management much more complex. In an SOA environment defining and then managing to Service Level Agreements is difficult.

      The product allows the definition of SLAs (for services, parts of services or complete BPEL transactions) and then tracks to see if these are being met. The product discovers services, measures observable aspects, analyzes and predicts behavior, monitors and acts. This includes predictive analysis of services trending to failure, as well as monitoring of the SLAs using explicit rules, and it will both report and act in response to problems. This response might include re-provisioning new resources to maintain service levels or borrowing resources from other services. The role-based dashboards allow users to figure out why they are having problems and do some computing capacity planning.

      Some time ago I wrote about the need for this kind of “smart” decision-making solution to deliver on autonomic computing. If you examined such a solution, I said:

      • It would use business rules to record SLAs, procedures, best practices, rules of thumb from experts as to how to respond to particular failures, how to interpret readings, how to select new routings around failed equipment.
      • It would use predictive analytics to turn historical log data into executable predictive models. These might take temperature data and use it to predict the likelihood of failure of a piece of hardware or traffic data to predict a bottleneck. Other models might use Neural Network technology to “learn” from patterns of data and identify unusual variations and even unusual variations from the usual variations.
      • Clearly these predictions result in the need for more rules to deal with these predictions - I might behave differently in response to a potential for overheating when traffic is low and I have spare capacity than when it is really high and I do not, for instance.
      • Lastly companies might want to run simulation of how a set of decisions might impact uptime, throughput etc for different constraints so as to develop optimal strategies over time.

      Pretty close to what the folks at Tibco have done for service performance management. Autonomic computing may still be a vision but people are already using business rules and analytics, enterprise decision management (EDM), to deliver on some of its promises.


      Posted August 8, 2008 9:41 PM
      Permalink | No Comments |
      Copyright © 2008 James Taylor. Visit the original article at First Look - IDS Scheer ARIS Business Rule Designer.

      I had a chance to catch up with Marwane from IDS Scheer the other day and talk about ARIS, IDS Scheer’s enterprise modeling product. The ARIS architecture or platform has currently more than 25 products for enterprise modeling divided into 4 platforms (Strategy, design, implementation and controlling) and 6 solutions (Enterprise BPM, EA, SAP, SOA, Process Intelligence, Performance Management and BAM, GRC) - everything from organization models to functions, value chain, data, process, structural behavior etc. What they are best known for, of course, is business process modeling and this is central to their products which are all pretty business process oriented. Their focus is on allowing you to model your enterprise and at some point that means having to deal with automation (very few modern enterprises can run on manual processes after all). The product that particularly interests me is the ARIS Business Rules Designer (though I wish they had called it the ARIS Decision Designer) as this allows you to model decisions, and the rules behind them, as part of modeling your process. Just as modeling processes requires an eventual transition to executable process models in order to set theses processes to production, so modeling decision making at design time requires an ability to specify business rules which can be run in a productive environment.

      The product is designed to let you specify rules at a reasonably high level - against a business vocabulary rather than a detailed object model. The intent is to keep business designers at a conceptual level - once they have a good model of their process then they can model explicit decision making in a declarative way. The primary interface for this is decision tables, chosen both for being intuitive and for their easy support for branching and parameter-based logic (important in a process). The vocabulary against which the rules are written is modeled as a UML diagram or an Entity Relationship Diagram. A vocabulary model can then be automatically generated out of these data models. The interface used to model decision tables also allows capturing rules in natural language syntax. It is designed for supporting capturing business rules while they are still at an early stage of specification. The underlying components (rule engine) of the decision modeler are from Corticon’s product (as I discussed before).

      I liked the way IDS thinks about decisions. Decision services are defined within the process that map to a Rule Flows. Rule Flows are a linked and ordered set of decision tables, in future versions it will apparently be a workflow of decision tables. These are integrated into to process steps by annotating functions with Business Rule Objects. These Business Rule objects have Rule Flows assigned to them. While they see some confusion around the difference between process/workflow and Rule Flow, their approach is exactly the one I would have described, modeling complex decisions as rule flow and action steps as process. After all, many processes consist of business rules/decisions but not much else. In these circumstances Rule Flow helps manage these more complex decisions. All of this maps exactly to how I would think about decisions in process (check out this presentation on using decision management to make processes smarter and more agile, for instance, that I gave at the Intalio user group).

      I look forward to working more with the ARIS products.


      Posted August 8, 2008 4:11 PM
      Permalink | No Comments |
      Copyright © 2008 James Taylor. Visit the original article at IBM, SOA and Business Rules.

      Well it seems that IBM believes in business rules too. I was reading SOMA: A method for developing service-oriented solutions which I found thanks to Eric Roch’s post on IBM’s SOA Methodology anda couple of things struck me:

      • Business rules get called out explicitly both in the meta model Eric shows and in the overall flow. Personally I would have liked to see Decision called out but Business Rules and Policies are a good start.
      • Rule services (what I call Decision Services) get a mention as a design artifact and a way to collect rules into something implementable
      • A rule engine appears in some of the implementation diagrams (like this one)
      • An obvious Decision Services (Validate Payment) shows up in the worked example



      Posted August 8, 2008 3:38 AM
      Permalink | No Comments |
      Copyright © 2008 James Taylor. Visit the original article at An interesting poll on data miners and PMML.

      PMML - The Predictive Modeling Markup Language - is the primary XML format for describing predictive analytic models so that a modeling tool can share a model with either another modeling tool or, more usefully, with a deployment environment. The folks over at KDNuggets recently ran a poll asking their readers about their use of the standard (the results are available here). While use of PMML is still pretty limited, with half the responders saying they don’t use it at all, I was encouraged to see a solid core deploying most of their models using it (15%). There were some interesting comments, too, showing the usual range from people who don’t like XML, to those who prefer deployment direct to specific code to those who like the idea of a standard but have concerns about the specific.

      As someone who believes strongly that models are most valuable when both deployed and mixed with declaractive rules-based logic (for policy, regulations etc), I hope PMML will continue to gain ground. I am encouraged both by the number of modeling tools that generate it (including SAS, SPSS, Fair Isaac,IBM, R - open source) and rules-based environments that can comsume if (Fair Isaac’s Blaze Advisor, Pegasystems PegaRules and Zementis ADAPA, Chordiant Decision Management).

      Any readers got comments on PMML? Anyone using it out there? I’d love to hear from you.


      Posted August 7, 2008 4:28 PM
      Permalink | No Comments |
      Copyright © 2008 James Taylor. Visit the original article at Using decision management to deliver intelligent business performance.

      Steve Cranford of PwC wrote an interesting piece called Bringing Order to Chaos (brought to my attention by Alan over at Tibco) that made me think. Steve’s focus is on the next software suite for enterprises (something he calls an Intelligent Business Performance Platform) consisting of business intelligence, business process and business rules. Reading this it seemed to me very like the concept of dynamic business applications seen recently from Forrester, though with a somewhat different focus.

      While I agree that organizations need a platform for running their business more intelligently and more “by the numbers”, I think the components of such a platform are not BI, BPM and BRM but:

      • Performance management
        Using reporting and especially event-based dashboards to actively and effectively monitor ongoing business performance.
      • Process management
        To manage and improve the workflow and processes that deliver value.
      • Decision management
        To combine policies, regulations and analytic insight into continuously improving decisions.

      I don’t like to use “BI” as a component as it is such a broad term and we are mostly talking about dashboards/monitoring and data mining/analytics rather than reporting. I also think business rules is too broad as it is a useful component of many elements (something Steve recognizes later in the article when he talks about all the different things involved). Splitting out the combination of data mining/analytics/business rules/optimization (decision management) makes it clearer, I think, what is required. After all I need to run efficient processes that rely on effective decisions and can be monitored reliably.

      I also liked the drivers Steve outlined - a move to real-time, increasingly extended enterprises and a flat world though I have a longer list that I use when discussing the need for smarter systems. I would also add that it is not just about efficiency - actually also about effectiveness.

      Steve sees this new platform having many of the characteristics I see with real-time data feeds, better use of data with data mining and analytics not reporting, dynamic dashboards for performance management, business control and all built on a service-oriented platform. Indeed I see decision services as crucial in all of this. Like Steve I also believe that this approach does not require a “rip and replace” mindset but allows you to add value to existing systems - essentially making existing systems smarter (hence the book title).

      A final comment. Unlike Steve I don’t think such a platform requires a heroic effort. Lots of rules vendors have integrated analytics with rules, the best way to integrate Business Process and Decision Management integration is pretty well established and several vendors have integrated pieces of the puzzle well. Most of the rest can be done using standard service interfaces, portals etc. The products are, mostly, ready. Whether companies are is another question…


      Posted August 5, 2008 6:44 PM
      Permalink | No Comments |
      Copyright © 2008 James Taylor. Visit the original article at A reader asks… about development, business rules and model-driven development.

      I got an interesting series of questions from a reader that seemed to me to justify a longish post. The initial question was quite harmless looking:

      Can you give a clue as to what software engineering approach you use/recommend for EDM, but especially business rules that non-IT staff can alter safely?

      But the whole thing got more interesting as they explained some follow-up items:

      [is this] ‘just’ putting non-developer friendly interfaces on the process business rules inherent in MDD [Model Driven Development] or something completely different?

      Has all this effort been put into business rules engines because of the current limitations of MDD approaches: ie they are a stop gap or an ultimate end in themselves?

      Is the software engineering approach of the business rules engine a temporary convenience or something fundamental?

      Very interesting questions. Taking on the software engineering approach question first I would refer everyone to Enterprise Decision Management and the Software Development Lifecycle, a post I wrote not that long ago on the topic. Personally I think the Agile approach works especially well as I said in my recent Application Development 2.0 post. To repeat an article I wrote on agile business rules, I find the use of business rules to be completely complementary to the four tenets of Agile development:

      • Tenet 1: Individuals and interactions over processes and tools.
        One of the key interactions is between developers and domain experts. The use of busines rules facilitates this conversation.
      • Tenet 2: Working software over comprehensive documentation
        Business rules can deliver working software that is easier for domain experts to read and manipulate making it more “self-documenting” and lessening the pressure for documentation.
      • Tenet 3: Customer collaboration over contract negotiation
        The fact that both developers and domain experts can read and understand business rules allows true collaboration over the implementation of business logic.
      • Tenet 4: Responding to change over following a plan
        Business rules deliver business agility by making the actual code you write easier to change both during the project, and after it.

      So, to summarize: It does not really matter what approach you use (they can all work well) but Agile or Agile-like approaches will be highly compatible with using business rules. In particular, fast iterations and test-driven development work well with the kinds of short-cycle changes that business users make themselves.

      Now on to the Model Driven Development(MDD)/Model Driven Architecture (MDA) questions.

      I regard business rules as a part (and a very important one) of a Model-Driven Development approach or a Model-Driven Architecture (MDD/MDA) as they allow you to specify business logic without the nitty-gritty of code. No approaches to MDD/MDA manage business logic well today - they mostly assume it will still be coded by developers. As long as designers and developers are embedding business rules in use cases, statecharts, class models etc then MDD/MDA will not deliver on its promises. In the context of MDD/MDA a model cannot be limited to things that can be diagrammed - a model-driven approach must include a declarative language for business decisions - something like the current business rules languages. After all, improved business/IT cooperation requires a shared language and when it comes to the details of business logic I have yet to see anything better than business rules. Business rules allow for IT departments and business users to truly work together. As one of the key drivers for MDD is the need to build systems that can cope with faster business change and to do so by improving business/IT alignment, business rules would seem to be ideal. Too many MDD/MDA approaches seem more worried about tracing requirements to code (which won’t fix the problem).

      Without a truly declarative language to describe the business logic of business decisions, MDD/MDA is just another technical approach for generating code - a new form of CASE (Computer Aided Software Engineering) tools based on UML. MDD/MDA removes the burden of lots of programming from developers but still expects them to deliver the code that implements interesting things such as business logic and algorithms. But business logic and algorithms require business verification and business users hate code. Adding business rules to the MDD/MDA mix would address this. Furthermore, while projects using MDD/MDA have shown a reduction in time from problem identification to working code, it is still code and the IT department is still making the change rather than the business. Again, business rules would help with this. Finally, some of the benefits stated for MDD/MDA seem simple to someone used to a Business Rules Management System (BRMS) or even of a Business Process Management Suite (BPMS) - easy change of logic or process steps without regenerating the whole application for example - so business rules and business process would seem natural components of MDD/MDA.

      Current MDD/MDA approaches do have limitations because they don’t handle business logic the way a business rules approach does (or business process the way a business process approach does). This was not the motivation for current business rules products (they mostly pre-date MDD/MDA being widely discussed) but they remain a hugely beneficial and complementary approach for anyone doing MDD/MDA. I don’t see anything on the horizon that makes me think of them as stop-gap but I would never be rash enough to say that ANYTHING was “fundamental”.

      I think the effective mangement and automation of business decision making is now and will continue to be critical for the next generation of systems - helping to make current systems and infrastructure (and models) “smart (enough)”. For now there is nothing better than business rules for this.


      Posted August 5, 2008 1:16 AM
      Permalink | No Comments |
      Copyright © 2008 James Taylor. Visit the original article at Believe in business rules (I do).

      Earlier this week I posted Application Development 2.0 in which I addressed what I see as some of the issues with current development practices and tried to explain why I think a declarative, business rules approach is essential. This (and some blog posts around the blogosphere) made me think about the mismatch I see when talking to Architects - most have heard of business rules, few use them. Part of the challenge, I think, is that those of us who “believe” are perceived as fringe thinkers. It is easy to see why - we must a fringe as everyone else is writing procedural logic! Beyond this, though, are serious questions about business rules:

      • What are the benefits that justify the additional investment?
      • Why wouldn’t I just code the rules?
      • Will the rules perform, integrate and “play nice” with the rest of my system?

      and so on. When asked why he believes, Chris Berg of ILOG listed Encapsulation, Simplicity, Visibility, Collaboration and Shared Execution (SOA) as the reasons to believe in BRE. In a post on my ebizQ blog recently I listed a similar set of reasons:

      • The separation of decision logic from mechanical implementation gives you more flexibility to make changes with minimal or zero impact on basic systems operation.
      • Business rules are more understandable to business-level people, leading to better business/technical cooperation, reduced implementation times, and fewer opportunities for interpretation errors.
      • Business rules are easily segmented into groups for control over functional interaction and management.
      • Business rules management systems have interactive testing, execution flow, cross-reference tools, and reporting features to aid in development, testing, and documentation.
      • Business rules management systems have predefined rule replacement features to handle system updates without interrupting service to application users.
      • Business rules can have explicit times and dates when they should go into and out of effect.
      • Rule management templates can be created to let users update, view, or create rules in a controlled manner.
      • The rule engine can quickly look through large sets of rules, finding the proper ones to apply based on case-specific conditions.

      Now, there are those who believe that the purpose of business rules is replacing developers with business people - development without developers. I am not one of these people as I believe the value in business rules is in allowing collaboration between two groups with different, but valid perspectives. Yet this difference of perspective often results in serious problems when developing complex systems. Business users are at the mercy of regulations, court rulings and business policies that must be enforced. They must also respond to an ever-changing business and competitive environment. This often means they can’t stabilize their requirements or explain them easily to developers – legal or business jargon does not always map well to Java code! Meanwhile the developers typically don’t understand the regulations or business environment well enough and so can’t develop necessary applications, systems and updates fast enough. As an Illustration let’s take the example of a healthcare benefits system designed to who is eligible for what. First, the business Perspective

      The system needs to implement Federal and State regulations – most states have their own and these are applied sometimes to employees based on the state in which they live and sometimes to the state in which the employer is based and sometimes both. Additional rules and policies are imposed by plans, with every plan being different and often plans have different rules by state. Of course many of these rules have been the subject of court interpretations and any of them could be rescinded or altered at any moment by a legislature or court. In addition, we want to offer maximum contract flexibility for employers – we want to be able to let them make benefits contingent on almost anything that is legal and to change these rules whenever they want, though mostly in time for the main benefits election period. After that it gets complicated as we need to certify that we are enforcing all these rules and no-one on the team reads Java or understands XML etc…

      IT Perspective

      Well all these Federal and State regulations – sure, but how are we meant to keep up with them or read the legal jargon? If we don’t then we rely on the business to keep us informed. But they can’t explain them accurately enough for us to write code against them and none of them can read the code we right anyway making it impossible to verify it. We’ve tried developing test cases but there is an exponential growth in these as we add states and plans and anyway, often no-one knows how a case will turn out until they apply all the rules making it hard to develop test cases. If this wasn’t enough, the plans’ descriptions are full of healthcare terms and legal-speak that is outside our domain. As for this idea of allowing unlimited flexibility for the plans, that’s crazy. They have to limit the number of things that can be used to make decisions and the types of decisions that can be made so we can build some kind of configuration tool. Even then it is going to take a while to add a new plan to the system and we had better get some serious notice for any changes to the regulations…

      Two perspectives, one problem, one solution - business rules. Using a business rules management system to manage the decision logic in a system means:

      • Business users don’t need to manage objects, interface to existing systems, package up and deploy working code – IT still owns this process
      • IT can write technically complex rules in a syntax that business users can validate
      • Knowledgeable users can write regulations as rules using a simple, English-like syntax
      • IT can develop templates to constrain rules that business users want to change – templates prevent problems but allow for a high degree of flexibility
      • IT can do architectural design, integration etc. ensuring that the resulting application can be supported and integrated easily
      • Business user rule maintenance frees up future development time that would be tied up with system updates

      In fact, business rules offer as much to developers (perhaps) as to business people. By allowing non-technical folks to collaborate, developers will find it easier to build applications that make their users happy and so increase the rate of positive feedback. By pushing the nits of maintenance to the business users they will find more time to work on “cool” stuff.

      This post was prompted by a number of posts I saw today:


      Posted August 1, 2008 10:38 PM
      Permalink | No Comments |