Event Driven Architecture

One of the things I’ve noticed about the most complex systems out there is that they are all Event-driven.Â Operating systems, Windowing systems – at the end of the day, anything that’s trying to be a generalized platform for general purpose work ends up behaving as an event-driven system.Â Â Â Â That’s the point at which the bugs become insidious – race conditions, deadlock and other problems related to the fact that the developers have no way of knowing what is going to happen next at any given time.

This further has the consequence of creating layer upon layer of management, monitoring, resource management and error handling code, not to mention debugging, tracing, security and other tangential systems.Â You have to have them as you grow more “general purpose” because without them, you’re DOA everytime anyone uses the system. There’s just too many ways to fail.

So when I see things like ‘Corporate EDA’, I shudder a little.Â I wonder if they realize the can of worms they’re opening by trying to handle “anything”. Â Especially given that, as far as I can tell, each enterprise will require its own custom approach to it’s “Corporate Operating System”. Â And that COS will have to be maintained, evolved, improved, debugged and taught for years and years to come.Â Â And, worst of all, it will be viewed as a cost center, not a profit center, and will always have to fight for resources with the other auxiliary functions.
So who wants to be the next Microsoft?Â Apparently, everyone.