I talk with a fair number of vendors every month about their collaboration and social software offerings. Usually, these briefings have a familiar pattern (the easiest to use, the most experienced management team, growing ecosystem of partners, logo slide with lots of customers…), but I’ve noticed something new starting to creep in. Rather than talking about the features and what customers have done with them, more vendors are talking about how they built their products.
I recently spoke separately with two vendors with newish offerings (Oracle with Beehive and Day Software with CQ5 Social Collaboration) who emphasize that rather than pulling together different products or evolving an existing offering, they started over and designed a new product on top of a solid repository. A clean technical architecture has not typically been a high priority from vendors in this space, who either leverage technology from a variety of sources, including open source, or have legacy products which they need to build upon. Rather than making a point of their long history or leveraging of proven technology from elsewhere, Oracle and Day emphasized the “clean sheet of paper” design approach.
I know that there are others out there who have done this, but these are two that I happened to have spoken with recently who had a similar message. This could be just a way to differentiate a late entry into an established market. In Oracle’s case, I expect they also want to distance Beehive from its failed predecessor, Oracle Collaboration Suite.
I believe it is more than just a stab at differentiation, however. Social software has grown beyond the gee-whiz phase where early adopters can be induced to buy by flashy functionality or anecdotes of somebody having done something fun, somewhere. Corporate buyers and IT architects are getting involved and looking for justification and supportable infrastructures.
in response, I expect to hear other suppliers emphasizing this type of advantage, if they can find a way to claim it. No doubt, some vendors will come up with a variety of “creative” ways of demonstrating architectural superiority as this becomes a more common customer evaluation criteria.
For some, building on a framework that has proven itself over 20 years of usage with millions of users will be their evidence of superiority. Others will wave their clean sheet of paper to show they were not tainted by old ideas. Both approaches have their merits in different situations; the good thing for users is that this discussion has started, because how one builds software matters.