There have been many publications discussing how to set up an Intranet, or how to sell the concept within your organization. This paper moves past the point of "how to set-up" towards the larger issue of managing the Intranet as a business platform.
The number of applications being
on Intranets is exploding. The speed of change, plus the integration
inter-dependency across these applications will challenge Information
(I.S.) capability to provide this managed business platform. I.S. must
do a better job of planning than is done today, plus adopt new
addressing the speed of change, and the integration of applications and
services. An IT vice-president at a large bank observed: "Intranets
been treated as a hobby; it's now time we treat them as an IT
Intranets are proliferating in most businesses. One characteristic of Intranets, like the Internet itself, is that in the early stages they grow organically without any overall plan. The technologies are ideal for creating very responsive information systems. Various business groups can set-up their own servers with little investment. This lends itself towards experimentation - "how can we get started quickly, and what can we do with it?" While this is beneficial, it also results in a proliferation of approaches. One company thought it had three Web servers but found upon survey it had eighteen, another company IS which claimed to have no Intranet found it had four servers operated by various business groups. These servers operated on different platforms, used different software, and applications were being developed which utilized different browsers and plug-ins. This diversity increases the potential for "Intranet chaos", with associated impact on service quality, cost and extensibility. The ability to extend the Intranet to business partners; Extranets, will be much more difficult.
Today, chaos doesn't matter; Intranets are primarily used to provide access to information, and typically not business-critical services. Given the applicability of Web technology to both mainframe and many client-server applications, Intranets will move beyond information access to delivering the types of applications which businesses run upon. What does chaos mean to this environment?
Planning information systems is not a black art. Business requirements are used to define the technical architecture and the associated operational model.
The integration aspect is in some
more significant. In the information infrastructure we are evolving
services are implemented and operated as separate silos: file/print
Email systems, office automation applications, groupware applications,
custom business applications. With the evolving Intranet, these
silos are being integrated together at the user's browser and through
application servers which range from Novell Intranetware, to Netscape
to Web-enabled mainframe CICS applications. From a technology
this new environment is less able to be architected as separate and
systems. These systems must share common security services,
services and user desktop software. From a support perspective,
availability and responding to user and business requests becomes much
more complicated. Think of Helpdesks who must diagnose and dispatch
reports in this environment.
With rapidly expanding and changing Intranet applications, infrastructure is key to planning and management. Infrastructure is a way to manage application development - to manage diversity and redundancy. The essential element is defining what services are available, and how applications use these services - what standards, what standard software components.
What are some examples of infrastructure as a means of managing application design? Using the simple example of document publishing system for policies and procedures, project plans and status information; the most common Intranet application, the infrastructure consists of:
A "layered architecture" with
interfaces between the layers, is an I.T. 'best practice'. Intranet
have a different layering; an 'N-tier' layering with a broad set of
in the middle tier, and with services that are re-used across a wider
of applications - they are function-specialized, but not application
Intranet applications are built combining the application-specific
information, and templates, with the infrastructure services. The range
of service technologies for Intranets is quite large.
Document publishing: Servers for publishing unstructured data - such as policies and newsletters. This is the 'basic web server' functionality, but should also including authoring and document management capabilities such as provided by Netscape Enterprise server.
Search and index: Provide topic-based search and retrieval by automatically index document information within or across web servers. Examples are Netscape Catalog, Excite, Altavista.
Collaboration servers, including e-mail: Basic Email, calendaring, shared/threaded discussions, newsgroups, and workflow services. Examples are Netscape Collabra, Microsoft Exchange 5.0 with Active Messaging, Novell Groupwise.
Directory: Used for Email, security certificates and access control lists management. Examples are Netware NDS, Netscape Directory.
Database or database interface: Range from special web database servers to which specific content is transferred (e.g. the phone directory, or the parts catalog) to web-front-ending an existing database (e.g. the IS problem management system, the inventory database). Examples include MS SQLServer with Active Server, Oracle Webserver.
Transaction: Provide transaction integrity tracking from the client across backend servers. As Intranet applications evolve from accessing information to updating, this will be necessary to insure integrity and reliability associated with current client-server systems.
Security/certificate: Used for generating and managing public keys, - used with authentication, digital signatures. An example is Netscape Certificate Server.
'Push': Define and push 'information channels', such as information alerts, to users' desktops. Examples are Pointcast I-Server, Marimba Castanet.
Proxy: Provide information replication across network, which can be used to reduce traffic, improve response time, and provide security.
Software component/tool repository: Provide application developers with standardized tools and components for building applications, such as tested Java applets and ActiveX controls.
Along with the server technologies, there are client capabilities to be standardized; Client application standards such as browser vendor/ revision level or HTML version, specific add-ins, client-specific configurations (such as ActiveX control permissions)
For each individual service being provided as part of the infrastructure, a service definition must be documented, so that application developers will understand how they should utilize these services. Overall, the following decisions must be communicated to all potential developers:
Application/Infrastructure Boundary. What services will be provided by infrastructure, and made common across applications, and what services will be left for individual applications to define and implement? For example, it is very common to specify web document publishing standards, but very uncommon to define software component/tool repositories. However, the benefit of the software component/tool repository to both application developers and I.S. is potentially much greater. The guiding principle for these decisions should be whether multiple applications require substantially the same capabilities. If so, then these capabilities should be provided in the infrastructure.
Service-specific standards. Each service will require it's own specification. Examples for a Directory service would be directory schema and naming standards, directory access controls, protocol standards. Similar standards for a Database server would be whether to use JDBC, Active Server, Oracle cartridges, or other interfaces. A Search and Index service would standardize indexing parameters, such as keywords, and how information is excluded from indexing; when it is dynamic, confidential, or perhaps subordinate to a more useful document.
Vendor standards. Whether to use a predominantly single vendor strategy, allowing use of vendor-proprietary technology, or a multiple vendor strategy, and when alternative vendors might be considered.
Making the architecture responsive. A common concern raised by Intranet developers is how to preserve the benefits of the rapidly evolving nature of Intranet applications and technology and still get the planning benefits of an Intranet architecture: how to balance innovation with control. The most vital quality of an Intranet plan is that it must be responsive, both to business needs, and to changing technologies. This requires a logical process, and the participation of a wide range of 'stake-holders' in the process.
The processes to create a responsive Intranet plan are:
Develop an understanding of 'anticipated requirements', based upon organization's business plans, existing application base and new application plans. This may take the form of a 'vision statement' which identifies what business value will be enhanced through use of Intranet technology. This understanding will include a wide range of assumptions - where technology is going, how business will utilize it. While this may seem imprecise (it would never work for a specific business application), generalized requirements can be developed. This is the approach used whenever an Intranet "style guide" is created.
Identify the architectural characteristics to support these anticipated requirements. Essentially, you are defining high-level architectures for typical applications. From here, common architectural elements which are best delivered by the infrastructure are identified. Document the necessary infrastructure services; what they are and what interface applications will use. Include the Operational requirements: change management, user support, performance and capacity monitoring. Define an implementation roadmap - phasing what capabilities and services will be provided over time. Utilize the 'vision statement' and specific business application needs to justify the investment necessary for each phase. By defining phases, the infrastructure is implemented "just in time". The overall architecture is made more dynamic, as the assumptions it is based upon can be revisited for each phase.
essential. I.S. operations and application developers, and business
content authors and application developers must be involved with
it, and with evolving it. The steps just described should be the agenda
for a steering committee or planning task force. Potential users
be made aware through publishing the architecture, through application
proposal reviews, open steering committees, and other communications
*Alex Cullen is a Principal consultant with Onsett International, an IT management consulting firm. Mr. Cullen works with IT organizations in the planning, design and implementation of Intranet and Extranet application systems. He can be contacted at firstname.lastname@example.org.