Monday, October 8, 2007

Who should define event processing applications ?

This picture is taken from the recent ebizQ's event processing survey and shows an interesting picture, the survey done shows that the customers prefer that rules will be defined in 84% of the cases by non-programmers. This is not the current situation, but this is the way that the customers prefer it. Indeed, it is not possible to have the entire event processing end-to-end story done by non-technical people in this phase (maybe with applying some autonomic computing techniques we can come closer to it, but this is a topic for another Blog), but let's concentrate now in the CEP (Complex Event Processing) part - detection of patterns. Given the right level of abstraction both of the "programming in the small" - the individual pattern, and the "programming in the large" - the event flow, pattern composition may be delegated to business people (well - with some understanding of basic terms like the distinction between "OR" and "AND", but with no need to know how to program in Java, C, SQL and other languages geared for programmers). Bear in mind that the bigger expense in the application's life-cycle is not the cost of development, but the cost of maintenance, and this is especially true when changes are frequent, or there is a need to create new patterns to detect unexpected events within a short time. In fact, the agility, ability to quickly adapt, and ease-of-use for non-technical people is a success factor for the entire concept of event processing COTS, and the ground for competition among vendors. Investments in tools for developers address only 16% of the market, according to this survey. This reminds me that once in my academic past, I attended a teaching workshop given by an external experts, and they started their session saying that - most teachers base their teaching on the students' sense of hearing, while for most people the visual sense is much stronger, so there is a mismatch.... More later.


Unknown said...

I think this brushes up on the immaturity of computer/IT science to serve the needs of the public and especially the business person.

For example in the commercial building industry, if you are an architect, you discuss your building concepts with the owner in terms of occupancy, the types of work conducted, flow of people, etc.

Only when all of this is decided (and of course aesthetics) is it turned over to the engineering firm who details the general design of mechanical, electrical, etc. When the engineers are done, contractors bid on it, try to use cheap products, instead of the spec'd ones - all the usual stuff.

The point is that the owner doesn't fuss (much anyway) over a lot of those details. They know what they want to accomplish with a building, make it clear to those responsible for details, and pay the bills.

There is a "language" and "conceptual level" that the architect and owner use to make decisions. The building plans.

In IT it's hard for the "owner" (say manager of a business line) to really know what is possible in business terms, because so much of that is obscured by techie gobbledy-gook. Most of the discussion is technical.

If there was a very high-level language (extension to UML?) that can speak to the needs of a business person that covers the eventing space that'd be a step forward. The developers are there to implement, not take over responsibility just because they are the only ones that can speak the only available language (low level implementation stuff).

Job #1 should be to put the business person in charge.

Opher Etzion said...


I am a long time believer of high level programming that business people can cope it. While it is difficult to do in general applications, there are successes in limited domains - e.g. spreadsheets. There is some other experience in other domains, I believe it is doable in event processing (well - at least to a certain extent).


James Taylor said...

I think the collaboration of IT and business people on the solution is key in CEP, just as it is in decision management and other uses of business rules. For instance, I blogged about some secrets of business user rule maintenance and I suspect the same kind of things would be true in CEP.

Author of Smart (Enough) Systems
ebizQ blog