BUILDING PROSPERITY THROUGH BUILDING DREAMS

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 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. An 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."  
 
 

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?  

• different application front-ends - browsers, plug-ins, 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 

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. 

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 Novell Intranetware, to Netscape Mail, to 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.  
  
  

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 

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

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, 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.  

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.  

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.  

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. 
  

*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 acullen@ix.netcom.com.