Avoiding Intranet Chaos

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.

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

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 commonalized 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.
• Application interface standards. What standards application developers will utilize for accessing infrastructure services? HTML versions, CGI versions, choices when to use ActiveX or Java, VBScript, Javascript or other scripting languages. As the repository of re-usable components expands, this may include preferred component revision levels.
• 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.

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 process 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, what interfaces 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.

Communications and participation are essential. I.S. operations and application developers, and business content authors and application developers must be involved with defining it, and with evolving it. The steps just described should be the agenda for a steering committee or planning task force. Potential users must be made aware through publishing the architecture, through application proposal reviews, open steering committees, and other communications channels.

Where most Intranets are today is akin to when personal computers first appeared within corporations. Users and developers are excited by the possibilities, and less concerned with the implications of cost, support and operations. Like the personal computer, but probably much faster, Intranets will evolve through various stages of organizational integration. However, with the hindsight provided by the PC revolution, and other similar ones like LAN E-Mail, we can see where Intranet evolution must proceed, and begin putting the pieces in place to make this as smooth as possible. The dynamics of the Intranet are part of its value to businesses, even as they are a challenge to the I.S. organizations who must take responsibility for the support of business systems. By developing the architectures described above, Intranet builders can ensure these dynamics are balanced appropriately as this transition occurs.

About the author:

Alex Cullen is Principal Consultant at Onsett International Corporation.