Farewell Cassatt, Lessons Learned
April 27, 2009 - 6:10 pmBill Coleman, BEA founder and CEO of Cassatt, said in a Forbes interview today that Cassatt is “close to an end” after burning through nearly $100MM in funding. The Register has followed up with their own commentary.
Having followed (and sometimes positioned against) Cassatt for years, watching its unraveling has been an educational experience. Despite technology that was perhaps too far ahead of its time, Cassatt’s business practices often seemed the opposite: an old school 20th-century big dollar enterprise software model trying to compete in the 21st-century world of asymmetrical business and technology tactics.
So with a bit of melancholy (I’ve been in their shoes and know their pain), I bid farewell to Cassatt and am drawn to lessons we can learn from their demise:
1. Rip and replace doesn’t work. Boiling the ocean doesn’t work. The combination of the two really doesn’t work.
It didn’t work for HP’s cancelled Utility Data Center, it hasn’t really worked for IBM’s Autonomic Computing, and now it hasn’t worked for Cassatt.
If your product’s main value proposition depends upon people jettisoning wholesale what they’re using now (and incurring switching costs), with no way to get ROI incrementally, it’s a near impossible sale.
2. Corollary to #1: You need to play nicely with what people have. Especially if you’re a startup trying to penetrate the enterprise data center.
Integrating to other IT operations management systems in the data center is key here, and one way to deliver incremental value.
Open source solutions need to pay particular attention to this, as there is often a religious conviction against integrating with proprietary systems. Get over it.
3. IT departments and sys admins won’t change their (buying, tool, technical) habits just because you invented something neato. Doubly true if it’s neato but expensive.
4. In the 21st century, people expect to try your software, use it, and then (maybe) buy something. Big paid proof of concepts as a way to get hands-on product experience is going the way of the dodo.
Despite having $100MM in funding, Cassatt couldn’t get beyond “about a dozen very large customers”.
I suspect Cassatt was probably too large and complex to easily make into a downloadable product. But doing something to get it into the hands of the masses and get some grass roots traction could have done wonders.
5. If you need to make a Hail Mary, try going open source.
Where might Cassatt have been if they had released their product as open source a year or two ago? Where might they go in the future if they do so now?
In addition to the comments below, you can tweet me @davidpdennis or mail me at ddennis at gwos dot com.
David
[...] GroundWork Blog » Farewell Cassatt, Lessons Learned [...]
[...] GroundWork Blog » Blog Archive » Farewell Cassatt, Lessons Learned [...]
There are some really good lessons to be learned from Cassatt, both positive and negative. As a Cassatt employee, I’ve certainly picked them up firsthand and hope to gather my thoughts and publish them when this all sorts itself out.
For now, I did want to comment on items #1 and #2 above and clarify them with regard to what Cassatt actually has. On the rip & replace/boil the ocean comment, I think no one from Cassatt would disagree with you: it doesn’t work. We actually revamped our product line and created the multiple Active Response editions to address this issue back in ‘07. By splitting what was relatively monolithic product into several editions with incremental functionality, we tried to create a product line that could be used to solve particular problems in small steps. And, our products don’t require you to alter a line of your working code in order to use them, so there was no ripping nor replacing needed. We also have integration points to let it play nice with the system management and other IT operations tools already in place in your data center.
The real rip & replace part of the Cassatt solution, however, is related to your item #3 above. Cassatt does require you to change your IT management processes. That’s how it gives you the big value/ROI. That and the use of resources are where things are most inefficient. It’s an organizational/cultural issue much more than a technology one, from what we’ve seen. One positive note: those mindsets & approaches seem like they’re starting to change or at least be willing to look at alternatives with the early work on cloud comptuing that’s going on.
[...] closing - David Dennis had a nice write-up, but I ask John to add in his take which seems to be: “provisioning on steroids might be a [...]
[...] closing - David Dennis had a nice write-up, but I ask John to add in his take which seems to be: “provisioning on steroids might be a [...]