Over the last year and a half, I have been following with interest the rise of user and vendor interest in EDAs (event-driven architectures). My own take on EDAs: there’s some real value-add there.
Now, from a database programmer’s point of view, business-event handling is older than dirt. The basics of events, triggers, business rules, and stored procedures were there in the 1970s if not before; and a network-management specialist would probably tell you the same about distributed monitoring and alerting. What’s new over the last few years is the idea of an SOA (service-oriented architecture) that spans an enterprise network using standardized software interfaces. The basis of a SOA is often an ESB, or enterprise service bus, that acts to route calls from Web service consumer code, such as a Web browser, to Web service provider code, such as an enterprise app. This means that the ESB can now see all the events already flying back and forth from systems management, database transactions, and specific apps for specific types of events (such as quant apps handling stock arbitraging in milliseconds), filter them, report them, and act on them. So an event processing engine over/in the ESB – the event-driven architecture -- is a great way to handle existing event processing (such as systems management) across the enterprise.
Moreover, such an EDA moves event processing out of hard-coded existing stored procedures and apps to the enterprise-network level, where the developer can write enterprise-spanning apps. Hence the ideas of “business activity monitoring” (figuring out what’s happening in the enterprise by monitoring events on the enterprise network), “the 360-degree view” (adding monitoring the enterprise’s environment via RSS feeds, Web searches, and the like), and “the just-in-time enterprise” (semi-automated rapid responses to business events). No wonder vendors ranging from IBM and Sun to Progress Software and users like Orbitz are talking about EDAs.
So the obvious question is, why aren’t folks talking about applying EDAs to SaaS (software as a service)? When I google EDA and SaaS, there is a mention or two of the notion of supplying a CEP (complex event processing) engine as a service, but nothing really on the idea of SaaS providers offering an EDA on top of their SOA for added user benefits.
And yet, if I were a SaaS user, I would find an EDA offered by my provider quite intriguing. I might do business activity monitoring on top of my ERP app, or react quickly to customer-relationship problems identified by SugarCRM. As a boutique investment firm, I’d love the chance to create arbitraging code at lower cost.
And if I were a SaaS provider, I’d be interested not only in attracting customers by offering an EDA interface, but also in using an EDA to fine-tune hard-coded security and administration software for each multi-tenancy user. In fact, I think EDA would give me a great new tool for metering and charging users on the basis of business transactions rather than per-CPU.
So why isn’t there more interest in EDAs applied to SaaS? Inquiring analysts want to know …