Business Rules Forum 2006 : Mission Critical BRMS

Mission Critical BRMS

Daniel Selman
dselman@ilog.fr

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

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” 


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)


Rules are Critical!


Building Mission Critical Applications!


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


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…)


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.


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


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)


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)


Rule Scenario Manager


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)


Team Server Security Model


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


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


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


Monitoring Clustered Rule Engines


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


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


Integration with JMX Tools


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!


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/


Questions


Business Rules Forum 2006 : Mission Critical BRMS

Recomendados

Recomendados

Más contenido relacionado

Más de Dan Selman

Más de Dan Selman (10)

Business Rules Forum 2006 : Mission Critical BRMS