companies, the intranet started
as a grassroots experience -- often informal and unsanctioned. This
self-starting process certains advantages, particularly the capturing
of a high level
of interest and involvement from organizations and individuals
the formal IS structure.
Simply put, intranets give
"outsiders" more control than they've had with traditional computer
and it is the ability of intranets to involve and empower independent
and action that makes them compelling. However, as intranets are used
support more business communications, the requirements for integration
other resources -- both intranet and legacy -- become critical.
Integration pressures are
new. In the past we've tried to solve the problem by standardizing on
from a single vendor, but that strategy doesn't always work. Individual
or divisions sometimes continue to buy outside the standard to meet
needs, and there are instances where new products and capabilities have
emerged from someone other than the sanctioned vendor. This problem has
become exacerbated by the trend in mergers and partnering, where
there is a lot of
history and no single control over brands and vendors.
Intranets address these
problems better than any previously available set of technologies.
an intranet is an infrastructure, different from previous
in that it is based on Internet standards and tools, and focuses on
sharing within a limited and well-defined group.
efforts have attempted to force a homogenous approach, Internet
and tools are based on support for and incorporation of diversity.
rather than the process of content creation, is standardized; as long
an intranet tool can read, act on and output Internet-standard content,
internal workings and features are unimportant.
The issue facing enterprise
is that the arrival of Internet-type standards forces a network to
beyond the vendor-specific, legacy architectures. While this may seem
a daunting task, the payoff is that the foundation of the architecture
based on the enterprise's vision and needs rather than a vendor's
or technology requirements. This not only means more flexibility, but
the potential for the network owner/operator to differentiate his/her
An enterprise architecture
development at several levels in the organization (see sidebar). The
level of an enterprise architecture is the last to be developed,
provides the transition from the architectural abstractions to
products and implementations. It documents the services required and
they inter-relate. It does not include specific products or
The required services and standards depend not only on specific
of the business, people and process levels, but also on the legacy
and the future objectives of the organization. This article will look
approaches to integrating specific legacy situations.
The first step seems obvious,
but is often overlooked: defining what you intend to do. Is your intent
to take a legacy application and make
it available through a web browser -- i.e. web-enable an existing
-- or do you intend to build an intranet-based application that
legacy data? This is an important distinction because the requirements
tools are different.
To show the difference
"web-enabled" and "web-based," consider a web site designed to
a customer credit application process. This process can be looked at as
business-to-consumer process or a business-to-business process where
A wants a credit line from Company B. In its most basic form, the
lets a user come to the web site, fill out a form with credit
submit the form and receive information about acceptance or denial of
In the web-enabled system,
application on the web server does little more than accept the HTTP
(either a GET or POST), parse and package the data into a message and
the message back to the legacy workflow system, formatted to match the
system's API (Application Programming Interface). The legacy
processes the message just as it would input from any other source and
the appropriate action.
The business rules
with the process are encoded in and managed by the legacy application.
this case, the business rules might involve determining what credit
to offer, or whether to extend credit at all based on the submitted
credit history and current credit load. The legacy application
its standard output, which is post-processed into an HTML screen and
back to the application running on the web server. which then delivers
HTML content to the user's browser.
In the web-based system, the
on the web server parses the data in the request. The business rules
developed and managed using a rules-based system that allows the
person at the credit-extending company to enter, change and manage the
rules through their browser. In our example, the business person might
the rules governing how credit levels are set. Based on these rules,
rules-based system takes the request and determines what calls to make
workflow functions (application objects) that are able to interact
with databases or other legacy application services on the network.
the workflow functions are complete, the application on the web server
the business rules to the data received, merges the appropriate HTML
with the data, then displays the page to the user's browser via the web
While web-enabled systems
be a valuable migration tool for quick conversion of legacy systems,
time web-based systems are more desirable, because they are much easier
maintain and extend. Web-based systems also provide better performance,
both the business and computing points of view. This is because
systems require all updates to be funneled through the engineering
that supports the legacy system, where all of the functionality
which produces inefficiencies and inevitable backlogs and bottlenecks.
contrast, web-based systems can be maintained in a distributed fashion
different platforms for different purposes.
For instance, the business
that drive the web-based application can be updated or changed by the
specialists--the non-IT specialist who develops and is responsible for
rules from the business perspective. Similarly, the look and feel of
site can be updated by the designers responsible for presentation. This
the legacy and workflow functions to be updated by the engineering
that historically has been responsible for them.
are not easily extensible. Say the business wants to offer other
during the credit application process when the customer profile
a potential interest. For example, if the credit is being requested
a financial institution, and the requester profile shows that the
does business in foreign markets, the financial institution may want to
their new currency-exchange management services in addition to
the credit line.
In the web-enabled system,
only screens that can be presented to the user are those generated from
the legacy workflow system, but this system has no concept or ability
customize the experience. In contrast, in the web-based system, the
rules are separate from the workflow functions and legacy data.
presentation screens can be developed independently, even dynamically,
improve the audience's experience with the site. Even the new services
be integrated more easily, because they are integrated at the business
level, not as code in a legacy application.
A major benefit of an intranet
infrastructure and web-based applications is the ability to host
different services on different servers. While neophytes envision their
intranet as being hosted on the web server, experienced
practitioners quickly accept, and learn to leverage, the
power of diverse web servers on their intranet.
This can be important when
legacy systems. Vendors of specific legacy content often sell an
server and middleware that will accomplish the integration of their
applications with the least effort. While they try to sell these
servers as being "general purpose," you may be better off using it
primarily as an integration server for their legacy services and using
other servers for other functions on your
intranet. Just like selecting among screwdrivers, hammers and saws for
specific carpentry job, don't be afraid to use different web servers
middleware on the intranet to meet specific requirements. It often is
to think of each intranet service as a potentially separate web server.
For example, if a unit
the enterprise has an extensive history with Lotus Notes, a
server to support the integration is an obvious choice. If another unit
MS Exchange files extensively, then Microsoft's IIS web server can
that integration. Legacy data in an Oracle database might be most
served using an Oracle server, and there are even web servers for
MVS and VM operating systems that can integrate bulletin board
on the mainframes with intranet-threaded discussion groups.
The key point: Build
your enterprise architecture, not your legacy constraints. Whether you
one legacy system or many, look at these servers as specialized
servers that can be mixed.
If you are worried about the
of these multiple web servers, remember that you are already supporting
applications on multiple systems, and the web server generally is an
add-on. It certainly will be less expensive and disruptive than
a conversion or writing and maintaining custom integration code. The
standards were designed specifically to provide an integration rosetta
among diverse systems, so use it to your advantage. If you build an
intranet to support this diversity now, in the future you will find you
can migrate, at your own speed, to other solutions without the
necessity of massive, synchronized
Integrating content across
legacy systems for delivery through a web-based application is not
trivial and requires a sound architectural approach and good
development tools. The main issue is to provide a
single web-based application interface which accesses multiple,
heterogeneous content sources.
The content sources may be
(e.g. databases), semi-structured (e.g. rules-based or expert systems )
unstructured (e.g. email archives, discussion groups or web pages), but
each case, the access to these sources must be transparent to the user
the web-based application. Another large issue is the condition of the
returned from each legacy system and the normalization and cleansing
must be done in order to make the data suitable for web delivery.
The best way to deal with
issues is to use an architectural approach based on information
and agent technology. Generally, a web application built with this
will contain HTML page templates, static application content and
logic, but instead of going after legacy system content directly, the
application will talk to an "information broker" whose job it is to
content from legacy systems as it is delivered by the agent.
Agents connect the information broker
to legacy systems and are responsible for finding content in legacy
normalizing and cleansing the content and delivering it to the
broker according to the broker's published schema as well as the rules
for re-querying the content sources. Each agent has the knowledge to
specific legacy systems and contains rules for manipulating content
handing it to the broker. The agents are domain specific with usually
least one agent per content source. As new legacy systems come on line,
agent associated with that legacy system can register with the
The registration approach
it easy to bring on new legacy sources without any changes to the web
or the information broker. The only work to be done is to develop the
associated with the new legacy system (according to standards and
and have the agent register itself with the broker. This approach also
it possible for legacy systems to go off line without affecting the way
the web based application functions. When a legacy system goes offline,
cached data in the broker may be used to feed the application and there
is no change
in functionality, though it may be necessary to notify the user that
content is being used.
Intranets can be a powerful
communication and integration tool. However, to reach their full
potential, the infrastructure must
be predicated on supporting diversity and distributed control. This
a robust enterprise architecture, and an approach that leverages the
functionality to manage the integration rather than falling back on the
or single vendor approaches of the past.
Once the basic
and architecture are in place, this technology supports migration in
steps. Begin by looking for servers and tools that, with little effort,
web-enable your legacy systems. When implementing new applications,
them web-based; there are an increasing number of off-the-shelf
applications, generally from smaller vendors. For functionality not yet
off-the-shelf, high-level development tools are becoming available.
after web-enabling your legacy systems, you can migrate them to
more easily, because both systems can run simultaneously, using the
At a high level, creating an
enterprise architecture involves working through four levels: business
models, people roles, publishingprocesses and technology systems
(application, data or platform):
An Enterprise Architecture
While the details of the
model will vary with each enterprise, business content can be
into threebasic types: informal, formal and access controlled. These
are important because the roles, processes and, ultimately, system
will change depending on which type of information is being supported.
much of the innovation and "work in progress" that
place. Informal content has the fewest controls and is where all of the
content is created and refined. It includes personal work or
that get shared outside formal projects and missions, project or
work and communication not intended for the entire enterprise, and
content that has not yet completed a formal review and acceptance
Formal content is
by a recognized organization that stands behind both the quality of the
and any commitments it makes. Generally, the feature that moves content
informal to formal is an explicit review and acceptance process
by the organization that stands behind the content. Formal content
published company benefit programs, press releases, product collateral,
pricing schedules, company policies, company mission and value
competitive analyses, company forms, official process
and many other published standards, views and commitments that the
involves additional decision processes on who can see the
it's more restrictive or less restrictive than the general intranet
If the content is restricted to a subset of the intranet, it generally
referred to as the confidential intranet. If the restricted subset
partner or customer organizations, then we refer to the content as an
extranet. If all restrictions
removed (even the intranet restriction), then the content becomes part
Each type of content may be
and managed differently on the intranet. For example, requirements for
content often are as simple as providing for individually
publishing spaces, setting baseline rules that extend existing company
to intranet publishing, and adding the requirement that each page must
the owner, a contact address and the date of last update.
Formal content may
someone to fill the publisher's role of determining what kinds of
the organization will provide, as well as the editor's role of lining
and managing the content authors, guiding the content through the
review cycles and publishing the approved content, often with a logo on
that identifies the content as formal.
It is important to recognize
organizations and, ultimately, people, make decisions about the
meaning and theorganization's desire and ability to live up to
Processes and technologies can support the decision making, but in the
these are judgment calls made by human beings. The enterprise
needs to support these people and their decision processes.
Because the style and
for each person and organization are different, it is important that
architecture provide for diversity -- enabling
decision maker the option of selecting processes and tools that meet
needs. Developing a systems infrastructure based on community-owned
standards, rather than specific products, gives decision-makers another
of options. Providing the decision makers with intranet-based threaded
and project management services that they can configure and
themselves is yet another way to provide support.
There are at least four classes
publishing processes that can be applied to intranet content. The first
the everyone-as-publisher class. Here
member of the intranet community is capable of publishing his or her
content on the
Second is the webmaster
class. The name is taken from the historical role of early webmasters
the individual who took the content, converted it to HTML and placed it
the web directory on the server. In our context it refers to any
where publishing on the intranet requires giving the content to a human
who has control over what content is published and when.
The third is the database
class. Specific content is published into a database, and the database
as an automated intermediary with the web server. This process class is
in retail catalog applications and for generating dynamic pages.
Fourth is the object
This takes its name from the object programming model, which provides
classes, that can be modified into sub-classes and ultimately are
as specific instances. If a change is made to the class level, it
propagates itself down to all the instances of that class.
In an intranet publishing
we call the class a page template. When content is placed into the
it becomes aninstance of that template and it functions like an
of an object class. If the template is changed, the changes propagate
the content pages that were created using that template.
Each of these process
provides different levels of user enablement and management control. No
process is appropriate for all parts of an enterprise intranet. The everyone-as-publisher
process might be appropriate for much of
informal content; the webmaster process might be appropriate
content during the review and acceptance process that moves it from
to formal; the database process might be appropriate when
restricted-access content, and the object process might be
where publishing is distributed across divisions, but there is a desire
the format and image of the content to look coordinated. A good
architecture provides managers and domain specialists with the ability
match the appropriate process classes to their specific business
At the architectural level,
systems refers to the framework that includes the required services and
how they are related to each other. The
important standards both within the services and between them are
in the architecture. The most robust and flexible enterprise
are based on community-owned standards rather than de facto,
standards. The architecture should not specify products or
no matter how popular, because these change too rapidly to be useful
can lead to dead-ends and costly conversions in the future.