Mark Palmer seems to be turning Streambase in a positive direction since he joined .... either that, or the Streambase marketing machine is in full throttle.
Remarkably, Mark has managed to get testimonials from a number of financial services customers. Usually we are a secretive bunch, and many of the larger financial institutions do not like to have themselves used as a reference customer. Which makes it all the more interesting that Streambase has been able to persuade these customers to go public. Not only that, but Streambase has managed to convince Penny Crossman of Wall Street and Technology to rewrite their press release into an article.
Say what you will about Streambase's sales and marketing staff .... they have proven themselves to be amazingly effective. They have been able to trot out customer references, whereas Coral8 and Aleri have not. This gives the perception that Streambase is eating the competition, whether that perception is true or not.
Mark posted an interesting paragraph:
As Dr. Goodell described, Apama didn't even make the first cut in their evaluation. On the other hand, Aleri, the other final CEP product in PhaseCapital's evaluation, fared well with its high-performance, multi-threaded server architecture.
And, Penny follows it up with:
PhaseCapital evaluated a number of CEP vendors in the trading space, including Progress Apama, Coral8, Aleri and StreamBase.
It's very interesting that Phase Capital found that Aleri was the highest performing CEP engine. This has confirmed something that I have suspected. Aleri has always been touting themselves as the most performant of the CEP engines, and has welcomed the other CEP vendors to take the Aleri Challenge. However, it may have been the lack of spit-and-polish in Aleri's development environment that may have sunk it. I have previously blogged here that I thought that Streambase had the best development experience and documentation out of all of the other products.
I am wondering what factors caused Phase Capital to not choose Coral8. One thing that Streambase has that most of the others do not is built-in adapters for trading companies. As Penny writes:
StreamBase already had an adaptor for the QuickFIX engine as well as adaptors for the data streams provide by Lime Brokerage, PhaseCapital's execution broker. "The building blocks were very complementary to what we're ultimately trying to deploy," Pritchett says.
I have been saying this for a long long time on this blog --- the quality of the CEP engine does not matter as much as the entire ecosystem surrounding the CEP engine. You can have the best, fastest, most expressive CEP engine and language, but if you don't surround it with a compelling ecosystem, then you are sunk. And, Mark Palmer understands this.
©2009 Marc Adler - All Rights Reserved.
All opinions here are personal, and have no relation to my employer.
Subscribe to:
Post Comments (Atom)
6 comments:
Hi Mark,
"...the quality of the CEP engine does not matter as much as the entire ecosystem surrounding the CEP engine. You can have the best, fastest, most expressive CEP engine and language, but if you don't surround it with a compelling ecosystem, then you are sunk."
Say that you have CEP engine A and CEP engine B. CEP engine A has more powerful and expressive CEP language but no out-of-the-box interface with your event source. CEP engine B includes this interface.
Which one to choose? Building the interface to your event source is a one-time cost since the interface is not likely to change frequently, however you probably plan to build several CEP applications using the CEP engine language. If you compare the effort of building the interface vs the effort of your planned CEP development in the following years then the later probably is much more high than the former...Then, if CEP engine A makes your life 10% easier (i.e. reduces your CEP development effort in 10%) than CEP engine B when it comes to CEP development, which CEP engine would you choose?
Regards,
PatternStorm
Hi Marc - I don't think there's any "trick" to getting firms to speak about their use of a product. I think it boils down to mutual respect and partnership. We try our best to focus on their success - almost like the fabled IBM focus on customer success. We earn their respect by, for example, building the right connectivity, as you point out. And, most importantly, we have a kick-ass product - I think it's the Ferrari of CEP products. I am constantly amazed how great it is after having come here.
Perhaps what was missing before from StreamBase, was that partnership focus. I don't know. But it's much broader than "getting a press release."
One point of clarification.... Phase Capital did NOT reach the conclusion that Aleri was the highest performing CEP engine. My comment about multi-threading was only to contrast it with Apama, which is a single-threaded architecture, and is increasingly not making the short list on evaluations when technology matters. I didn't make that clear in my original post.
- Mark Palmer, CEO, StreamBase
PatternStorm, you seem to assume that people make rational decisions based on fact ;)
That is not true in any way.
That's why some would choose a particular product because it has one thing (adapter) that he actually recognizes the name of. Even if the product is not as good as the competing one.
Another example is that a nice GUI is very critical to selling a product. A rational way of thinking would be to require a stable run-time environment and use that as a critical factor. But nice shiny graphics wins almost every time.
This is very annoying to every software developer though...
PatternStorm - were you addressing Marc Adler or Mark Palmer? Well, I'll answer anyway.
Integration is essential, and, in many projects DOMINATES the development effort it takes to put a system into production. That is, think in terms of integration being 30%-80% of a project. Now rethink the answer.
Moreover, to your point, if you're going to build 5 applications, in a typical bank, that means 5 SETS of things to integrate with. If you're lucky, there will be some intersection (e.g., TIBCO RV and Oracle), so you can re-use a lot of standard adapters. But, GOOD database integration tools, that help you integrate with disparate schemas, is an important consideration.
And, what if those 5 projects operate on different asset classes? Now maybe you need a Reuters adapter for equities, CME for commodities, and FXAll connectivity for FX?
Now how about GUIs? .NET on one project, RCP on another.
Integration is tough, and as a CEP vendor we have to commit to supporting good integration because without it our customers don't deploy.
- Mark Palmer
http://streambase.typepad.com/
Hi Mark (Palmer),
I was adressing Marc Adler, however I do appreciate very much your response. Let me please comment on it:
...Integration is essential, and, in many projects DOMINATES the development effort it takes to put a system into production. That is, think in terms of integration being 30%-80% of a project. Now rethink the answer.
I agree, but notice that you are talking about putting the system into production, not maintaining and improving the system with, for instance, additional developments (that would not require any modification to the interface). The fact that you cannot include in your business case such additional developments and improvements (because you don't know the details enough and because is not the focus of your project) does not mean that they will not happen. If you are successful they should happen. However I realize that this is in theory and in theory there's no difference between theory and practice but in practice there is ;-) so it's nearly impossible to justify an increase in the cost/effort of your project arguing savings that will be realized after your project is done, specially when you are putting into production an emerging technology but, again this does not mean that these savings are not there...
Let me finish by saying that is good architecture practice to separate concerns, that is, uncoupling the event sources adaptors and the GUIs from the CEP engine in order to decrease my barrier to change it, otherwise I risk getting caught in vendor lock-in which is not a comfortable situation, specially in this case where we are talking about an emerging piece of technology that's therefore more subject to the risk of change.
So, yes, Mark, you are right and you are doing a good job, however as a customer I would prefer that you offered me a CEP engine that used an standard event format and a standard CEP language, rather than offering me proprietary adaptors to existing event sources: just because one simple thing, I don't think it is a good idea to become locked-in to one CEP vendor just because it has inetgrated GUIs and adpators to its CEP engine...
Of course if the CEP engine is the Ferrari of the CEP engines then you are very much on track and adaptors and GUIs come as a very appreciated add-on.
Regards,
PatternStorm
PatternStorm does make a very valid point about vendor lock-in. It's not always about the fastest or the "best" (whatever that is). It's about what can integrate into your existing processes with a minimal amount of retrofitting, across multiple platforms and/or development languages.
Post a Comment