Business Rules Forum 2006 : Mission Critical BRMS2. Agenda
About Me
Why “Mission Critical”?
People and Processes (Governance)
Architecture and Deployment
Service Oriented Architecture
Configuration Management
Full Lifecycle Support
Unit and Regression Testing
Security
Performance
Scalability
High Availability
Administration
Conclusions
Q&A
© ILOG, All rights reserved 2
3. About Me: Daniel Selman
Product Manager, ILOG
JRules 4.6 onward, specialized in performance, enterprise
integration and developer requirements
Architect, BEA Systems, WebLogic Portal
Rule engine for personalization/security
Data Synchronization for SOA
Product Catalog
Specification Lead, JSR-94
Editor http://javarules.org
Author “Java 3D Programming”
© ILOG, All rights reserved 3
4. Why “Mission Critical”?
Mission critical applications are:
On the critical path for processing everyday business transactions
Decisions (execution results) are time critical
Failures in mission critical applications incur heavy financial costs, or
erode business reputation.
ILOG examples (some…)
Equifax (credit scoring/decision making)
eBay (customer satisfaction)
Travelocity (travel planning)
St. Paul Travelers Insurance (automated underwriting)
JP Morgan Chase (CRM, processing 70M accounts)
Brokerage (automated trading system)
Credit card company (fees calculation, message routing)
Car rental company (pricing)
© ILOG, All rights reserved 4
14. People and Processes
Servers,
routers,
networks, Reporting,
routing… statistics,
data
S
Code analysis
Administration
coverage,
Scripting,
Java, C#,
M
Simulation / BI Regression
Data
Testing
structures,
Testing Algorithms,
R
Integration
Development
B
Standards,
Processes,
Architecture
IT portfolio
Requirements
Analysis elucidation,
Impact
assessment,
Requirements Strategy, Modeling
Competition,
Business impact Application Lifecycle
© ILOG, All rights reserved 14
15. Architecture and Deployment
The “Architect Knows Best” Principle
Don’t impose design decisions on a context you don’t
fully understand. All customers are different.
Examples
Calling rule engine from: JSP, Cold Fusion, Message
Oriented Middleware, Batch application, J2EE
middleware, ESB, SAP, BPM, SOA, mainframe etc.
Requirements:
A range of integration options to cover many
scenarios (WS, stateful, stateless, sync, async, tx…)
© ILOG, All rights reserved 15
16. Integration into Enterprise Architecture
Best of breed BPM/SOA solutions involves partnership
ILOG allows BRMS Decision Services to be easily integrated with the
leading BPM and SOA platforms.
© ILOG, All rights reserved 16
17. Configuration Management
Of software
Automate building testable software from source code
Of systems
Setup and tear-down servers as efficiently as possible
Requirements:
Integrate rules artifacts into configuration management
repository
Automate extracting rules from rule repository and deploy
Easily replicate configuration data from development servers to
staging or production servers
© ILOG, All rights reserved 17
18. Full Lifecycle Support
Version 1.0 of app in production
Policy Managers editing rules
Version 1.5 of app in development
Developers building new integration capabilities
Analysts defining new business object models
Developers/analysts refactoring rules
Requirements
Synchronization of rule repositories
Object Model Evolution (BOM, XOM, B2X)
© ILOG, All rights reserved 18
19. Unit and Regression Testing
Continuous Integration
Integrate software modules early, often and
continuously
Includes business rules
Requirements:
Automate running tests on code or rules
Unit tests written by developers (code) or policy managers
(rules)
Regression tests written by QA (code) or policy
managers/QA (rules)
© ILOG, All rights reserved 19
21. Security
Authentication
Who are you?
Authorization
Are you allowed to do that?
Requirements:
BRMS integration with enterprise user registry (LDAP etc)
Fine-grained permissions to protect access to business rules
resources (Access Control Language)
| NOUN | VERB | PERMISSION |
| DECISION TABLE | EDIT | PolicyManagers |
Follow Enterprise “best practices” (SSL, password management
etc)
© ILOG, All rights reserved 21
23. Performance
Is a constraint…
Is it “good enough”?
Involves difficult trade-offs (time, money, hardware,
maintainability, future-proofing, scalability, testability…)
Recasting a “slow” problem can often provide a “fast”
solution
Requirements:
Understand your performance profile (bottlenecks)
A “fast” rule engine offering a variety of optimizations and
algorithms (e.g RetePlus, Fastpath, Sequential)
Multi-threaded (concurrent) performance
A “productive” rule management environment for your target
number of rules
© ILOG, All rights reserved 23
24. Performance of Compliance Rules
250
Processing 10,000 objects 200
Single-threaded
Seconds
150
Dell D600 1.7 Ghz
100
Linux
Sun JDK 5 50
0
5,000 10,000 15,000 20,000
rules rules rules rules
Java code Sequential Fastpath
© ILOG, All rights reserved 24
25. Scalability
Can you “throw hardware at the problem”?
Does doubling system capacity double throughput?
Usually the answer is no, because most real-world
performance profiles are not that simple
Requirements:
Support for applications virtualized across multiple
servers (clustering)
Clustered hot deployment
BRMS designed for multi-threaded, highly concurrent
access
© ILOG, All rights reserved 25
27. High Availability
Avoid a single point of failure:
Support for clustering and state replication
Deployment of BRE/BRMS to two or more
geographically distributed data centers
Requirements:
Server configuration replication
Easy deployment of rules to multiple data centers
Automatic fail-over of execution components
Minimize per-server impact of hot-deployment
© ILOG, All rights reserved 27
28. Administration
Applications are typically developed in months, but run
for years
Administration tools are a great way to increase ROI
Requirements:
What rules are deployed?
Monitor execution performance (on each machine)
Support for rolling back deployments
Integration with management consoles (Tivol/OpenView)
Define QoS alerts
© ILOG, All rights reserved 28
30. Conclusions
Mission critical applications bring a tough set of
challenges to the table.
Building robust systems requires thinking transversally:
across the IT infrastructure, the development process,
roles and responsibilities.
The BRMS (both rule authoring and rule execution)
must provide the tools, processes and integration
capabilities to meet these challenges.
Try not to forget the simple cases!
© ILOG, All rights reserved 30
31. For additional information
Daniel Selman
Product Manager, ILOG
e-mail: dselman@ilog.fr
web: http://www.ilog.com
Whitepaper: Deploying Rule Application with ILOG JRules:
http://www.ilog.com/products/jrules/whitepapers/
© ILOG, All rights reserved 31