Social technologies: Standalone Applications Or Features?
During CScape at Cisco Live, one of the more interesting conversations I had started with a simple question: Is social software (and collaboration software in general) a set of standalone applications or features of other business applications? This sprang from a discussion on the future of the collaboration technology business and really speaks to a couple of important developments in the market:
1) Collaboration platform vendors incorporating social features into their offerings. Anyone who's followed my research and my blog posts knows this story: Cisco, IBM, Microsoft and Novell (amongst others) have released collaboration tools that include robust Web 2.0 technologies such as social networks, tag clouds and blogs. This has led to a maturing of the messaging of pure-play vendors – going from "we have the best social software" to "this is how we solve a specific business problem."
2) Business applications that power business processes are becoming social. Another recurring theme in my research is corporate interest in (and fear of not having) enterprise 2.0 technology has led business application vendors to jump into the market. As these vendors do so, they are seeking out tools to help them make their applications social. The inclusion of business application vendors, though, has put more pressure on the pure-play vendors to find a niche that will allow them to compete with vendors that have sure footholds in businesses.
Facing these market realities, is there really room for standalone social software? Well, let's start with how pure-play vendors are beginning to address this crowded competitive landscape: Jive Software and Socialtext are working to roll out solutions that are embedded in business processes and tie together business applications. These moves are indicative of a simple truth: It's very hard to change business processes (which are tied into corporate culture) and even more difficult to change the way people work (which is tied into human nature), so why not meet them where they are? So, in some regards, it does seem that the pure-play vendors are seeking to weave their way into business processes (and by extension, business applications) by either being a dashboard for managing these processes (the Jive approach) or in tying together applications with a social layer (the Socialtext approach). Taken together with collaboration platform vendors' and business application vendors' incorporation of social software into their offerings, it would appear that social software needs to either tie into other applications or provide an interface with other applications. I don't totally agree.
When thinking about standalone social software, I start with the delineation between intracompany collaboration and intercompany collaboration. Within the firewall of a business, there are established procedures – and applications to support those procedures – that information workers have been groomed to accept. So, in this context, introducing a standalone collaboration tool that requires a business user to work differently is going to have very limited success because you need to fundamentally change the way people work. However, when you cross the firewall and try to create interactions between companies, those processes – and the applications to support them – aren't necessarily mature (if they exist at all). There aren't many applications that allow for colleagues in different companies to share content, ideas and information while building relationships. And because there is a gap here, this is an area where standalone social software can play an important role. For this to happen, though, we need to be farther down the path with standards and security for these technologies.
In sum, it isn't an either or proposition for social technologies – we need embedded and standalone applications. For product managers and marketers, deciding which way to go is a matter of deciding how you want to serve business interactions – behind or across the firewall. If it's the former, then product managers must understand the job types within verticals they intend to serve: the applications they information workers use, the problems they face, the way they work; and product marketers must understand these job-specific items to create the rationale for an IT department to integrate your social layer. If it's the latter, then product managers and marketers need to acknowledge the problems of crossing the firewall – interoperability, security policies, government regulations – and design to address them.