impossible for ideas to compete in the marketplace if no forum for
Architecture for Federated Portals
Contributed by InfoImage, Inc.
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. Thats 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:
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 organizations 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.
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 organizations partners and suppliers as part of the federation. In effect, the portal network supports information sharing, collaboration, and decision making throughout an organizations 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 users 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
Todays 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 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.
By avoiding the "one size fits all" approach, federated portals focus on providing a particular department with a portal environment tailored to that departments unique needs. This, in turn, streamlines planning and greatly assists in consensus building.
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:
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.
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.
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.
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:
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.
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 organizations 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 users 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 users job than it does to the artifacts of the IT infrastructure.
Completing transactions with the help of an affiliated server
In todays 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:
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.
The other subsystem that leverages the federated architecture is the Knowledge Broker repository. This repository houses the metadata that contextually ties the following together:
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:
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.
Specific business and technological advantages of a federated architecture include the following:
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.
Search the ENTIRE Business
Forum site. Search includes the Business