On the Relationship Between Portals and Social Networking: Replace or Coexist?

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.

Comments

[Stéphane Croisier]

Nice post. I share the same feeling... excepted that there is no real SN Suite out there which is framework-neutral. Most of the SN suite are currently focused on being deployed as fast as possible on customer environement and more on stand-alone dedicated servers. This means that they embedd their own kind of "Portal/Widgets Fondation". Ideally speaking it would be great to see more portable OpenSocial powered Portlets (or gadgets)(at least in the Java world) so that anyone could plug them into any existing Portal Server. On the other hand this also mean that all Portal Server implements for instance OpenSocial. Else you will rapidly have all activities monitoring widget at double, two distinct user profile application, etc... (one managed by the portal and the other one by the SN Suite).

So on the Jahia side (www.jahia.org), an open source WCM and Portal server we were looking for a SN Suite which could act as a complementary offering and which could take care of all these social aspects.... Still quite hard to find for the moment (or at the cost of lots of custom integration)!

I am taking all good ideas ;-).