Analytics & Optimization Build or Buy or Both?


Saw this article To build or to buy IT applications? by Polly Traylor in InfoWorld. The article lays out some of the decision points for those trying to decide between building and buying application software. Reading this it seemed to me that for many organizations, especially those working on an SOA approach, a combination of bought applications and custom development using business rules might be perfect. So how would this work? Buy commercial software to automate the core processes and manage the data. Best practices and standard approaches will probably be fine. Using business rules to inject "intelligence" into those processes by automating the key decision points - which discount to apply, what product to offer, which policy to underwrite etc. This means you use an industry-standard approach with unique, company-specific decisions. Where custom processing is required business rules are perfect - they get the business more involved, give you flexibility and minimize the future cost of change. This allows you to get the benefit of custom...

1 Comment

Analytics & Optimization Complex decision-making and business rules


Lars Toomre posted a comment that made me think about complex decision-making.I would think that this solution would be great for any bread-and-butter insurance underwriting situation, but would break down with the some of larger, more complex deals for certain corporate P&C lines. How does one get more information on what Blaze Advisor can do with complex rules?So let's take a couple of specific examples. Automobile insurance is relatively repetitive and so companies can get very high rates of automation - Auto Club Group, for instance, automates 99% of their decisions. What about the other 1%? Well those still get referred to underwriters for review but, in those circumstances, the rules can and do execute both to add additional information likely to be relevant (MVR or Motor Vehicle Reports for instance) and to inform an underwriter as to why it is being referred ("Number of crashes is relevant and was too high for automatic risk calculation" or whatever). In addition, rules can be used to refer the policy to a particular underwriter e.g. one who...

Leave a comment

Analytics & Optimization Are BPMS and BRMS complementary or not?


In his blog posting on BPM 2.0 Ismael Ghalimi gives a number of characteristics of a 2.0 BPMS. While there is much here with which I agree, he also said:Rule Engine IncludedUp until now, BPM solutions would fall into two camps: you either had a glorified rule engine presented as a generic BPM solution, or you had a generic BPM solution that failed to support the execution of complex business rules natively. As a result, most customers who deployed a BPM solution of the later kind had to look for a rule engine from a third-party vendor, even though they did not really need a full-fledged rule engine to being with. BPM 2.0 makes the rule engine a requirement, so that it can be leveraged by the BPM vendor itself in places where it makes sense, such as decision branching, message routing, late-stage service binding, or contextual user interfaces.Here I can't tell if I agree with Ismael or not. He could mean that it is no longer OK for the BPM vendors to have nothing in the way of a rules engine - they must either build something comparable or, more likely, OEM...


Analytics & Optimization Offshore, backshore, business rules


Ephraim Schwartz has a great article in InfoWorld today - Bringing software development back in-house. In hit he quotes someone who was reversing a decision to outsource:Fields believes that software technology is a collaborative process among designers, architects, and programmers. Agreed. This is one of the reasons I really like business rules. By removing the impedance between business experts and programmers, you can more truly collaborate. Business users can read even the technical rules that programmers write while other rules can be managed directly by business users using a range of template-driven rules and metaphors like decision tables and decision trees.But even that wasn’t the major reason for Fields’ decision to “backshore.”“Companies our size should not take their core IP [intellectual property] and have it essentially owned by individuals of another company,” Fields explains. Now I think this is a key distinction. It seems to me that not all the code in a system is "core IP". But the code typically replaced by business rules...

Leave a comment