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.
Intranets
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.
(top)
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.
(top)
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.
(top)
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
(top)
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.
(top)
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.
(top)
Next
Chapter
Table of
Contents
Original Version: October, 1996
Last Updated: November, 1996
Copyright 1996 - Steven L.
Telleen,
Ph.D.
info@iorg.com
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.
|
