An Executive’s Guide to Portals - CRModyssey.com … · How to Position Portals within Your Overall IT and E-Business Strategy.....5 The Future of Portals On Doors, Windows, Workspaces,

85 Devonshire Street, 5th Floor, Boston, MA 02109 • Phone 617.742.5200 • Fax 617.742.1028 • www.psgroup.com

Patricia Seybold GroupSt ra teg ic Consu l tan ts & Thought Leade rs

An Executive’s Guide to Portals What Customer-Centric Executives Need to Know about Portals

By David S. Marshak and Patricia B. Seybold

Pat

rici

a S

eybo

ld G

roup

’s E

xecu

tive

Ser

ies

© 2003 Patricia Seybold Group

TABLE OF CONTENTS

Foreword: What Customer-Centric Executives Need to Know about Portals A Customer-Driven Approach ......................................................................................................... 1

What’s Your Portal Strategy? How to Position Portals within Your Overall IT and E-Business Strategy ..................................... 5

The Future of Portals On Doors, Windows, Workspaces, and Adaptive Portals.............................................................. 16

Portals—What Companies Care About Results from Our Portal Survey..................................................................................................... 19

The State of Portlet Standards Clearing Up the Confusion ............................................................................................................ 28

On Adaptive Portals and Contextual Collaboration Is It the Perfect Match? ................................................................................................................. 36

Portal Framework Our Framework for Evaluating and Comparing Portal Platforms ............................................... 42

Portal Platform Evaluation Framework Matrix ............................................................... 56

What’s Next? If you find this report valuable, then: Print It – YES, you are free to print and freely distribute this report as long as its contents are not changed.

Send It – Send a friend or colleague to http://www.psgroup.com/vm/portals/ so they can download their own copy.

Stay Informed – Subscribe to our free e-mail newsletter at http://www.psgroup.com/signup.asp to stay up-to-date on this and other important research topics.

Contact Us – Contact us at [email protected] to find out how our additional research and consulting services can help your organization sort through its Web Services strategy.

Customer Scenario and Customers.com are registered trademarks and Customer Flight Deck and Quality of Customer Experience (QCE) are service marks of the Patricia Seybold Group, Inc. 85 Devonshire St., 5th Fl., Boston, MA 02109 USA • www.psgroup.com

An Executive’s Guide to Portals

What Customer-Centric Executives Need to Know about Portals A Customer-Driven Approach

By David S. Marshak January 2003

WHY SHOULD CUSTOMER-CENTRIC EXECUTIVES CARE ABOUT PORTALS?

Portals are Web pages that customize and aggregate information for specific constituen-cies. In general, portals provide:

• A custom framework for presenting pages and components within each page and or-ganizing information for specific constituencies

• Personalization capabilities for individual users

• A set of “portlets” (the components that integrate with data, applications, content, and resources and actually present information to the portal user)

• A single sign-on to the set of applications accessed via the portal

• Other features, such as search and collaboration

Our definition expands to include the evolution of portals as methods to provide specific experiences to a set of constituencies and to support the specific scenarios of each con-stituent1.

We divide portals into two forms of these scenarios: 1) task-oriented portals and 2) cus-tom workspace portals2.

When most business executives hear the word, “portal,” the idea of an employee access-ing HR information is the first thing that tends to pop into their minds. Common usage and industry hype centers on how employee self-service portals can save companies time and money. Indeed, common wisdom states that the majority of portals currently being planned and implemented are targeted at this constituency. But you, as a customer-centric executive, understand that portals should be designed not merely for tactical employee needs, but as a strategic part of your overall customer experience.

1 See “The Future of Portals,” http://www.psgroup.com/doc/products/2002/5/PSGP5-30-02CC/PSGP5-30-02CC.asp. 2 See “What’s Your Portal Strategy?” http://www.psgroup.com/doc/products/2002/8/SG8-8-02CC/SG8-8-02CC.asp.

What Are Portals?

Why Are Portals Strategic?

2 • An Executive’s Guide to Portals


There are two dimensions to a customer-focused portal strategy:

• Direct Customer Portals. • The Customer Impact of Employee and Partner Portals.

DIRECT CUSTOMER PORTALS. Customer-centric executives should be focused on using portals as methods of bringing information directly to customers, and customer-oriented portals. According to our portal survey3, (and contrary to common wisdom), cus-tomer portals are being implemented or planned by almost 80 percent of our readership. In fact, the customer portal (narrowly) beats out the employee portal as the most frequent initial implementation. Many of these customer portals have evolved from customer pre-mier pages and other methods of enabling high-value customers to interact directly with their suppliers. Other customer portals have evolved from e-commerce and customer self-service Web sites more oriented towards smaller businesses and consumers.

CUSTOMER IMPACT OF EMPLOYEE AND PARTNER PORTALS. Indirectly, em-ployee portals (not to mention other portals, such as those for suppliers, channel partners, etc.) also impact customers. Providing the right information and tools to employees can make it much more likely that customers will receive correct information and timely as-sistance. It will also make employees at least appear to be more customer-oriented. Moreover, using portal initiatives to streamline internal processes and making employees more productive will have an impact on the way customers interact with and perceive your business.

Portals should be seen as a strategic tool in the customer-centric executive’s arsenal. As such, they should be approached with the same customer focus as any other e-business initiative.

In her best-selling book Customers.com, Patty Seybold put forth eight critical success factors to making it easier for your customers to do business with you.

1. Target the Right Customers 2. Own the Customer’s Total Experience 3. Streamline Business Processes that Impact the Customer 4. Provide a 360° View of your Customer’s Relationship 5. Let Customers Help Themselves 6. Help Customers do their Jobs 7. Deliver Personalized Service 8. Foster Community

These principles provide basic guidelines for building portals (both direct customer por-tals and employee or partner portals), particularly if we extend the term, “customers,” to include all of these constituencies. A note here: While we accept the terminology that the target constituency is the “customer” for any portal, we strongly urge (and practice with our own clients) the design of all business processes from the end-customer-in rather than from the inside-out. This even extends to employee portals, where the design should be

3 See “Portals: What Companies Care About,” http://www.psgroup.com/doc/products/2002/6/SA6-20-02CC/SA6-20-02CC.asp.

A Customer-Driven Approach to Portals

Foreword • 3


from the point of view of the employee—making his or her life easier and more produc-tive.

TARGET THE RIGHT CUSTOMERS. Since portals are built around specific constituen-cies (customers, partners, employees, retirees, etc.), they are already targeted. The keys are to target at the right granularity—is there a portal for all customers or a separate one for business customers and consumers?—and to prioritize based on the impact on your most important customers.

OWN THE CUSTOMER’S TOTAL EXPERIENCE. Portals are all about providing a total experience. They should be designed to ensure that all of the information, tools, and re-sources can be easily accessed (preferably without logging in more than once). External resources (e.g., logistics partners for shipping information within customer portals and financial service partners for 401K information within employee portals) should also be accessible without leaving the portal environment.

STREAMLINE BUSINESS PROCESSES THAT IMPACT THE CUSTOMER. We are finding that portals are not simply facades that you put in front of your existing processes. They surface and call into question many previously “back-box” processes. Portal also provide the opportunity to redefine customer-impacting processes at the portal level—this being simpler than re-engineering and integrating multiple back-end systems.

PROVIDE A 360° VIEW OF YOUR CUSTOMER’S RELATIONSHIP. Portals, by their nature, enable the presentation from multiple sources of information in a single place. Thus, any customer portal should include all information about the customer and his or her relationship to the business. Likewise, any portal for a customer-facing employee should also include all of the same information. This points out a key tenant of portal strategy—separate portals will often contain the same information. Therefore, they may best be implemented as a single portal with different secure views and experiences for each constituency.

LET CUSTOMERS HELP THEMSELVES. Self-service applies to all types of portals. They key is to make all of the information and resources available to the customer trying to complete a task—and walking them through the task is even better. In addition, cus-tomers (and partners and employees) may want to access the portal via different devices (cell phones, PDAs, etc.) or they may want to move between devices when tying to ac-complish their tasks. For example, they may want to begin to solve a problem on the por-tal site, then talk to someone, and finally get an e-mail confirming the solution. In order to make this a seamless experience, portals need to be designed to support multiple forms of interaction as well as supporting multi-session, multi-touchpoint scenarios.

HELP CUSTOMERS DO THEIR JOBS. One of the most impressive developments in por-tals is using them to create custom workspaces for specific jobs and roles, where all of the information, resources, and tools are readily available for the user. Most of these tend to focus on internal jobs—sales people, customer support, help desk, etc. However, there are workspace portals for customers (generally business customers) with specific roles, such as procurement or systems management.

DELIVER PERSONALIZED SERVICE. Portals support both customization and personal-ization. Customization can be applied at the constituency level, the group or role level, or the individual level. Customization can include specifying look-and-feel, branding, and



other UI behaviors. It can also include which information the group or individual can ac-cesses and where and under what conditions the access appears. Individuals can also be allowed to personalize many elements of a portal, including look-and-feel and which Portlets they will see, in what location, and what form (minimized, maximized, normal sized).

FOSTER COMMUNITY. Portals provide a great opportunity to build and support com-munities4. Because portals are designed around specific constituencies, communities of interest and practice are frequently self-identifying and easy to support via the various collaborative tools supported by almost all portal platforms.

Of course, if you are in charge of the portal initiative, you will have to make a product decision. Our “Portal Framework”5 will help you evaluate products, as will the set of product reviews. However, equally important to the specific product selection is working with IT on an overall portal architecture. Far too frequently we are seeing multiple portals initiatives (often with different products) that do not even know about each other, much less being built with a common architecture. We believe that portals can be seen as the first implementation of service-oriented architectures, and we are working with our cli-ents to make sure that the investments in portals and the services that are consumed by portals are leverageable as they move forward.

We also think it is important to keep up the standards efforts in the portal arena, particu-larly as they relate to the portability and interoperability of Portlets. The current efforts are discussed in “The State of Portlet Standards6.”

The area on which we have been spending the most time with our clients is taking a cus-tomer-centric approach to defining the metrics and ROI that can be associated with a por-tal initiative. Here too, our customer-focused methodologies—Customer Scenario® Mapping and Customer Value Prioritization—are proving valuable in setting expecta-tions and defining priorities. Executives wishing to learn these techniques are invited to attend one of our upcoming Portal Executive Seminar Sessions.

4 See “On Adaptive Portals and Contextual Collaboration,” http://www.psgroup.com/doc/products/2002/8/PSGP8-15-02CC/PSGP8-15-02CC.asp. 5 See http://www.psgroup.com/doc/products/2002/12/FW12-12-02CC/FW12-12-02CC.asp. 6 See http://www.psgroup.com/doc/products/2002/9/TA9-12-02CC/TA9-12-02CC.asp.

Choosing a Portal Platform

Defining Portal Metrics and ROI



What’s Your Portal Strategy? How to Position Portals within Your Overall IT and E-Business Strategy

By Patricia B. Seybold and David S. Marshak

NETTING IT OUT Portals are hot! E-Business is not. As the portal fad continues, many companies are in danger of increasing the complexity of their operations and infrastructure.

Our suggestion: You should combine your e-business and portal initiatives into a single, comprehensive, and pragmatic strategy. You should leverage the learning and the invest-ments you’ve already made in developing and delivering Internet, intranet, and extranet Web sites. But you should take advantage of this portal phase to accomplish three goals:

1. Redesign your business from your customers and constituents back.

2. Rationalize your redundant Web sites.

3. Prioritize and re-architect your IT application and infrastructure services and your customer-impacting business processes.

Here’s how we recommend that you explain your pragmatic portal strategy to your man-agement and board:

“We can use portals to provide customer ex-periences that deliver desired outcomes to groups of customers and other constituencies.

We can take advantage of portals to redesign our business processes to be customer-centric.

By implementing portals for each constituency we serve, we can hide the fact that our applica-

tions were not originally designed to serve these constituencies well.

We can experiment with portals to get the cus-tomer experience right; we can quickly adapt customer experiences and alter business proc-esses.

At the same time, we can redesign our back-end systems and processes using a services-oriented architecture to create a more flexible, dynamic and adaptive business.”

ISSUE: WHAT’S THE ROLE OF PORTALS IN YOUR (E-)BUSINESS STRATEGY?

We’ve noticed a distressing trend afoot: Many companies are embarking on portal initiatives as if portals should be distinct from the organizations’ existing e-business operations. This is a mistake. Portals are e-business initiatives.

If your organization is like most others, you probably have ongoing e-business activities in the form of e-commerce Web sites; partner, customer, and/or supplier extranets; as well as employee intra-nets. You probably also have several portal projects underway: employee portals, customer portals, part-ner portals, and so on.

Unfortunately, we are finding that, rather than reducing complexity, many companies’ portal pro-jects are often introducing more complexity. That’s because management is unclear about both the role of portals and the current role of e-business within their organizations.



What Should Your Portal Strategy Be? We believe that you should be using a portal ap-

proach (whether or not you call it a portal7) to achieve three goals:

1. To make it easier for different constituencies to do business with your firm by providing them the tools, information, and resources they need to achieve their goals. These constituencies probably include different types of customers (by customer segment), different groups of em-ployees (by roles), distribution partners and other business partners (your bankers, marketing partners, etc.), suppliers, government agencies and/or regulators, investors, and so on.

2. To rationalize your existing Internet, intranet, and extra-net Web sites in order to re-duce duplication of effort.

3. To transform your business processes and IT infrastruc-ture by redesigning from the outside-in while you refine customer-impacting business processes and re-architect IT to leverage common application services.

We also believe that your portal initiatives and your e-business initiatives should be tightly coordi-nated with your customer experience initiatives—including CRM, contact centers, Point of Sale (POS) and in-store navigation, channel partners, inventory availability, billing, quoting, service, delivery, and so on—as well as with your customer profitability analysis.

Portals Are Hot! E-Biz Is Not E-business is “out” and portals are “in.” That

means that, for many of you, e-business budgets and staffing have been cut, while portal projects are get-

7 There’s so much confusion about the meaning of the

term “portal” within many businesses that some people simply refuse to use the term. Yet, many of the companies who eschew the term are still embarking on “portal” strategies.

ting management’s attention. That’s also why many companies are in danger of re-inventing the IT infra-structure wheel, once again. Here’s what we see happening in a number of companies.

E-BUSINESS IS PASSÉ. In the aftermath of the dot-com bust, many executives and board members are embarrassed by the scale of their erstwhile e-commerce ambitions. As reality has set in, they’ve realized that they are never going to spin these op-erations off as separate companies with their own money-making IPOs, nor will their company gener-ate lots of additional revenues just because it has an e-commerce Web site. The backlash has taken hold. E-business budgets are being cut, staffing has been

pared down, and, unfortunately, projects to sell more products direct via the Web are being back-burnered.

However, these same organizations still have public Web sites with sections for prospects, customers, investors, and prospective employees, and sub-sites for each of their major product lines. They also have transactional e-commerce sites,

interactive customer support sites, secure customer extranets for their largest accounts, private partner extranets for their dealers, and employee intranets. By now, most companies also have Internet-based supply chain management systems.

Thus, companies’ e-business initiatives haven’t disappeared. They’ve simply become the way we all do business. We use the Internet as our communica-tions infrastructure and as the means by which we access information and applications. E-business ini-tiatives, in the form of interactive Web sites, extra-nets, and intranets, have enabled us to expose our products, pricing, and many core business processes to a variety of constituencies. These e-business pro-jects have often been the catalysts for change within our organizations. Our e-business initiatives have revealed many of the inconsistencies in our internal processes, raising long-buried customer-impacting issues to the top of the priority list. E-business is the use of the Internet to streamline and transform the way we do business.

However, for many businesspeople, e-business is now unfortunately tainted with the dotcom brush.

We believe that your portal initiatives

and your e-business initiatives should be tightly coordinated

with your customer experience initiatives.

What’s Your Portal Strategy? • 7


The good news for e-business leaders who have been caught in the post-dotcom doldrums is that portals offer a safe haven within which you can continue transforming your business to make it more cus-tomer-adaptive.

PORTALS ARE PRAGMATIC. The same board members and executives who cringe at the “e-word” are enthusiastic about portals. Business people like portals because they think they understand them. They understand that there are customer portals, em-ployee portals, partner portals, sales force portals, human resource portals, and so on. This makes prac-tical sense. Business people recognize that a portal is a place to go via the Internet that pulls together the in-formation and resources to serve a particular set of us-ers’ needs.

Each portal pulls to-gether information, re-sources, and applications for a particular group of people who have a particular set of things to do. So, theoreti-cally, portals are a great way to make sense of all the information and applications in which our company has already invested. Instead of being perceived as a risky futuristic business investment, like an e-business project, portals are currently viewed as be-ing a sound way to harvest the investments we’ve already made in IT.

So, portals are pragmatic and useful ways to de-liver functionality and information via the Internet to groups of people who have common needs. By fo-cusing on the audience for each portal and the needs of that audience, it becomes straightforward to pull together a set of resources and to present those re-sources to that audience via a semi-customizable Web site.

Portal Platforms Abound There is now a growing set of maturing informa-

tion technology tools and solutions—portal plat-forms—to help you develop, deploy, and manage your portals. These off-the-shelf solutions are tool-kits that help your technology team:

• Aggregate and deliver information from a vari-ety of internal and external resources

• Wrap up and deliver application functionality from your existing IT systems and from external applications

• Enable single sign-on and authentication for the applications and resources that end-users access via the portal

Offer customization capabilities to portal owners and basic personalization ca-pabilities to end-users

Portal platforms are de-signed to help you create multiple, purpose-built Web sites for different groups of constituents, using a “cookie-cutter” approach. Like any cookie-cutter approach, por-tal platforms have con-straints. They are not de-signed to handle e-commerce functionality—although you

can plug transactional capabilities into a portal via a portlet (a set of application functionality that is ac-cessed via a portal window).

Portals come with a pre-defined set of windows or frames, with a presumption about the kinds of things you’ll want end-users to be able to see and do in each type of window—view the latest content, see alerts or bulletins, run a wizard to accomplish a task, access reports and drill down into more detail, query databases, enter information into forms, and so on.

For e-business designers who are used to creating their own custom-built Web sites for each set of functional requirements, portal platforms can be both a blessing and a curse. They make some things easier to do and other things more difficult.

For example, the integration of multiple applica-tions should be easier with a portal because portal platforms offer standard interfaces and mecha-nisms—variously called “portlets” or “gadgets” or “Web Parts”—that enable developers to wrap appli-cation functionality and make it available via portals. And it’s easier to deliver a collaborative workspace using a portal because many platforms have one al-ready built in.

The good news for e-business leaders

who have been caught in the post-dotcom doldrums

is that portals offer a safe haven within which you can continue

transforming your business to make it more customer-adaptive.



By contrast, tuning the performance on a portal can be more problematic than performance-tuning a “built-from-scratch” application. There are lots of variables and interfaces you may wind up needing to tweak.

A PORTAL INITIATIVE CAN MAKE IT EASIER FOR FOLKS TO DO BUSINESS WITH YOU

A portal strategy can help you make it easy for different constituencies to do business with your firm. We think of each portal as a workspace for people with particular jobs to do or for people with certain tasks to accomplish.

Most of today’s portal implementations fall into two categories: Dedicated Workspace portals or Task Resource portals (see Illustration 1).

• Dedicated Workspace Portals. A Dedicated Workspace portal is a place where employees or other stakeholders “hang out” to do their day-to-day jobs. Sales people spend their day working out of their Sales Force portal, for example. It lets them manage their customer opportunities, generate proposals, pull together competitive in-formation, and close deals.

• Task Resource Portals. A Task Resource portal is a place where people go to accomplish a cer-tain set of tasks. Employees go to your HR por-tal to file a health insurance claim or to request maternity leave. Customers go to your com-pany’s Help Desk portal to resolve a problem.

Both of these types of portals have something important in common. They are designed to make it easy for the end-users to perform a set of tasks—either the tasks required to do their jobs or the tasks required to solve a problem or to get something ac-complished. (See Illustration 2.)

Use Your Portal Initiatives to Design Your E-Business from the “Customer’s” Point of View

Your Sales Force portal is a dedicated workspace that your salespeople work from most of the day.

Your HR portal is a task resource that employees go to in order to accomplish certain tasks. Your Small Business portal is a task resource that prospects and customers in small companies use to streamline their interactions with your firm and its partners. In all three cases, there’s a set of scenarios these end-users need to do and a set of desired outcomes they need to accomplish for each scenario. You design your portals to help them accomplish those outcomes.

FOCUS ON CUSTOMER SCENARIOS. When someone asks you to create a portal for a particular group of people—your field sales force, your distri-bution partners, your largest customers—they’re really asking you to get into the heads and minds of a group of people who have a common set of tasks to accomplish. They’re asking you to understand what it is that these end-users need to accomplish and to design “fast paths” for them to accomplish those outcomes. We call that Customer Scenario® Design and it’s the key to good portal design. (See Illustration 3.) We define a customer scenario as a set of tasks a customer is willing to do to achieve his or her desired outcome. For each group of custom-ers, there are typically three to six core scenarios and several ancillary scenarios you’ll want to streamline. (See Illustration 4.)

A PORTAL STRATEGY CAN HELP YOU RATIONALIZE YOUR E-BUSINESS INITIATIVES

What should be the relationship between the e-business initiatives you’ve done in the past and your portal initiatives of today? The good news for most of you is that portals are maturing just in the nick of time! Many of you are struggling with an overload of separately created and maintained Web sites, each of which sprang into being to address a specific need—customer support; online catalogs and e-commerce; country-specific offerings, pricing, and policies; large account-specific Web sites; partner extranets; departmental Web sites on employee intranets; and so on.



Dedicated Workspace Portals

Sales Person HR Exec Manufacturing Mgr

MySales.com

MyJob.com

ABC

MyHRManager.com MyFactory.com

ABC

ABC

Task Resource Portals

Customer HR ExecManufacturing Mgr

MyTasks.com

ABC

MyTasks.com

ABC

Supplier.com

XYZ Company123 CorpABC Inc.

SSOrder PricingInventory & Availability

CompanyBenefits.com

Health InsuranceAbsenceRetirement

CompanyBenefits.com



TravelPlanning.com

FlightsCar RentalHotelsBudget

© 2003 Patricia Seybold Group, Inc.

Illustration 1. Portals, today, tend to come in two flavors: Dedicated Workspace Portals and Task Resource Por-tals. Dedicated Workspace Portals, depicted at the top of this illustration, are designed for groups of employees who have a similar job to do, such as sales people, HR managers, etc. Each portal contains all the tasks and re-sources these people need to do their jobs, and the employees typically spends most of their days accessing work from within these workspaces. Task Resource Portals (at the bottom of the illustration) are designed for occa-sional use by people who have a set of related tasks to perform. For example, benefits administration might be a Task Resource Portal that employees and their spouses might use (CompanyBenefits.com).



Use Customer Scenarios® to Help Portal Users Get Tasks Accomplished

MySales.com

ABC

Schedule a Customer Meeting

Prepare a ProposalSchedule a Customer Meeting

CompanyBenefits.com

ABC



TravelPlanning.com


Sales PersonSales Person

Submit a Health

Insurance Claim

Request Paternity

LeavePrepare a Proposal

Plan a Trip


Illustration 3. Each portal should be organized around a set of customer scenarios—the tasks that users are will-ing to do to achieve their outcomes.

Relationship between Workspace Portals and Task Resource Portals

CustomerPurchasing Agent

Employee

MySupplier.com


SS Order PricingInventory & Availability

MyPurchasing.com

ABC

CompanyBenefits.com



MyHRManager.com


Health InsuranceAbsenceRetirement HR Exec


S Order Pricing

Inventory & Availability


SS Order Pricing



Illustration 2. The Task Resource Portal and the Dedicated Workspace Portal can be two faces of the same set of underlying applications and resources. The Task Resource Portal faces the end-user/customer, while the Dedi-cated Workspace Portal faces the dedicated employee. For example, an employee uses the CompanyBenefits.com Task Resource Portal to access information about all his benefits, while the HR manager access the same infor-mation from within her MyHRManager.com Dedicated Workspace.



You can use your portal strategy to pull together the functionality from these disparate e-business Web sites around the needs of different groups of constituencies. (See Illustration 5.)

Use Your Portal Initiatives to Concatenate Scenarios from Separate Functional Web Sites

What’s the benefit of combining Web site func-tionality into portals that are designed around groups of constituents and/or groups of tasks? If you do this right, you should be able to eliminate massive dupli-cation of effort while, at the same time, making it much easier and more productive for people to do business with you.

Here are some examples:

• Combine Customer-Facing Web Site Func-tionality. Most companies have separate Web sites that have sprung up over time for the fol-lowing functions: company marketing, product marketing, on-line shopping, customer support, and account management. Most firms also have one or more of these sites for each country or geographic region in which they do business.

And most companies also offer specialized Web sites for their largest accounts.

A portal lets you pull together relevant of-ferings and functionality for each group of cus-tomers (large accounts, customers in France, small business owners, students, and so on). You do this by creating re-usable customer scenarios (e.g., search for appropriate products, place an order, check on the status of an order, request assistance, and so on). Then you can leverage each scenario and customize it for different cus-tomers’ contexts. Moreover, customers who choose to can modify their own task resource portals to include the tasks they care about and to exclude the ones that aren’t germane.

• Combine Employee-Facing Web Site Func-tionality. Most companies also have employee intranets that have evolved over time. Each de-partment tends to post the information that it creates and maintains in its own departmental section of the intranet. The manufacturing plants post their safety processes and statistics, their quality processes and ratios, their plant inven-tory and maintenance records. The travel plan-ning department offers a Web-based travel res-ervations service. The HR department posts

The Same Customer Scenarios® Will Appear in Several Portals

CustomerCustomer

MySupplier.com



MyFactory.com

Order Replacement

Parts


S Order Pricing



SS Order Pricing


Manufacturing Mgr

Order Replacement

Parts


Illustration 4. Note that the same or similar customer scenarios may appear in more than one portal. For exam-ple, a customer might initiate the “order replacement parts” scenario from a Task Resource Portal, while the manufacturing manager might embark on the same scenario from within his Dedicated Workspace Portal.



policies and lets employees modify their benefi-ciary and policy information or file claims and track the progress of claims. The accounting de-partment offers online expense filing and reim-bursement activities as well as an e-catalog for purchasing supplies from company-approved vendors at pre-negotiated prices.

Again, by turning each of these separate Web sites into a collection of Customer Scenar-ios, the scenarios can be recombined into a se-ries of dedicated workspace portals—for your

manufacturing employees, for your sales force, for your HR managers. Each dedicated work-space can contain the most frequently-accessed scenarios for that group of workers. Individual employees can add or delete scenarios based on their needs—some employees need to make travel plans frequently; others do so infre-quently. For infrequently-accessed tasks, em-ployees can access a task resource portal, e.g., travel planning and reimbursement or health in-surance coverage and claims.

Use Your Portal Strategy to Concatenate Functionality from Multiple Web Sites

MySupplier.com


SOrder PricingInventory & Availability

MySupplier.com



Update My Account Profile

Customer

Purchase Products

Find Out about Appropriate

New Solutions

Get It Working Again!

E-StoreW W W.E-StoreW W W.

E-SupportW W W.

E-SupportW W W.

E-Product MarketingW W W.

E-Product MarketingW W W.

Custom E-StoreW W W.

Custom E-StoreW W W.

Purchase Products

Get It Working Again! Find Out about

Appropriate New Solutions

Purchase Products

Custom E-SupportW W W.

Custom E-SupportW W W.

E-Access to Account Profile & History

W W W.E-Access to Account

Profile & History

W W W.

French CountryW W W.

French CountryW W W.

Purchase Products

Find Out about

Appropriate New Solutions

Update My Account Profile

Get It Working Again!


Illustration 5. Many companies are suffering from a glut of separate e-business Web sites. Each one was designed and implemented by a different group within the firm. If you build portals targeted at specific groups of people, you can pull together the functionality each group needs from across a variety of Web sites. You can use portals to concatenate and rationalize your pre-existing Web sites.



Combine Your E-Business & Portal Efforts However you choose to approach portals, you

should take advantage of your existing e-business efforts and accomplishments. Don’t start over again. We recommend that you combine your e-business and portal initiatives.

Let the folks who created your intranet evolve that intranet into employee scenarios that can be combined into dedicated workspace portals for each group of employees and/or into employee task re-source portals for each group of tasks that all em-ployees need to do.

Have the folks who created and who maintain your customer-facing Web sites and your customer extranets evolve those into customer sce-narios that can be re-used in portals designed for different types of customers. (Your cus-tomer-facing Web sites and extranets may be just fine. On the other hand, if they need more work, take a look at the relative ease of customization and application integration that you might gain by using common customer scenar-ios in conjunction with a portal platform.)

Let the folks who created your partner extranets explore the possibility of creating partner portals by leveraging the customer scenarios that were created for customers and employees. Partner portals will probably be much easier to create by using the newer set of tools and capabilities that are now available via portal platforms. These tools will en-able your firm to provide common scenarios and information to all partners, yet to customize the por-tal for each channel partner. Partners will also be able to further customize their portals for each cus-tomer account. Finally, customers who prefer to ex-perience a blended manufacturer-direct and channel partner relationship will be able to access the com-bined scenarios and functionality on their custom-ized portals.

In other words, leverage the learning and experi-ence you’ve got. Don’t create a separate portals or-ganization. And, for goodness sake, don’t throw out the e-business platforms you’ve already deployed. Many of them will support portals just fine.

Make Sure Your Seasoned E-Business Team Is in Charge of Your Portal Implementations

Despite the fact that portals are “in” and “ebiz” is out, luckily, we’re finding that many of the folks who have been tapped to implement portals for the line-of-business portal owners (the head of HR, the VP of Sales, the Director of Channel Partners, the global account manager) often are the same people who were implementing the company’s Internet, intranet and/or extranet initiatives. That’s good. It means that they won’t need to learn everything from scratch. And they’ll be less likely to throw out the best parts of the company’s existing e-business in-

frastructure as they layer por-tals on top.

One advantage of leverag-ing the learning from the folks who have been running your various e-business initiatives is that they know all the dirty lit-tle secrets. They know how much of the current e-business infrastructure was put together with duct tape and silly putty.

They know how many different search engines are currently in use and which ones are any good. They know how many different sources of poorly-maintained content there are. They know which Web sites are kluges and which ones are well-architected. They know which application interfaces work well and which ones are problematic.

If you harness their knowledge as a team and of-fer them the opportunity to create an enterprise por-tal architecture that evolves the existing e-business infrastructure in a consistent, well-architected man-ner, you’ll be way ahead.

Use a Common Set of Portal Platforms & Services

By now, it should be obvious that, if you’re go-ing to use your portal strategy to rationalize your existing e-business Web sites and architecture, you don’t want to subject your organization to another round of redundant platform proliferation.

We are sorry to report that most companies are unwittingly well on their way to layering more com-plexity on top of the complexity they’ve already got. They are launching several portal initiatives, each

We are sorry to report that most companies

are unwittingly well on their way to layering more complexity

on top of the complexity they’ve already got.



with a different portal platform. And they are layer-ing these on top of, or, often, next to, a bunch of pre-existing Web sites, many of which were created us-ing different tools and platforms.

Ideally, you’ll want to select a single portal plat-form architecture (this may be an integrated portal suite or a best-of-breed approach). You’ll also want to take a common architectural approach as you break out and encapsulate the functionality from each of the pre-existing Web sites you already have deployed and re-wire that functionality into cus-tomer scenarios that can be deployed as portlets or wizards within both dedicated workspace portals and task resource portals.

A PORTAL STRATEGY CAN HELP YOU RATIONALIZE YOUR IT INFRASTRUCTURE & BUSINESS PROCESSES

Most IT executives we talk to are committed now to a strategy of re-architecting around a service-oriented architecture (SOA) model. However, they aren’t sure where and when to begin. The portal ini-tiative is the perfect place and time.

Standardize & Leverage Application Services

First, using portlets to deliver functionality to end-users forces companies to think of existing ap-plications as services. You’ll discover them as you define the key customer scenarios that are needed in each portal. For each customer scenario, you’ll dis-cover a set of application services that are required to support it. For example, you probably want to leverage the following types of application services across your customer scenarios and portals:

• Inventory availability • Order entry • Customized pricing • Search for products based on product attributes • Delivery status

There are lots more. You’ll want your IT archi-tecture team to rationalize and to standardize these application services and to wrap them up as Web Services, if necessary, in order to make them easy-to-access within and across portals.

Standardize and Leverage Infrastructure Services

Virtually all of the major portal platforms already are, or will soon become, Web Services-enabled. These portal platforms will be able to consume any Web Service and either present it to the user or use it internally to support application functionality. Thus, portals can become both an entry point and a proof-of-concept for an SOA architecture and a Web Ser-vices implementation.

For example, a portal platform may provide its own user authentication service, but it should also let the portal developers access existing authentication services within the company in order to provide sin-gle sign-on to the portal. That way, your architects can select the most appropriate authentication ser-vice for your business.

Here are some examples of the kinds of underly-ing infrastructure services you’ll probably want to reuse across portals and applications:

• Authentication • Authorization • Personalization • Collaboration • Calendaring • Scheduling • Session Management

Identify and Standardize Underlying Business Processes

In addition, if you’ve designed your portals to support key customer scenarios, you’ll discover which internal business process need to be redes-igned, integrated, or perhaps discarded entirely.

For example, you’ll probably discover that you want to standardize your marketing campaign man-agement processes across portal constituencies and across other interaction touchpoints (phone, direct mail, and so on). You wouldn’t want a small busi-ness customer to receive conflicting offers from dif-ferent product-line marketing organizations, for ex-ample.

To get you thinking about the kinds of business processes you may want to re-use across portals and customer sets, here’s a short list of typical candi-dates:



• New or revised content approval • Product catalog maintenance • Campaign management • Customer support • Customer relationship management • Expense reimbursement • Returns handling

You’ll think of and discover many more core business processes as you implement your portal strategy. But the point is that you can take advantage of your portal initiatives to identify and to prioritize core customer-impacting business processes that can be streamlined, leveraged, and customized for dif-ferent constituents. This approach will save you huge amounts of redundancy and rework.

CONCLUSION: A PRACTICAL APPROACH TO USING PORTALS STRATEGICALLY

We believe that the portal fad has come at the right time to help organizations continue to redesign themselves from their customers and constituents back.

You can ride the wave of portal popularity to continue the organizational transformation that was started by your e-business initiatives. Because many portals are designed to address the needs of a group of people (e.g., large-account customers or manufac-turing employees), they are, by definition, customer-focused. By zeroing in on the key customer scenar-ios that each group of constituents wants to achieve, you wind up redesigning your business for ease of use.

Portals allow you to create a user-friendly layer of functionality on top of a set of underlying inward-facing applications and business processes. As you

streamline scenarios for each constituency, you can prioritize the changes that need to be made to redes-ign your underlying applications and business proc-esses.

Portals encourage you to identify and to reuse underlying application and infrastructure services. These services are used to support customer scenar-ios. Both the scenarios and the services that support them can be re-used in a variety of portals.

If you agree with our description of the role that portals can play in transforming your organization to be easier to do business with, and if you’d like to try out this approach, here’s a set of bullet points we offer for you to use in describing the goals of your portal strategy:

• A portal is a vehicle we can use to provide cus-tomer experiences that deliver desired outcomes to customers.

• A portal is a means through which we can redes-ign our business processes to be customer-centric.

• By implementing portals for each constituency we serve, we can hide the fact that our applica-tions were not originally designed to serve these constituencies well.

• We can experiment with portals to get the cus-tomer experience right; we can quickly adapt customer experiences and alter business proc-esses.

• At the same time, we can redesign our back-end systems and processes using a services-oriented architecture to create a more flexible, dynamic and adaptive business.



The Future of Portals On Doors, Windows, Workspaces, and Adaptive Portals

By David S. Marshak

NETTING IT OUT Portals, since their popularization, have drawn our ire because the very definition of the term—doorway (to someplace else)—is contrary to this vision of technology as a way to deliver in-formation and resources to each person, di-rectly within his or her context, rather than hav-ing to "go someplace else" to do their jobs. The first generation of portals (Access Portals) in-stantiated their definition by providing a set of links (either static or by search) to other infor-mation and resources. The second generation (Aggregation Portals) improves this by bringing information back to the portal so the user does not have to go anywhere. However, aggrega-tion portals tend to be static and are not able to adjust to the user’s context.

We are now entering the next two generations of portals—generations that have again excited us about their potential, if not their name. We have named these next generations Workspace Portals—where the portal becomes the users’ work environments, including all of the appro-priate information, tools, and resources—and Adaptive Portals—where the portal experience, itself, dynamically changes depending on the user’s context and ongoing process.

PORTALS ARE EVOLVING!

We have a confession to make. We can no longer count ourselves as leading anti-portal evangelists. This is not to say that we were wrong in the past when came out strongly against portals as a long-term solution. We were right, and our view has not

changed. In our opinion, most early portals (and some current portals) were attempts to bandage incompatible, non-integrated systems by providing the user a doorway and a path to find these systems. Our negative reaction was related to the fear that portals would stymie the proper architecture and integration that we believe is necessary.

What has changed (and is still evolving) is the use of the term “portal” to encompass far more for-ward-looking concepts.

Portals as Doorways A friend of mine, AJ Dennis, once said, "The

beauty of the Internet is, wherever you want to be, you’re already there." The portal that we reacted to negatively, and still abhor, is the exact opposite—the portal as a doorway leading to someplace else. Of course, this was the original use of Internet portals such as Yahoo and Lycos, with portals providing doorways to other Web sites via links and search, a highly beneficial function in the early days of the Web. Not surprisingly, this doorway version of the portal served as the basic model for corporate portals as they took off.

We term this first generation, Access Portals. Al-though access portals have benefits for the casual user, they force people to travel back and forth, rather than bringing all of the information together in one place where it can be worked upon.

Portals as Window The second stage of portal evolution became a set

of windows to see what was going on in the outside (or inside) world. The portal became the place where specific information could be displayed—information such as sales reports, product specifica-tions, company news, etc. In addition, following the

The Future of Portals • 17


evolution of the public Internet portals, individuals could add personalized content, such as stock prices, weather, and sports scores.

We call this second generation, Aggregation Por-tals. Aggregation portals bring all of the information that a person needs (at least, all information that can be anticipated) to a single place. This becomes much more useful as a work tool as well as a powerful place to maintain information for customers or part-ners—very much like the premier pages we saw in the early business-to-business Web sites.

While aggregation portals (at this point, they should have no longer been called portals) certainly provide more value than mere access portals, they still fall short of the promise that portal technology is now presenting us in their third generation.

Portals as Workspaces We have entered the generation of what we call

Workspace Portals. Now, the portal has the potential of becoming the user’s customized, personalized workspace from which work is actually done. To-day, portlets (and soon Web Services) provide not only the information, but also the tools users need to do their jobs. And these workspaces are not only personal; they can be collaborative as well, provid-ing a persistent, in-context, and real-time method for individuals, communities, and enterprises to collabo-rate.

We have seen, and been very excited by, compa-nies that have created their portals as the point of integration of all user functions, including e-mail, calendar, HR, and line-of-business applications. The portals are being customized on a roles basis to meet the needs of workers in the context of what they are trying to accomplish. And, in these companies, we are beginning to see changing behavior as the portal becomes the “place where users live.”

The model has thus evolved from doors to win-dows to workspaces—and the workspaces are now evolving into rooms. The rooms model is not new; in fact, it was developed at Xerox PARC in the

1970s. The rooms paradigm provides a context-based model, where information, tools, and other people “reside” that are essential to you getting your job done.

THE FUTURE: ADAPTIVE PORTALS

Workspaces and rooms make the portal (again the wrong word—but we’ll have to live with it) the most exciting development in user environments since the multi-window graphical user interface. They enable users to live in a single contextual place to do get their jobs done, and they enable the organi-zation to control that context for individuals and roles.

However, the third generation may be short-lived, as we are not far from the fourth generation, which we have named Adaptive Portals. See illustra-tion. With adaptive portals, the users’ actual proc-esses become the context for the portals. Users do not need to go to different parts of the workspace or into different rooms. The information they need “magically” appears just as they need it. Collabora-tion is completely contextual—e.g., I see the avail-ability and expertise of the people I need based on what I am doing (rather than a static buddy list) and based on what they are doing at the time. Thus, peo-ple working on the same project would know each other’s availability and have real-time access to each other when and, if desired, only when they are ac-tively working on that project.

Adaptive portals will make full use of other ap-plications, information sources, and people via Web Services. In addition, there will have to be a portal-level process management system that tracks work done within the portal across the services that are called. Portals will thus have their own workflow and rules. These rules will integrate into the work-flow/rules systems of the applications they call and will continually adapt to the ongoing user activity and context.



Portal Evolution

Access Portals

Context-Driven

Pers

onal

ized


Illustration. Each generation of portals encompasses the capabilities of the previous ones. The evolution is marked by an increase in personalization and contextuality of the portal experience.



Portals—What Companies Care About Results from Our Portal Survey

By David S. Marshak

NETTING IT OUT Our survey on portal issues was extremely well received by our readers, with over 500 re-sponses (86 percent from CXOs, directors, and line of business managers). Based on these responses, we have come to the following con-clusions and insights:

• Customer-oriented portals are a primary focus of the majority of companies respond-ing—90 percent of responding companies list customers as a major target for their por-tal initiatives, with customer-oriented portals ranking as the single highest priority. This contrasts with the conventional view that portals are being used for only employees and partners.

• Portals are being used to change (or try to change) key business processes within companies and with their customers and partners.

• The key issues facing companies in their portal initiatives are: making the business case/ROI, integration with other systems, content management, and delivering a compelling user experience.

• Companies are confused, anxious, and do not have a lot of confidence in the portal technology nor in the portal suppliers.

GOALS OF THE SURVEY

In late May, Patricia Seybold Group sent out an invitation to participate in a Web survey on Portals. Our goal was to find out what companies believe the key issues are around portals, including what they

are currently using them for and how far they’ve gotten in using them effectively.

Specifically, we wanted to know the breakdown of employee portals vs. customer and/or partner por-tals and how many companies were implementing for more than one constituency. We also wanted to know the relative importance of the issues around portals—including business, organizational, and technical issues. Finally, we wanted to get some sense of whether the suppliers and products that are considered the leaders in the portal space are indeed the ones actually being used.

We were extremely pleased with the response to the survey. Over 500 of our readers, a large propor-tion of them corporate executives, (see Illustration 1 for the breakdown by titles) filled it out—and to their credit, this was not simply a multiple choice questionnaire, but required quite a bit of thought.

A SUMMARY OF RESULTS

Our survey found, first and foremost, that portals are critical initiatives in many companies. They are generating interest at a very high level in organiza-tions. And they are receiving the scrutiny that is typically reserved for mission-critical applications.

Our specific findings include:

• Customers are important! They are included in the portal initiatives of about 90 percent of the companies responding to the survey. Customer-oriented portals also constitute the largest, albeit by a very small number, target among compa-nies with only a single portal audience.

• Portals change business! Key drivers for portal initiatives are not simply convenience or cost savings, but actually changing the way compa-



nies do business internally, as well as with cus-tomers and partners.

• Companies must have a business case! The top issue, by far, is around cost—making the busi-ness case, ROI, and getting executive buy-in.

• Focus on hidden costs! The next two critical is-sues are integration and content management, two hidden costs that companies recognize will sink any portal initiative if not properly ad-dressed.

• Focus on the user experience! Portals can only be successful if people actually use them and find immediate value.

• Portals are happening! Companies are well un-derway in their portal initiatives—over one-third

have deployed and over one-half are deployed or in development.

• Help! There is large amount of confusion and fear, uncertainty, and doubt (FUD), and not a lot of trust of the portal vendors. Companies want help in making the ROI case, sorting out the technology options, and understanding best practices.

TYPES AND PURPOSES OF PORTAL INITIATIVES

Portal Audiences Our readers targeted one or more of four major

groups with their portals—employees, partners, cus-tomers, and the public. In general, each of these por-tals is a separate initiative (often on a different plat-

Responders by Job Title

Manager25%

Director/ Senior Manager23%

CEO/ President/CXO22%

VP/ Senior Director16%

Consultant7%

Engineer/Architect4%

Programmer/Analyst/ Developer

3%

Illustration 1. This chart represents the breakdown of the over 500 survey respondents by job title. Note that 86 percent are manager and above with almost 40 percent being vice president, senior director, and above.

Portals—What Companies Care About • 21


form—see below), though there is an emerging trend to extend a portal from one constituency to another. We are also seeing some movement towards plan-ning new portals for multiple targets from the start.

CUSTOMERS ARE IMPORTANT. Common wis-dom holds that portals are mainly implemented for employees—with HR self-service as the killer appli-cation. We, however, were not surprised to find that customer portals play a key role for our readers—customers constitute the largest individual audience for portals. Over half of the companies building por-tals target customer portals (see Illustration 2). This may be due to the self-selecting nature of our readers (they do have an interest in becoming customer-centric), but we believe that the extent of the use of portals to improve the customer experience is cur-rently under-appreciated.

SO ARE PARTNERS. Companies in the survey are also very interested in using portals to support their relationship with their partners, with over half of them having active or in-progress partner portals. Interestingly, very few companies are pursuing part-ner portals as their exclusive portal initiative. It thus seems that the partner portal is the second or third focus after customers and employees.

Portal Goals Our survey found that companies have a variety

of drivers for their portal initiatives. These drivers tend to cluster into five groups (see Illustration 3):

• Integrated Access to Information

• Improved Customer Interaction

Portal Audience

Customer22%

Employee21%

Employee/Customer/Partner

21%

Employee/Customer16%

Customer/Partner8%

Employee/Partner5%

Partner 5%Public 2%

Illustration 2. Breakdown of target audiences for current and in-progress portals. Multiple audiences, in general, represent multiple, rather than integrated, portals.



• Improved Employee Communication and Pro-ductivity

• Business Process Improvement and Cost Sav-ings

• Organizational Improvement

INTEGRATED ACCESS TO INFORMATION. This is certainly the raison d’etre for the largest number of portals—though interesting, fewer than one-third have this as one of their major goals. This goal ap-plies to all of the variety of audience-specific por-tals.

This group includes such portal staples as single-point-of-access to multiple sources of information and to multiple applications. It also includes the por-tal as a single-point-of-logon for accessing the in-formation and applications.

To a lesser extent, integrated access refers to per-sonalized and customized user environments, with a small number using the portal to create an integrated user workspace.

IMPROVED CUSTOMER INTERACTION. An al-most equal percentage of portal strategies have cus-tomer interaction and the overall customer experi-ence with the company and its brand as the key driver. These portals are designed for both making it easier for the customer (e.g., customer self-service) and to facilitate (and drive) an increase in customer purchases and thus corporate revenue. These can be viewed as “top-line” portals.

IMPROVED EMPLOYEE COMMUNICATION AND PRODUCTIVITY. This, of course, specifically relates to employee portals where communicating to employees and enabling employee self-service are the major activities, with the goal of increasing em-ployee productivity as the key driver.

Some companies also see training and education as significant purposes for employee-oriented por-tals.

BUSINESS PROCESS IMPROVEMENT AND COST SAVINGS. These are essentially “bottom-line” por-tals, whose goal is to improve internal business

Purpose of the Portal Initiative

Improved Customer Interaction

30%

Improved Employee Comunciation and

Productivity15%

Business Process Improvement and

Cost Savings12%

Integrated Access to Information

31%

Organizational Improvement

12%

Illustration 3. There are a variety of drivers for portal initiatives.



processes and to reduce costs. Costs that these com-panies expect to decrease vary widely and include:

• Printing and paper costs • Administering multiple servers • Network traffic • IT support • Communications • Customer support

ORGANIZATIONAL IMPROVEMENT. Finally, a number of companies are seeking to use their portals for improving their internal collaboration and knowledge-sharing. For these companies, collabora-tion seems to be somewhat more important than knowledge management.

STATUS OF PORTAL PROJECTS

As we noted above, companies (at least those of our readers who responded to the survey) are well underway with their portal initiatives. Almost 40

percent of them have portals in production (see Illus-tration 4), with many of these in their own re-design or second-generation stage.

At the other end, there is a small percentage that has not started. This group seems to include a very small number of companies that are just beginning to considering portals. The majority of this group are either “waiting for executive approval and funding” or are “on hold.”

In the middle are two large groups: those in the planning stage and those in development.

Within the planning stages, over one-half are do-ing requirements analysis, about one-third are work-ing on strategy and feasibility assessments, and the rest are evaluating portal technologies and products.

Within the development stage, about two-thirds are in actual design and development, while the rest are in pilot and test phases.

Stages of Portal Initiative

6%

28% 27%

39%

0%

5%

10%

15%

20%

25%

30%

35%

40%

45%

Not Started Planning Development Deployed

Illustration 4. Almost 40 percent of companies responding have already deployed portals.



CRITICAL ISSUES AROUND PORTALS

At the heart of the survey is our attempt to better understand the key issues that companies have when planning and implementing portals. While there are many issues—technical, business, organizational—around portals, one issue is by far the most promi-nent in these companies’ minds. This number one issue is best stated as, How do we make the business case for portals?

The top four issues are:

1. Business Case/ROI 2. Integration 3. Content Management 4. User Experience

Issue #1: Business Case/ROI Over and over in the survey responses, we heard

that companies are greatly concerned about how to make the business case for, and determine the ROI of, a portal initiative. This concern crossed all types of portals, all purposes of portals, and all job titles.

Closely related to the business case issues are concerns around getting executive buy-in/support, appropriate resources, and internal agreement on strategy.

Typical responses to the question of the key is-sues surrounding portals include:

- “Prioritizing and balancing business needs and cost with potential portal applications”

- “Where are the ROIs?”

- “Predicting and then measuring ROI”

- “The ROI and reason for doing it in the first place”

- “Portal implementation is costly therefore the ROI must justify the expenditure.”

- “Getting everyone on the same page. Each exec has a different idea of what a portal is and what it will solve.”

- “Management support, executive responsibility are key from the very start, and, if not, the cross-

functional environment of portals is very likely to lead to problems.”

- “It’s probably the most difficult political issue we’ve faced”

Issue #2: Integration The second most recurring issue is integration of

the portal with legacy systems and back ends. The specific systems vary, although integration with au-thentication systems and providing single logon is clearly a pervasive need. Other systems frequently mentioned include:

• Document management • Content • Databases • CRM • ERP • Web servers • External information • Internal processes • Home-grown systems

Typical responses about the importance and dif-ficulty of integration include:

- “Difficulty [of] integration into complex legacy environment”

- “I believe the key issue is system interfacings”

- “Ease/compatibility of integration with underly-ing applications and easy/efficiency of handling a secured single sign on”

Issue #3: Content Management We have continually heard from those running

leading-edge e-commerce sites that the great hidden secret is how costly and difficult it is to create and maintain content. From our survey, it is clear that those who are focused on portals have the same challenges. These challenges include making sure that the content of the portal is “fresh,” “depend-able,” “accurate,” and “relevant.”

Many responders noted that content management for them was not only the creation and maintenance of the information, but also the categorization and assignment of metadata.



Typical answers about the content management issues include:

- “Publishing bottleneck”

- “Content to drive the portal”

- “What is involved in implementation and ongo-ing maintenance of content”

- “Lack of consistent metadata across an organiza-tion’s data assets. The technology is the easy part!”

Issue #4: User Experience Survey responders had a set

of issues that directly involve the user experience, which they generally agreed must be posi-tive for the portal to succeed. These concerns include:

• Ease of navigation. Many view what they call the standard portal interface to be difficult for users to navigate.

• Level of personalization and customization. Many are finding that getting the right amount of customization and freedom to personalize is difficult.

• Getting people to use the portal. Many say their greatest challenge is to get users (this includes employees, partners, and customers) to come to the portal and to make appropriate use of it. Of particularly concern is getting people to use the portal to collaborate.

There was also a lot of sentiment among the re-sponders that a key success factor is to correctly set users’ expectations of the portal experience, with many stating that portals have been oversold to users (and to management).

Typical responses around the issues of user ex-perience include:

- “Getting users to use them! Making sure they add value rather than introduce confusion or in-convenience.”

- “A user wants an easy, understandable, clear, simple portal. He wants to get his job done with the least number of clicks and short loading times.”

- “The tension between user expectations of per-sonalization and company needs for control and management.”

- “Re-educating our people about the necessity to openly share information with customers AND to help customers do their jobs is an ongoing/never ending effort!”

Other Issues… After the top four issues,

survey responders listed a set of other significant concerns about their portal initiatives. These include:

• Security of internal data

• Ease and cost of purchasing, building, and main-taining portals

• Standards and integration with Web Services

• Mobility, wireless, and off line use

• Performance, availability, and storage require-ments

• Spread of multiple portals

• Localization and internationalization

HOW PORTALS AND PORTAL VENDORS ARE PERCEIVED

In addition to the specific issues, there are some serious underlying currents of uncertainty and dis-trust in the portal space. Much of this is aimed at the

There was also a lot of sentiment among the responders

that a key success factor is to correctly set users’ expectations

of the portal experience, with many stating that portals

have been oversold to users (and to management).



vendors, while some of the anxiety is about the por-tal technology itself.

The portal software suppliers do not seem to have generated a large degree of confidence, and there were a number of comments that portray them in a quite unfavorable light, such as:

- “Companies make it hard for customers to de-cide what to buy since all the sales persons say ‘yes we can do that,’ it becomes a commodity like milk.”

- “Existing portals and application vendors do not provide much help for implementing what we refer to as an ‘employee-centric’ virtual desk-top.”

- “…proprietary nature of everyone’s portlets, amount of work it takes to learn APIs, then build and maintain custom portlets.”

In fact, we did not find any countering comments praising suppliers for their assistance, either in the planning or implementation phases.

There is also a strong sentiment that the portal products themselves are immature and incomplete:

- “Portal products are typically ‘shallow’ products that are more middleware ‘veneer’ that don’t al-low you to build a full site architecture; content management.”

- “…lack of techniques and metrics to design and monitor portals.”

- “The tools are rotten! Hard to use, very slow, and complex.”

However, at least one responder felt that the

technology is growing up:

- “It’s coming together—only now is there a good choice of richly functional products for the di-verse range of portal requirements.”

TOP PORTAL VENDORS BEING USED

Our intent for this survey was not to try to evalu-ate nor to quantify the market share of the current set of portal vendors. However, we were interested in

which technologies and products are currently being used and considered by our readers.

Not surprisingly, a clear plurality (one-third) are using home-grown initiatives to build their portals, rather than a specific portal product. Within this group, about one-half report using Microsoft tech-nologies (ASP, .NET) while about one-quarter are committed to a Java and/or OpenSource approach (the remaining responders did not declare a specific technology or architecture).

Vendors of portal products that companies report using or considering fall into four clusters, with Cluster 1 receiving the most use and consideration and Cluster 4 (whose supplier names we will not include in this report) receiving a very few responses each. Within each cluster, the suppliers are listed in order of frequency of mention by respondents, with the highest in each cluster being listed first. (See Table A.)

Top Portal Vendors

IBM (WebSphere) Oracle SAP Plumtree

Cluster 1

Microsoft BEA BroadVision

Cluster 2

Epicentric ATG IBM (Lotus Domino) Sun Vignette Citrix Siebel Computer Associates Hummingbird Interwoven Tibco

Cluster 3

PeopleSoft

Table A. This table clusters the portal vendors men-tioned most frequently by our respondents. Compa-nies/products in the same box were each mentioned the same number of times. For example, Oracle and SAP were mentioned an equal number of times.



CONCLUSION: ADDRESSING THE CONCERNS

The Portal Agenda In order to address companies’ key issues around

portals, the industry as a whole, led by the major portal players, is going to have to take some signifi-cant steps:

• Costs, maintenance efforts, and time to imple-mentation are going to have to come down. Inte-gration and content management processes will be key.

• Suppliers must become credible in their cost and time estimates, and they will need to assist com-panies with ROI calculations.

• Portal products are going to have to include their own measurement systems that can tie the portal activity to business-critical metrics.

• Federated portal architectures that interconnect multiple portals from multiple vendors must be developed. Portals will thus have to present their functionality as Web Services as well as to be consumers of Web Services themselves.

A Study in Contrasts Delivering on this agenda is going to be difficult

for a number of reasons—primarily the fact that companies don’t necessarily trust the vendors and view them as having proprietary agendas of their own. Furthermore, as our survey reveals, the portal space is a rapidly-moving target marked by confu-sion and polarization. It could be said that the portal space is, indeed, a study in contrasts, as exemplified by two very passionate survey responders:

• “This is the hardest project I’ve ever worked on—including creating a E-business from scratch in 1997 (still in business, I might add) because no one has a clear vision of what a por-tal is—everyone had different ideas on what problems the portal will solve. They’re all execs, but we have no clear portal champion. We really can’t get our arms around what exactly we need to build.”

• “They rock! Our portal has clearly made our company more competitive and saved us enor-mous amounts of time and money. User produc-tivity is enhanced through one interface access to everything they need to do their job, and the self-service functionality allows resources to be utilized more effectively.”



The State of Portlet Standards Clearing Up the Confusion

By David S. Marshak

NETTING IT OUT Portlets are the heart of portals, making the por-tal experience almost infinitely extensible and integratable. However, this comes at a high cost and product lock-in, since Portlets can generally run only within the portal platform for which they were created and, therefore, must be developed separately for each. In addition, maintenance costs are high, since Portlets must be modified every time back-end functionality changes.

There are two major standards initiatives. The first, JSR 168, is a Java Portlet API that allows Portlets to run locally on any J2EE portal server. The second, WSRP, is an extension to Web Services that enables a Portlet to run re-motely while controlling the presentation as well as the data within any portal. V.1.0 of the speci-fications of both of these standards are due at the end of 2002 or early 2003, with standards-based products likely by the end of 2003.

When implemented, JSR168 and WSRP will usher in a new era of standards-based, interop-erable Portlets.

PORTLETS: A TECHICAL VIEW

Portlets: The Key Integration Feature of Portals

All of the current enterprise portal platforms are built on the same model. The portal itself is a con-tainer application into which a set of components can be assembled to create customized and personal-ized pages for groups of users. The components are

commonly called Portlets (by IBM, Oracle, Sun, and others), but also have many other appellations, such as Web Parts (by Microsoft), Gadgets (by Plumtree), iViews (by SAP), and Content Delivery Agents (by Citrix). Each Portlet occupies a small piece of visual real estate on a portal page, and delivers access to a specific application or other source of content.

The Portlet model makes it easy for portals to be extended to and integrated with virtually any appli-cation or information source. All portal platforms ship with a large variety of Portlets that enable ac-cess to the common application and data sources. They also all include some form of software devel-opment kit allowing application and information providers or corporate developers to write their own Portlets. When a new function needs to be called or new information needs to be made available to a set of users, one simply writes a new Portlet.

Servlets for Portals From the developer’s point of view, Portlets are

like Servlets. They are Web components that run on a server and are accessible via a Web browser. How-ever, Portlets have the additional property of being able to run within the context of container Web ap-plication—i.e., a portal—and be aggregated together to form a portal page. Portals also have a different processing model than Servlets, with an action and render phase.

We tend to refer to Portlets by what they ac-cess—e.g., an Oracle Database Portlet, an Outlook Calendar Portlet, a Lotus Sametime Portlet. Note that even though we name them in the singular, they really should be looked at as plural. While each Port-let generally accesses only a single function or in-formation source, each Portlet can have, and gener-ally does have, multiple instances. These instances correspond to multiple users of the portal, with each

The State of Portlet Standards • 29


instance using different data with each user and user’s activity.

Portlet-to-Portal Communication While the basic function of Portlets is to commu-

nicate with external (to the portal) resources, Portlets also need to communicate with the portal for the fol-lowing:

• Access to user profile information for the current user

• Access to the window object that controls the window in which the Portlet is to be displayed

• Participation in the portal window and its action and event model

• Access to Web client information

• Inter-Portlet messaging

• Access information about the portal

• Storing and retrieving persistent per-user, per-instance data

Common Portlet Properties Portlets themselves have a common set of prop-

erties that is supported by virtually all portals. These common properties are: Window States, Portlet States, and Portlet Modes.

WINDOW STATES. Window State refers to the Portlet window size within the portal page. The common states are:

• Normal • Maximized • Minimized

In most portals, Window State can be customized and locked for specific users and groups, or they can be left to the users themselves to personalize.

PORTLET STATES. Portlet State refers to the in-formation that the Portlet maintains. Levels of these states include:

• Session State—this is a transient state that re-flects the state of the current interaction with a particular user.

• Configuration State—this is a persistent state that affects all Portlet instances.

• Instance State—this is a persistent state that af-fects a single Portlet instance.

For example, a weather Portlet may have a Ses-sion State storing the fact that the user is looking at the “five-day forecast,” a Configuration State that tells it where to get weather data, and an Instance State that tells it to show Boston weather for this specific user.

PORTLET MODES. Portlet Mode refers to what the user can do to and within the Portlet. Portlet Modes include:

• View Mode. This is the basic mode of a Portlet in which the functionality is accessed by the user.

• Edit Mode. This enables the users to edit their instance data.

• Help Mode. This explains how the Portlet is to be used.

• Configure Mode. This allows the administrator to configure the Portlet.

• Design Mode. That provides a Portlet-specific interface to changing how it looks.

• Preview Mode. This displays a preview of the Portlet’s appearance.

Typically, the View, Edit, Help, and Preview modes are available to the user, while Configure and Design modes are used by administrators. All Port-lets support View Mode, and most major products support all of the modes.

The Drivers for Portal Standards

PORTLETS ARE PROPRIETARY FOR EACH PORTAL PLATFORM. With all this commonality amongst the various Portlets, you would think that it



would be simple to develop a Portlet for one portal platform and have it work on all (or at least many) others. Unfortunately, each portal platform vendor has created its own Portlet model, and these are gen-erally not usable in any other environment.

PROBLEMS CAUSED BY THE LACK OF STANDARDS. The lack of standards directly and negatively impacts several constituencies, including application and content providers who want their services accessible from within multiple portals, corporate developers who need to provide access to homegrown applications (many companies have multiple portal platforms), and companies deploying portals that may not have a full choice of portal plat-forms and Portlets.

Specifically, there are three reasons that the lack of Portlet standards impact these constituencies:

• Development Costs/Delays. Information and application providers and corporate developers all have to build Portlets for multiple platforms. This increases their costs and delays availability of the Portlet for all but the first Portal.

• Maintenance Costs. Every time back-end func-tionality changes, a new Portlet must be devel-oper for each portal. It must then be distributed and deployed.

• Limits Choice of Portal Platforms. Because of their investment in Portlets, companies can get locked into their current portal choice. Compa-nies may also be inhibited from selecting less popular platforms, since they would tend to be the last to get third-party Portlets

Thus, the drive for Portlet standards is coming from application and information providers and from companies implementing portals—particularly those implementing multiple portal products. The portal vendors themselves, particularly those with the larg-est installed based and most Portlets built for their platforms have shown some ambivalence towards Portlet standards—though some of them (most nota-bly IBM and Sun) have been in the forefront of the Portlet standards movement.

THREE APPROACHES TO PORTAL STANDARDS

Confusion Around Standards Initiatives We are seeing a lot of confusion around the vari-

ous Portlet standards initiatives. We hear incompre-hensible numbers (JSR 168) and unpronounceable acronyms (WSRP), to say nothing of various quasi standards bodies such as OASIS and JCP. However, the biggest confusion seems to be around the notion that the major Portlet standards proposals are the same or are part of a single standards initiative. As we shall see, they are quite different.

There are actually three separate approaches to addressing the problems posed by the lack of Portlet standards. They can be described as:

• Interoperability—where the Portlets from one vendor are supported in another vendor’s portal.

• Portability—where Portlets are written to a standard API so they can run in any portal that supports the standard.

• Distributed Functionality—where part of the Portlet runs remotely and is called as a Web Service by any portal that supports the Web Ser-vices protocols.

Portlet Interoperability—Support for Market Leaders

Today, the only way to run Portlets on multiple systems is based on a de facto standards approach whereby a vendor of one portal platform will support the proprietary Portlets of another (generally market-leading) vendor. A good example is Citrix NFuse Elite Access Portal’s support for Microsoft’s Web Parts.

Portlet Portability—The Java Portlet API One of the key efforts at Portlet standards is to

create an API that will allow any Portlet written to it to run within any portal. Actually, the current major effort—the JSR 168 Portlet API—comes out of the Java community and is thus aimed at enabling the Portlets to run on any J2EE portal server (which in-cludes those from IBM, Sun, Oracle, Plumtree, and



many more). Below, we will discuss JSR 168 more fully.

Distributed Functionality—Web Services for Remote Portals

The second key Portlet standard effort is to build on and extend Web Services so that a Portlet would be able to be called remotely and run within any por-tal without any local programming required. This initiative comes out of OASIS and has resulted in the effort to create a Web Services for Remote Por-tals (WSRP) specification. We will more fully dis-cuss WSRP below.

JAVA PORTLET API—JSR 168

Need for a Common Portlet API Today, each portal platform supports a different

Portlet application and programming model. In order for developers to create Portlets that will run on any portal platform, a common API is required. The movement towards this common Portlet API is com-ing out of the Java community.

Java Specification Request Process and Timeline

Java Specification Request (JSR) 168 is a pro-posal submitted to the Java Community Process (JCP). JSR 168 defines a set of APIs that enable Portlets to plug into any J2EE portal server.

JSR 168 was submitted by Sun and IBM. Other members of the Expert Group include Apache Soft-ware Foundation, ATG, BEA, Boeing, Borland, BroadVision, Citrix, EDS, Epicentric, Fujitsu, Hi-tachi, IONA, Novell, Oracle, SAP, Sybase, and Tibco. In addition, Accenture, Bowstreet, Cap Gem-ini Ernst & Young, Computer Associates, CoreMe-dia, DaimlerChrysler, Documentum, Enformia, Hewlett-Packard, Interwoven, Macromedia, McDonald Bradley, Plumtree, Silverstream, Taran-tella, and Vignette have committed to support JSR 168.

The initial kick-off meeting of the expert group took place in San Francisco during the March 13 to 15, 2002 meetings. The goal was to define the first public draft of the API by the end of September,

2002, and, by the end of December, 2002, to have Version 1.0 of the specification with a reference im-plementation and a compliance test kit scheduled for January, 2003. However, the final specifications seem to be slipping into the first quarter of 2003.

JSR 168 Design Goals The design goals of the JSR 168 Portlet specifi-

cation are:

• Client agnostic

• Support for multiple types of clients and devices

• Simple Portlet API

• Support for localization and internationalization

• Hot deployment and re-deployment of portal applications

• Declarative security (same as the mechanism found in Servlet and EJB spaces)

• Architected to support remote execution of Port-lets

Relationship to the Java Servlet API The JSR 168 specification is specifically de-

signed to be based on the Java Servlet specification. It is envisioned that the developer API for JSR 168 will be similar to the Servlet API. In addition, the Portlet specification will restrict the functions pro-vided by the Servlet API to a subset that makes sense for components providing fragments of a markup page. And, like the Servlet specification, the Portlet specification will allow access to enterprise information systems without imposing restrictions on the type of protocols.

Relationship to the Portal JRS 168 specifies that the Portlet API will pro-

vide functions for the Portlet to obtain context in-formation from the portal. This includes:

• Current user profile information

• Participation in the portal window and action event model



• Web client information

• Sharing information with other Portlets

• A standard way of persistently storing and re-trieving per-user/per-instance Portlet data

Portlet API Functionality JSR 168 will define:

• The minimum set of possible Window States for a Portlet (e.g., normal, minimized, maximized).

• The valid Portlet modes (such as view, edit, help, configure) per markup language.

• A URL-rewriting mecha-nism for creating links to trigger actions within a Portlet without requiring knowledge of how the URLs are structured within the particular Web applica-tion.

WEB SERVICES FOR REMOTE PORTALS (WSRP)

Need to Extend Web Services In contrast to the common API approach where

Portlets are portable across portal platforms because they are written in the same language to the same API, a Web Services approach enables Portlets to call functionality from remote systems. This can be done via any API set running on any platform (as long as both support Web Services). Web Services are key to virtually all portal strategies, since one of the basic ways (and rapidly becoming the preferred method) that Portlets will connect to external appli-cations is via Web Services.

While Web Services provide arguably the best way to bring data into Portlets, they do not address the issues raised by the lack of Portlet standards. Without standards, Web Services consuming Port-lets still have to be built separately for each portal platform for every external application, and they all

have to be modified and redeployed when any changes occur.

The reason for this is that the current set of Web Services protocols (WSDL, SOAP, and UDDI) pro-vides a way to communicate data between applica-tions. However, there is no way to communicate the presentation layer from application to application (in this case, Portlet). The incoming data must be inter-preted and presented by the local Portlet, and the local Portlet must be aware of and contain the ability to handle specific presentation.

For example, a Portlet calling weather informa-tion from a Web Service will only receive weather data. The Portlet must have the internal program-

ming to then create whatever presentation vehicle that is best for the user—a complex task if the vehicle is anything other than simple text, e.g., weather maps, graphs, etc. Today, a specific Portlet must be built for each portal platform. JRS 168 will diminish the number of Portlets to be built, but a new Portlet must be built, distrib-uted, and installed every time any changes are made to the service.

The Web Services for Re-mote Portals (WSRP) initiative is designed to enable the service provider to write and maintain the Port-let, which can be remotely called from within any portal, without having to write any code on that por-tal. All of the presentation would be controlled by the service provider. Local Portlets would be re-placed by generic Portlets that only need to know how to call a WSRP service (see Illustration 1). They would not need to have local programming or maintenance.

OASIS Process and Timeline Web Services for Remote Portals is a technical

committee of the Organization for the Advancement of Structured Information Standards (OASIS). It is attempting to define a Web Services-based compo-nent model that will enable Portlets to be plugged into or called from portals.

Without standards, Web Services consuming Portlets still have to

be built separately for each portal platform for

every external application, and they all have to be modified

and redeployed when any changes occur.



The OASIS WSRP technical committee first met on March 18 to 20, 2002, at the IBM Research Labs in Hawthorn, New York. The goal was set to have Version 1.0 of the specification and a compliance test kit available by the end of 2002—though, like JSR 168, this seems to be slipping into the first quar-ter of 2003.

WSRP Goals The goals of the WSRP initiative are:

• Enable interactive, user-facing Web Services to be easily plugged into standards-compliant por-tals

• Let anybody create and publish their content and applications as user-facing Web Services

• Let administrators browse directories for WSRP services to plug into their portals without pro-gramming effort

• Let portals publish Portlets so that they can be consumed by other portals without programming

• Make the Internet a marketplace of visual Web Services, ready to be integrated into portals

WSRP and Web Services WSRP extends the current Web Services to the

presentation layer by adding context elements (in-cluding information about user profile, location, de-vice, and desired markup language) to Web Services for Interactive Applications (WSIA) built on SOAP and WSDL. WSRP defines presentation-oriented, user-facing Web Services that plug into portals or

Web Service-Based Approaches to Portlets

Data-oriented Web Service

10010196

100

10010196

100

10010196

100

PresentationLayer

Presentation-oriented Web Service10010196

100

10010196100

10010196100

PresentationLayer

Illustration 1. As shown on the left, the current set of Web Services enable data to be brought into local Portlets, requiring the presentation layer to be written into the local Portlet. Shown on the right, WSRP extends Web Ser-vices to enable the service provider to define the presentation and have it be remotely invoked on the portal. Source: IBM submission to OASIS WSRP Technical Committee.



other applications (see Illustration 2). WSRP in-cludes:

• Interfaces defined in the Web Services Descrip-tion Language (WSDL).

• Metadata for self-description and conventions for publishing WSRP services in UDDI directo-ries.

• Services that are required to implement SOAP binding. Optionally, additional bindings may be supported.

• Services that can be implemented as Java/J2EE or .NET services.

WSRP Functionality With WSRP, a single version of the Portlet can

be built by the Portlet service provider. The portal

administrator has to merely place a generic Portlet proxy in the portal page.

WSRP will define:

• A WSDL interface description for the invocation of WSRP services

• Ways to Publish, Find, and Bind WSRP services and their metadata

• Markup fragment rules for markup emitted by WSRP services

• Applicable Security, Billing, and other mecha-nisms

IS THERE A DOWNSIDE TO THE PORTLET STANDARDS EFFORTS?

We all applaud standards efforts, and, certainly, both flavors of Portlet standards deserve our support. They definitely point to the day where the cost of

WSRP and Portlets

Internet/ Intranet

Internet/ Intranet

PortalServer

HTT

P

HTM

L W

ML

Voic

eXM

L ...

Port

let

API

WSR

PGenericPortletProxies

LocalPortlets

WSRPServices

Publish/Find Web Services (SOAP)

UDDI Registry

WSR

PClients

OtherPortals

Illustration 2. WSRP defines a common interface between services and generic Portlet proxies running on any portal that can consume Web Services. Source: OASIS WSRP Technical Committee.



building and maintain Portlets will be lowered and the options of portal platforms and Portlets will be increased.

However, as we speak, there are certain negatives emanating from the Portlet standards arena.

First, the confusion around the two major stan-dards initiatives is making today’s portal decisions more, rather than less, difficult. Since virtually all the major portal players pledge support for both ini-tiatives (with the notable, but not surprising, excep-tion of Microsoft—we expect that Microsoft will eventually support WSRP, but support for the Java Portlet API does not make any sense for Microsoft), there is little differentiation around standards that can help companies make choices.

At the same time, since there is little that compa-nies can do today—with products actually support-ing the standards unlikely for about a year—they may actually become more frustrated than heartened by standards initiatives.

Finally, there is an underlying current around the two major initiatives that makes it look like we may be in for yet another set of political battles (though couched in technical terms), this time between the J2EE supporters and those that favor a more general-ized approach to Web Services.

The Java camp argues that JSR 168-based Port-lets will provide higher performance and scalability

and will better integrate into the J2EE architecture. The Web Services camp argues that WSRP-based Portlets, in addition to providing greater user inter-face functionality and portability, can run in wider variety of portals, including those based on J2EE and .NET. IBM, a primary player in both JSR 168 and WSRP, is leading the effort to combine both efforts. According to IBM’s Thomas Schaeck, the Chairman of the WSRP Technical Committee, the two groups are working well together. “The idea is make it possible to wrap WSRP services into Portlet proxies written to JSR 168 and expose JRS 168-complient Portlets as WSRP Web Services.”

CONCLUSION: UNDERSTANDING THE RELATIONSHIP OF JSP 168 AND WSRP

Going forward, it is important to understand these two major Portlet standards initiatives and how they relate to each other (see Illustration 3). On their own, each adds to the overall capabilities, richness, and value of the portal environment. Together, they present a roadmap for entering the next era if stan-dards-based, interoperable, portable, distributed Portlets.

Contact Info: oasis-open.org/committees/wsrp/ www.jcp.org/jsr/detail/168.jsp

Relationship between Portlet APIs and WSRP

Web Services for Remote Portals (WSRP)

Java Portlet API (JSR 168)

C# „Portlet API“

(.NET). . .

Platform Independent Web ServiceInterface

Platform specific, local Portlet APIs

WSRP Impl. onplain J2EE or .NET

platform

Illustration 3. WSRP could use any local Portlet API, including JSR 168 and any potential new Portlet APIs that could be built on C# or any other new API defined for either the J2EE or .NET Web Services platform. Source: OASIS WSRP Technical Committee.



On Adaptive Portals and Contextual Collaboration Is It the Perfect Match?

By David S. Marshak

NETTING IT OUT Portals and Collaboration are frequently viewed as going hand-in-hand. Many companies im-plementing portals have collaboration among employees, partners, and customers as a stated goal, and almost all of the portal vendors tout the collaboration capabilities of their offer-ing. Despite this perception, very little collabora-tion—other than document-sharing amongst different constituencies—is actually being done within today’s portals, which, at best, are being used as places to access and launch separate collaborative applications and workspaces.

However, since both Portals and Collaboration are evolving, this situation will change. We have identified the next step in the evolution as Adaptive Portals and Contextual Collaboration respectively. Each of these stages will closely match what users are trying to do at any given moment. They will also bring Portals and Col-laboration together in meaningful ways, ena-bling collaboration within portal scenarios and access to appropriate information within col-laboration scenarios. Moreover, these next generations will come together around Exper-tise Management—which is a growing Knowl-edge Management feature of Portals and is re-quired in many Collaboration scenarios. And knowledge of the user’s context by the portal will contribute greatly to the quality of collabora-tion—for example, by enabling others who are in the same context (i.e., working on the same project) to know that a team member is online and can be reached, while not providing this

information to those who do not currently share this context.

In order to reach this level of integration and functionality, a new area of management will have to be added—Profile Management. Profile Management will build on the current Identity Management schemes. However, Profile Man-agement will also need to add three specific capabilities:

• Attribute Management—which will manage roles, expertise, and interests

• Context Management—which will under-standing the person’s current and changing scenarios

• Availability Management—which will report an individual’s availability for Instant Mes-saging, phone, or even face-to-face interac-tion based on the current contexts of both the individual and the person who wishes to make real-time contact

While pieces of these functions exist in various products, we are, unfortunately, still a genera-tion away from having these capabilities ubiqui-tous within our Portal and Collaboration plat-forms or, better yet, as underlying services available to and across each of them.

On Adaptive Portals and Contextual Collaboration • 37


DO PORTALS AND COLLABORATION GO TOGETHER?

Active Collaboration versus Passive Portals Sometimes, we are surprised to see collaboration

and portals being put into the same category. What could be more different?

Collaboration is the most active form of interac-tion, where people use the underlying technology to work with each other in ways that they could never have before. Collaboration is about teams with a common mission accomplishing goals at great speed across boundaries of time, geography, and, fre-quently, organizations and cultures.

Portals, on the other hand, have historically been much more of a passive presentation of a set of in-formation or links to the user. The user’s activities are browsing and finding rather than acting and ac-complishing. We have, of course, seen portals be-coming more dynamic and evolving to become workspaces where individuals can get their tasks and jobs done, with the promise of portals some day be-coming even more adaptive to meet users’ contexts and scenarios. Even so, the most adaptive of portals are about the individual finding and doing, not about teams working together.

Yet, They Are Viewed Together Yet, the common wisdom is that portals and col-

laboration somehow go together. In our survey of portal initiatives, one of the frequent goals is better collaboration among employees and between em-ployees and partners or customers. And the portal vendors certainly are putting the two categories to-gether. As an extreme example, Microsoft has the same name (SharePoint) for its enterprise portal product and its workgroup collaborative workspace.

And, of course, most portal platforms support (via portlets) e-mail/calendar access, discussion threads, and group-defined and -maintained work-spaces. Some provide real-time meeting support within the portal, such as screen shar-ing/whiteboarding, application sharing, and au-dio/video conferencing, as well as Instant Messaging and chat.

TODAY: COLLABORATION AND PORTALS ARE ORTHOGONAL

Despite all of this, portals and collaboration have not yet come together in a meaningful way. Cer-tainly, users can access e-mail, enter collaborative workspaces, or launch workflows from the portal, just as they can access other applications. However, there are few examples of collaboration that takes advantage of the portal itself.

When we talk to companies about what type of collaboration they are actually doing or contemplat-ing with their portals, we consistently find that por-tals are being used to simply share documents among different constituencies—departments, cus-tomers, or partners. We have not yet seen many ex-amples of integrating actual collaboration within the portal.

COLLABORATION AS PART OF PORTAL SCENARIOS

Portals that are built to support customer scenar-ios will, by necessity, include collaboration where it is required to complete the customer’s goals.

One obvious example is the collaboration be-tween a customer trying to accomplish a task and a customer service representative (CSR) who is charged with servicing that type of customer. Inter-estingly, the two will likely come together from very different portal experiences—the CSR from a Work-space Portal and the customer from a Task Resource Portal. As Illustration 1 shows, the customer, in the course of accomplishing her task (at a Task Re-source Portal), interacts with the CSR (who, in turn, lives in his Workspace portal). The interaction can be real-time (e.g., chat, audio/video conferencing, shared Web surfing, etc.), asynchronous (in a space where either can discuss or put documents), or a combination of the two.

This type of collaboration between customer and CSR is already being done by a number of compa-nies via specialized applications and custom Web sites (see, for example, “TightLink Provides Contex-tual Collaboration for Customer Service”8), and

8 Published March 28, 2002,

http://www.psgroup.com/doc/products/2002/3/PR3-29-02CC/PR3-29-02CC.asp.



could easily be integrated directly into both portal experiences.

We will continue to see more examples of one-to-one collaboration and, eventually, multi-party collaboration as part of scenarios supported by Task Resource and Workspace Portals alike. However, as we enter the era of Adaptive Portals, we will see an even tighter bond between the portal and collabora-tion experiences.

ADAPTIVE PORTALS AND CONTEXTUAL COLLABORATION

Portals and collaboration are both evolving as concepts and as technologies. Portals are evolving from static presentations of information and links to adaptive environments that change based on the user’s role, context, and purpose. Collaboration is evolving from something done in specific places (workspaces, databases, applications) to a set of multi-person activities that can be accessed and ac-complished from within any context. Obviously, the common element becomes context, with the user’s scenario driving both the portal and collaboration experiences.

Specifically, we will first see collaborative fea-tures appearing within the user’s portal context. This will be far more than simply providing access to col-laborative capabilities (e-mail, calendar, chat, meet-ings, etc.) from the portal. This will even be more

than the contextual collaboration currently being demonstrated by companies such as IBM, where, for example, when I retrieve a document via the portal, I can instantly see whether the author is online and, if so, open an Instant Messaging session with her.

The Adaptive Portal will really understand my context so that it will not only provide the generic collaborative choices (with the document author or a CSR in the customer support example). The Portal should know that, in my context, I am more likely to want to work on this document will several col-leagues, rather than “talk” to the author.

Even more significantly, the Adaptive Portal will be able to use its understanding of my context to display my availability for collaboration to others. The portal can know that I am working on a particu-lar project and can then show me as “Busy” to any-one who is not working on the same project. Or it can know, based on the fact that I am working in a specific workspace, that I am available as a resource, expert, or community member to others with specific needs or interests (see Illustration 2).

Real-Time Collaboration through Portals

CustomerCSR

MySupport.com

abc123 order

MyAgentDesktop.com

ABC

Chat Chat

Task Resource Portal Workspace Portal


Illustration 1. The meeting of Workspace Portals and Task Resource Portals are frequently the perfect place for real-time collaboration. In this example, the customer interacts with the support person in a collaboration that is accessed within each of their respective portal experiences.



PORTALS, EXPERTS, COLLABORATION, AND COMMUNITIES

People and Expertise: The Ultimate Resource

This brings us to a frequently missing piece in the discussion of both portals and collaboration. When people talk about portal resources, they gener-ally limit these to information and applications. Left out is the most important of resources—people. De-spite this, companies (particularly large companies) have found that the number one use of their internal portals is to locate other people—with the truism of “Employee Directory as the initial killer app for in-ternal portals” being continually confirmed.

Expertise Management—Knowledge Management about People

It is not a great leap to go from finding people by name to finding them by other criteria—such as role, expertise, or interests. This is akin to adding knowl-edge management capabilities to simple search and retrieval (something that all portals provide), and we expect to see more expertise management added into portal capabilities in the future.

Yet, most current implementations of collabora-tion likewise lack the expertise dimension. Typi-cally, they enable a defined set of people to interact. More advanced collaboration platforms enable peo-ple to be defined as roles rather than individuals. However, in many contexts, I want to interact with the appropriate experts—whose name and specific roles I may not know. For example, I may want to set up a meeting that includes a marketing and tech-nical support person who both know a specific prod-

Contextual Collaboration

MyProjects.com

Project RedProject BlueProject Green

MyProjects.com


MyProjects.com

Project YellowProject BlueProject Green

Available

Busy

Available

Busy

Available

Busy

Betty

Grace Howard


Illustration 2. An adaptive portal will understand context. In this illustration, collaborators are only available to other team members working on the same project. If Betty stops working on Project Blue and switches her focus to Project Green, the portal will recognize the change of context and make her available to Grace but not to Howard.



uct. The same expertise management capabilities that are being built into portals will enable me to create this meeting and invite the correct people.

Thus, in the future, the definition of Portals may well be the place find experts and communities of practice with which to collaborate.

Building and Leveraging Communities This, of course, brings us to communities—

remember, Create Communities was a Critical Suc-cess Factor of Customers.com. Portals started as a way to build communities—and then to advertise to them. Building communities was not the wrong part of this strategy. Rather, the mis-take was that, in order to draw numbers that would impress ad-vertisers, the communities be-come too broad and ceased to be communities at all. Many com-munities that have maintained their focus have been able to survive— eBay, AOL, and many online gaming communities are examples.

For companies that are not going into the busi-ness of becoming a portal (thank goodness), creating communities is still an important part of a customer-oriented strategy, as well as a way to leverage inter-nal knowledge. A great example is the community of Java developers created and nurtured by Lew Tucker at Sun. Sun’s goal was to get broad adoption for the Java platform and language. This community still exists today and plays a key role in maintaining the Java momentum.

The very nature of portals is to organize them by communities—both by role (customers, partners, employees, marketing, sales, engineering, etc.) and by practice (i.e., by task, goal, or scenario). Thus, they are a natural vehicle for creating collaborative communities of customers, employees, or both. The portal not only could help individuals find others like them with similar interests and issues, but it could also manage their interaction—for example by showing current availability of other community members within the context of the community—but only within that context.

THE MISSING PIECE: PROFILE MANAGEMENT

All of this adaptive, contextual, expertise, and in-terest-based interaction leads to the question of how this can actually be accomplished. Right now, there is no complete answer because we lack the ability to manage all of these factors in a single place. What is required is a rich set of Profile Management capa-bilities that will enable the user’s context and goals to drive the adaptive nature of the applications.

Profile Management will need to encompass all of the identity management capabilities being dis-cussed in the great Passport versus Liberty debate,

and it will have to meet all of the security and privacy issues that have been raised. However, Pro-file Management will have to go several steps further, also sup-porting:

• Attribute Management • Context Management • Availability Management

Attribute Management Attribute management includes managing roles,

expertise, and interests. This is the natural extension to identity management and is already implemented in some products and contemplated in others. It needs to extend to be more dynamic—for example, by determining expertise and interests by actions as well as by explicit assignment. We see this capabil-ity in some advanced search and discovery plat-forms, such as Verity’s K2 Enterprise.

Context Management Context management is basically understanding

the person’s current tasks and desired outcomes. We are far from being able to do this, except in cases where the user explicitly chooses an outcome (I want to book a trip) or launches something like a wizard to accomplish a task. However, we do not have any ability to handle the change of context when the user decides to do something different or does it in a dif-ferent order. Today, most context is identified from “tricks” such as cookies—and these do not follow the user across contexts such as different devices,

In the future, the definition of Portals may well be the place find experts

and communities of practice with which to collaborate.



although one product, Cymbio from Cysive, is able to maintain the user’s context across devices.

Availability Management Many portal and collaborative scenarios require a

person or expert to be contacted in real time. Instant Messaging platforms enable users to see whether that person is online and whether they have stated that they are available or busy. What is now required is for the “expert” (or anyone who may be contacted by anyone else) to be able to show their availability differently based on who is looking for them and based on both of their contexts—e.g., they both are working on the same project. We have not yet seen any portals or collaborative products that provide this level of availability management, but this is clearly going to be required if we are going to be able to leverage real-time interaction as part of adap-tive environments.

CONCLUSION: NO LONGER ORTHOGONAL

As portals and collaboration evolve to become more adaptive and contextual, they will blend into the set of services and interfaces that enable people and groups to get their jobs done. No longer will the portal be simply a resource that may include a col-laborative workspace. The portal itself will adapt to become a collaborative workspace, as collaboration becomes necessary. No longer will users collaborat-ing need to go to their respective portals to find the information or experts needed for their purpose. The collaboration will become the portal into the needed resources and scenarios. And no longer will we build separate environments, interfaces, and infrastruc-tures for individual and group activity. The contex-tual nature of the environment and the services ori-entation of the infrastructure will make this a single, seamless, ever-adapting experience.



Portal Framework Our Framework for Evaluating and Comparing Portal Platforms

By David S. Marshak

NETTING IT OUT A portal platform delivers the infrastructure, services, and tools upon which portals can be built. Portal platforms provide the ability to en-able access to multiple sources of data, con-tent, and applications. Portal platforms also provide methods (such as layout and search) to aggregate them for the user. Users interact with portals through Web pages (or as “pages” on a cell phone or PDA)—pages that serve as con-tainers of Portlets that are used to access the external source the user needs.

Portal platforms can be used to create portals targeted at different constituencies (customers, employees, partners) and to create different types of portal experiences (such as workspace portals or task portals) for these constituencies.

When we evaluate portal platforms we look at three areas within which there are a set of por-tal-related services, functions, or tools:

User-Level Portal Services. These include Access Services that enable user and group management, client device management, and adaptability; Presentation Services that provide design, navigation, customization, and person-alization; Collaboration Services that enable portal-based and contextual collaboration amongst portal users and communities; and Integration Services that center on Portlets, which are components that deliver resources to the portal user.

Portal-Level Services. These include services to manage single sign-on, search/retrieval, con-tent, knowledge and expertise management,

user context, and portal-level business proc-esses.

Portal Architecture. This includes operating and database environments, application struc-ture/components, security, and ‘abilities (such as manageability, availability, and scalability).

PORTAL PLATFORMS

What are Portal Platforms? Portal platforms, also known as portal frame-

works and portal servers, provide the infrastructure, services, and tools upon which portals can be built.

Defining Portals We define portals as user experiences targeted at

specific constituencies that:

• Aggregate and deliver information from a vari-ety of internal and external resources

• Wrap up and present application functionality from existing internal IT systems and from ex-ternal applications

• Enable single sign-on and authentication for the applications and resources that end-users access via the portal

• Offer customization capabilities to portal owners and basic personalization capabilities to end-users

Portal Framework • 43


Types of Portals Types of portals can be differentiated in a num-

ber of ways. Two of the most important are by target constituency and by user experience.

TARGET CONSTITUENCIES. Portals can be classi-fied by the constituency, roles, or communities that they are built to serve. Typically, portals are created for customers, employees, partners, communities, and the public, with sections of portals (or sub-portals) being customized for specific roles within each constituency.

We are beginning to see more generalized portals being built to serve multiple constituencies (such as employees and partners, employees and customers, etc.), with the different access requirements and con-stituencies being handle via customization rather than by creating separate portal infrastructures.

USER EXPERIENCE. Portals can also be divided by the specific user experiences (or scenarios) that they support. Basic portals support an access experi-ence—where users are offered a set of (frequently unrelated) links to different resources. More ad-vanced portals are designed around specific user scenarios—with the two most common being Dedi-cated Workspace portals or Task Resource portals (see Illustration 1).

• Dedicated Workspace Portals. A Dedicated Workspace portal is a place (generally a Web site) where employees or other stakeholders “hang out” to do their day-to-day jobs. Sales people spend their day working out of their Sales Force portal, for example. It lets them manage their customer opportunities, generate proposals, pull together competitive information, and close deals.

• Task Resource Portals. A Task Resource portal is a place where people go to accomplish a cer-tain set of tasks. Employees go to your HR por-tal to file a health insurance claim or to request maternity leave. Customers go to your com-pany’s Help Desk portal to resolve a problem.

Why Are Portals Important? Portals are hot! And they are hot for several rea-

sons.

First, today most companies see portals as ways to implement self-service applications for customers, employees, and partners, with the goal of immediate ROI in cost savings.

Secondary (for most) goals including increasing customer spending, increasing employee productiv-ity, improving internal processes, and breaking down communication barriers.

Finally, portals provide a relatively easy and quick way to provided targeted user experiences to specific and important constituencies. Thus, many e-business and other customer-focused initiatives that otherwise might lay dormant can be implemented under the banner of portals. (See “What’s Your Por-tal Strategy?” for our guidelines to a strategic ap-proach to portals9. )

The Portal Platform Marketplace Portal platform products and players proliferate.

One of the best ways to sort them out is to categorize by origin of their portal offerings (see Table 1).

A second method is by market presence (see Ta-ble 2)—our survey shows IBM, Oracle, SAP, Plum-tree, and Microsoft as the market presence leaders—what we call Tier 1. We will focus our first set of evaluations against this framework on the Tier 1 products.

AN EVALUATION FRAMEWORK FOR PORTAL PLATFORMS

Three Key Criteria Levels We evaluate portal platforms in three general ar-

eas (see Illustration 2).

1. User-Level Portal Services. These include Ac-cess Services that enable user and group man-agement, device management, and adaptability; Presentation Services that provide design, navi-gation/search, customization, and personaliza-tion; and Integration Services that center on Portlets.

9 “What’s Your Portal Strategy? How to Position Por-

tals within Your Overall IT and E-Business Strategy,” http://www.psgroup.com/doc/products/2002/8/SG8-8-02CC/SG8-8-02CC.asp.



Dedicated Workspace Portals

Sales Person HR Exec Manufacturing Mgr

MySales.com

MyJob.com

ABC

MyHRManager.com MyFactory.com

ABC

ABC

Task Resource Portals

Customer HR ExecManufacturing Mgr

MyTasks.com

ABC

MyTasks.com

ABC

Supplier.com



CompanyBenefits.com


CompanyBenefits.com



TravelPlanning.com



Illustration 1. Portals, today, tend to come in two flavors: Dedicated Workspace Portals and Task Resource Por-tals. Dedicated Workspace Portals, depicted at the top of this illustration, are designed for groups of employees who have a similar job to do, such as sales people, HR managers, etc. Each portal contains all the tasks and re-sources these people need to do their jobs, and the employees typically spends most of their days accessing work from within these workspaces. Task Resource Portals (at the bottom of the illustration) are designed for occa-sional use by people who have a set of related tasks to perform. For example, benefits administration might be a Task Resource Portal that employees and their spouses might use (CompanyBenefits.com).



Portal Platform Market Presence

IBM (WebSphere)

Oracle, SAP

Plumtree Tier 1

Microsoft

BEA

BroadVision Tier 2

Epicentric

ATG, IBM (Lotus Domino)

Sun, Vignette

Citrix, Siebel

Computer Associates, Hummingbird, Interwoven, Tibco

Tier 3

PeopleSoft

Table 2. In our 2002 Survey on Portals, companies implementing or planning to implement portals declared their products/vendors in the above order.

2. Portal-Level Services. These include ser-vices to manage search/retrieval, collabora-tion; content, knowledge and expertise, con-text, and portal-level business processes.

3. Portal Architecture. This includes operat-ing and database environments, application structure/components, security, and ‘abilities (such as reliability, availability, and scalabil-ity).

Portal Platform Landscape by Origin

Platform Players Application Players

“Pure” Players Re-Defining Players

Related Players

BEA Oracle Epicentric (purchased by Vignette)

ATG Bowstreet

IBM PeopleSoft Plumtree BroadVision Interwoven

Microsoft SAP Citrix Netegrity

Sun Siebel Sybase Verity

Vignette

Table 1. The major portal platforms generally come from platform players, enterprise application players, or pure portal players. In addition, several companies have redefined themselves as portal players, while others (though they may have both portal platforms themselves) offer related service in areas such as Portlet develop-ment, content management, and security/identity management.



1. USER-LEVEL PORTAL SERVICES

User-level portal services provide the basic methods of getting information to the users and ena-bling them to interact with it. There are four catego-ries of User-Level portal services:

• Access Services, which include User/Group Management, Device Management, and Global-ization

• Presentation Services, which include Design, Navigation, Customization, and Personalization

• Integration Services which focus on Portlets as the primary method of integrating external in-formation and functionality into the portal

Access Services There are three areas of Access Services:

• User/Group Management • Device Management • Translation

USER/GROUP MANAGEMENT. The ability to manage users and groups not only provides the ac-cess control to both internal and external resources needed for secure portals, but it also enables portals to be targeted to and customized for specific con-stituencies. In addition to the user authentication and authorization services provided in the platform ar-chitecture, portal platforms need to provide a method for portal owners and administrators to manage ac-cess for individual users and, most importantly, for groups.

Thus, portal owners and administrators need to be able to perform the following access and cus-tomization functions by individual or group:

• Assign access to the portal • Assign access to pages

Portal Platform Evaluation Framework

Environments Organization Structure SecurityEnterprise ’abilities

Platform Architecture

Portal-Level Services

Single Sign-On

Search/Retrieval Services

CollaborationServices

Content Management

Services

Context Management

Services

Knowledge and Expertise Management

Services

User-Level ServicesAccess Services

User/Group ManagementDevice Management

Globalization

Presentation ServicesDesign

NavigationCustomizationPersonalization

Integration ServicesPortletsGadgets

Web Partsetc.

Internal Content

Data

Legacy Applications

Third-Party Content

Third-Party Services

Enterprise Services

Business Process

Management Services

API

WebServices

WebServices

API © 2003 Patricia Seybold Group, Inc.

Illustration 2. We evaluate portal platform products in three areas: User-Level Services, Portal-Level Services, and Platform Architecture. All of these combine to serve the basic portal function of delivery and presenting re-sources (content, data, applications) to a user.



• Assign access to Portlets • Assign specific layout for portal pages

Directory Integration. Portal user and group lists are generally imported into portal directories from existing directories. A key consideration is the way the directories are integrated—via one-way import, one-way update, two-way synchronization, or plug-ging in an existing directory as the portal directory. At a minimum, portal platforms should provide an ongoing (either real-time or batch) one-way update to make sure that, for example, new users added to a corporate directory appear in the portal directory.

In addition to importing and/or synchronizing us-ers, some platforms enable the use of external direc-tory groups and lists to be used as portal groups. This feature can significantly reduce the work of creating and managing portal-level groups.

Role-Based Authorization. Groups are a fixed list of people. Portal platforms also need to support a dynamic way of providing access and customization via the use of roles. Roles can be assigned to users and groups based not only on directory information, but also on context and behavior. A good example might be the security required in a complex site such as eBay, where the same user may act in the role of seller, bidder, buyer, or rater.

Distributed Permissioning. Also critical, particu-larly in customer portals, is the ability to enable non-technical users to set permissions for all or part of a portal. In customer portals, it may be required that an account manager set access permissions or cus-tomize the portal for her customers. Or it may be desirable that the procurement officer at a customer site be designated to set permissions for users and groups within his company so that they can view and order specific items from the portal. Note how im-portant the concept of roles (rather than just indi-viduals and groups) is for extending permissioning past the simplest level.

CLIENT DEVICE MANAGEMENT. Portals are not just for PC/browser access. More and more, mobile individuals want to be able to access the portal in-formation via wireless devices such as PDAs and WAP phones. Providing wireless access to the portal can simplify the mobile/wireless problem for an or-ganization by not requiring the rewriting of multiple applications to support each type of wireless device.

Some products include or integrate with transcoders, so that the portal, page, or Portlet owner merely has to choose which are the target clients, without any additional coding.

While, today, mobile access to portals is still relatively rare, this will be an area of growing need.

GLOBALIZATION. Companies are creating portals for their own multinational locations and for their global sets of customers and partners. While some of the localization issues (particularly those relating to e-commerce and currency exchange) do not gener-ally apply to portals, the issue of translating portals into local languages certainly does. There are three approaches to translation that can aid in making the portal useful in a global context.

The first is to create multiple sites in different languages. The design of these sites can come from a single template, but the content is maintained in a separate stream (from, perhaps, a content manage-ment system that knows how to handle multiple lan-guage outputs).

The second approach is to create a single site with content being presented in a local language based on the customization capabilities of the portal itself.

The third approach is to translate content on the fly—depending on the user. While, today, this ap-proach is probably not accurate enough for most situations, it is highly useful in translating the real-time text conversations of instant messaging and chat. In this context, close-to-accurate translation is sufficient, since the reader can always ask the sender to explain something that does not make sense.

Presentation Services Presentation Services control the key elements of

the users’ experience as they work within the portal. Portal platforms provide presentation services in the following areas:

• Design • Navigation • Customization • Personalization

DESIGN. Portal platforms provide various design tools for portal developers to control the overall look and feel and branding of the portal. These layout



tools include themes and skins, which can be applied to an overall portal or to specific pages and sets of pages. Themes set the graphic look and feel and placement of elements such as the navigation bar. Skins set the look and feel of the elements that sur-round the Portlets (see below for a full discussion of Portlets) as well as enabling the designation of a specified layout (e.g., the number of columns).

In addition, some portal platforms provide tem-plates that can be used to quickly create portals with specific design features. Key template elements to consider include:

• Are templates included in the product?

• Does the product have a template creation tool?

• Can templates be created by saving an existing configuration?

The key question around portal design (and the navigation and customization categories that follow) is: Who can design portals? This is both a question of rights (who can be given design and customiza-tion privileges?) and, more importantly, of capabili-ties (is it easy enough for business users to create, customize, and maintain portals?). While the choice of who should create, customize, and maintain por-tals will be left to the companies implementing them, the option to have business users have these responsibilities should be available.

NAVIGATION. All portals need a way for users to see the overall organization of the portal and to navigate between pages and sections. Common navigation methods include:

• Tabs—generally at the top of the page

• Hierarchical interfaces—frequently displayed as explorer-like boxes on the left side of the page

• “Breadcrumbs”—which show the users where they have come from

• Site maps—which show the user where they are in the overall organization of the site

At this point, we do not yet have a set of portal navigation best practices—much less design stan-

dards—so providing the option for any and all of these models is the best approach.

CUSTOMIZATION. The hallmark of portals is the ability for portal owners/designers to customize the user experience for individuals and groups. Cus-tomization further refines and presents the resources to which users have access. While security deter-mines who you are (authentication) and what you can do/see (authorization), customization determines what you actually see, given a set of rules and events.

Customization can thus be used to provide spe-cific information and capabilities to different groups and roles. It can also be used to enforce a specific experience, such as promoting a corporate brand or limiting access to irrelevant information.

Portal owners/designers generally customize a portal by creating specific pages that are assigned to a specific person, role, or group. For example, one user’s (or member’s) homepage may display differ-ent information in different layout than that of an-other. Users can then, under certain circumstances, further personalize the page (see “Personalization,” below).

Customization is generally at the group level, al-though it can be applied to individual users and roles. Customization is handled at the page-layout level and specifically addresses:

• Design and navigation elements

• Portlets that appear on the page

• Other functionality, such as the ability to per-sonalize specific elements

In addition, rules can be applied that take into ac-count the user’s context, as well as other data—ranging from stock prices, to weather reports, to a customer paying its bill.

Advanced customization can be used to create Workspace portals, where the user appears to be working more from a customized workplace or ap-plication than from a generic portal.

PERSONALIZATION. All portal platforms provide some level of personalization, enabling users to (be allowed to) change aspects of their portal experi-ence. Most common are the ability to add new Port-lets (generally these are things like weather, stocks,



traffic, etc.), reposition Portlets on a specific page, and change Portlet properties—adding custom in-formation (such as specific stocks to track) or chang-ing the appearance of the Portlets (e.g., to open minimized, maximized, or to a specific size). More advanced personalization allows users to designate their own starting point for portal entry and to choose to be notified when information within a Portlet changes.

While personalization is an essential feature of portal platforms, its importance is often overrated. In practice, most portal users rarely use any but the most simple personalization features, and even they tend to personalize only when they first use the por-tal.

WHAT ABOUT PORTLETS? Portlets are key ele-ments of the user experience, since virtually all in-formation and functionality is exposed to the user via Portlets, and most customization and personal-ization is done around the placement/presentation of Portlets or within Portlets themselves. Thus, Portlets are the passive elements of the customization and personalization of a portal page.

However, we view the major purpose of Portlets as providing the primary method of integrating ap-plications, content, and other resources into the por-tal, so we analyze Portlets under the category of In-tegration Services.

INTEGRATION SERVICES

Portlets: The Key Integration Feature of Portals

All of the current enterprise portal platforms are built on the same model. The portal itself is a con-tainer application into which a set of components can be assembled to create customized and personal-ized pages for groups of users. The components are commonly called Portlets (by IBM, Sun, and most others), but they also have many other appellations, such as Web Parts (by Microsoft), Gadgets (by Plumtree), iViews (by SAP), and Content Delivery Agents (by Citrix). In general, each Portlet occupies a small piece of visual real estate on a portal page and delivers access to a specific application or other source of content.

The Portlet model enables portals to be easily ex-tended to and integrated with virtually any applica-tion or information source. In this context, Portlets can best be understood as little windows in a portal page that display functionality from applications outside of the portal itself to the user. Portlets can be used to display Web pages (and to let the user type in URLs to retrieve Web pages), provide access to specific information or content (e.g., a corporate di-rectory or file system), provide access to external services (e.g., weather, news, stocks), or provide access to an enterprise application (e.g., the user’s login screen to SAP, Oracle Financials, or Siebel). It is quite arguable that, without Portlets, you cannot have a portal—at best you can have a page with a set of links that lead you out of the portal.

All portal platform products ship with a variety of Portlets that enable access to the common applica-tion and data sources such as e-mail/calendar, news feeds, and file systems. They also all include some form of software development kit allowing ISVs, information providers, or corporate developers to write their own Portlets. When a new function needs to be called or new information needs to be made available to a set of users, one simply writes a new Portlet.

With Portlets being so central to today’s portals, they are certainly one of the critical evaluation crite-ria. We evaluate Portlets in the following areas:

• Included Portlets • Portlet development environment • Portlet architecture • Adherence to standards • Portlet-to-Portlet communication • Portlet management

Included Portlets One of the key factors that determine how

quickly a portal initiative can be implemented and provide value is whether (and how many) custom Portlets must be built to provide the required access and functionality. The major portal platform provid-ers are trying to speed this process by including a set of Portlets to common services (directory, file sys-tem, URL, stocks, weather) and to enterprise appli-cations.



Companies must consider not only the number of included Portlets, but also the applicability of those Portlets (a set of SAP Portlets is useless if I use Ora-cle Financials) and the depth of the Portlet function-ality—merely bringing up an SFA login screen may not be nearly as useful as a set of Portlets that di-rectly access My Accounts, My Opportunities, My Activities, or My Tasks.

Portlet Development Environment Creating custom Portlets is a requirement for vir-

tually all but the simplest portals. This requires a Portlet development environment or SDK. Key questions include: whether familiar tools and devel-opment environments can be used, what level of programmer it requires, and whether there are any third-party development environments that can be used to build new Portlets.

Portlet Architecture Portlets are implemented as servlets or scripts

that run within windows (i.e., are handled as win-dows objects) on the portal or application server. Portlet scripts can be stored in a file system or a da-tabase.

Portlets integrate with external content and appli-cations in one of three ways: they can be written to the external application’s APIs, they can access the external application via a Web browser interface (if one is available), or they can access the external ap-plication via a Web Services interface (if one is pre-sented).

Portlets interface directly with the portal frame-work to:

• Access user profile information from the portal directory for the current user

• Access the window object that controls the win-dow in which the Portlet is to be displayed

• Participate in the portal window and action and event model—i.e., enable the opening and clos-ing of the Portlets window

• Access the Web client information, such as browser types

• Enable Portlet-to-Portlet communication to pass information between portlets

• Store and retrieve persistent per-user, per-instance data, such as user session and state

PORTLETS AND WEB SERVICES. Portlets are evolving to interact with external resources and the portal framework itself via Web Services. This re-quires Portlets to be both producers and consumers of Web Services and to surface their functionality as Web Services. There are emerging Web Services (WSRP—Web Services for Remote Portals) that are specific to enabling Portlet functionality to be called from a service provider and run on a local Web ser-vices-enabled portal framework.

Adherence to Standards Portlets generally work only in the portal plat-

form for which they were built, making it quite ex-pensive and time-consuming to create and maintain Portlets for multiple portal platforms. This is a key issue for both information/service providers and for internal developers whose companies are imple-menting multiple portal platforms (a relatively fre-quent occurrence). There are significant efforts at both enabling specific Portlets to work in other por-tals and to establish a set of Portlet standards10.

Portlets can be made “standard” through one or more of three approaches:

• Interoperability—where the Portlets from one vendor are supported in another vendor’s portal.

• Portability—where Portlets are written to a stan-dard API that interfaces between the portal plat-form and the Portlet so they can run in any por-tal that supports the standard. Right now, the J2EE-based portal industry is converging on a Java Portlet API (JSR 168) that would enable any Portlet written to the API to run on any J2EE-based portal framework.

• Distributed Functionality—where part of the Portlet runs remotely and is called as a Web

10 See “The State of Portlet Standards: Clearing Up the

Confusion,” http://www.psgroup.com/doc/products/2002/ 9/TA9-12-02CC/TA9-12-02CC.asp.



Service by any portal that supports the Web Ser-vices protocols. Here, the Web Service-oriented portal vendors are converging on WSRP (see above).

JSR 168 and WSRP are designed to address dif-ferent aspects of Portlet standards—one being a portability API for the Java community and the other being a remote call for the Web Services commu-nity. While there is some confusion today on whether these standards compete with each other, we believe that, in the future, all J2EE-based portal plat-forms should and will support JSR 168, and all por-tal platforms should and will support WSRP.

Portlet-to-Portlet Communications Portlets were originally designed to integrate

with external resources and interact with people. Recently, Portlets are being designed to be able to communicate with each other by passing data back and forth. An example of a simple use of Portlet-to-Portlet communication--a user can put a location into a travel reservation Portlet. After the flight is booked, the travel reservation Portlet can pass the destination to a weather Portlet, so the user can see the forecast for her destination in the weather Port-let.

As this simple example demonstrates, most Port-let-to-Portlet communication is currently used to save re-typing by the user. However, some portal platforms enable their Portlets to spawn more com-plex actions in other Portlets, based on certain rules and values stored within the Portlets. This type of capability is a key differentiator in portal platforms today.

Portlet Management Most portal platforms ship will a manageable

number of Portlets. However, as the number of Port-lets grows from both external sources and internal development, management issues, such as finding the appropriate Portlet, updating it, maintaining ver-sion control, etc. will become problematic.

We are just beginning to see portal platforms provide management facilities to handle large num-ber of Portlets.

2. PORTAL-LEVEL SERVICES

Portal-level services span the user activities and connect them to the portal framework and to each other. While these services are important to provid-ing advanced portal functionality, none are essential for simple portals, and most can be offered via inte-gration with third-party products and services. Key portal-level services are:

• Single Sign-On • Search/Retrieval Services • Collaboration Services • Content Management Services • Knowledge and Expertise Management Services • Context Management Services • Business Process Management Services

Single Sign-On Portals need to provide a method for users to

login a single time and be able to access information and applications via the portal without having to login again. Portal platforms can provide their own Single Sign-On (SSO) and/or integrate with one of the available enterprise SSO or identity management products.

Search/Retrieval Services A key capability of any portal is to provide a way

to search across multiple internal and external data sources. Many portals include their own full-text search engines, while others OEM or integrate with third-party products. More advanced portal searches enable federated search, where a single query can be sent to and processed by multiple engines and return a single response. Other advanced types of search include parametric searching and social searching.

Portals can also vary in the level of sophistication in presenting the retrieved information to the user—some of the more advanced capabilities include Boo-lean, metadata, or parametric search; relevance rank-ing; and stored searches that are re-run by the user or re-run themselves on a scheduled basis, alerting the user with any new results.



Collaboration Services While collaboration and portals have different

origins, they are more and more becoming inter-twined11. Today, virtually every portal platform of-fers at least some collaborative capabilities, either directly or via integration with third-party products.

COLLABORATION WITHIN PORTALS. On the highest level, Collaboration Services enable portal users to interact with other people. Collaborative capabilities can be presented to users within portals in one or more of three ways:

• Access to Collaborative Applications and Services. Collaborative capabilities can be di-rectly accessed by the portal user from a Portlet. For example, a person’s IM buddy list, a threaded discussion, or project workspace can each appear within the portal interface or can be a portal page unto itself.

• Task-Oriented Contextual Collaboration. Collaborative capabilities can also be accessed within the context of work going on in the por-tal. For example, a user reading a document can see the author’s online availability and open a chat session with him. Or a customer service representative can find an expert on a specific problem who is online at the moment.

• Place- and Project-Based Contextual. Similar to work-based context, place-based context en-ables collaboration among people who are in the same place (page or Portlet) within the portal. These means that, for example, people working on the same project can instantly find each other to collaborate in real time (while perhaps main-taining their “unavailable” status for everybody else). At some point in the future, portals will know enough about a person’s context to know which project she is working on, irrespective of specific pages or places. At that point, we will be able to provide project-based presence awareness (see Illustration 3).

11 See “On Adaptive Portals and Contextual Collabo-

ration, Is It the Perfect Match?” http://www.psgroup.com/ doc/products/2002/8/PSGP8-15-02CC/PSGP8-15-02CC.asp.

CATEGORIES OF COLLABORATIVE SERVICES. We divide collaboration services that can be pro-vided by a portal into four categories:

• Online Presence Awareness. This determines and presents the presence status of other users. This can be in the form of a personal “Buddy List,” a user directory, or, as noted above, within the context of the work being done in the portal.

• Persistent Shared Workspaces. These can in-clude threaded discussions, shared documents, document management, project management, and workflow. Shared workspaces can be cre-ated and managed by administrators and, in some platforms, by users themselves.

• Chat and Instant Messaging. Often combined with presence awareness, this provides real-time text communication between individuals or among groups.

• Electronic Meetings. These take chat capabili-ties and add meeting functionality such as pres-entations, shared whiteboards, shared applica-tions, and audio/video conferencing.

Most portal platforms provide access to many of these functions by one of three methods: directly, by integrating companion products from the same ven-dor, or by integrating third-party products. Our view is that each approach is permissible. However, direct online presence awareness may be required for con-textual collaboration. In addition, third-party work-spaces, chat, and electronic meetings may not be able to become part of the overall knowledge man-agement of the portal and the organization.

Content Management Services Within the context of the portal, content man-

agement refers to the lifecycle (creation, approval, publishing, updating, archiving) of the content that goes into the portal12. Some portal products contain their own integrated content management capabili-

12 See “Content Management: Our Framework for

Evaluating and Comparing Enterprise Content Manage-ment Systems,” http://www.psgroup.com/doc/products/ 2002/9/FW9-26-02CC/FW9-26-02CC.asp.



ties (generally delivered as “light” or Web content management), while most integrate with popular enterprise content management systems. The inte-grated option is generally less expensive and fre-quently enables faster deployment of the portal.

Our philosophy is that portals, ideally, should not require their own content management. Very little content should be created solely for the portal. Con-tent should be created and managed as part of the business processes that own their information. This information can then be accessed via the portal.

This approach tends to raise organizational is-sues, since the portal owner has little control over the content and has to negotiate with the content owners to keep it fresh and up-to-date.

The decision around portal-related content man-agement can take on organizational and cost dimen-sions as well as technical evaluations.

Knowledge and Expertise Management Services

A major purpose of many, if not most, portals is to provide access to the overall knowledge of the organization. This knowledge can be surfaced to the user via simple search (for access to documents) and collaboration (for access to other people).

Knowledge Management systems provide addi-tional capabilities in exposing organization knowl-edge to users. This can be done by creating and maintaining metadata based on Information Tax-onomies that reflect the business and its concerns

Project-Based Presence Awareness

MyProjects.com


MyProjects.com


MyProjects.com

Project YellowProject BlueProject Green

Available

Busy

Available

Busy

Available

Busy

Betty

Grace Howard


Illustration 3. In this illustration, collaborators are only available to other team members working on the same project. If Betty stops working on Project Blue and switches her focus to Project Green, the portal will recognize the change of context and make her available to Grace but not to Howard.



and enable topic-oriented search of metadata as well as full-text search of documents and pages. We are just now beginning to see taxonomies being intro-duced as part of portal solutions. In addition, Knowledge Management tools can be used to pre-sent information to the user in customized and unique visual representations.

One specific area of Knowledge Management—Expertise Management—uses the portal (or scenar-ios within the portal) as a way to find information and experts. Expertise can be an explicit part of the portal directory, can be based on the user’s roles, or can be implicitly determined by activity (e.g., I have authored x number of documents on this topic, or I have participated in these specific discussions). Ex-pertise management can also be a key part of col-laboration—where I want to collaborate not with a specific person or persons, but with people knowl-edgeable in a particularly subject or field. We are just beginning to see Expertise Management services being offered within portal platforms or by third-parties.

The term, “Knowledge Management,” is cur-rently out of favor and few portal platforms specifi-cally call out their capabilities in this area. However, we believe that the ability to use the portal for knowledge/expertise discovery and sharing, and, in turn, the ability to leverage portal activity to further improve the organization’s understanding and man-agement of its knowledge resources, may just prove to be the driver that will bring Knowledge Manage-ment back into the forefront.

Context Management Services A basic capability of any portal platform is state

management, the ability to maintain throughout a session a certain set of user context variables, such as who the user is, from what device is he accessing the portal, and is the user still online (presence awareness). This level of context management is required to create what appears to be a single session to users, since the basic Web protocol (http) is itself stateless. In addition to basic state information, deeper context can be maintained, such as in what role is the user acting and what has he done up to now.

We expect to see an evolution to more advanced context management services in the future—services

that would understand what the user is trying to do by viewing the context as a series of steps, not only the first or last step. We are also beginning to see services offered that can manage user context across sessions and even across devices. While these are not yet included in portal platforms, they are likely to emerge as portal-available services soon.

The Future: Business Process Management Services

Today, this category is a placeholder for a set of service we expect to become available over the next year or two. These services will enable rules and workflow that reside at the portal level, not within individual Portlets. These rules and workflows will be used to build and manage meta-processes (which match the user’s real business processes) that cross the existing stove-piped applications that are ac-cessed via Portlets.

3. PLATFORM ARCHITECTURE

We evaluate five elements of platform architec-ture:

• Environments • Organization • Structure • Security • Enterprise ’abilities

Environments Portal platform environments include factors

such as:

• Operating Systems—which operating systems and which versions does it run on

• Operating Environments—specifically J2EE and/or .NET

• Application Servers—which application servers are included and/or supported

• Content Storage—where content is stored (e.g. RDBMS, document database, content manage-ment system, file system)



• Repository Database—which databases are in-cluded and/or supported

Organization Organization identifies a product’s major com-

ponents and the interfaces between them. Typically these include a repository database that stores con-figurations and user profiles, a state engine that pre-serves session information, and the portal engine that handles user requests and portal communications with Portlets.

Structure Structure describes what is inside the product’s

major components, particularly the Web pages, pro-gram logic, and database. This includes the language of the components, whether they are built on an ob-ject model, how they present their metadata, and whether they are exposed as Web Services.

Security Portal platform security includes the basic secu-

rity categories of:

• Authentication—including username/password, PKI, and other methods of recognizing users

• Authorization—the ability to limit access to in-formation and functions to specific users

• Encryption—between user and portal, within the portal functions, between Portlets and informa-tion sources

One key aspect of portal security is the ability to integrate with corporate directories (LDAP, .NET, Domino, etc.) and third-party enterprise identity management systems such as those from Netegrity, Sun, Tivoli, and Oblix.

Enterprise ’abilities Enterprise ’abilities include the reliability, avail-

ability, and scalability of the platform. Supporting features include:

• Load-balancing • Clustering • Cloning • Fail-over • Mirroring/State Management

CONCLUSION: USING THE FRAMEWORK

Portal can be used both tactically (to aggregate and present information to specific constituencies) and strategically (to re-define your customer-, part-ner-, and employee-facing processes). Selecting a portal platform is but one of the key decisions that must be made—with your overall portal strategy, the business case, and organizational responsibilities being equally important. That said, it is important that the portal platform selection meet your current portal needs and be able to evolve as your needs and the scope of your portal strategy changes.

The framework documented in this report has been designed to help you select the portal platform product that is best for you, minimizing the time and risk of that selection. Our ongoing evaluations of portal platform offerings against the framework will further simplify and reduce that risk and will help speed your evaluations. In a few months, we’ll com-pare the products that we’ve evaluated. These com-parisons, based on the key attributes that differenti-ate the products, will simplify, speed, and reduce the risk in your selection decision even further.



Patricia Seybold Group Portal Platform Evaluation Framework Matrix

Platform 1 Platform 2 Platform 3 Platform 4 User-Level Portal Services

Access Services User/Group Management Device Management Globalization

Presentation Services Design Navigation Customization Personalization

Integration Services: Portlets Included Portlets Portlet Development Environment Portlet Architecture Web Services Portlet Standards Portlet-to-Portlet Communications Portlet Management

Portal-Level Services Single Sign-On Search/Retrieval Services Collaboration Services Content Management Services Knowledge and Expertise Management Services Context Management Services Business Process Management Services

Platform Architecture Environments Organization Structure Security Enterprise ’abilities

Documents

An Executive’s Guide to Portals - CRModyssey.com … · How to Position Portals within Your Overall IT and E-Business Strategy.....5 The Future of Portals On Doors, Windows, Workspaces,