Introductory Lecture – SPA 2006 Spring Lecture Series


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Introductory Lecture – SPA 2006 Spring Lecture Series

  1. 1. BRITISH COMPUTER SOCIETY SPA Specialist Group Wednesday 11th January 2006 at 6.30pm at BCS, London 1 Introductory Lecture – SPA 2006 Spring Lecture Series Paul Vincent, Rules Specialist and Product Manager, Fair Isaac 2 Introduction Fair Isaac is a household name in the USA – the FICO score is a rating of creditworthiness. Paul’s specialism is Business Rules – how to manage them, how they relate to other topics in this series. The small number of vendors in this space are all agreed that they would rather have happy customers than foist unsuitable products on them! 3 Drivers for BRM, BPM and SOA A straw poll found that the subsets of the audience involved in each of these topics did not overlap! Historically, software development has gradually moved to higher and higher levels of abstraction, culminating in model driven approaches in the 1990s and component-oriented SOA appraches in the 2000s. Solutions are getting increasingly complex and having to be delivered faster with fewer specialists on the ground. It’s no wonder that the public perceives IT projects as frequently costly, late and/or failures. 3.1 Software development today • Customised solutions (e.g. ERP solutions such as SAP): all-in-one, single-vendor responsibility, but customisation can be time- and resource-consuming or even impossible; may end up having to bend the business to fit the tool o One customer uses Fair Isaac’s rules engine to validate input from SAP forms! • Tool- and Component-Based (e.g. RDBMS such as Oracle): more reuse (few developers would decide to roll their own database management system as part of a solution these days), but at the cost of specialised training and high system integration effort • Custom application (typically in defence): fit for need, singular purpose, but development time & cost can be prohibitive and so can the system integation
  2. 2. In many large developments there will be a mixture of these approaches. SOA (Service Oriented Architecture) fits into the tools/components approach. Services are made available and can be reused across an organisation – so developers have less excuse to ignore them. Business rules supply a component that formalises the representation of decisions made in application development, which can be maintained independently and using a business-level language. What remains when all the business logic has been extracted from a system? All the “system code”, if you like. There is in fact an industry built around tools to perform this type of re-engineering of legacy applications: the OMG calls it “Architecture-Driven Modernisation”. It tends to be fairly labour-intensive. Business Process Management (BPM) is all about defining business applications in terms of business processes – usually in a graphical process studio of some kind – and then running them in that form. So SOA/BPM/BRM combines to cover the advantages of custom and componentised approaches without their major disadvantages. Each of the technologies has a “sweet spot” where it is most applicable. 3.2 A business IT stack Layers include: • Service • Process • Rules (business logic) • Database • Operating system / platform Another view is to treat services as components knit together with processes. An optimal service-oriented IT architecture exposes each of the middle three layers as services. Paul says that a service-oriented approach does not always imply a formal SOA. Judging the granularity correctly to trade off efficiency vs. reusability is a fine art. Static linking can work effectively in the right context instead of HTTP/XML. • Process / Flow layer o Service o Process Logic o OS / Platform • Rules / Declarative layer o Service o Rules
  3. 3. o OS / Platform • Data layer o Service o Database / Persistence o OS / Platform Processes and rules can invoke services at any level in this three-tier approach. Fair Isaac’s toolset allows definitions of components to be shared between applications / components, which increases reuse even more. 3.3 Disclaimer • SOA = Service Oriented Architecture – a specific technology o SOAP, WSDL, UDDI, BPEL etc. o Just one implementation of the service oriented approach • Service Oriented Approach is not necessarily SOA o Services can be any software component mechanism o Web services are considered immature technology by many As a software-tool vendor, Fair Isaac is of course obliged to provide a Web Services implementation. 4 The Business Rules Approach Business rules should be defined, stored, reported etc. in isolation from other entities – • In business documentation • In process definitions • In use-cases and system requirements • In the code IBM WebSphere’s rule beans allow you to do this precisely. Business rules should be defined declaratively • Changes to rule definitions should not require changes in other rules (except where there is a direct dependency) • Rules should be independent of order Typically they are defined in a linear list – hierarchical variants are known (decision trees are an example). 4.1 Comparison with other approaches It is common practice to define and manage data separately from code, so why not business rules?
  4. 4. Object orientation: • Objects should encapsulate data and behaviour • This doesn’t prevent us from managing the data and rules separately from the code 4.2 Main Drivers for using Business Rules The real business experts in many businesses are the IT staff – they have had to deal with all the real boundary cases! Business managers typically have a clear notion of policy, but not the details of practical rules. By bringing the rules together, they can be verified for compliance with regulations, company policy / strategy etc. • Centralise: always know where the rules are • Standardise: always use the same rules from the same source o California Highways Department found that branch offices applied the rules differently to calculate cost of vehicle licences • Control execution: return control over business decisions to the business o Give business users an interface to modify rules and test the results – in many cases it is just the parameter values that have to be changed, so why involve expensive IT staff? • Control update: allow for timely changes to IT systems o Provide a configuration management / release management environment to migrate changes into production systems • Allow more complex processes to be automated: allow planning, scheduling, best-choice decisions to be made Rules languages include “natural language” recognition. These do not obviate the IT disciplines of verification, validation, testing, configuration management etc. One customer actually used a rules system to generate the test cases for each release of a system. Another customer complained that the rules engine was giving incorrect results – but on closer investigation, it turned out that their test suite had 10% errors in it. Ontologies are beginning to gain significance in business as a way of controlling the quality of rules. Rules are expressed in some vocabulary and it is therefore clearly important to start from a stable underlying model of data (or the world). The AI aspects of rules, which are the domain from which rules engines sprang, are a very small proportion of the application of rules today, but nevertheless quite important, as these tend to be high-value. This is referred to by the “complex processes” bullet. A cable operator had formalised the constraints around contracts with advertisers (e.g. spots
  5. 5. in three league games per week) to optimise the broadcast schedules. Some heavyweight rules experts were needed to boil these down into about 100 production rules that save weeks of work every time they are run. 5 Rules Engines vs. Rules Management 5.1 Rule-based programming tools Rule engines are specialised components for executing declarative rules. 1970s: expert system shells – typically goal-driven AI languages: LISP, PROLOG 1980s: AI/KBS development tools – e.g. ART, KEE 1990s: OO rule engines – e.g. Nexpert Object 2000s: Semantic Web and Ontologies Component-based rule engines, e.g. Blaze Advisor, JESS, ILOG JRules, Aion… In the research arena, large projects like RuleML are still going on. 5.2 How are Rule Engines evolving? Types: • Declarative (more expressive) vs. Sequential (higher performance) • Forward and backward chaining; event-driven reasoning • Multiple rule-types used together Platforms: • Java vs. .NET vs C/C++/COBOL… • Embedded device  PC  Web Services  Mainframe Rule and policy Abstractions: • Decision tables • Decision trees • Score cards / score models Examples include the generic decision component that Cisco has started to add to its routers and switches – these can be used to enforce service level agreements, firewall functionality etc. One customer has implemented a rules engine on a combine harvester. The Stealth Bomber has a sextant to help navigate even in the absence of GPS signals – there’s a rules engine to optimise its maintenance. Forward chaining, which is simply cause-and-effect, typically has higher performance than backward chaining, which is looking to satisfy a goal. In the real world, even for open-source rules engines, performance is
  6. 6. no longer a big issue (unlike five years ago). The Blaze rules engine (available for .NET and Java – it can even generate COBOL) is embedded in Fair Isaac’s financial services applications – e.g. 75% of European credit institutions use it to detect possible fraud. The data orchestration is the main bottleneck to performance, particularly in these days when it tends to get expressed in XML. There is a “Miss Manners” benchmark and a WALTS (sp?) benchmark if you’re really interested. The general advice is to benchmark your rules engine on your rules, ignoring standard benchmarks. Further trends: • High scalability and performance • Rule expressiveness for business users • Multiple data interface capability o 3GL (Java bean) support o Database / SQL support o XML support o Messaging / middleware support (CORBA, J2EE) • Standards support o OMG Business Rules Working Group since 2002 (now Business Enterprise Integration Task Force)  Semantics for Busines Vocabulary and Rules for formal business statement expression  Production Rule Representation (mid 2006) for real- time interchange across software models (if… then…) – this allows rules to be stored as part of SLAs, contracts etc. o W3C Rule Interchange Format working group since late 2005 o RuleML standards body often associated with W3C  Unfortunately based on PROLOG ideas, which express both data and rules in clauses o JSR-194 Rule Engine Invocation standard  Likely to be extended with PRR to represent rules in Java applications 6 Rules Management and IT Rule engines only provide an alternative mechanism for implementation of behavioral rules in software. The main benefit of using a rules engine is the associated rule management process.
  7. 7. • Represent rules in natural language • Rule reporting, verification, validation • Rule metadata, versioning, organisation by business function This is where most of the vendors are expending their research dollars. 6.1 How does it all fit into applications? Rule management software provides: • Rule authoring • Rule repository • Rule execution service It has a Business interface for rule engineering and management, and a Service interface for applications to use. The Rule Store incorporates persistence, versioning and security. This is more of an opportunity for IT staff than a threat. At egg, for example, the business analysts have a rule engineering environment that allows them to create and test rules and then deploy them when the tests have passed. The rule engine has not been touched or upgraded in three years, even though the business logic changes on a cycle of just weeks. The customer-facing web servers have fallen over a few times, so has the application server, but the rule server has just kept going. 6.2 Software Best Practices vs. Rule Management Software best practices are defined by RUP as: • Develop iteratively • Continuously verify quality • Control change • Manage requirements • Use component-based architectures • Visually model software How does rule management fit in? Each of the technologies discussed in this lecture series ties into that list. Iterative: declarative Continuous verification: independence Control changes: declarative Manage requirements: the business rules virtually are the requirements Component-based: rule engine Visually model: rule engines don’t really help, but visualisation tools are usually provided by vendors.
  8. 8. 7 Rules Management vs. Process Management From a vendor perspective, this is one of these perennial questions. What are the differences? Processes are higher level than rules. • Rules can be used to implement processes • Rules are exposed as services, while processes consume services See also the Business Motivation Model at There’s probably a whole management science behind this model: in how many organisations are strategic goals actually written down and communicated in a way that lets policy makers and rule builders implement them effectively? The Zachman framework also helps (as a reference) to understand the answer to these questions. BPM is very poorly defined – can be used to stand for different acronyms and even then different vendors / practitioners define them differently! • Business process modelling (and simulation) • Business process orchestration and flows • Business process automation and workflow (manual) • Business performance monitoring  • Focus on process definition and execution aspects Much the same can be said about BRM. It’s much less common to find BRM solutions that don’t execute the rules (though they can be found). The BPM solutions all have to cope with both automated and manual processes, so non-execution solutions are more common. Process flows can be simplified by abstracting out the decision logic into rule sets. Conversely, business rules can invoke business processes as services, either to return a result needed to take a decision or because the rules say that some process has to be run if certain conditions exist. 7.1 Summary Business rules, rule engines and rules management: • Provide a good fit with SOA and BPM • Good fit with IT • Plenty of tool support – open source to full house • Increasing interest from the Big 3 – IBM, Microsoft, Oracle
  9. 9. 7.2 References See the presentation slides on the BCS SPA web site – • deals mainly with text-rules, non-automated • Ron Ross and Barbara van Harle (sp?) are the leading authors • Eurobizrules conference in London in June 2006 A BCS specialist group may be established specifically for business rules. Please drop Paul a line if this interests you. [Ends]