"It is impossible for ideas to compete in the marketplace if no forum for
  their presentation is provided or available." �        �Thomas Mann, 1896

---

Architecture for Federated Portals

Contributed by InfoImage, Inc.

Introduction

This paper discusses the difficulties in implementing enterprise portals for large organizations, and describes the business and technical advantages of using the federated portal architecture to build an enterprise portal.

Much has been written about enterprise portals. The idea is simple and compelling: build a web and browser-based system that allows knowledge workers in the enterprise to access all the information they need to do their job, regardless of where that data is stored. By providing access to numerous corporate data sources through a single web interface, called the enterprise portal, employees save time they would otherwise spend requesting reports, contacting colleagues, and waiting for answers from other departments.

Implementing this appealing idea, however, is seldom easy. That’s because most enterprise portals on the market are built on a "data center" architecture that relies on centralizing the access to data in one server and, that also requires a centralized, enterprise-wide planning and implementation program. This data center approach has three costly liabilities:

• Collecting and restructuring enterprise data to fit the schema of a centralized architecture consumes substantial enterprise resources.

• Up-front planning and development time involves logistical and political roadblocks associated with building consensus for enterprise-wide issues.

• As the number of users grows beyond the capacity of a single server, additional servers must be added. In the process, knowledge management and collaboration functions are lost, isolating the users associated with the separate servers.

As a result, enterprise portal projects built on data center architecture are rarely successful.

Why Implement a Federated Portal?

Most enterprise portal solutions are based on an architecture that a) collects all enterprise data and stores it in a data warehouse, or b) connects to all data sources using a single enterprise information portal server. Under this architecture, information is distributed to users from the data warehouse or enterprise information portal. Portals designed around either of these approaches can be accurately described as data center enterprise portals.

The alternative to data center enterprise is based on the idea that the benefits of the distributed computing model can be applied to portal development. A distributed architecture approach offers an attractive solution to the problems inherent in data center enterprise portals. These problems include business issues such as planning, ownership, and budgeting and technology issues such as scalability and growth.

A distributed architecture for an enterprise portal involves a network of connected, department-sized portal servers working together as a group of federated portals. The word "federated" implies a union of independent entities working together to provide specific functions. This federated portal approach is exactly the solution needed to overcome the problems faced in building data centered enterprise portals.

Data Center Architecture

A data center architecture approach to building an enterprise portal fails to present a viable solution to alleviate the complexities of building an effective portal solution. The problem with this approach is that collecting and restructuring enterprise data to fit the schema of the data warehouse requires an exhaustive, labor-intensive effort that consumes substantial enterprise resources. As a result, the collection and distribution of data within the enterprise represents a serious bottleneck in the planning and execution of enterprise portals. In most cases, departmental portals need data from the organization’s centralized systems combined with their own locally kept departmental data. However, departmental data is usually kept in departmental systems that are often not under the control of IT, and not maintained in the central data center. Many portal projects fail because of these planning and ownership issues. The data center approach is further hampered by the complexities of distributing data throughout user communities in diverse formats.

Figure 1 illustrates the centralized, data center architecture that leads to bottlenecks and inefficiencies inherent in the enterprise-wide planning and implementation of an enterprise portal.

Distributed Architecture

Building portals on a distributed architecture allows local departments to maintain control of their data and handle budget considerations related to planning and implementing the portal at the departmental level. This level of control facilitates the streamlining of planning and consensus building. A distributed architecture allows departmental line-of-business executives to build portal applications tailored to the unique needs of the department in a much shorter time than it would take to build traditional data center enterprise portals. In terms of technology, distributed architecture provides scalability at the very highest degrees, built-in redundancy, and the ability to invest incrementally so that the enterprise portal can be designed and built without the massive, enterprise-wide planning effort required by data center enterprise portals.

Another advantage of the distributed architecture model is its ability to include portals from an organization’s partners and suppliers as part of the federation. In effect, the portal network supports information sharing, collaboration, and decision making throughout an organization’s value chain, not just between and within its internal departments. This is in contrast to the emphasis of traditional supply chain and value chain automation, which is primarily focused on the transaction side of business, for example, sending and receiving purchase orders, monetary transactions, inventory adjustments, etc. A distributed architecture allows an enterprise to bring the information sharing and decision-making benefits of a portal to the entire value chain.

Federated portals work because they share a common knowledge framework across all federated servers that use common object models and protocols for communication, primarily XML and LDAP. The common knowledge framework is a shared user directory structure called Digital Business Identity (DBI) and a cooperative metadata directory called the Knowledge Broker (KB). DBI maintains an identity record for each user and KB maintains metadata information about the various data and information sources available to users. Each server in the federation relies on these core components to determine which server can best meet user’s requests for information or assistance.

Figure 2 illustrates the distributed portal architecture, which provides for more efficient planning and resource allocation.

The Federated Portal Advantage

Today’s business decisions are made most effectively at the department and even group level. However, the velocity with which business needs change, especially at the departmental level, threatens the relevance of a long-term enterprise-wide portal effort. In fact, enterprise portal projects often stall or are scaled back dramatically because of disconnects within the enterprise regarding planning, ownership, and budgeting issues.

The federated portal architecture solves this problem by distributing power; that is, by building multiple, locally owned portals – not one centralized portal – and so increasing the speed at which design decisions can be made and at which portals can be developed. The federated portal architecture recognizes that an effective portal maximizes the input of local operations under the guidance of organizational IT professionals.

Business advantages: planning, ownership, and budgeting

Building a portal based on data center architecture requires an investment of time and resources to plan and gain consensus on what data should be included in the data center. Budget and ownership issues magnify the difficulty in gaining consensus for the project. Even with strong leadership and commitment, it is often difficult to get all enterprise departments behind an enterprise-wide project, dedicating departmental budget and resources to the effort. These issues present a significant bottleneck to the overall project. As each department offers its vision of what the portal should provide, the scope of the project grows exponentially, requiring a costly and exhaustive planning process.

The federated portal solution attacks the problem of planning and budget allocation by allowing each department to shape and guide their own portal. With leadership and input from the enterprise IT group, federated portals allow for local, user level input into the design and implementation of a portal solution. The result is a reduction in costs and less time before users start to see benefits.

Planning

Planning and implementation can be done at the departmental level, thereby ensuring a speedy deployment, and an early realization of the financial benefits that the portal provides.

Ownership

By avoiding the "one size fits all" approach, federated portals focus on providing a particular department with a portal environment tailored to that department’s unique needs. This, in turn, streamlines planning and greatly assists in consensus building.

Budgeting

Because the federated portal is planned at the local, departmental level, budget responsibility and overall cost are clearly delegated. When a department needs to add a new portal server, or expand the capacity of an existing one, hardware procurement is simplified because the financial responsibility lies with a single department head.

Technological advantages: incremental investment, scalability, and growth

In addition to the advantages of local, departmental planning and budgetary control, a distributed architecture offers sound technological advantages over a centralized, data center architecture. A distributed architecture establishes a solid foundation that allows for:

• incremental investment

• rollout

• scalability

• growth

Incremental investment

A federated portal approach allows bandwidth, hardware, administration, and other infrastructure costs to be distributed over time, keeping pace with the development and deployment of the departmental portal servers.

Bandwidth needs are efficiently accounted for in a federated portal environment. Instead of routing all user traffic to a central portal server (or a central cluster of servers), the federated architecture keeps most of the traffic local to the individual portal server. In addition, portal servers can be set up in close proximity to the departmental systems to which they connect, which reduces networking and system-interfacing costs.

Rollout

A distributed architecture is also congruent with rollout strategies. Portal applications that result in immediate return on investment are of the department-level tracking and workflow variety. These applications should be built first, and the departmental portal server is the appropriate platform on which to build them.

The distributed nature of the federation, and the fact that servers in the federation communicate with each other, allow a degree of flexibility in the implementation of connections between portal servers and data sources. A distributed architecture does not require that every data source be connected directly to every portal server. This allows the option of configuring the federation so that it best suits the infrastructure of data sources that it must communicate with.

Scalability

One of the greatest advantages of a distributed architecture is that it naturally lends itself to supporting a large variety of connected systems. A portal server in the Finance department could be connected to an Exchange mail system, while the HR department portal could rely on an existing Notes Mail infrastructure. In this case, each server is individually configurable for its outward facing connections while still connected to the federation using neutral protocols.

A federated portal approach guarantees the scalability of the portal system at the enterprise level. This approach spreads user communities across a number of servers working together. Departmental portals supply users’ primary needs, while additional servers supply specific, enterprise-based information. Since all servers in the federation work together, the distributed portal architecture allows the customer to identify and adjust to the specific use patterns at the organizational level.

Growth

Because the full potential of the portal concept is not yet evident, it is imperative that organizations install portal architectures that can evolve as the uses for the portal change. A data center portal architecture requires far more rebuilding to meet compatibility requirements of new application types and usage models than a distributed architecture. A distributed architecture, on the other hand, continues to function as pieces of its network are replaced, upgraded, and redesigned for new uses.

To add new capabilities to the system, rather than replace or rebuild a portal server, it is possible to leave the existing servers in place and route requests that require new features (an improved search engine for instance) to a new server. Existing portal applications are thereby impacted only slightly.

The three reasons to add servers to the federation are to:

• Scale existing applications to a large numbers of users.

• Add functionality to existing applications by deploying a new server that provides that function, such as a customized form for searching and indexing.

• Bring additional user communities on-line with new applications while building on the KB and DBI data that already exists.

Because a distributed architecture provides a shared structure, it is possible to build portals simultaneously for several departments without requiring the large up-front planning needed for a monolithic enterprise portal.

Communication protocols

Distributed architectures require that close attention be paid to communication and synchronization protocols. The federated portal architecture does this at the system level. The software that allows federated portals to work together, and not the software that determines the information content of the portal, handles these basic, portal infrastructure duties. Obviously, the strength of the vendor platform in these areas is essential to the viability of the architecture.

Federated Portal Features

We have discussed the benefits of building federated enterprise portals based on a distributed architecture. Specifically, the federated portal approach opens up a number of functional possibilities, providing a far more valuable portal than one that simply disseminates data. Some of the possibilities are briefly described in the following:

Collaboration: enterprise decision making

A federation of portals can extend to the organization’s value chain with relative ease. The same effect can take place within the organization. In both cases, the larger reach of federated portals leads to the possibility of enterprise decision-making where people from disparate departments can participate in collaboration. This collaboration is facilitated using tools like workflow, chat, and expertise directory services.

Connections: leveraging information

The usefulness and power of any portal application is proportional to the number of systems it connects to. Portal applications built using the federated portal architecture have data from more systems available to them and can, therefore, be used for processes that span a number of data sources or enterprise IT systems. Under a federated portal architecture, it is not necessary to connect every portal server to every data source. This is because a single portal server can store query results (and other analysis) that run against systems it connects to, then share these results with other servers in the federation. In this case, servers within the federation can share to the degree allowed by security.

Personalization: role and task-based computing

An advantage of all portals, not just those built as a federation, is that the user’s view of the system can change from an application-centric one (dictated by the arrangement of systems they use), to a view determined by the role of the individual user. Because the portal provides one user interface to many systems, the distinction between those systems can be hidden from the user, and replaced with a portal console that conforms more to the user’s job than it does to the artifacts of the IT infrastructure.

Completing transactions with the help of an affiliated server

In today’s World Wide Web, we see many instances where users navigate from site to site to work with different vendors or partners. Each of these sites is different, with a different interface, different mechanism for search, creating/executing transactions, and so on. One advantage of a federated portal architecture is that basic information and collaboration data is shared between portals even if each portal presents the information differently or implements a different user interface. Thus, users can participate in workflow from another department (or even a partner) using the workflow tools, which they are familiar with from their own portal.

The Federated Portal: Technical description

As discussed earlier, Digital Business Identity (DBI) assigns users with an identity that describes their role, activities, skills, and position in the organizational chart. The Knowledge Broker (KB), on the other hand, provides users access to the information they need by creating and maintaining data relationships.

In a federated portal architecture, some data must be shared between the servers in the federation. Other data is specific to the application and is stored locally. The shared data comes in two types:

• user-specific information, e.g. everything stored in the Digital Business Identity for users

• data needed across applications, e.g. the Knowledge Broker data

Figure 3 illustrates the federated portal architecture, particularly the domain structure that comprises of a group of portals.

Digital Business Identity

Digital Business Identity consists of data specific to individual users. It consists of information about their skills, their role within the organization, the projects/activities they work on, their interests, their preferences, etc. This personalization information is not only useful for the portal system but is also very relevant to other users of the system. Personalization information helps users come together by identifying one another to collaborate, make better decisions, solve problems, and contribute to the overall knowledge of the organization. This distributed requirement of DBI information makes it a good candidate for a federated component of the portal.

Knowledge Broker

The other subsystem that leverages the federated architecture is the Knowledge Broker repository. This repository houses the metadata that contextually ties the following together:

• data sources with other data sources

• people with data sources via reports and queries

• people with data-related events (e.g. alerts)

The Knowledge Broker metadata grows as departments add more portals and connect them to various data sources, and as the number of users increase. Given that a Knowledge Broker repository is not, and cannot be, effective in isolation, the servers within the federation must exchange information stored in their respective knowledge repositories. The federated architecture allows metadata to be distributed across a group of portals, allowing users of any one portal to seamlessly leverage the knowledge repositories of other portals in the federation.

Federated Knowledge Directory

A Domain in a federation comprises portal sub-groups closely related either by a) geographical proximity or, more likely, b) a logical grouping based on user requirements for peripheral vision. Each portal in the domain represents a distinct user community. For example, a typical domain in a federation might consist of the following three portals, or user communities:

• an executive portal connected to financial and operational systems

• a field sales portal connected to CRM, customer service and order status systems

• a partner portal connected to an e-commerce system plus the customer service and order status systems

Each user community not only has access to relevant data on the home server, but also has access to information on the other servers in the domain. Restrictions to this access are governed only by security rules. This means that users who are stakeholders in a particular decision can share facts, collaborate to reach consensus, and jointly participate in the execution of the decision.

Conclusion

Specific business and technological advantages of a federated architecture include the following:

Business advantages

• Planning and implementation at the departmental level ensures a manageable deployment.

• Ownership at the departmental level allows executives and managers to develop a portal tailored to the department’s unique needs.

• Budgeting responsibilities can be clearly assigned at a departmental level.

Technological advantages

• Incremental investment allows bandwidth, hardware, administration, and other infrastructure costs to be distributed over time, keeping pace with the development and deployment of departmental portal servers.

• Rollout provides a degree of flexibility in the implementation of connections between portal servers and data sources.

• Scalability lends itself to supporting a large variety of connected systems.

• Growth allows the portal to evolve as the user requirements and available technologies change.

Building an enterprise portal around a data center architecture is like trying to eat an elephant – simply too large and complex a task to be handled in one sitting. A distributed architecture, on the other hand, gives line-of-business executives and managers the responsibility and power to plan and build smaller departmental portals that satisfy their unique needs and requirements sooner rather than later. These departmental portals can still participate in a larger, networked, implementation of a true enterprise portal. The end result is incremental investment, faster deployment, and a greater return on investment.

A federated portal strategy based on a distributed architecture model reduces the time and consensus building required in the planning stages. With departmental control and leadership from the organizational IT group, planning and budgeting issues are more manageable, the purpose and expectations of the portal are more clearly defined, and the portal strategy is seen by department level executives as having clear, tangible benefits for their short and long term needs.

---

The Business Forum
Beverly Hills, California, United States of America

Email:  [email protected]
Graphics by DawsonDesign
Webmaster:  bruceclay.com

---

 �  Copyright The Business Forum Institute - 1982 - 2014  ** All rights reserved.
 The Business Forum Institute is not responsible for  the content of external sites.

Read more

---