SOA and Events - Two Sides of BAM?

I came across a prospect recently (new markets so engineering help is always welcomed :-) ) - a domain consulting company now building a Governance Risk and Compliance (GRC) solution. Now, this very much being in the area of BAM, one would expect that traditional Business Activity Monitoring (BAM) would be used. But as we were discussing it more, it turns out that more often than not, GRC is about triggering the risk assessment and compliance/governance checks as business events occur. Here again, the trite assumption (that even I made) is that the organization has SOA imbibed all over and so it can easily tie in BAM and use that BAM environment to 'detect' and trigger the necessary checks/rules. And here again, I was proven wrong because SOA is not as widely prevalent as we all would like to believe! The consulting company, a group with a strong domain expertise in Governance & Risk/Performance, who is building the solution said they wanted an "extremely loose" integration, but their prospects were unlikely to have a mature SOA infrastructure. Which means, they cannot really expect BAM to be practical.

After looking at the biz analysis they had already performed, and taking the time to breakdown the GRC system into a bunch of flow-charts (one for each scenario), they found a 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 biz domain (they were targeting a specific sector in the financial space) - in a very interesting manner. As a set of key business events, anyone in the domain can immediately understand what each of these events mean. Each business event includes a clear definition of the accompanying data. In effect, they flipped the complete domain business ops as a set of business events! Hmmm...

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 biz events is very unique. The former is a view of defining the business flows (processes) that form the enterprise's biz 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.

From this consulting company's point of view, modeling the enterprise as a set of business events and the data that each event emanates was a more practical view. The communication to their clients was that they have modeled the GRC flow for each of these biz events. And the integration of the GRC solution involved the client's IT team "wiring" in these events into their existing solutions - wherever the said business activity occurs, and in any technology they may have, SOA or no SOA.  When they wire this, they will also need to pull out the data from their existing systems and "emit" the same as per the defined event data structure.

Pretty neat idea! Is anyone else seeing it this way? Is a GRC solution more about events and less about SOA? Is SOA primary and events incidental, or are events primary and the SOA infrastructure that could generate this be incidental?

Comments

[Gavin Terrill]

One result of using events is that conformance checking happens a-priori. Ideally though, you would want to prevent the action from happening *before* a control is invalidated. Nonetheless, the ability to have better visibility into how your business processes are actually being performed is indeed an improvement.

> Is anyone else seeing it this way?
We have been experimenting with this using CEP combined with a rules engine: http://www.bpsinc.com/2009/01/the-ultimate-orm-platform-enterprise-edition/

Also, this paper looks at using events to check for process conformance (in this case via event logs): http://sites.computer.org/debull/A08Sept/aalst.pdf

[Eric Wayne]

Ramesh, interesting read. Could you elaborate on your view that SOA must be a pre-requisite for BAM? I agree that implementing BAM can be easier if you have established a set of services with well defined event formats and interfaces to be invoked when problems are detected. But most BAM software provides "on-ramps" for events from various forms of architecture (e.g., MQ, databases, native application adapters) and mechanisms to invoke applications in an existing solution.
Thanks.