Blogger: Craig Roth
Burton Group recently announced the completion of a field research project to determine how organizations are approaching social networking (see Field Research Study: Social Networking Within the Enterprise). The interviews were only very lightly guided, so respondents got to guide the conversation where they wanted to go. It was telling that quite a few of them, when asked to talk about social networking, wanted to talk about portals. In fact, one third of the 29 organizations interviewed steered the conversation to portals at some point. This point occurred in one of two places: when talking about how social networking could bolster an existing, successful portal – or how it could replace a failed portal.
First, replacing a failed portal effort with social networking. Respondents in this category indicated they had failed in attempts to create a portal to address generic “knowledge management.” One idea is that perhaps social networking will offer a better route to KM than portals since it focuses on human interconnections rather than collecting data assets. For example, one organization said they had an “older KM Portal previously established, but information was hard to find and use,” so now they were interested in social networking.
In other cases, portals failed to get off the ground due to endless planning. One respondent indicated “They have not deployed yet after a year and a half of planning but are now looking to go to a collaboration platform”. Another organization had different internal constituencies (IT, corporate communications, and HR) come into conflict as they forced the portal in different directions. For this organization, the result has been a portal effort that has been stalled for over 3 years. We recommend time boxing portal implementations to be six to nine months (the longer time being for large enterprise deployments) to avoid analysis paralysis.
If a social network is being launched from the ruins of a portal effort, one has to seriously ask why the social network is expected to succeed when a portal failed. If the answer is that a focus on connecting people to people is really what the organization needed rather than connecting people to applications and content then you may be on the right track. But if the answer is that the new technology is better or more exciting, expect failure for the same reasons the portal failed: lack of business buy-in, poor or no governance, poor adoption resulting in a failure to reach a critical mass of users, analysis paralysis, and no business proposition for solving problems the users can recognize.
Now that I’ve discussed using social networking to replace a failed portal effort, I want to move on to the more cheerful subject of using them together. The path is clearer for organizations with successful portal efforts that want to add social networking in. Portals act as a personalized hub for applications, content, collaboration, and processes. This puts them in a unique position to reach people in a role-based manner who may want to interact in a social network. Through integration, social network sites can inject people and relationships into the portal interface. One interviewee explicitly mentioned that it “would be interesting to add people and relationships to the portal user interface and experience ... to surface social networking in the portal.” Another mentioned they were interested in hanging community features off of their new, open source portal. This makes sense since portal infrastructure is often used today to create role-based portal sites. For example, one respondent had separate portals for employees, alumni, retirees, and a women’s network. By adding social networking technologies, these existing portals could become even more powerful mechanisms for connecting people with similar interests that may not come in casual contact during their workday.
Note that in this model the portal is not itself a social network, but it can work with the social network site. The SN site may have portlets or widgets that the portal can consume, APIs that custom-written portlets could access, or (worst case) screen scrape summary information the network site. The portal could also provide links to contextually relevant social network sites. The social networking site simultaneously exists as a destination for use when social networking is a primary activity and can point to information in the portal. In this way the portal and the social network site can each play to their strengths and make each other stronger and more successful. The portal provides the back-end integration (directory, single sign-on, implementation of portlet standards, portlets connecting to enterprise applications) and front-end presentation (in a personalized, screen real-estate metaphor) for building portal sites. However, the SN site is probably not built on the portal framework. The SN site provides the ability to define an online persona, list connections, receive notifications on the activities of those connections, participate in inter-personal, group, or community activities, and control social networking permission, preference, and privacy settings. It’s a great combination and one we expect to see more frequently.
