Liferay Portal provides an excellent platform for building web applications, websites, and portals, but recently customers have been looking at a new category of web applications called "social applications." Liferay has several key features to implement social applications.
The definition is simple: a social application is a web application that additionally leverages social: identity, data, and features or services. In the figure to the left, the light blue squares represent a definition of a standard web application while the darker blue squares show the addition of social aspects. First, a standard web application consists of a user interface built to access application logic (e.g., a web form with a submit button allows a user to store fields into a database). Second, web applications are often influenced by a formal identity policy. For example, only persons with a username and password are allowed access, or only individuals within the sales organization in the role of manager are allowed to access the application. Lastly, web applications are often built to interface with external services; e.g., an application allows users to browse an external catalog, select an item, and submit orders into an external order processing system.
Nearly any web application, can also be built as a social application, increasing the productivity of users. Any one of the three areas above can be leveraged to create a social application: social identity, social data, and social features and services. The first area, social identity, however, is important for enterprises concerned about identity management.
Leveraging Social Identity by Adding it to Formal Identity
The right diagram shows how Bob Smith is identified by both his formal and social identities. He has a formal identity that states his membership in the Engineering Organization, Core Engineering Team, Project X Group; plus, he has the additional role of Manager. This formal identity is defined by policy, implemented by people administrators, and is often regulated by SOX compliance.
Enterprises often implement a systems architecture which simplifies access management. First, applications are configured to grant access based on a user's organization, role, and so forth (e.g., ability to access a Sales Portal if they are within the Sales Organization). Second, all applications are configured to point to a central user repository (such as a Directory Server). Lastly, individual user accounts are all managed in the central directory via identity management or role management software. Implementing a formal identity management and access policy or architecture simplifies the management of a large and changing number of users that are accessing an equally large and changing number of applications. It also allows auditing and compliance as all accounts are centrally managed and all access can be centrally audited.
In addition, portals can be used to simplify role-based access control by aggregating applications that do not understand formal identity. The portal allows administrators to define access policies in the portal, which then controls access to applications integrated into the portal. For example, a sales activity page is created and made available to people in the portal if they are in the sales organization.
Standard web applications can be developed to leverage a formal identity in at least four methods. The first, simple access control, is to allow access if a person has a username and password within the centralized directory. The second, node specific access control, allows a person access if they are within a specific organization or role (i.e., you can only access the application if you are in the sales organization or have the manager role). A third method, role-based content delivery, allows a person to access additional content or features based on a person's organization or role (i.e., an individual may get an additional "Sales" tab added to the application's web pages if they are within the sales org, or the individual may be allowed access to the manager's reporting tool if they have the manager role). The fourth, workflow access, allows acces to workflow tasks based on a person's role (i.e., a user can only submit fix tickets if they have a manager role, or a manager will be given alerts to approve fix tickets submitted by their team members and not from other team members based on who they directly manage).
Formal identity policies and portals have been very useful for medium and large-scale enterprises to control access to applications. But today, users can be identified by more than their formally defined-from-the-top-down identity. Each user can also be identified by their social identity. Before social collaboration software, people had social identities. They had friends, they formed groups, and they worked in teams. Within an enterprise, sales individuals would network with engineers and request help from time to time. Engineers in different groups would share ideas on development. Marketers may lead a company softball team. Today, these groupings can be supported by collaborative services. Individuals can form a team calendar or create an engineering wiki or work within a forum. The graphic to the left shows how Bob can access a social collaboration site, which knows he has a friend network which is different than Steve's and Joe's friend network.
Social applications leverage a person's social identity in several forms. The first form is activity streams, where users may see and share activity data or posts by others within their network. For example, you can see microblogging posts from friends combined into a single wall stream. The second is subgrouping, where a user can divide his or her entire collection of friends into a set of teams or groups and can then define access to specific information based on these subgroups (e.g., a user can define that specific content or alerts can only be shared with friends that are also labeled "Family"). The third is grant access control, where user can define content, application or site access based on a friend network (e.g., a user is allowed to view photos from a friend within their network). The fourth is restrict access control, where a user can restrict access based on a persons status (e.g., a user can define parts of their content to be unavailable to search or read). A fifth form is delegation, where a user can delegate tasks or authority to others within their network, (e.g., a user can allow a friend to have ownership rights to a document while allowing others only read access). There are many other forms to leverage this data, (e.g., alerting, presence, tags, equity) but the key for an enterprise is to define an authoritative repository for this social data. Otherwise, each collaboration application will define a different social network for each user, similar to having different Facebook, Tripit, Ning, Orkut and Last.FM accounts and different friends in each.
Leveraging Social Data by Expanding Data Scope
A social application is often designed to have a data scope that is broader or more restricted based on an individual's social identity. In the right diagram, the left application is a standard web application while the one on the right represents a social application. The standard web application has application data, but Bob can only see the application data associated with himself. For example, he may have set a weather portlet to view weather in area code 92009, or he may have uploaded a set of online documents, or he may have created events/tasks into his online calendar. Only he can access this data. Others with access to the same applications will only see their data. Bob cannot see any data from Steve and Steve cannot see things from Bob. In the right example, if Bob is accessing a social application, he can see data that is specific to himself as well as information that is specific to all members in Project Y (that is, if the application was made available to Project Y). An example could be a team calendar, where all individuals can enter events/tasks and all individuals can see the events/tasks entered by the group.
Changing an application to support a new dimension in data scope allows team members to work collaboratively on a range of tasks. Google Docs is a good example in which individuals can together work on a single document, even at the same time. But many applications, which today are built as standard web applications, could provide vast improvements in collaboration if done as social applications. For instance, a team of individuals can work on a web-based tasking system, sharing and collaborating within the application, all available to a self-identified grouping of individuals. Individuals can invite people into a project area for a limited time to help on a specific task, then remove that person's access once it is complete. This could all be done without need for IT group support.
Leveraging Existing Social Features and Services in Social Applications
Social applications can be developed to leverage social features and services available in a social application platform. Liferay provides many applications/fatures that provide collaborative features and can be combined into the use case for the application in development. These services can be grouped into categories as shown below. More than simply adding links, each can become a service within a social application. Take, for example, a new application that needs to be developed that would allow management to assign tasks to a set of telecommunications field workers. This application can include a calendar and task management portlet where teams are assigned group tasks; a wiki, in which individuals can update technical pages; a doc sharing area for technical docs; ability to allow individuals to subscribe to various forum threads on technical topics or specific projects; an initial default UI where several portlet/widget apps are set on the home page but can be customized with other applications; and an ability to include various content, features, and applications based on the user's role. Liferay would vastly simplify the development of this application.
As mentioned, Liferay makes an excellent platform for building a social application. The portal ability to build an application as a set of modules, where features can be grouped into one or more pages, helps to make the application customizable while simplifying the growth of the feature set over time; new features are added as updates to existing portlets or added as new portlets and pages.
Liferay as an OpenSocial Container
Social applications can each implement their own social repository or leverage a centralized repository for social identity. As mentioned above, if each application is developed to leverage its own, then an enterprise with many social applications can have many different friend network definitions for each person, and each new application would require users to re-request friends for the new application. A more efficient method is to create an authoritative source for friend networks and social identity.
Liferay 6.0 implements OpenSocial, which defines both a method to run gadgets and widgets as well as a common method to store and access social identity. This allows enterprises to develop an authoritative source for social identity information. A single Liferay installation in an enterprise allows users to create a profile page, develop a friend network, create and manage new communities or join other communities. This means a social IdM repository for the entire enterprise is developed within that one Liferay instance, which can then be accessed by multiple social applications. New applications, which also support OpenSocial, can be developed and added to the portal (as portlets or gadgets), allowing the new application to use the already defined friend networks for an individual.
Given that Liferay allows the development of multiple sites and portals within a single implementation, the social networks developed by an individual within Liferay can be leveraged across multiple sites developed within the same Liferay portal architecture. For example, users can leverage their friend network across the Sales Portal, HR Portal, and CompanySoftballTeam portal within a single Liferay deployment. Enterprises that leverage this "Enterprise-Facebook" like functionality gain the collaborative capabilities available by popular internet-based social networking sites, but make it secure (behind the firewall) and controlled by formal IdM policy and auditing.
Liferay as a Centralized Social Identity Repository
Additionally, because Liferay leverages the OpenSocial standard, and because Liferay externalizes the definition of the friend network, a single Liferay implementation can be leveraged as the master repository for social networking data as shown left. Applications that also support OpenSocial can point at the Liferay implementation (similar to pointing an application to an external LDAP repository) and leverage a common social identity repository. Enterprises that implement this method will be able to develop a single IdM repository for social data, enabling a single source for collaborative defnitions (and auditing).
