More on CEP Product Complexity

April 5, 2008

Mark Tsimelzon, President & CTO, Coral8 replies to CEP Product Complexity at Coral8 with More on CEP and Complexity.

In Mark’s reply he gently reminds us that the Coral8 Engine is a developer’s tool, not a business users tool.  Mark also tacitly reminds us that his customers are a bit smarter than our development team at Techrotech.  Perhaps that is why we can never get our SOA project off the ground!  

Mark’s customers can learn a new concept in a single day; however, our developers need a full week to learn the same thing.   Making matters more difficult, our CIO at Techrotech, Jerry Fleck is clueless according to the marketing analysts.  Jerry has not yet figured out SOA; so concepts like windows, joins, design patterns, causal tracking, messaging layers, adapters, CCL, and persistance will cause Jerry to fall Off the Grid.

It took us years to get rid of most of our legacy C programmers, bring in a bunch of Java gurus, and at the same time, correct our stock option backdating “clerical errors”.    Maybe we should now replace our worthless legal and HR departments with a CEP Engine?


CEP Product Complexity at Coral8

April 5, 2008

In What makes a Coral8 Expert?, Coral8 CTO Mark Tsimelzon outlines nearly 60 subject areas that a customer must master to become a Coral8 expert. 

While this complexity is impressive, it tends to demonstrate why CEP is, today, more hype than reality.

I can hear the team at Techrotech in my mind, “Yea! Greg purchased Coral8 for our CEP solutions yesterday!   Holy Cow!! Let’s go out and learn 60 topics in depth so we can become experts in using and deploying Coral8!”

So, let’s say you are intelligent and can master a subject in a single weeks time (if you have nothing else to do), so you can become a Coral8 expert in only one year if you don’t have a day job!!

I don’t know about you, but the way Mark describes their product, Coral8 sounds more like a lab tool for the engineering department of Caltech or Stanford than a tool for everyday business users.  Mark concludes his post;

Not too scary, is it?  – Mark Tsimelzon, President & CTO, Coral8

Hmmmm.   I think I’ll ask the software team at Techrotech to write some event processing applications in C since we have a strong team of C programmers coming off another project next week….  then again, I heard some Java programmers will be free in two weeks …. 

Orthogonal Blogging at the SOA Horse Races

January 20, 2008

Dear friend Opher Etzion responds to my post Betting on the SOA Horse with a discussion on how SOA, EDA and CEP are technically orthogonal, concluding:

“Event Processing can have different interactions with SOA, and when IBM’s announcements in this area will be available you’ll realize that there are different entry points. Event processing can also work in legacy and non-SOA environment.”

Richard Veryard, who also kindly reads my blog (and Opher’s blog) replies with Technological Perfecta where he opines,

“I think there are some mutual dependencies between these technologies, but they are what I call soft dependencies.”

Opher, Richard, you guys are technically right, but you are blogging orthogonally to the message in Betting on the SOA Horse.

First of all, my post was not a technical discussion, it was a discussion about business, marketing, timing positioning and the software industry in general. Therefore, it is a bit humorously orthogonal to reply to a marketing metaphor about investments, competition, software postioning and horse racing with architectual posts about technology and how they are related or interdependent.

In a nutshell, here is why….

Candidly speaking, despite what many analysts want you to believe, end users rarely build “SOAs” “EDAs” or CEPs”. End users have IT budgets to solve business problems with the most cost effective technology they can find; and they do not care (if they have a clue) what cute three letter acronyms have been created by analysts to describe momentum in the software market. Sorry, it is true really.

For example, I remember when I was in Tokyo where the very capable and conservatively risk adverse Japanese executives told me time and time again, “We don’t care about SOA we simply want to integrate our systems.” They were quick to remind me, “You guys in America must realize we don’t care what the western analysts, supported by software companies, say. They have a conflict-of-interest anyway and they are not end users. What we care about are mature technologies with solid reference clients and proven implementations.”

By the way, this is one reason I admire Japanese business so much. They are not impressed with handwaving hyperbole. They just want to see results. In other words, “Prove it, don’t just say it.” The devil is in the details, as they say. The Japanese are highly skillful at cutting through the smoke-and-mirrors. I think this is one reason the Japanese are among the leaders in so many industry sectors, but that is a blog story for another day.

To this point, if you are in front of customers and you are pushing SOA because your software company has “bet the farm” on positioning themselves as an SOA company, you are making a mistake. Three letter acronyms and technology jargon do not solve business problems. In fact, for the most part, they are a red-herring. The same is true of EDA and CEP. This was the main message in my post Betting on the SOA Horse.

How do I make such a statement?

Because for over 20 years I have worked as a consultant working on the opposite side of the table of hungry software vendors who come into our house (organization) tossing out buzzwords, acronyms, and jargon. My job was solving real business problems, not selling software. We used to wonder when all the scrabble and babble the software companies were tossing at us was going to turn into a business language that solves real business problems easily, rapidly and economically. That day never came.

Then, I made a conscious decision to take a break from a long career of consulting to get an insiders perspective on, and perhaps even transform, the software industry (What was I thinking?). This experience, working for a software company, was an eye-opener.  

Candidly speaking again, some software companies tend to live in “La La Land”.

They create go-to-market strategies based on jargon, buzzwords and three letter acronyms that have little to do with understanding their customer’s business problems, risks, and culture. They spin, position and reposition in a market of smoke-and-mirrors happy to sell you a gold disk of “the-answers-to-all-your-problems.”  Then, they leave you the gold disk, and your business problem, as they drive away, looking at your business in the rear view mirror as they count the revenue from their victorious campaign.

These same companies bet on jargon like SOA, EDA, CEP, BAM and they hedge their bets with different combinations of the above, the theme of my post Betting on the SOA Horse, which was not a technology, architectural nor implementation discussion, in any way.

Is it any real wonder why SOA has become, for the most part, complex, vendor-driven jargon barely making a dent in the practical real-world, whereas social-networking and other grass-roots user-driven technologies, most without trendy jargon, has left SOA in the dust for the past few years?

A Funny Thing Happened on the Road to Xiamen

January 10, 2008

We leave for a short business trip to Xiamen, China, tomorrow, staying at the Sheraton Xiamen Hotel.   

Here are the current prices for a short visa to China from the Chinese Embassy in Bangkok.

  •         Thai Nationals       1000 Baht
  •         Other Nationals     1500 Baht
  •         US Citizens            3450 Baht

This is the first time I have run into this type of visa pricing structure as long as I can remember.

What do you think will happen when we get off the plane?

Stay tuned…..

Adapters and Analytics: COTS? NOT!

December 26, 2007

Marc Adler shows why his musings are rapidly becoming one of my “must read” blogs in his post, CEP Vendors and the Ecosystem.

We have been making similar points in the event processing blogosphere, namely the important of adapters and analytics.   Today, event processing vendors are surprisingly weak in both areas. 

For one thing, there was way much emphasis on rules-based analytics in 2007.  Where are the rest of the plug-and-play commercial analytics end users need for event processing??

And another thing….. 🙂

Why are there so few choices of adapters and why do we have to write our own??

Sometimes I think that if I read another press release on 500,000 events per second I’m going to shout out – the event processing software on the market today cannot even connect to a simple UNIX domain socket out-of-the-box, so how about ZERO events per second!

The bottom line is that the market is still wide open for a software vendor to come to the party with a wide array of plug-and-play, grab-and-go, adapters and analytics.  

Folks are talking COTS, but more often it is NOTS.

Agent Logic is Not the Leading CEP Vendor, Sorry.

November 19, 2007

This press release just came across my desk, Agent Logic’s Release of RulePoint. The press release has one of the more laughable statements I have read in a CEP-related press release for quite some time.

“Agent Logic, the leading provider of user-driven Complex Event Processing (CEP) software, today announced the general availability of RulePoint…”

Come on guys!   Get control of your marketing department!  

Agent Logic is not the leading provider of user-driven CEP software.

The Top Ten Security Threats for 2008 (Part 3) – Risky Situations and Context

November 11, 2007

Opher Etzion provides a timely segway for Part 3 of this series on The Top Ten Security Threats for 2008 in his two blog posts, Context and Situation – are they synonyms? and The notion of context and its role in event processing.  

I will briefly illustrate and elaborate by applying the concepts of context and situation to risk identification, or the identification of increasingly risky situations, in terms of the three core contextual elements of risk, (1) threat, (2) vulnerability and (3) criticality.  

Risk Context and Situational Model

The intersection of the context (or elements) of risk, illustrated in the figure above, defines various situations relevant to risk and risk management.   Here is the context and the various situations:

(1) Threats environments that have no critical assets or known vulnerabilities. This is a bit like flesh eating zombies isolated on a remote island in uncharted ocean waters.   There is a low probability of a risky situation developing, except in those horror movies where shipwrecked bikini clad tourists enter the scene!  Then, we have the situation of barefoot people in bikinis (vulnerable) and some who are very beautiful (critical assets) – see situation (7) below!

 (2) Vulnerabilities in systems, programs, people, equipment or facilities that are not associated with critical assets and there are no known threats.    These are like the vulnerable barefoot bikini clad people on the ship who are not critical to the plot of the horror movie.

(3) Critical assets (information, systems, programs, people, equipment or facilities) for which there are no known vulnerabilities or threats.   These are the stars of the movie – the ones highly paid for their critical assets 🙂

(4) A threat or number of threats has acquired specific knowledge and/or capability to exploit a vulnerability to non-critical assets.  An example would be the people who are “killed early” in the horror movie, the vulnerable, non-critical assets!  

(5) Critical assets for which there are no known vulnerabilities but there is exposure to one or more specific threats.   These are like the strong, beautiful, undefeatable folks in our island of horror metaphor.  They are simply not vulnerable to the flesh eating zombies!

(6) Critical assets for which there are known vulnerabilities but no known threats.   These are like the bikini clad beautiful people before they landed on the island of terrible flesh eating zombies!

(7) Critical assets for which there are known vulnerabilities and threats.  This context defines the most risky situations for our cast of vulnerable, bareful, beautiful, fashionable, bikini clad tourists on the island of flesh eating zombies!   Run for your lives!!!

Situations and context?    We experience this in almost every moment of our lives.   Our senses provide the information for the context (somewhat autonomic, or lower level, cognitive context) and our minds formulate the (higher cognitive) situations.

So, where are the top ten security threats for 2008 I promised? 

Stay tuned…..