Wednesday, September 12, 2007

Event processing - hard-coded ? specialized software ? generic software ?

Some people what's new about event processing? have not we done event processing for ages ?
so what is the new enunciation here ? it is true that we had done event processing for long time, sometimes in "exception" mode, but it has been done in a hard-coded way embedded in regular programming. I guess that still today if we'll take most of the implemented functionality that falls under the category of event processing, we'll find that they are hard-coded within applications. The new thing is the existence of generic software. When should we used generic software ? if all what is needed in event processing sums up in one or two functions - it is probably not cost-effective to purchase, install, learn and develop in a generic tool. It starts to be cost-effective if one of these conditions is satisfied:
  • The "event processing" functions required in the application quantity is at least medium.
  • The complexity of these functions is not trivial, there is a benefit of programming it in high-level language rather than lower-level language
  • The event processing is not internal to a single application - thus there is a connectivity issue (e.g. pull events, using adapters to re-format the event, listen to events, publish events etc..) . Again - hard-coding all of this may not be cost-effective.
  • Agility requirement - frequent changes. Again - easier when there are higher-level abstractions.
  • Need to enable control on the behavior by business users without involving programmers - this is a mountain we have not conquered yet, but conceptually will be easier with generic tool.

The analog, in a way, is generic DBMS with all its utilities vs. implementing your own database using file systems. There are certainly cases in which it is worthwhile to use file systems, and not use the abstraction layer that DBMS provides, but in most cases the TCO (total cost of ownership) is substantially lower, when the level of abstraction goes up. Note that the main cost saving is maintenance time and not in development time, especially if agility is a consideration.

There is another variation between the "generic" software and hard-coding which is a specialized function. It still provide high-level language, but the function is limited to a specific application / application types. Should we use generic software for all such cases ? or are we better in using specialized software, which raises an interesting question - should we strive for the "one side fits all' ?

More of this discussion will continue later

No comments: