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; its 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 doesnt 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?
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 users 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:
Expanding this to the architecture of complex client-server applications being extended through Web interfaces would require standardized, Intranet-specific:
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
|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:
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 process to create a responsive Intranet plan are:
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.
The time to plan is now
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.
One of the ways around the issues of security and control that make some businesses wary of cloud computing is to build a private cloud -- one that remains within the corporate firewall and is wholly controlled internally. Private clouds also increase the agility of IT an organization's IT infrastructure and make it easier to roll out new technology projects. Download this eBook to get the facts behind the private cloud and learn how your organization can get started.