Bill H's Library tagged EA →  View Popular

How do the emergence of service orientation and the maturing of
layered application architectures change the dynamics of buy vs. build decisions for enterprise applications?

• Traditional technical domain and component models must be augmented with
  more applied end-to-end models (technical patterns) and shared-infrastructure
  models (technical services) as key planning concepts.

IBM Buys Wisely. IBM's planned acquisition of Ilog will fill
a serious gap in native WebSphere business rule-processing functionality,
especially as IBM seeks to dominate the business process management suite (BPMS)
market, and show leadership in complex event processing (CEP) and
service-oriented architecture (SOA). While IBM partners with Fair Isaac,
Corticon Techologies and Ilog — for example, Ilog provides visualization
capabilities for WebSphere Business Events and is a common partner with IBM's
FileNet — IBM's lack of direct ownership of quality rule-processing technology
limits its reach, vision and credibility when compared to BPMS vendors such as
Pegasystems. With Ilog, IBM will gain a premier BRMS. In addition, IBM is
expected to leverage Ilog's presence in optimization and visualization —
emerging topics that are relevant to BPMS and business activity monitoring/CEP
opportunities.

Key Findings



• One of the major benefits of a BRMS is that it can identify the
  relationships among rules, expose inconsistencies and make it easier for users
  to resolve those inconsistencies.
  
• BRMS and CEP engines can be used to support human decision making or to
  compute fully automated decisions.
  
• Rule engines in BRMSs are typically request-driven, while CEP engines are
  typically event-driven. This largely determines the technical architecture of
  each product type.
  
• There is nothing to prevent a vendor from creating a single product that is
  good at both kinds of rule processing, but the algorithms and technical
  architectures used for each would need to be different.

Recommendations



• Use a BRMS or CEP system to externalize business rules in applications in
  which the rules change frequently or can be shared among multiple applications.
  
• Use a BRMS for operational applications in which complex business decisions
  are made for transactions that can be processed individually.
  
• Use a CEP system for calculations that involve time windows, patterns or
  aggregate results (such as totals and averages) on a large set of event data
  considered together.

Key Findings



• Decision tables and decision trees are popular, user-friendly formats for
  business rule representation.
  
• Standards for business rule management are not well-embraced. Expect
  differences in how vendors implement their business rule representation
  approaches.
  
• Pure natural language is not ready for the BRM market, so enterprises should
  not consider it as a solution to their business rule needs.

Recommendations



• Select your business rule representation approaches based on your own
  understanding of the trade-off between complexity (what you put into the effort)
  and linguistic power (what you will get out).
  
• Consider simpler approaches when your users are nontechnical, business
  process owners who prize simplicity and clarity over power.
  
• Consider structured languages for IT-savvy users who are familiar with
  programming languages and concepts and who want more linguistic power in their
  business rule implementations.
  
• Consider constrained natural languages (limited syntax, vocabulary and so
  on) when syntactic variation, flexible levels of textual interaction (for
  example, querying in natural language), and other "it must read like English,
  French or German" requirements are in place.
  
• Although the benefits are substantial, investments in an ontology and/or a
  taxonomy are not required for every BRM effort.

Key Findings



• For processes with low volatility and a strong core stream with few possible
  paths, then most activity should be folded into the process itself, including
  rules.
  
• For processes with high volatility and with many exceptions, there should be
  a focus on having most activity based on explicit rules.
  
• Most processes have a mix of strong core process paths and evolving
  exceptions, so understanding the process/rule continuum will enlighten process
  designs. There are a good number of options that leverage the best of both.
  

Recommendations



• Organizations should perform a volatility analysis on rules and flows to
  determine the agility needs of the eventual process.
  
• Organizations are encouraged to project agility needs over the long term by
  considering likely business scenarios.
  
• Organizations with strong planning cultures and/or with higher-risk
  situations should plan for greater volatility that will need to be managed and
  linked to planned business scenarios. In this case, organizations are likely to
  plan for outlier scenarios.
  
• Organizations that have a higher component of rules in and around their
  processes are encouraged to practice business rule management.
  
• Organizations should expect to blend rules and processes, and that means
  blending rule technology (for example, business rule management system [BRMS]
  and business rule engine [BRE]) and process technology (for example, business
  process management systems [BPMSs]).