Since we’re heading to Digital ID World next week, we thought it might be interesting to show a demo of why virtual directories can help companies build social media driven applications. This post is a follow-up to my previous blog posts on “Virtualizing Social Networks” (Part 1, Part 2 and Part 3) by using a virtual directory to incorporate social media information into a virtual directory like Radiant Logic’s RadiantOne VDS. Our demo shows how you can leverage Twitter to promote products to your users based upon the people following and followed by the user.
Here is the general scenario. Company A is building a portal and would like to expose enhanced information to their customers. They are interested in enriching their user profiles by combining social network information into the data. This makes the information available in the portal more relevant for the users. They decide to start by incorporating information from Twitter into the system. This will allow them to promote products purchased by people following the user and whom the user is following. The following identity/data repositories are involved:
Enterprise Directory containing a list of all users in the portal
Order database
Twitter
One of the key requirements is that they want to minimize the application development costs and also position themselves for incorporating other social networks. They decided to leverage a virtual directory to create a view into the identity and data repositories which allows them to easily consume this information within their application. This also allows them to incorporate additional social networks without making other application changes.
Our demo highlights how you can easily incorporate data from Twitter and combine the data with information coming from both the enterprise directory and the order database without needing to make significant application changes or modify the underlying data sources. The following diagram highlights the logical design:
We used the following approach to create the demo:
Created an Enterprise Directory with the list of customers
Joined the customer directory to the order database to get a list of products purchased by the user
Joined the customer directory to Twitter to get the list of followers and who the user is following
Set the Twitter handles of other users in the VDS store to Twitter handles that match so that we show the relationships (note that we could use something like ICS to do more sophisticated matching without necessarily needed the matching Twitter ID)
The demo shows how to create two different directory tree structures for consumption by the portal:
The “Following View” shows the orders purchased by the user and the people following or being followed by the user on Twitter. The “Purchased View” extends this information to show what products have been purchased across the user’s social graph.
As a sneak peak, here’s a video walking you through what we are showing:
Here is the third and final post on my proposed model for using a virtual directory to create social graphs. It only took a couple bunches of bananas to get Charlie to let me finish my post. It seemed like a good bargain.
In Part 1, I presented the case for using a virtual directory to integrate social networks for the identification and representation of relationships. In Part 2, I presented the value of virtualizing social networks.
In this final installment, I wanted to present a theoretical use case for a fictional company called, MyNewsBox which allows users to find interesting news tidbits from across the internet and store them in a suitcase for reading at a later point in time. They have been reading a lot about social media and decided that they would like to extend the capabilities of their existing application to make it more “Web 2.0“. They also have a new application in the works that will allow user to set up projects and track the dependencies between the projects so they are able to get a quick view how project changes impact the overall delivery of their broader program.
MyNewsBox identified the following requirements:
Allow users to find interesting stories across Twitter and Facebook and add them to their news box
Create the ability to share news items with other users
Recommend other news items that the user might find interesting
Suggest other users with similar interests and allow them to subscribe to their news box
Easily add new networks without have to make major application changes
Create a framework that can be leveraged for new application development efforts
After spending several weeks investigating similar applications, they settled on the following interface design:
The new interface highlights the connections between the the user and their stories, suggests new stories and also recommends new friend connections. MyNewsBox decided to approach the new application changes by creating a base framework that managed the connections and relationships between users. They based the framework on top of a virtual directory. Since they already had user information in the system, they saw additional value in that the virtual directory allowed them to access existing local information and new information from the social networks all through a single point. MyNewsBox then used the Java API’s to build basic connectors for Twitter and for Facebook. They then updated the application to provide the option for their users to enter the Twitter and Facebook identities into MyNewsBox. Through explaining the value of the new features, MyNewsBox hopes to be able to get a significant number of users to add the additional account details.
Once the user information for Twitter and Facebook is collected, MyNewsBox created views into the information which allow the application to make three queries:
1. Find users on the system who have friends in common on Twitter and Facebook, but are not yet connected on MyNewsBox.
2. Find people who have similar interests defined on Facebook so that the news stories that they have saved can be recommended to other users with common interests.
3. Return Facebook interests for a user so that when a user searches for new stories on Twitter, those Facebook interests can be used as keywords.
These views were both created in the virtual directory and made available so that any application could easily obtain this information by making a SQL call to the virtual directory. Since the business logic is based upon configuration in the virtual directory, nothing needs to change in MyNewsBox once Twitter starts letting users tag their interests and types of relationships. After creating their social network virtualization framework, the application changes required were very minor and mostly consisted of user interface updates to show the new information being queried from the virtual directory.
After gauging the success of the changes to MyNewsBox, they started work on the new project dependency application. One of the key requirements for the new application was to create communities for people working on common projects. They felt that LinkedIn provided an easy way to identify users of the same company and show them a view of all of the projects going on at that company. The users would then be able to send a notification requesting access to the project. Instead of building a standalone connector for the new application, MyNewsBox added this connection through the virtual directory. After adding LinkedIn, they created a new view which the project dependency application used to determine common connections within the same company. After adding this connection, MyNewsBox was also able to take advantage of this new information in their existing application simply by adding the ability for users to define their LinkedIn account information and by updating the views in the virtual directory to include the new business logic. No other application changes were required. MyNewsBox was able to also activate the persistent cache in the virtual directory to deliver this information across all of the social networks with a high level of performance. Since the cache was a configuration on the virtual directory, no coding was needed to take advantage of this improved performance.
Hopefully this helps to explain why adding an social network abstraction layer through a tool like a virtual directory is an interesting approach. Thanks for taking the time to read through this information. I would love to hear your feedback.
Hello again! I guess Charlie is in a generous mood. He decided to let me post Part 2 on using a virtual directory to create social graphs. Yesterday in Part 1, I presented the case for using a virtual directory to integrate social networks for the identification and representation of relationships.
Here was the model I presented:
Real-time searches of the networks for user information are possible by hooking the virtual directory connectors up to the various social networks. By allowing users to setup their own accounts, you can ensure that the data is accurate and that users have opted-in to having their information included. Attributes of the correlated user identities are used to represent the relationships and types of relationships that user has in the context of the configured social networks. User information can then be pulled together across the social networks creating a unified profile in the virtual directory. These profiles allow applications to derive the links between the defined accounts and others with accounts defined in the virtual directory by crawling the relationships to contextually understand the users’ relationships.
So the next question and the focus of this post is what value a system like this would bring. Jeremiah Owyang has a nice post outlining how to explain the social graph:
“Users: For users this means efficiency and control over one’s personal data, their relationships, and how they are deployed on different social networks, it makes navigating the web better.
Social Networks: For companies that are social networks, they can benefit by increasing the amount of users as the social graph will populate all of a users network they permit.
All other websites: For companies that are not currently social networks, (like a corporate website) expect these social features to be part of your site. People will co-surf and share information about your content whether you like it or not.”
Creating this model in the virtual directory provides a significant advantage for companies building applications for both internal and external consumption. All applications can leverage the virtual directory as a hub both for the creation and retrieval of account information and to easily understand the relationships between the registered users. New applications can instantly take advantage of this information to make recommendations for interest-based connections to other users and display targeted information. The virtualization platform creates an extensible model for building viral applications without each application having to understand the underlying social networks. This model also lends itself to being able to layer on additional services like single sign-on and federation (e.g. Facebook Connect). As I browse across the various sites, identity information relevant to the network can be presented allowing me immediate access into the system without being re-challenged.
As we move more towards an interconnected world, the value of virtualization becomes more significant. Companies will need the capabilities to quickly leverage new social networks and to easily allow users to collaborate across networks and to participate in those conversations.
Any additional ideas or feedback would be appreciated. In Part 3 I plan on covering a possible real-world use case for this type of a solution.
Hello again. Well, I’d like to introduce one of my assistants, Todd. He stopped by to talk about how the same principals that can be applied to identity virtualization can also be applied to social network virtualization. I don’t like to let him out much, but I figured that one post here every so often can’t be that bad. I’m curious to hear what you think… In any case everyone say hi to Todd!
- Charlie
Thanks Charlie for the introduction. As I thought about identity virtualization and how CoreBlox used virtual directory technology for our Identity and Access Management (IAM) projects, it seemed this same logic could be applied to social network virtualization. There are several virtual directories out there, but for the purpose of the post I am going to use RadiantOne from Radiant Logic as the way to describe virtual directory technology.
Identity virtualization means the following to me:
Layer of abstraction between identity consumers and identity providers
Allows for mapping and correlation of identity information (e.g. one user identity across many systems)
Application oriented views of identity information (e.g. what systems can be accessed by the user, and what permissions does the user have in each system)
When virtualization is applied to social networks, this is often referred to as a Social Graph. A good description of social graphs can be found on the ReadWriteWeb (RWW) site:
While these articles are a little on the older side, I think they are still fairly relevant. RWW defines a social graph as:
“Our society spawns one gigantic social graph. In this graph, each one of us is a node. There is an explicit connection, if we know each other. For example, two people can be connected because they work together or because they went to school together or because they are married.”
While there are API’s for constructing social graphs (Google’s: http://code.google.com/apis/socialgraph/), the virtual directory already has all the pieces necessary to identify and understand these relationships. To steal from an image I used in a recent presentation I did at TEC 2009, you can visualize identity virtualization as follows:
So, the virtual directory allows you to apply the following functions to populations of users:
Aggregation: Bring the user populations together so that they appear as the superset of all of the user populations. This creates one view of the users and surfaces this information through one access point (or protocol).
Correlation: Determine the union of the various user populations. So, by taking common attributes you can create the unique identity that represents a user across all of the populations.
Integration: Understand the context of identity information. This gives you that “Single version of the truth” that allows virtual directories to link back to the identity providers in the right context and the right process by fully understanding the relationships between the identities.
So, if we applied this same logic to social networks, the virtual directory can bring those relationships between users to light simply by leveraging capabilities that are already embedded in these products. The diagram for this might look something like this (the virtual networks listed there are just to show a sample of what could be included):
In this model, aggregation is accomplished through defined connectors into the various social networks to show the overall population across the networks. Since the enormous user populations would make viewing all identities across these networks impractical, you could instead provide a means of searching for a given user’s information in real-time.
Similarly, correlation is delivered through account mapping where each user defines their accounts across all of the social networks in which they participate. Allowing users to setup their own accounts ensures that the data is accurate and also allows users to opt-in by creating only the accounts that they would like to have included.
Finally, integration represents the relationships that a user has to other users on the subscribed social networks and, if possible, an indicator as to the type of relationship. So, for Facebook this would be my friends, for Twitter my followers and those that I am following, and on Flickr my friends and family.
Once I have this information and the mappings are defined in the virtual directory, I can easily use it to pull together information about people across those networks. Basically my account mapping gives me a unified profile in the virtual directory, which can be used to pull in information about me from each of my subscribed networks. I can also derive the links between the defined accounts and others with accounts defined in the virtual directory by crawling the relationships. For example: if I select three people from the virtual directory with Facebook accounts, I can view the friend lists for each of those people. If I see that person A has a relationship with person B and person C has a relationship with person B, I can then start to understand the links between all of the users. Finally, my defined interests on each of the social networks allow me to understand the context that I have both to the networks and to other users of the system. So, if on Facebook person A has interests in Apple and Skiing and on LinkedIn person A has interests in Social Media and IAM, I can relate the unified identities to other unified identities based upon their defined interests and their specific social network link. All of this information can be represented as my attributes in the virtual directory.
Data in the virtual directory is exposed through various protocols. So, applications could access this information through LDAP, SQL, or by making web service calls to pull the information needed to display the social graph. Leveraging the abstraction of the virtual directory allows the viewer to structure the data relationships by different attributes without modifying the underlying structure of the data itself. Additional social networks can be added in (or removed) on the fly without changing the consumers of this information. Since the virtual directory also provides LDAP’s model of security, its information could be secured at a fine-grained level of access which could help to alleviate privacy concerns with access to this information.
Due to the sheer volume of the information available across social networks, it would need to be shown that virtual directory technology can scale to this amount of data and to the complexity of the joins required to create views into the various relationships. Leveraging the caching capabilities of the virtual directory should help, but a proof-of-concept would highlight where there are limitations.
Hopefully this provides a solid overview of the approach. I am definitely interested in hearing feedback and ideas. I will post additional information as we gain more clarity into this approach.
In Part Two I will follow-up with some additional details on ways of putting this type of a system to use (assuming Charlie will have me back!).
Here is the third and final post on my proposed model for using a virtual directory to create social graphs. It only took a couple bunches of bananas to get Charlie to let me finish my post. It seemed like a good bargain.
In this final installment, I wanted to present a theoretical use case for a fictional company called, MyNewsBox which allows users to find interesting news tidbits from across the internet and store them in a suitcase for reading at a later point in time. They have been reading a lot about social media and decided that they would like to extend the capabilities of their existing application to make it more “
Hello again. Well, I’d like to introduce one of my assistants, Todd. He stopped by to talk about how the same principals that can be applied to identity virtualization can also be applied to social network virtualization. I don’t like to let him out much, but I figured that one post here every so often can’t be that bad. I’m curious to hear what you think… In any case everyone say hi to Todd!
