Traditional business models have focused on a process and interaction model that hasn't changed for more than 100 years. This traditional model involves a hierarchical approach where there is an expectation that all good ideas come from the leaders at the top of the organization. This model creates barriers for fully utilizing the core knowledge and experiences of each and every individual within the enterprise. However, with the injection of some fundamental Web 2.0 technologies such as social networks, businesses can finally tap into the knowledge of all their employees, partners, and customers. This notion of collective intelligence is critical for businesses to understand, so they can map these new Web 2.0 technologies into their organizations.

Enterprise Social Networks are made of people who are linked together in some fashion. These linkages can be formal and well defined like an organizational structure, partner network, or a team workspace membership. The social network may also be informal and more fluid in nature based on shared goals, objectives, expertise, or projects. In this case, it is the information and meta-data (or description of the information) that logically links individuals together. Because of their diversity, social networks have broad requirements, and the technologies required to fully deliver on the promise of enterprise knowledge sharing must be comprehensive yet very simple to use.

Key Social Network Enablers
Building a social network requires technologies to create and share information and discover experts. These technologies range from simple tools for users to collaborate and share information to capabilities that help track progress toward specific goals and measure success.

Pages
In a Web 2.0 era, pages are arguably the most important way to share information. Therefore, composing pages must be intuitive, simple, collaborative, and expressive. Wikis are a good start and provide the foundation for collaboration, but they don't go far enough. A more complete list of the necessary capabilities includes:

• Rich and yet extensible set of available resources. Call them widgets, gadgets, portlets, whatever you like, but in order to express knowledge, the right components need to be available for users to compose their pages. Unfortunately, system designers can never anticipate all the user needs nor do they have time or resources to build out every single component. In addition, these pages need to include information from throughout the enterprise, as well as across the Internet. In this case, there are key standards to consider for the page model. They include JSR-168 and WSRP. Both of these standards are familiar in the portal market space but are critical when one considers models for easily plugging new components into an existing set of pages. Therefore, any solution capable of fulfilling the needs of enterprises must support these basic standards.

• In-place rich text editing, including the ability to change styles and themes. Users need a collaborative way of sharing information that isn't dependent on passing around the "right" version of a specific document. Whether it is the entire page that will simply be a text document or a section of the page that requires text, creating a rich text page should be as simple as creating a wiki page, and adding rich text to an existing page should be extremely simple. Every person and every team wants their information and ideas to be presented and appear as clear and professional as possible. However, not everyone has the eye or skills to make their pages look as if an expert designer created the page. Including design styles and themes that can be applied quickly and easily to existing pages will encourage users by making their ideas stand out from all the rest. In this area, JSF provides the key underlying technology called Skins, which allows for these professional styles to be defined by more than just color schemes. Skins can include layouts, look and feel, and basic navigation. JSF Skins combined with some of the other technologies described below are key to providing a much more adaptive user interface.

• Sharing pages with those you want and keeping them private from those you don't. Outside of a well-defined membership space, the common usage pattern is for all pages to be available to everyone. But, for the times where a limited set of users should be the only ones with access to certain information, a user must have the ability to define who has the right to view specific content. Leveraging JavaServer Faces (JSF), the page model enables the application to keep these permissions separate from the rest of the application logic. In addition, JSF provides both the application code and a description about the application. In this way, JSF establishes the foundation for how customizations and personalizations will be saved, accessed, and presented in the context of the application. There is a more detailed description of customizations below.

• Users have high expectations for the way they interact with these new Web 2.0 applications. They expect all the bells and whistles that are available on the public Internet including capabilities such as drag-and-drop component arrangement, dynamic layout changes, in-place component editing without leaving the page, component minimize, maximize, expand and collapse, and partial page refresh of enterprise data. The Apache Foundation started the Trinidad project to enable these AJAX-based controls to foster the open source community to deliver these types of components.

• In order to make everything on the page relevant to a particular user or task, enabling in-context viewing, users want to be able to mashup these components. They also want to combine enterprise information with Internet services. The key standards here are WSRP 2.0 and JSR-286 along with de facto standards like Google gadgets and Web services. They allow one component to pass context to another. The challenge here is that there is no transactional integrity across these two components. JSR-301 provides a key concept of exposing JSF fragments as portlets, so developers can build their JSF applications as they normally would and then expose a portion of the application as a portlet. This also provides developers with a single place to manage their applications and portlets rather than managing two projects: one for the application and one for creating portlets.

• Tailoring a page or application so that it works for every department or line of business is a must. Page customization, common to the portal world, is a very important technology for the enterprise. Allowing each user to modify the page is commonly referred to as personalization. Having an infrastructure that can handle all these customizations and personalizations requires a core service to manage and retrieve all this metadata. More important, these customizations should be easy to change once the application has been deployed. Figure 1 shows how all of these customizations and personalizations get layered to present an application to the user. As mentioned before, JSF provides a description of the application and then key technologies are required to save these customizations as layers. This is required so that when version 2 of the application is deployed, these layered customizations can be added on top of the new version without being lost. Developers require a set of JSF components that have this customization architecture built-in to minimize the complexity of leveraging such a powerful solution.

Figure 1: Layered customizations are essential for adaptive applications.