In his new post post Richard Veryard discusses relationships between SOA, BPM and events. Richard notes that:
From the early days of SOA, we've talked about understanding the enterprise as a network of services, but clearly this is not the only possible viewpoint. Can we understand the enterprise as a network of events?
His opinion is shared by Ramesh Loganathan, describing his resent prospect - a consulting company building a Governance Risk and Compliance (GRC) solution. Architecturally, the implementation is based on the following pattern:
- a business event occurs as part of ongoing business processing
- the event includes the relevant business data
- a series of GRC checks and rules are executed
- any violation is recorded and an alert raised
This consulting company has gone a step further and also modeled the whole business domain as a set of key business events, which are well understood by anyone in the domain. Each business event includes a clear definition of the accompanying data.
So far, we have seen models that show the enterprise as a bunch of business processes that invoke a set of services. With the above flipped view, the enterprise modeled as a bunch of business events... The former is a view of defining the business flows (processes) that form the enterprise's business processing. The latter view is more of a snapshot of the enterprise post the fact - as business events that "occur" in the enterprise. Both very clearly model the purpose and the data involved, but in the former method, it is the data that flows through. And with the latter approach, the data that gets "generated" post a business activity.
Commenting on Ramesh’s post, Richard notes:
At the strategic level, we need to understand the relationship between an external set of possible events and an internal set of possible events. Each enterprise is capable of responding in certain ways to certain classes of external events. Making an enterprise more agile means enabling the enterprise to mobilize more appropriate responses to a greater range of external events, without proliferation of unnecessary complexity. In system thinking this is called Requisite Variety.
So if we think about the enterprise as a network of events, this gives us a direct way to reason about strategic business improvement.
Such discussion is not new. For example, back in 2006, Jack van Hoof wrote:
...the synchronous command-and-control nature of SOA is a way of tightly coupling application components... SOA may be loosely coupled in the technical domain, where common web services technology is used, but it certainly is not in the functional domain where SOA is associated with ‘calling’ foreign (reusable) services and eliminating data redundancy... In contrast to SOA, EDA provides a way of loose coupling. EDA is not a synchronous command-and-control type of pattern, but just the contrary: an asynchronous publish-and-subscribe type of pattern. The publisher is completely unaware of the subscriber and vice versa; components are loosely coupled in the sense that they only share the semantics of the message.
For some reason people are still under the assumption that SOA/BPM and EDA are two contradictory approaches. To a large extent this misconception is caused by the traditional RPC structure of Web Services. As SOA implementations advanced and different message exchange patterns emerged, including one-way messaging, the differences between SOA and EDA started to blur. In the words of Bobby Wolf:
... either way, you're implementing services, it's just a matter of how the services get invoked. Do they get invoked in a rather direct SOA sort of fashion where the consumer invokes the provider directly? Or is it in a much more abstract and indirect sort of way where an event causes a handler to invoke the service?
Both events and business processes are essential parts of an enterprise business model. An optimal SOA implementation can be defined as a set of enterprise business processes orchestrating execution of services. These processes can be invoked either directly by other processes or in response to internal/external enterprise events. Processes also emit events, which can be used either for invocation of other enterprise processes or by business activity monitors to evaluate the effectiveness of enterprise functioning.