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.
The success of Service-Oriented Architecture (SOA) has created the foundation for information
and service sharing across application and organizational boundaries. Through the use of SOA,
organizations are demanding solutions that provide vast scalability, increased reusability of
business services, and greater efficiency of computing resources. More importantly,
organizations need agile architectures that can adapt to rapidly changing business requirements
without the long development cycles that are typically associated with these efforts. Event-Driven
Architecture (EDA) has emerged to provide more sophisticated capabilities that address these
dynamic environments. EDA enables business agility by empowering software engineers with
complex processing techniques to develop substantial functionality in days or weeks rather than
months or years. As a result, EDA is positioned to enhance the business value of SOA.
The purpose of this white paper is to describe the approach employed to overcome the significant
technical challenges required to design a dynamic grid computing architecture for a US
government program. The program required optimization of the overall business process while
maximizing scalability to support dramatic increases in throughput. To realize this goal, an
architecture was developed to support the dynamic placement and removal of business services
across the enterprise.
Service-oriented architecture has proven to be a boon in the computing world. At its core, SOA provides enterprise patterns for systems development and integration where legacy systems are viewed as discrete business capabilities and packaged as standards-based services interfaces. SOA also typically describes an IT infrastructure that allows different applications to exchange data with one another as they participate within business processes. Over the past few years, SOA has grown almost exponentially in popularity, becoming one way for companies to knit together applications and processes in a flexible, reusable and cost-effective way. SOA separates functions into distinct units, or services, which developers make accessible to users over a network, ideally allowing them to combine and reuse them in the creation of business applications. These services communicate with each other by passing data from one service to another or by coordinating an activity between two or more services.
TOGAF 9 encompasses the entire enterprise architecture life cycle, which is important as architecture is a never ending journey, always changing and evolving. The figure below depicts the TOGAF Architecture Development Method (ADM) which covers the entire architecture life cycle.
For those unfamiliar with business-driven architecture, I believe the most viable, agile architectures will be comprised of a blend of architecture strategies, including (but not limited to) service-oriented architecture, event-driven architecture, process-based architecture, federated information, enterprise integration and open source adoption.
This is EDA! Model your business events right and have their software representations travel in real-time through a global (enterprise wide) data space (call it an ESB), then you are offering your business huge opportunities. Think of connecting your global data space with those controlled by other enterprises: your fantasy is the limit.
EDA is more a manifestation of finite state machines going all the way back to Alan Turing. Old_State + Event = Some_Action + New_State. It is the simplest, yet most powerful way to design robust systems. I only wish more people would give it due consideration.
A very old implementation example is I/O interrupts (hardware events) for asynchronous I/O - real time event handling which enabled multitasking operating systems.
Many want to use web services for everything now and at times it is hard to convince people that other messaging schemes and standards are a better fit for some problems.
Business Process Management (BPM) und Business Rules Management (BRM) zusammen in einer service-orientierten Architektur (SOA) sind die methodischen und technischen Voraussetzungen, um Geschäftsprozesse zu industrialisieren und agil zu sein. BPM schafft die Automatisierung und Standardisierung von Geschäftsprozessen, BRM die Standardisierung und Transparenz von Management-Politiken und -Prinzipien. Und eine SOA bringt die Service-Orientierung, die uns erlaubt zwischen spezifischen Logiken einzelner Prozesse und prozessübergreifenden Logiken gebündelter Kompetenzen und Dienstleistungen sauber zu trennen. Das schafft Agilität zusammen mit Industrialisierung.
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)