Governing events and architect anti-patterns

As the name suggests, SOA is all about services. What about events? In the past, several SOA-efforts tended to neglect events; ultimately causing SOA not to deliver on its full potential or fail altogether. So SOA-practitioners evangelized the use of events. And of course we as IT-industry came up with new terminology to emphasize this: EDA, SOA 2.0, and event-driven SOA to name a few.

This blog is not about promoting events since its importance is (hopefully!) recognized and events are mainstream in nowadays SOA-initiatives. If not, I encourage you to read this blog that explains why events are important from both business and technical perspective. There can be no real SOA without events. Events are just as important as services!

So everything hunky-dory, right? Then why are some SOA-projects using events at runtime to model business processes and their interactions and enable loose-coupling, but neglect to address the governance aspect?

• Organizations set up SOA-registries that include and publish services but not events. Service consumers can discover services, reuse them, retrieve metadata such as ownership, contract, interface, and so on. What about event consumers? What about including events in your registry?
• Architects design taxonomies that structure services into various layers (business services, composite services, and elementary services) and domains (finance, CRM, sales, etc.) but have no taxonomy for events.

Bottom-line: not only use events at runtime, but make events an integral part of your governance processes just as you do for services and processes. That enables reuse of events, dynamic event-discovery, lifecycle-management of events, and so on.

What I’m wondering though if there is a ‘one-size-fits-all’ solution when it comes to governance of services and events? Does the same taxonomy apply for services and events? Is the lifecycle for services the same as for events? Is the metadata we need and store for effective governance the same for events and services? Do you want to unify governance for services and events?

Some experiences might suggest so. We could structure events into business events, composite events, and elementary events. An event has a contract, interface, and implementation. An event has event producers and event consumers. An event has an owner. An event can be discovered. An event provider can guarantee message delivery. An event can be under development, in production, deprecated, retired, and so on. Replace event with service in these last few sentences and it all seems to fit.

However, I don’t want to rush to conclusions and try to squeeze everything into one all-knowing overall model. Guess that’s a known architect anti-pattern: everything has to fit the boxes we draw and models we think of. Even if reality fails to fit in. We rather try to alter reality then to change our models :-)

Obvious differences would be that the consumers of services are generally known whereas event consumers could be unknown (hence also better decoupling). This has different consequences for services and events when it comes to dependency management and impact analysis. Also, events and services could have some specific attributes such as consumer type for events: single (queue) versus multiple (topic).

In any case, I’m going to find out! For a new customer project I’ll be defining the business, information, and technical architecture around services and service-registries and define their governance processes. And guess what? We’re going to include events in this effort. Let’s see what the result will be.