Monday, May 14, 2007

The need for a Portal architecture

On almost any company’s agenda thesedays is the need to increase flexibility and speed of development for digital services. They are the main tool for implementing business processes meeting ever-changing customer demands. The need for efficient content management have been a base requirement for many years now, but to really unleash the potential of digital services, You need an efficient delivery platform. These are commonly called web portals.

A portal is a point for the person gathering of information and consumption of services in different situations. They provide an excellent way for enterprises to provide a consistent look and feel with access control and procedures for multiple applications, which otherwise would have been different entities altogether.

In choosing a portal platform, it is important to study to what extent the portal products supports the integration of digital services (a k a web applications or simply portlets). Portlets are pluggable user interface components that are managed and displayed in a web portal. Portlets produce fragments of markup code that are aggregated into a portal page. These portlets will typically be targeted to different kind of users both internally, among partners and externally (see previous post on Audience Targeting ).

Typically, following the desktop metaphor, a portal page is displayed as a collection of non-overlapping portlet windows, where each portlet window displays a portlet. Hence a portlet (or collection of portlets) resembles a web-based application that is hosted in a portal. Portlet applications may generic portlets such as include email, weather reports, discussion forums, news and business specific portlets like product search & sales, support issue management.

Portlets may be used as user interface components implementing efficient business processes providing the users a great service experience. Portlet standards are intended to enable software developers to create portlets that can be plugged in any portal supporting the standards.

The new thing is that the business process and the collaboration around these processes, not the web content, is at the heart of the new generation of portal solutions. Important supporting technologies include workflow management (business process automation), document management, forms management, system integration, collaboration, personalization, multi languages and security.

In evaluating portal products, I suggest the following focus areas of investigation:
- Portal application development and portlets
The portal application development and portlets verification aim to investigate the efficiency and ease of portlet development using the recommended portlet standard (web parts, WSRP, JSR168). The distribution of functionality between CMS-tools and portaltools may be a problematic area, especially from a content editor/administrator perspective.


- Interfaces and principles for integration
Evaluating integration options to existing platfirms and systems in the IT infrastructure. Look into how well the products expose their components according to a service-oriented architecture.

- Included portal components
Investigate the level of functionality of the out-of-the box portal components. Document management, collaboration, workflow, search and forms management is particularily interesting.

- Web standards
How well will portal solutions build on each tool conform to accessibility standards such as WCAG (Web Content Accessibility Guidelines)? WCAG is based on specifications from W3C (World Wide Web Consortium) and is aimed for everyone developing content and services for web publication.

The following figure illustrates the necessary components of a portal platform and the composition of these components.



I will deconstruct
this portal architecture in great detail in an upcoming series of posts.

© Copyright 2007, Tomas Elfving

Wednesday, May 2, 2007

Audience Targeting and User profiles in MOSS 2007

The concept of Audience Targeting brings a new dimension to web portal site design. You are not any more restricted to define a single (or maybe two; the unknown's and the logged-in's) target audience, with targets audiences the granularity of user group definition has decreased significantly. You may now distinguish one user from another based on any single piece of information that you have on that user, and customize the services and content presented to that user by dynamically showing relevant Web parts based on the values of the Web part's custom properties. An audience can be identified by using SharePoint groups based on Active Directory, distribution lists, or security groups or by using a rules-based system to create a global audience.

By using Audience Targeting in MOSS 2007, You can define an audience by specifying criteria to define a subset of your user crowd. Once you have defined an audience, you can then configure content such as list or library items, navigation links, and Web Parts to conditionally display its content only when the current user is a member of that audience. This makes it straightforward to target services and content to those users who need it while hiding that content from users who would find it distracting. On an intra-or extranet these groups may be defined as an Active Directory user group like "Project managers" having for project managers customized Web parts presented to them. You can also use custom properties to define audiences for users that You don't store in the Active Directory. It could, for global audiences on an internet eCommerce site, be that You want to give special attention or service on your site to customers that have previously spent more than a certain amount. You don't need to be logged in, the custom properties of a Web Part could be set by using session variables from user interaction, or read from a cookie.

Audience Targeting builds upon another nice feature of MOSS, User profiling. Within an organization, there is generally a lot of information about a user stored in various IT systems. A user has a network login, an EmployeeID, name, an address, a phone number, a title, maybe a photograph, current assignments, time reporting information and the payroll department may have tax and salary information.

This information usually is stored in disparate systems that aren't integrated with each other. The User profiling feature provides a solution by making it possible for all this information to be stored in one system, so that specific content could be targeted to specific users. So, for example, news regarding a project could be viewed only bu people assigned to work on that project. User profiles allow you to associate metadata with every UserID. This metadata can then be kept in sync with the other systems in the organization using the Business Data Catalogue connections or an Active Directory.

User profile has, among others, the following features:


User data can be imported into a User profile from these data sources:

Active Directory is not required, but still the recommended technology for user data storage for MOSS.


On the Microsoft Sharepoint Products and Technologies' blog, they have provided step-by-step instructions on setting up personilazation.


© Copyright 2007, Tomas Elfving