Confusion about Services Based Architectures [SBA, SOA, EDA, ...] has been created by a number of industry elements. Industry critics like Forrester first used the term Services Based Architecture until 2000 when Gartner came up with their own term Services Oriented Architectures (SOA). Forrester was still using the term SBA in 2002. Gartner next created the term Event Driven Architecture and has now come full circle back to SOA 2.0 (supporting both SOA and EDA like the original SBA).
What they’ve learned is that for every new ETL script, there are probably 20 other systems that have to custom developed their own data retrieval code and never documented it.
The main characteristic to be aware of in these tools is that BE is primarily rule-based (using an embedded rule engine), whereas BW and iProcess are orchestration / flow engines. In BE we can use a state diagram to indicate a sequence of states which may define what process / rules apply, but this is really just another way of specifying a particular type of rules (i.e. state transition rules).
The main advantages to specifying behavior as declarative rules are:
Handling complex, event-driven behavior and choreography
Iterative development, rule-by-rule
The main advantages of flow diagrams and BPMN-type models are:
Ease of understanding (especially for simpler process routes)
Process paths are pre-determined and therefore deemed guaranteeable.
In combination these tools provide many of the IT capabilities required in an organization. For example, a business automation task uses BW to consolidate information from multiple existing sources, with human business processes for tasks such as process exceptions managed by iProcess. BE is used to consolidate (complex) events from systems to provide business information, or feed into or drive both BW and iProcess, and also monitors end-to-end system and case performance.
As IBM absorbs ILOG it will be important that it continue to invest is this multi-platform approach. Not only are there some nice features in the .Net product (that I for one would like to see available to the Java product) but decision management with business rules is, for most companies, a multi-platform problem. The value of using business rules to decision management comes in part from making sure the same rules are used everywhere they are supposed to be used. While deploying business rules in Decision Services on SOA makes this easier, the best solution is to allow the rules to be packaged up and deployed as Java components, Web Services, .Net assemblies or COBOL code so that they can run natively on all the platforms that run the business.
J. Schiefer, S. Rozsnyai, C. Rauscher, and G. Saurer. DEBS '07: Proceedings of the 2007 inaugural international conference on Distributed event-based systems, page 198--205. New York, NY, USA, ACM, (2007)