Introduction to Portals

This topic provides background information on fundamental portal concepts and definitions, portal frameworks and features, and portal models relevant to this Portal Strategy.

Fundamental Concepts

This topic explains fundamental concepts and definitions.

Portal Definition and Characteristics

Definition: A portal is a gateway that provides a given user community with access to an organization’s information, services, and data through a consolidated web-based user interface.

Through an organization’s portal, a user gains access to content and services provided by multiple sub-organizations and applications. The user perceives the multiple applications as one system since the portal implements common mechanisms for navigation, authentication, and layout for all content and services.

Portals share several other important characteristics:

  • Typically, a portal appears to users as a website accessed using a web browser. Portal gateways can interact with other client devices such as smartphone applications, telephones using voice and touch-tones, or client applications supporting cellular text messages, e-mail, File Transfer Protocol, facsimile, or other digital data transmissions.

  • Client devices can communicate with a CMS portal through one or more CMS networks designated for that portal. Thus, a portal can be on an external network (the Internet), an internal network, or both. Each portal has a unique address on each network.

  • A portal system can host multiple portals (each with its own address) to serve different user communities or different types of client devices. The community of users served by a given portal may include multiple types of users with different roles and interests.

  • Portals are used by the public, business partners, and employees. A portal may be available to the public, or it may be limited to specific user communities such as enrolled physicians or CMS staff.

  • Portals are customized for the purpose they serve, such as providing information and data collection for physicians or integrating information and tools from multiple data systems to create an efficient digital workspace for a CMS knowledge worker.

Enterprises with Multiple Portals

Enterprises that operate multiple portals on the Internet, or on any network, must make business-driven trade-off decisions. They can choose to consolidate content into one portal, integrate separate portals, create distinct portals for each line of business or user community, or some combination thereof. Several factors should be considered in these decisions:

  • Multiple unrelated portals may confuse users with multiple userIDs, conflicting duplicated information, or inconsistent branding. Multiple portal systems may also duplicate resources and lead to higher implementation and maintenance costs.

  • Significant differences exist between portal platforms in cost, content management, and compatibility with business applications. Some business domains may see significantly lower operations and implementation costs if they use a portal platform that exactly matches their needs instead of a standard product selected by the enterprise. Security concerns, rapid development requirements, or support for specific web technologies can also drive an enterprise toward multiple portals.

  • Portals dedicated to a specific line of business or to a specific community of users may allow significant efficiencies in marketing and user administration.

Portals on the same network (such as the Internet) can be designed to allow users to seamlessly navigate between them. This allows the possibility of several independently operating CMS portals on the Internet appearing to users as a single CMS portal environment with one primary entry point address. This also allows any portals on the same network to serve as entry points to this unified CMS portal environment, if they are so designed.

The CMS enterprise must determine how best to execute optimal branding and marketing of CMS portals and content.

Definition: The scope of a given portal is defined by the community of users that portal serves and the client devices it supports.

An enterprise approach to planning multiple portals requires a clear description of each portal’s scope. For example, a top-down approach to enterprise portal planning begins with creating a three-dimensional map that includes:

  • The user communities to be served by the portal(s)

  • The content and services each user community requires

  • The types of client devices that will provide content and services to each user community

This mapping process will identify which portals are needed and provide a basis for each portal’s charter.

Portal Systems and Portal Frameworks

This chapter makes distinctions between three related terms:

  1. Portal. The interactive digital environment presented to users.

  2. Portal System. The software, hardware, and network infrastructure used to create and manage one or more portals.

  3. Portal Framework. The portal system plus other software, metadata, standards, process workflows, and technologies used to create, manage, and render content for one or more portals. Some portal systems provide a complete portal framework, while others rely on separate components for web content management functions.

The most effective portal framework design for a given portal depends on the purpose and content required by that portal. Existing CMS portals currently use multiple portal systems and frameworks. CMS is developing a portal system reference architecture that will provide guidance for multiple portal frameworks. Over time, CMS will migrate existing web applications to the portal system reference architecture.

Web Applications, Web Services, and Portlets

A “web application” is a business application that uses web technology. The term is most often used to describe applications that use a web browser for the user interface, but it also includes any use of web technologies within an application.

Web applications are often designed as standalone portals that present users with only one application-specific user interface. Web applications may also be designed as either “web services” or “portlets” to be integrated into enterprise portals.

Web services are interfaces of a web application that support transactions using Extensible Markup Language and related cross-platform web service standards. Portal-side scripts present an input form to the user, pass the user’s input to the web service, and render the transaction results for display to the user. Web services require development of portal-side scripts that often must be uniquely customized to each portal platform.

Portlets are pluggable, user-interface software components of a web application that are managed and displayed in a portal, often as a window, frame panel, or image within the portal’s user interface. Portlets may be standalone applications (for example, a calculator); a generic interface for a standards-based application service (for example, a newsfeed reader that displays news headlines); or an application-specific, client user interface such as a form or a dashboard graph. Portlets often use web services as an interface to web applications. Portlets do not require customization of scripts or code for each portal platform, and their installation on a portal is a relatively simple process.

By incorporating web services or portlets, an enterprise portal can present the user with a single user interface to multiple web applications. For both web services and portlets, adherence to industry standards is essential for compatibility and interoperability.

Web Content Management

Web content management (WCM) refers to four functions: creating, managing, storing, and deploying web content. A web content management system (WCMS) is a collection of products, preferably integrated, that supports these functions by providing some or all of the following content services:

  • Authoring

  • Publishing

  • Scheduling

  • Storage

  • Versioning

  • Workflow

  • Archiving and Disposal

From an enterprise perspective, all WCM implementations must address existing federal and CMS policies for protection of sensitive information, CMS disclosure and public release requirements, and data retention requirements. WCM implementations are unique to each portal framework and sometimes to each portal. CMS uses multiple WCMS products to support portals across the Agency, subject to the following goals:

  • To ensure consistency for all portals that content appears on, each collection of content should have only one original source within CMS.

  • To avoid unnecessary complexity and inefficiency in web content management, content should flow through a minimum number of WCMS workflow paths to reach portals. Parallel WCMS workflow paths should be consolidated or connected whenever possible.

  • To leverage common skills and IT investments, CMS will standardize on one WCMS product for all portals and all content other than web applications. Other WCMS tools may be used when appropriate or advantageous to CMS.

Three Portal Models

From an enterprise strategy perspective, the biggest difference between portal models is not in their technology, but in their purpose, user interface design goals, owner responsibilities, and content life-cycle workflow. Table - Three Different Portal Models compares three different portal model examples to illustrate these differences: Applications-Focused Portal, Information-Focused Portal, and Team Collaboration Portal. Operations, governance, and portal frameworks will be different for each of these (or any other) portal models.

Table - Three Different Portal Models

Component

Applications-Focused Portal

Information-Focused Portal

Team Collaboration Portal

Purpose

Provide a unified user workspace where all information, resources, and tools are readily available to users to support a given user role, job function, or activity.

Inform and educate users, providing access to services and assistance.

Provide tools and workspaces that teams may use to share, communicate, and collaborate on documents, information, calendars, and tasks.

Design & Personalization Goals

Provide a highly task-optimized user interface that aids users in their daily roles.

Provide an intuitive and supportive user interface presenting content in convenient formats that guide users’ attention to relevant information.

Empower a team to customize their workspace while ensuring simplicity and security.

Content Characteristics

  • Content represents a user’s actual work and resources for a given activity or role.

  • Some content may be prioritized for presentation based on timeliness, importance, or relevance.

  • Content other than that generated or retrieved by applications rarely changes.

  • Content has no life-cycle workflow except as implemented by the applications.

  • Content is provided by one or more CMS organizations or services.

  • Content must be intuitively organized, easily navigated, and searchable.

  • Some content may be prioritized for presentation based on timeliness, importance, or relevance.

  • Content is frequently added or changed.

  • Content life-cycle workflow is defined and automated.

  • Content is provided by users.

  • Content must be searchable.

  • Intuitive organization and navigation may be a team responsibility.

  • Content is continuously added or changed.

  • Content life-cycle workflow is ad hoc and manual.

  • Users are allowed some control over access to content and its organization.