Lessons Learned from High Tower’s Demise
In November 2008, Aliso Viejo-based High Tower Software, a venture-backed developer of security, compliance, and log management software, shut down. Like many of our “CEP/ESP vendors”, High Tower orchestrated numerous “awards” for their security information and event management (SIEM) software, However, these fluffy marketing awards were not enough to keep HT from a nose dive.
High Tower’s focus was IT security products that supported real-time visibility, alerts, and reports on network threats and organizational policy violations with proprietary analytics they called MetaRules™. I took a close look at High Tower’s “MetaRules” when I was working for TIBCO a few years ago. Basically, the “MetaRules engine” was a very simple rule-base that had very little, to no, value added analytics or advanced correlation techniques. The High Tower architecture was build on a simple centralized, trivial rule-based architecture, so as a distributed-network systems architect focused on CEP at the time, I advised High Tower executives that their software architecture was not scalable and their analytics were pale in comparison to TIBCO’s flagship event processing product.
My advice was not well received, as I think High Tower executives were expecting me to heap praise upon their technology. In fact, their rule-based approach was far too simple for most information security challenges. The High Tower folks booted me out the door, so to speak, because I told them the painful truth about their technology, based on decades my of operational experience in network and security systems engineering and management.
During this same time period, I have also advised the self-styled CEP and ESP vendors. These centralized rule-based approaches, admittedly better than High Tower’s approach, are still years away from being capable of detecting anything but the most simple scenarios in complex security and network management problems. Instead of addressing these serious shortfalls, most of these vendors are in denial, just like High Tower was “offended” after I spend a few days analyzing their software architecture, rules engine, and overall approach. ESP vendors get excited when someone posts a trivial situation-detection problem and argue that it is “not really event processing” if their solution cannot easily process it.
There are very serious lessons to be learned from High Tower’s fall. First of all, listen and learn. I hope that in 2009 vendors will not dismiss my advice when I explain to them how routing and scheduling is not complex event processing. When we look at the blogs and logs about complex event processing, the focus is still SQL-based stream query processing in sliding time windows. This is a niche area which addresses less than 10% (pick a different number if it makes you happy) of real-time detection oriented problems. Like High Tower, vendors in the CEP/ESP/EP space must evolve, or die.
Second, do not base your solutions on centralized approaches. Most stream processing engines we see on the market centralized client-server architectures. Events are pumped into a centeralized stream processor and some simple rules are applied against the stream. This approach is acceptable if you are viewing these engines as a type of edge device in a large event processing scenarios, filtering, aggregating and routing. However, in a more general approach, you need collaboration and cooperation from multiple agents. Ironically, these CEP/ESP stream processing engines do not even make a good scheduling in a complex distributed problem-solving, agent-based architecture.
Finally, incorporate advanced analytics sooner than later. Rules are limited by a number of factors, the same limitations that are well known in expert-systems. Advanced detection requires a number of sophisticated analytics. Until this happens, the CEP/ESP engines on the market today will continue to push routing, orchestration and simple detection solutions, while a the same time, avoiding complex event processing detection scenarios.
The clock is ticking on CEP and the alarms bells are not very far away. Companies who do not listen and adapt will find themselves in a similar situation as High Tower and their investors.








Peter Lin says:
Saturday, January 10, 2009 at 12:58am
Lately, I’ve been thinking about adaptation techniques for expert systems and AI agents. This is largely inspired by your blog. I think there is still alot of research needed to make adaptive techniques work well in practice. I haven’t seen many people talk about it, but it’s becoming clear to me that rule engines that take a statically/strongly typed approach to model events will never scale to support the type of CEP you’ve described in the past.
Given dynamic environments change rapidly, the developer or architect can’t possibly create an object model that will work. I’m starting to think that weakly typed approach is needed to make event discovery and event detection easier. The system would still start with an initial set of rules that guide the machine learning. As it learns, the system creates the models, data and rules it needs to adapt.
I hope the CEP industry learns from High Tower and starts to revisit existing research on machine learning and other adaptive techniques.
peter
Tim Bass says:
Saturday, January 10, 2009 at 7:34am
Hi Peter,
As you might have read, High Tower was backed by Falcon Fund, Hallador Venture Fund, INROADS Capital Partners, J.F. Shea, Kinship Partners, Liberty Partners, Merrill Lynch Ventures, and the Tech Coast Angels. They had raised at least $24M in funding, and was founded in 1999. Originally, they had asked me to help them under a compensation package light on cash and heavy on stock. I thought their stock was going nowhere and that certainly turned out to be the case.
Frankly speaking, I have been approached by CEP-related companies offering me similar “low cash, heavy stock” advisory packages. In each case, I have turned them down because the way vendors are implementing the technology is going nowhere fast. Businesses know how to solve trivial problems, the big money is in the uncharted waters of advanced analytics required to solve complex problems, some of which you mention above.
Thanks for visiting and for your comments!
Yours sincerely, Tim
daSepp says:
Monday, January 26, 2009 at 4:12pm
Just wanted to note that in contrast to other CEP vendors Senactive offers a “service-oriented” approach of processing events.
A service can be a rule component that is attached to the processing flow or a custom component that is applying baysian networks to the flow of events or a classification model that is extracted from data mining algorithms applied on events.
By the way – that is how Senactive is doing fraud detection in the transaction domain such as credit card fraud.