Key Learnings - Using EDA to implement the core SOA principle of "loose-coupling"!!!

A lot has been said about how SOA and EDA are unique "architecture styles". It seems like only one or the other architectural principle is considered in proposing architectural solutions. However, there is a distinct benefit to using both paradigms in unison in solving business problems!!


Business events are the "core concept" that drive any EDA implementation. On the other hand, decoupling business applications and the business functions/ business processes embedded in these business applications is the core theme of SOA. SOA implementations rely on the use of standards based web services technology stack and that of canonical business documents (XML) .

However, it is my contention that an enterprise that does not invest in the web services or ESB technology can still leverage EDA style business events to implement loosely coupled business services provided it makes an effort to analyze its' business events and creates canonical representations of these key business events. This could mean defining business events that encapsulate a business concept that have an associated business concept state indicator or a business action indicator. Further, these business events can be used to trigger constructs such as event handlers that act as a facade or layer of indirection to execute a business function via the use of an application API.

It must be noted that the terms event producers and event consumers or publishers/ subscribers are being used loosely to denote the initiator of the event and the owner of the business behavior that "knows" how to deal with the event. In a SOA realm this would be the service consumer and the service provider respectively.

The key to this model in leveraging SOA is the use of self-describing canonical business events that are subscribed to by independent event listeners. These event listeners and/or event handlers that are delegated to by these event listeners help insulate the event producers and event consumers from the complexity of knowing how to interpret the events. Here the event producers/ publishers and event consumers/ subscribers are decoupled from one another via the use of canonical business events as well as messaging technologies.

Either of the two layers i.e. the event publisher or event subscribers can be altered long as the contract is adhered to in terms of the canonical business events. Also, messaging technology oriented configuration consoles allow the definition of the event publisher/ subscribers to be connected via metadata as opposed to hard-wiring these in code. Event handlers act as event adapters in that these could translate the event and invoke the required API call to deal with the event. The event handlers act as a business facade that hide the workings of the business application and allows the business application to change without affecting the event producers.

To recap, if loose-coupling is a core SOA principle that promotes business agility then the use of event handlers invoked using messaging technology and canonical business events can be used to deliver this goal. The enterprise does not need to invest in a SOAP stack right away to achieve this goal. If desired technology standardization and interoperability can be introduced at a later phase by turning these event handlers into web services. This two phased approach defined above enables the enterprise in pushing off investment in the technology stack to a future phase without sacrificing business agility and/or offering novel business capabilities.

 
Please feel free to drop me a note.
thanks.
surekha -

Business Event Subscriber Responsibility?

Thought I would write a comment about what are some of the expectations of a business event subscriber.  These would be rules that the business event publisher could depend on.  These sets of rules form the basis for Event Driven Architecture (EDA) based implementations.

Subscribers of business events and business alert notifications often assume that the business event publisher is responsible for insuring that duplicate events and any repeat alert notifications are suppressed. However, to protect itself the subscriber has to be able to "analyze" the business event to determine if the erroneous event/ alert was sent by the business event provider, messaging architecture or the enterprise service gateway. The subscriber (business application, business process) would have to "know" when to discard the business event as being a duplicate event, as well as when to re-apply the same business event, which could have been issued as a result of change in the business policy or due to an increase in the business alert thresholds.  Knowing when an event transmission is real versus a false notification insures that the outcome of the EDA implementations are valid.

For instance, if a "low inventory alert" is received by the Purchasing Process it may react to this alert notification by transmitting a PO to the supplier. However, if the same Purchasing Process gets a second alert a few seconds or a few minutes later chances are the Purchasing Process may choose to ignore this. Not examining the alert more closely may cause it to erroneously discard the alert.  It is possible that in order to optimize and tune the response processing the subscription process just looks at the product and quantity to de-dup alerts received within a certain period thus causing the second alert to be discarded. The business impact of ignoring the second alert was failure to increase in the "minimum product level". The bottom line, the subscribing process has to know how to differentiate between fundamental business rule changes and duplicate alerts and not have a compute process optimization overrule business policies.

In general, in an event driven architecture realm the disconnectedness of the publisher/ subscriber pair places a burden on both parties to insure that there exists a mechanism and rules to enable "semantic" translation of the message payload that carries the business event or the business alert.  Without investing in the definition and analysis of these semantics benefits of the loose coupling EDA architecture would deliver a scalable technical architecture model but would not yield the right business outcome.

It must be noted that standards such as WS Eventing, WS Base Notificaitons and WS Notification help to define WSDL and XML Schemas for defining the mechanics of loosely coupled and inter-operable EDA implementations but the business semantics and rules in constructing and consuming the events are not really well laid out.  Not having had exposure to specifications such as ebXml and OAGIS business documents I assume some of the B2B interactions may have more mature semantic definition but for the most part I think these rules of engagement may still need to be fleshed out by the participating parties.

Thoughts and feedback on this topic would be very useful.
surekha -

Role of Events in taking Proactive Action

In exploring the role of events is it possible to achieve predictive analysis to provide rapid response and take proactive action?

One possibility is by tracking how humans handle event exceptions and locking their processing logic and turning this into business logic. This allows one to perform event correlations and to automate exception handling. Here event handling can take the form of rapid response or proactive action. Further, analysis of precursor events (i.e. events that occurred just prior to the exception) could lead to predictive alerts to be raised to circumvent exception situations and thus enable proactive actions to be taken.

If sensors and RF ID technology are the first steps to event capturing and event processing then addition of event analysis and event composition (Complex Event Processing style) is the next step in the evolution with exception based learning and proactive action based event emission may be considered a more advanced step in the process of EDA.

Many transportation companies and carriers and just in time supply chain providers could adopt EDA for rapid response or even proactive action. For example, combining weather based events, traffic flow patterns etc can be used to insure quality of the goods being transported to minimize wastage in transport. Furthermore, containers that transport organic food that does not use preservatives could use special types of "sensors" that detect the emission of gases and chemicals within the shipping container chambers to assess the freshness and the ripeness of the produce. If these events indicate rapid ripening proactive action based events can be sent to these shipping containers to lower temperature etc. to retain the freshness of the produce for transportation with minimum damage. (This example is only illustrative as I am not a expert on this subject.)

It must be noted that traffic and weather based events are combined with information about product preservation rules, correlated and processed to preserve sensitive consumer products to safely and preserve the high quality after this type of behavior has been observed in the human actor and this exception processing logic has been codified for future automation. EDA in this case is utilized for the purpose of tracking human exception processing and then automating this behavior albeit all the while depending on incoming current state events and outgoing proactive actionable events.

It seems very much a plausible use of EDA and so I am curious how many of you are using EDA for solving similar use cases.

As always your input is very valuable.
surekha -

Key Lessons – The new and improved Enterprise Architecture Group

When invited to start the Enterprise Architecture Group a couple years ago my only thoughts were how to technologically implement SOA and EDA as the core architectural principles. However, soon enough came the realization that without having access to those who had sound business knowledge and those that knew the core business domains, value streams and the strategic business capabilities it would not be possible to effectively deliver SOA or EDA.


Service orientation of business behavior encapsulated in business applications and the definition of business events that initiate key business processes both require enterprise-wide understanding of business behaviors and business activities. Furthermore, the ability for identifying business services and/or business events comes from being able to abstract business needs that cross business domain boundaries. These skills can be found in a group of individuals being called business architects – a unique group of individuals who can translate the strategic business needs into an action plans that show how to enhance current business processes that support core value streams.


This led me to find resources that could analyze business processes (a.k.a. Process Architecture discipline) and resources that could analyze business information-flow, the value-addition pathways (where by business information is enhanced as it is exchanged across multiple business domains) (a.k.a. Information Architecture discipline). Both sets of these resources have allowed me to embark on true SOA style service definition. So the “new and improved” Enterprise Architecture Group has Process Architecture, Information Architecture (or what the industry calls Business Architecture) and Technical Architecture representatives.


Finally a note about the Technical Architects; my opinion is that, standards are vital but then if the Enterprise Architecture Group is unable to demonstrate the right use of standards in a true production environment this group will be left with very little credibility or be deemed the “ivory tower” group.


Having a cross-functional group of resources has made the Enterprise Architecture Group to be a well rounded group. The Business Architects of the group are in dialogue with the business as they can speak to the business in its lingo while the Technical Architects of the group are able to work with the developers as they are able to demonstrate the use of technology for building and delivering stable, performant and reusable services. The end result is that the individuals of Enterprise Architecture Group are openly invited to the table for consultations and recommendations.


I would love to hear of other organizational patterns/ formats that have enabled implementation of SOA and EDA.

Thanks.
surekha -

Integration Tomorrow, Part 2: SOA Architecture

Part 1 of the two-part series described the past and current integration approaches. This second part, takes a practical approach on how technology is going to change business landscape and the potential infrastructure changes required to integrate the business both at business and IT levels.



Read more about this here.