Buzzwords demystification

Words like "SOA", "ESB", "EDA" are common and, unfortunately, extremely abused. In summary, below a one page description of the main buzzwords floating around.

Architectural Styles

SOA is an architectural style aimed to create a conceptual framework and a collection of practices to improve the alignment of IT to core business needs. SOA is not about technologies. At its core there is the concept of Service, which is an abstract interface to a concrete business function, for example: logistics management, HR & recruiting, stock control, order management, invoicing, ... A Service implementation is governed by a policy, exposes an end-point, implements a defined contract and sends / receives messages. A service is transactionally atomic by definition, otherwise it's a process, which actually is about atomic services orchestration, so a very different and higher-level concept than service itself.

ESB is an architectural style aimed to highly decouple clients form service implementations, by creating an uniquely identifiable space where service policies can be applied uniformly and managed consistently.

SOI Service Oriented Integration is an evolution of classical EAI concepts, introducing an higher level of decoupling among applications by connecting abstract interfaces defined by service contracts instead of mere point to point connectivity usually happening within EAI traditional solutions. SOI = EAI + SOA.

EDA Event Driven Architecture is an architectural style which is the evolution of previous MOM techniques toward SOA concepts, by using one-way asynchronous message exchange patterns. It is a way to model the typical real-time, asynchronous system interactions happening in the real world. Routing, filtering, pipe-lining of messages are the typical tasks of an EDA, activities like CEP (Complex Event Processing) are sometimes necessary.

In Conclusions

Architectural styles and practices are the "what", "who", and "why" of a solution, they shouldn't be confused with technologies, which are the mere "how". Still we read around or listen to people who think that to make his/her IT infrastructure better and more fashionable they need to implement a bunch of SOAP Web-Services + some BPEL orchestration... That is deadly wrong and has driven the acronym SOA to be abused and inflationed and a lot of projects to fail.

Updates: yesterday Paul forwarded me this very interesting article about how Bechtel Corporation is implementing a huge SOA effort to create an internal SaaS infratructure.