When CMS Memes Attack!
“Oh no,” says the Sergeant. “I’ll have no such chat,
And neither will I take it from snappy young brats,
For if you insult me with one other word,
I’ll cut off your heads in the morning.”
- ARTHUR MCBRIDE
In the beginning there was the CMS Vendor Meme, which turned into a light hearted and entertaining exercise in which over 20 CMS vendors participated. As a response to this, Vignette posted a second meme which appears to have backfired. There aren’t going to be many (any?) responses, and Luis Sala has posted a rather biting response on his *personal* (not Alfresco’s) blog.
Before I comment on this, I’d like to say for the record that there is a lot about Vignette that I like. They were, without doubt, CMS pioneers. When Vignette V7 was released many moons ago, I genuinely believe it was the best Content Management System out there. Apart from a couple of major gripes, I still like the CMS and think certain aspects of it are uniquely attractive. VAP is one of the leading portals too. I hate the Dynamic Portal/Site integration but that’s just me. But I would still happily implement Vignette and do currently work with it.
Before reading this, make sure you read Luis’ post Vignette tries to start a WCM Vendor Meme (yawn!). I wonder if Vignette are going to respond to this, or just leave it at that. Vignette have lost their way a bit and I agree with a lot of the comments that Luis made. They have also been in the press quite a lot recently for a number of reasons, and I’m not going to repeat things that have been already said elsewhere. Some of the points in Luis’ post have been discussed in the CMSWire article Five Reasons to Choose Vignette (or Not…) by John Conroy and Irina Guseva. I am, however, going to add my thoughts to a few of Luis’ comments.
I would argue that one of the main reasons that happened was because Vignette, Interwoven and Documentum are entrenched in 7-15 year technologies and mindsets that have resulted in stagnation while the smaller, more agile vendors that ranked a little higher on the list can more successfully innovate and adapt to changing market conditions.
I think is completely true that the speed of development of the ECM vendors mentioned is much slower. Compare Vignette VCM 126.96.36.199 to 7.6 – not as much progress as one would hope in about 5 years. It isn’t only Vignette – we’re still waiting for TeamSite 7 for example having had a sneak peak 2 years ago at GearUp 2007. But I blame the technologies more than the mindsets. In the Vignette CMS case, I’m going to point the finger at an extremely complex J2EE implementation using some technologies that are pretty old by current standards. Aim some monitoring software like SpotLight at the VCM, change and publish a simple content type, and watch the party. Quite staggering just how much is going on behind the scenes. Not surprising that it is complex to extend and change. In addition, I think the larger players are hamstrung by backward compatibility promises as they tend to support much larger, business critical implementations. You’d think this means that their upgrade paths are easier and more reliable, but sadly recent history his taught us the opposite.
That’s probably one of the main reasons Vignette’s earnings continue to drop and, more alarmingly, Vignette Professional Services account for roughly 50% of their revenue. Very scary…
Yes, Vignette’s PS account for a large part of their revenue. From the agency/systems integrator (that’s where I live) perspective, we are very cautious of this model. It doesn’t make our lives any easier when we need to compete against the vendor’s PS team if we recommend their CMS for an implementation. More and more small vendors are moving to the Partner Channel only model, which makes life much more pleasant for everyone. And I appreciate that the vendors need to ensure that partners have the skill to implement correctly and want to certify some parts of the solution, but I believe the Professional Services should be contracted to the partner, not directly to the client.
All vendors must be very careful about claiming “massive scalability” as every implementation is unique and while the software may be capable of scaling in one use-case, it could die in sputtering, driveling fits in the other.
Of course. Bad implementation can kill any software. Let me tell you a story that depresses me a bit. 10 years ago, Vignette had what I consider an excellent caching model. They used “Components” which actually ended up as output cached HTML fragments. They used Server Side Includes (SSIs) to allow for an extremely flexible mix of cached and dynamic content on the same page. They didn’t have a very sophisticated dependency graph based de-cache back then, but no-one really did. They were very proud of it, claimed it had multiple patents, and I think it was the dog’s bollocks (that’s a good thing for the non-UK readers). The model vanished in later versions, and was replaced completely when Vignette Application Portal (VAP) become the recommended delivery mechanism.
A couple of years ago I was presenting at Vignette Village 2007 with a customer. One of the main themes of this Village was that Vignette had the fastest, most scalable delivery mechanism in the universe, ever. Another main theme was that the product roadmap was very driven by customer demand. “You asked, we listened” kind of thing. So I found it quite ironic that a major product launch at Village was a brand new component that sped up the delivery even more: Vignette High Performance Delivery (HPD). Now the fastest delivery mechanism in the world is even faster! And the architecture behind HPD is remarkably similar to the caching model they had in the late 90s!
I’m going slightly off topic here, but I don’t like the way the blurb on the site for this product says “HPD lets organizations deliver fresh, customized content online without either the high cost of hardware or the unacceptable cost of slow site performance“. There are other options. For example, Vignette really did a great job on the Atlanta 2004 Olympics site. It looked excellent and performed well under massive load. But this was all Akamai fronted. I’m a big fan of CDNs and ESIs for massively scalably delivery.
After wasting investing hundreds of millions buying OnDisplay, DataSage, Revenio, Epicentric, Intraspect, Tower Technology and most recently Vidavee, one could argue that Vignette could *possibly* address all those areas, but the dirty little secret is that even over a decade after some of those acquisitions occured, Vignette has positively and quite spectacularly failed in truly integrating all those services.
I think the key word here is “truly”. Some of the products are reasonably well integrated, but these are point integrations between product A and product B. I’d like to see a generic integration architecture instead. A single repository (or illusion thereof) for the different products would be the dream, but that seems unlikely. I think the word wasting is unfair, although some of the acquisitions have been worse than others. I’d also like to add that I believe Vignette are aware of these issues, do embrace and support enabling emerging standards (JSR-168/286, JSR-170/283, maybe the new favourite CMIS) which could help with their integrations, and still have some really smart people. But their current product stack makes this a really difficult problem which is going to take them a lot more time (which maybe they don’t have?) to solve.
The Vignette Application Portal is pretty much the only *simple* way to render content. While the sales and sales engineers might say that customers can create websites using any web framework and programming language, a realization of the effort involved will serve as a near-instant death-knell to such foolhardy notions.
I’m going to disagree with this on two points. I like the VCM Content API and have successfully implemented systems that use a non-Vignette (this doesn’t mean bespoke!) delivery framework. Surely one of the main benefits of the “decoupled” ECM approach is that one does have the option to use the ECM suite simply to manage content to be consumed by any delivery channel. My second disagreement is that VAP is a simple way to render content. For a public facing site that does not need a portal, I believe that using VAP (or any portal) is overkill and fraught with peril.
Customers foolish enough to buy from Vignette are faced with an 8 page-long pricesheet (please take a look!)
Actually, the PDF version is more like 30 pages. In response to the “Simple Price List” question in the initial meme, part of the response was “Look out for a pricing innovation coming soon to a price sheet near you … it will probably be simple enough for a five year old”. Vignette are aware of the over-complication and hopefully will address it. If they don’t, they’re in trouble.
Vignette’s product suite is so expansive and disjointed that the typical Vignette sales engineer cannot even fathom how to install them all. So Vignette has a “Sales Enablement Team” whose primary job function is to figure out how to install all these moving parts and set up a hosted VMWare environment so that they can demo it. I pity my brethren there who still have to run more than one Vignette app on their laptops.
Anyway, enough of this now. Let me close my coffin on this near extinct meme with a final thought. I still believe Vignette has some really good software and some really good people. They’ve also got some really big architectural and software problems. I, for one, hope they can sort them out before it is too late. If they don’t, they wouldn’t be the first US Pioneer to die in Texas. And it is only 81 miles / 1 hour 22 mins drive from Vignette Corporate Headquaters to the Alamo.