White Papers


© Copyright 2000

TOC - Ch 1 - Ch  2 - Ch 3 - Ch 4 - Ch 5 - Ch 6 - Ch 7 - Ch 8 - Ch 9

Chapter 4: Logical Architectures

Intranet Organization: Steven L. Telleen, Ph.D. 

Preliminary Concepts

Before discussing the architecture of Intranets, a few background concepts need to be introduced. 

An Intranet is a communication infrastructure. It is based on the communication standards of the Internet and the content standards of the World-Wide Web. Therefore, the tools used to create an Intranet are identical to those used for Internet and Web applications. The distinguishing feature of an Intranet is that access to information published on the Intranet is restricted to clients in the Intranet group. Historically this has been accomplished through the use of LANs protected by Firewalls. More recently technology has begun to make restricted access feasible in shared environments. The advent of virtual firewalls will extend the concept of an Intranet, but the basic distinguishing feature will remain the protected environment, be it real or virtual, for the Intranet information. 

Two Types of Pages
There are two basic types of pages: content pages and broker pages. Content pages contain the information of value required by a user. Broker pages provide context to help users find the content pages appropriate for their current requirements. 

Content pages can take many forms. They may be static pages, like the ones you are reading here, or they may be active pages where the page content is generated "on the fly" from a database or other repository of information. Content pages generally are owned by an individual. Over time expect the "form and sense" of content pages to change as more experience is gained in the areas of non-linear documents (hyperlinking), multimedia, modular content and integration of content and logic using applets. 

Broker pages also come in more than one form, but all have the same function, to help users find relevant information. Good broker pages serve an explicitly defined audience or function. Many of the pages with which we already are familiar are broker pages. A hyperlink broker page contains links to other pages, in context. It also may have a short description of the content to which it is pointing to help the user evaluate the possibilities. On the other hand, a search oriented broker page, like AltaVista, is not restricted to the author's scope, but it also does not provide the same level of context to help the user formulate the appropriate question. 

Combination search and hyperlink broker pages are common today. Search engines return the "hits" as a hyperlink broker page with weightings and first lines for context, and hyperlink broker pages sometimes end in a specific category that is refined by searching that defined space. It is unlikely that hyperlink broker pages ever will be generated entirely by search engines and agents, because the context that an expert broker provides often contains subjective or expert value in its own right. After all, not all content is of equal quality or value for specific purposes, and even context sensitive word searches cannot provide these qualitative assessments. As the amount of raw content increases, we will continue to need reviewers to screen which competing content is most useful, or identify the official source, for workers in our enterprise. 

A special use of broker pages is for assisting with the management of web content. There are several specific instances of these management pages. We call one instance the "Enterprise Map" because collectively these broker pages form a hyperlinked map of all the formal content in the organization. Other sets are used for project management, functional management and to support content review cycles. The use of broker pages for each of these management functions is discussed in more detail in the next section. 

The Enterprise Map

A structured set of broker pages can be very useful for managing the life cycle of published content. We call this the Enterprise Map, and while the primary audience for this set of broker pages is management, we have discovered that end users frequently find the Enterprise Map useful for browsing or to find content when their other broker pages have failed them. 

With the exception of the content pages at the bottom of the map, the Enterprise Map pages consist only of links. Each page corresponds to an organization committed to the creation and quality of a set of content pages. In today's organizations, commitments tend to aggregate into a hierarchical pyramid, but the mapping technique also could be applied to most any organizational model. The Enterprise Map also does not have to be based on organization. It could be a logical map where the top level is the mission, the next level the major focuses required to accomplish the mission, and so on, down to the content level. Since most large organizations are starting from a pyramidal accountability structure, that is the form of the example that follows. 

Using the terminology from the previous chapter, the Enterprise Map begins with a top page, owned by the CIO and /or CEO (with responsibility usually delegated to the Web Administrator). This page consists of a link to the Map Page of each line of business and major support organization in the enterprise. The Map pages at this next level are owned by the publisher for each organization. The Publisher Pages, in turn, consist of links to each of their Editor's Pages. The Editor's Pages may have additional pages or structure below them created and maintained by the editor that help organize the content, but ultimately these pages point to the formal content pages. 

This model can scale to governments or large diversified companies. In a government organization, the Administrator's Page would point to all the Agencies, and the map would follow each agency structure to the content level. Since each agency may be a large organization, each may have its own Administrator and Web Council. A major advantage of this mapping architecture is its flexibility. It can originate from the top down or the bottom up. If several government agencies developed their Intranets independently, with this type of Enterprise Mapping structure, they can be linked together at any time in the future by creating the next level map page. None of the existing Maps need to be changed. This flexibility is a result of the distributed decision making central coordination model on which the architecture is built. 

The Map provides a commitment (or accountability) view of all the formal content in the enterprise. Management can start at their point in the map and follow the links to all the content which supports the functions for which they are responsible. They also can look at what other organizations provide and how well it integrates. Experience predicts that when a Management Map is first implemented, and managers get involved, they are shocked by the quality and incompleteness of the information for which they are responsible. The reason is that they have never been able to easily browse all the information and create multiple, contextual views of their own when the information was on paper or in rigid electronic formats. The Intranet gives them this ability. Handled properly, demonstrating this ability to managers is a great opportunity to show the strengths of an Intranet for improving not just accessibility but information quality. 

An Enterprise Map has several interesting characteristics. Once it is in place, authors and editors can self publish, and the information automatically shows up in a logical structure. Also, content categories and even editor level functions generally are not affected by reorganizations, because major product lines and service areas generally are not added or deleted. Most reorganizations shift responsibilities at higher levels in the Map. This means that when a reorganization does occur, the Map can be adjusted quickly, by the managers affected, by changing one or a few links. Content does not need to be moved around. The result is a very low maintenance path to all the formal enterprise content, without forcing publishing through a central authority that can quickly become a bottleneck. 

Shadow Maps

The Enterprise Map provides a management path to all the formally published content. However, management also has a need to see work in progress, formal content that is not yet completed. This is the realm of project and departmental information. A Shadow Map can be constructed for this purpose. The Shadow Map works the same way as the Enterprise Map, but it is not generally advertised and can be protected by passwords or other access controls. The Shadow Map can be enhanced with a few additional Broker Pages to assist with the management of content development. 

A Shadow Map continues down to the author level. In this model, the author maintains an Index Page that is divided into two sections, work commitments and work completed. When the first draft of committed content is created, the author places it in his web directory and links the item line on his Index Page to the file. As revisions are made, the author places the latest version in the same directory with the same name so the Index automatically points to the latest version. This does not preclude keeping back versions if they are required. The previous version is copied and numbered as it is moved out of the current version status. When the content completes review and goes into "production" the author moves the item from the committed section to the completed section and redirects the link to the permanent address of the published item. Note that this can work for development of non-web content as well by configuring mime types and having the browser automatically start up the appropriate application on the client when the link is activated. 

A second Broker Page that can be added is a Project Page. This page is created by the Project Manager and contains item lines for all the project deliverables. When the author creates the first draft, she not only links the content file to her Index Page; she also notifies the Project Manager of the location so the content can be linked to the appropriate line item on the Project Page. Like the Index Page, as the content is revised the Project Page always points to the most current version, without additional maintenance. 

In a matrix organization a third Broker Page can be created by the Functional Manager. This page consists of links to the Index Page for each employee reporting to the Functional Manager. This provides a quick path to the work, both in progress and completed, of all her employees. Once again, after the structure is set up, it takes little maintenance, with each person keeping his own information up to date. 

Finally, Reviewer Pages can be created when the content is ready for review. Each reviewer has a "Review Page," which consists of links to all the content in their review queue. When the Editor (or whoever is responsible for managing the review process) places the content into formal review, it is added to each reviewer's page. The reviewers access their page when they are ready to do reviews, and by selecting a link can retrieve and view the content. There are numerous ways the comments and comment resolution could be handled using Internet technology. One is to funnel comments into a threaded-discussion-group format. Automated email messages can be used to notify or remind reviewers of deadlines and status. 

The various Broker Pages discussed above are meant to create a model of the basic management functions and how they can be structured. Whether or not the specific model described here is used, the most effective process for managing Intranet content will use Intranet tools and approaches. 

When we first conceived of this model, there were no higher level tools to help create and manage the pages for a process like this. Today several tools are emerging to help manage functional sets of pages, and they can be configured to support these processes. Some are message-based, others are centralized, shared-database models with Web front-ends. Over time, we anticipate that a variety of vendors will offer improved tools, based on Intranet paradigms, that are specifically tuned to support the distributed, message-based management model. What ever tools are chosen, the most effective are those that help the functional managers use the Intranet to manage the development of the content for which they are responsible, without requiring technical specialists in between. In the beginning, many managers may find a simple static page implementation of this logical structure more approachable than a more sophisticated automated tool. 

General Brokering

Brokers are the main way users find information on an Intranet. A broker may serve many functions. He may provide information to users in the context of specific processes, providing structure for efficiency and consistency. He may screen large pools of content for material relevant to a large number of employees so each one does not have to duplicate the process. He may identify which information is considered official. Or, he may provide interpretation of general information in the context of the organization. 

Most knowledge worker jobs today involve some form of information brokering. In the paper world the broker output often is formally sanctioned by the organization and may be the worker's main responsibility. The same kinds of roles will evolve in the Intranet world, and ideally the people in the role today will evolve into the electronic version of their role. These types of formally managed broker pages can be treated as content in the map structure described above. 

Most organizations also have informal broker pages that spring up. An individual may start the page for herself, and it gains a following, or she may identify an unfilled need and consciously fill it. These pages can be a valuable way to identify and quickly meet new requirements. However, until these pages are in a formal commitment (or accountability) structure, there is no guarantee that the content is verified or that the author will keep the content current. 

The Broker Directory
An Enterprise Broker Directory, sometimes called a "Yellow-Pages," organized by subject, can help users find the broker that they need. The Broker Directory generally is maintained by either the Web Administrator or the Web Grandmaster. Because informal broker pages are included in the Broker Directory, some mechanism needs to be included to keep the directory from filling up with outdated and abandoned pages. As with other Intranet functions, the challenge becomes providing the centralized view without imposing a central implementation bottleneck. 

One way to handle this is to create a "Sunset" provision for all pages not officially managed by an organizational entity. Any broker can list their page by submitting a web form or email to the Web Administrator or an automated script. However, informal pages are only listed for 60 days. If the broker does not renew the request in 60 days, the page is removed from the Broker Directory. This allows informal brokers to "self-publish," and protects the directory from becoming a repository of links to abandoned pages. 

The Enterprise Index
The Enterprise Index provides users with another way to find information. This frequently is tied to the Search Engine. Keeping with a distributed decision-making model, the Index and Search Engine should not require pages to be published on a specific system or managed by specific management software. The Index and Search Engine should be fed by a discovery agent (Web Crawler or Spider) that regularly searches the Intranet and catalogs the content. This is consistent with the coordination versus control model and also protects the enterprise from major conversion efforts (proprietary locks) if an alternative product or upgrade is desired in the future. The Enterprise Index provides yet another way for users to find the content they require. 

Brokering Summary
Three distinct discovery paths need to be provided by the Intranet Infrastructure: 

  • The Enterprise Map
  • The Broker Directory
  • The Index and Search Engine

Workflow Management

Workflow management is a relatively new focus for the Intranet. Historically, a number of Internet/Web tools have been available to help with this process. Email, threaded-mail discussion groups and news groups provide forums for discussion and resolution of issues. The HTML "mailto:" function has been used to provide reviewers with easy connections through their browser to these forums. 

What has been missing are packages that integrate the functionality of the independent tools, add routing and tracking, and provide the user with an interface that is easy to configure. This appears to be changing with the appearance of companies like  MKS, Action Technologies, WebFlow and  Netmosphere  who now offer web-enabled and web-based products that support groupware, reviewer comments, routing, sign-off, checkout-checkin and project management functionality in an open, web environment. 

Access to Database Information

Discrete, structured information still is managed best by a database management system. However, the quest for a universal user interface has led to the requirement for access to existing database information through a web browser. Three models of access can be identified: 
  • Automatic tailoring of page content
  • User specified database requests
  • User initiated database updates
From a technical standpoint, there are a number of ways these interfaces can be created. What is important is that access be provided to the authors (knowledge workers) in a way that supports the distributed decision-making, enabling model rather than the centralized expertise model. This means that authors who are relatively naive technically need to be able to incorporate database managed data into their pages. 

A number of tools are beginning to emerge that move in this direction. Most of the database vendors and several other application vendors are pushing the use of their databases to manage all the content in the web. The advantage is unique pages can be generated automatically and easily. These are the tools that support the first model identified above, automatic tailoring of page content. The disadvantage is that much of the "distributed decision making" and "do for yourself" paradigm is violated. Experts are still needed to manage and change the database schemas for innovation to occur. 

A more promising approach combines a library of scripts (CGI, Java, Active-X, etc.) residing on the hosting web-server with templates, wizards and "bots" incorporated into WYSIWYG authoring packages (e.g. Microsoft's FrontPage ). Another set of tools, coming from the database side, automatically converts existing database schemas into hyperlinked web pages that allow users to browse and access the data from their web browser (e.g. Netscheme). When applications that merge these two functional approaches begin to appear, very powerful packages will be available to content providers who need to incorporate database information into their pages. 

This approach satisfies both the "distributed decision making" and the "do for yourself" paradigms. At the current time, these approaches do contain a "proprietary lock." The authoring tool and web server extensions are tightly coupled and not interchangeable with other packages. However, at this point the proprietary nature is not unduly restrictive. First, the client remains independent of the authoring tool and server extensions. Second, individual authors can choose to use different tools than those used by their peers, as long as a server with their tool’s extension set is available. Third, this technology is still in the early innovative stages, where a significant amount of knowledge needs to be gained. This is the appropriate stage for non-standard solutions. As more knowledge is gained, one hopes that the authoring tools will become increasingly independent either through standardization of the script libraries or through standardization of object linking technology. 

The development of object linking standards and the availability of tools that conform to these standards will increase the power of Intranet technology. These tools, in conjunction with previously mentioned software that uses agents to discover and create organized views of distributed objects, provide a promising base for supporting the distributed decision making and implementation model. A major trend one can expect to see is a move away from the use of database technology (or other structured technologies like SGML) for integrating content enterprise-wide. Instead these tools will be used to manage local content, and integration will take place as needed by linking the content objects through Intranet standard pages. 

A major topic in logical architectures is security. This topic is large enough to have its own chapter, which comes up next. 

Next Chapter
Table of Contents

Original Version: October, 1996
Last Updated: November, 1996
Copyright 1996 - Steven L. Telleen, Ph.D.

This material is based in part on work that the author wrote while an employee of the Amdahl Corporation. Those portions covered by the Amdahl Corporation Copyright are reprinted with the permission of the Amdahl Corporation.

  top page | papers

For more information contact:
© Copyright 1997-1999