Avoiding Intranet Chaos

Download the authoritative guide: Cloud Computing 2019: Using the Cloud for Competitive Advantage

Share it on Twitter  
Share it on Facebook  
Share it on Google+
Share it on Linked in  

There have been many publications discussing how to set up an Intranet, or how to sell the concept within your organization. We are moving 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 hosted on Intranets is exploding. The speed of change, plus the integration and inter-dependency across these applications will challenge Information Systems’ (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 approaches addressing the speed of change, and the integration of applications and services. A IT vice president at a large bank observed: "Intranets have been treated as a hobby; it’s now time we treat them as an IT program"

Organic growth and diversity

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 yet 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?

  • different application front-ends - browsers, plugins, supporting different scripting languages
  • inconsistent user interfaces and navigation, increasing user difficulty
  • multiple server platforms, with highly varied server configurations
  • different methods for providing security, search, directory, database access capabilities
  • highly distributed development, management & operations, with lack of concentrated expertise - making costs harder to manage
  • orphaned’ applications - department created, but with no department ownership
  • security holes due to inconsistent security policies, architectures and schema’s

To avoid this potential chaos, Intranets must move from unplanned to planned, and Intranet applications from opportunistic to architected.

The Planning Challenge

Planning information systems is not a black art. Business requirements are used to define the technical architecture, and the associated operational model. Technical architectures describe the client and server functionality, and the hardware and software components to provide this functionality. The operational model describes how the hardware and software components will be managed and supported, and how users will be supported.

Intranets require a different approach to planning and architecture. The reason for this can be boiled down to two factors: the speed of change, and interdependency caused by application integration. The speed of change; in technologies, in uses, and in the structure of the Intranet information itself, is widely appreciated and often seen as a virtue. The downside is that I.S. has to learn to adapt to this pace of change. An IT director at a large technology firm recently observed that his organization operates around a one-year cycle for changing back-end software and desktop applications, but with the Intranet, he is now being asked to compress this to less than three months. The ramifications of this impact everything from how he can support and train users, to how he forecasts network traffic.

The integration aspect is, in some ways more significant. In the information infrastructure we are evolving from, services are implemented and operated as separate silos: file/print servers, Email systems, office automation applications, groupware applications, custom business applications. With the evolving Intranet, these separate silos are being integrated together; at the user’s browser, and through Intranet application servers which range from your Novell Intranetware, to your Netscape Mail, to your Web-enabled mainframe CICS applications. From a technology perspective, this new environment is less able to be architected as separate and distinct systems. These systems must share common security services, navigational services and user desktop software. From a support perspective, ensuring availability and responding to user and business requests becomes much more complicated. Think of Helpdesks who must diagnose and dispatch problem reports in this environment.

"If you build it they will come"

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:

  • Web document servers
  • Defined client standards - HTML versions, available plug-ins such as Acrobat
  • "Intranet publishing kit" - tools for creating and submitting content
  • Index server software to provide topic-based searching
  • Server infrastructure to support authoring - submission directories, change control, linking pages

Expanding this to the architecture of complex client-server applications being extended through Web interfaces would require standardized, Intranet-specific:

  • client applications and applets classes
  • database system interface
  • security/authentication services
  • server and application monitoring systems
  • user authorization & profiling processes
  • user support processes

The above examples illustrate value of a set of defined Intranet services and interfaces which application developers will gravitate to, much like car drivers gravitate to expressways.

 What are infrastructure services?

A "layered architecture" with clearly defined interfaces between the layers, is an I.T. ‘best practice’. Intranet applications have a different layering; an ‘N-tier’ layering with a broad set of services in the middle tier, and with services that are re-used across a wider range of applications - they are function-specialized, but not application specialized. Intranet applications are built combining the application-specific rules, information, templates, with the infrastructure services. The range of service technologies for Intranets is quite large, as shown by associated Table

Intranet Services

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.