Event-driven architecture as the latest buzzword in the enterprise architecture space.
If you’ve been reading the trade press lately, you no doubt have come across the term event-driven architecture as the latest buzzword in the enterprise architecture space.
So you dig about to find out just what is this event-driven architecture. And if you dig around a bit, you’ll find that event-driven architecture (EDA) is an application architecture style that is defined primarily by the interchange of real-time or near-real-time messages or events.
Astute readers of this web site, our white papers, attendees at our seminars, and of course our clients, recognize that this is exactly what we have been espousing for years as to what a good service oriented architecture looks like. You may recall our Enterprise Message Modeling architecture that prominently featured publishing. Event analysis was to define key messages being sent from application to application. You may recall our many exhortations to use “publish and subscribe” approaches for message dispatch whenever possible. You may recall us relying on events to populate managed replicated stores for just this purpose.
So, you might ask, why does the industry need a new acronym to do what it should have been doing all along?
First, a bit of history. In the 1960s MRP (Material Requirements Planning) was born. To the best of my knowledge, the first commercial implementation was at the GE Sylvania television plant. The system started from the relatively simple idea that a complex Bill of Material could be exploded and time phased to create a set of requisitions for either inventory parts or purchased parts. But these early systems went considerably beyond that and “closed the loop,” checking inventory, lead times, etc. After the successes of these early systems, a number of packaged software vendors began offering MRP software. However, to meet the common denominator and make the product as simple as possible, these products very often did not “close the loop;” they did not factor in changes in demand to already existing schedules, etc. Then a mini-industry, APICS, the American Production Inventory Control Society, sprang up to help practitioners deal with these systems. What they soon proposed was that these MRP systems needed to be “closed loop.” Sure enough, a few vendors did produce “closed loop” systems. This created a marketing problem. The response was MRPII and a change in the acronym; it now stood for Manufacturing Resource Planning.
“MRPII is what everyone needs.” And most of the education and marketing was about the shortcomings of the earlier MRP systems. Of course, the earlier MRP systems were, for the most part, just bad implementations, not something that was more primitive, in the way that we look at Paleolithic art.
And so it is with SOA. Apparently what has happened is that the Web services movement has become associated with service oriented architecture. However, most practitioners of Web services are comfortable using Web services as a simple replacement for the remote procedure call (RPC). As a result, many organizations are finding their good intentions of SOA being sucked down into a distributed request/reply environment, which is not satisfying the issues the architecture was meant to address. Nor is it delivering on the promises of the architecture: loose coupling, and the commoditization of shared services.
Perhaps it’s inevitable we’ll have to deal with new acronyms like EDA. But if you’ve been tuned in here for a while, think of EDA as SOA done right.
