Chris Bird evoked a memory of the late 1980’s technology advances in the context of modern-day SOA. The introduction of database triggers by Sybase (!) helped extend the relevance of the DBMS substantially beyond its roots as the data platform. Triggers were a big deal, giving rise to a whole new development model, which, perhaps for the first time, put together loose coupling, context isolation and inversion of control.
Triggers are certainly an example of event-driven design, which has its place in service orientation (see below). However, as with all analogies, there is a point at which the two situations diverge. Triggers respond to database changes resulting from business transactions, whereas applications emitting an event offer explicit extension points for spawning new business processes and performing additional follow-on activities. The key distinctions are that triggers are sensors in the technology domain of EA, where the effects of business transaction processing are persisted. The top-down event-oriented design would provide explicit events in the business domain independent of how or where they are processed.
Triggers can be tremendously useful for extending, customizing and integrating legacy systems, often far beyond initial expectation or design. No doubt, the modern technology frameworks can benefit from this approach for the same reasons. In fact, ESBs can evaluate rules on message content, thus detecting events in the observable message flows. That bakes application (service) extensibility into the platform, so we can augment the business logic without having to redesign or re-architect our systems. No, it’s not always pretty, but sounds familiar.
SOA can leverage these technology options — DBMS triggers or ESB content rules — in the detection of events. Pub/sub middleware and service platforms can be similarly seen as enabling technologies for event-driven SOA. However comparing EDA to them is like comparing SOA to Web services. And as long as events are cast as a technology solution, they will continue to be overlooked as an EA concept.
This is unfortunate, because events can powerfully transform EA. Much like SOA, event-driven architecture style enables further enterprise decentralization, supporting business agility and distributed innovation. But it does so in a way which makes EDA uniquely different: by doing away with explicit orchestration. Without an assumption that somebody has to have complete knowledge of how any particular situation must be handled, delegation expands into areas never before possible. Not only what happens is delegated, but also the rationale for making it happen and by whom — what their role is or how many of them there are. Of course, the more there is to know, the less it is understood, which is why separation of concerns is such a sorely missed feature of SOA.
EDA certainly makes up for that. Indeed, it is perhaps more appropriate to speak of EDA’s coupling style as nonexistent at all rather than being loose. What EDA has instead is nothing but extensibility. You can plug in any number of extensions into each extension point provided; event source has no awareness of coupling whatsoever. It is this inherent extensibility and elimination of design-time coupling that enables the resulting architecture to embrace architectural change without loss of interoperability. If there ever was a way to future-proof an architecture, EDA is it.
Of course, there are challenges and drawbacks in any design style — otherwise there would be no other. Stay tuned for some thoughts on EDA’s (hint: if fruits of EDA are at the same level as SOA’s, might the challenges be similar too?).
Recent Comments