Printer Friendly Version

Logical Versus Physical Consolidation

The decision to merge multiple pre-existing sites, when taken seriously, should involve more than creating a single home page gateway linking to a widely dispersed number of sites and labeling it an intranet. Creating this type of a facade as a launching pad requires the least amount of effort, but it's also a very lackadaisical approach without any sense of continuity or interrelationship among information.

The process of multi-site consolidation is very granular and varies in degree from simple cosmetics to full application development. And the extent to which you want to take your merger will depend on your requirements and your available resources.

In order to begin to understand the effort required to create an intranet from your existing sites and applications, we can classify most mergers into two broad categories: logically merged intranets and physically merged intranets.

Logically Merged Intranets
Logically merged intranets involve the standardization of design and navigation and requires less effort intensive of the two. All sub-sites within a logically linked intranet share the same look-and-feel, but the underlying technology may be quite different and may reside on several independently owned servers. This gives the end user community the appearance of site uniformity and continuity regardless of the technology and physical location of each individual component.

Ownership becomes a much more sensitive issue, however. If any sub-site owner is ever forced to abandon their piece of the pie — through organizational restructuring or changes in priority and business needs — the remaining members of the intranet will be left to deal with the orphaned site. And because a logically merged intranet may contain a wide range of technology, it may be difficult to transfer ownership — especially if no one has any real experience with the orphaned site's inner workings.

Physically Merged Intranets
Physically merged intranets share, not only a common design and navigational structure, but also a standard technology and development language. Intranets that use one or several core technological standards ease the process of maintenance, allows for a greater level of ownership, and promotes a more organized approach to future development.

Web sites and applications can be spread out across a cluster of servers and maintained under the auspices of a single group — usually IT. This ensures the integrity of the entire intranet and takes advantage of centralized backups, data redundancy, load balancing, and disaster recovery procedures.

But physical mergers can be extremely time-, effort-, and resource-intensive — especially if your current Web development infrastructure contain sites that use technology that's widely inconsistent with the others. And regardless of the advantages of sharing a common developmental environment, physical mergers are the most difficult to implement—not only because of the logistics involved in the consolidation of pre-existing sites that are based on disparate environments, but also in the possible resistance from current site owners who remain loyal to their platform.

Technological Backbone

Companies without a formal intranet often house several departmental sites that were built to meet very specific and individual requirements. This leads to a mishmash of sites and applications that's as varied as the experience and knowledge of those who created them.

They can range from a simple Web site designed with Microsoft FrontPage to full-fledged applications developed with tools such as Microsoft's .NET framework, Macromedia's ColdFusion MX, or IBM's WebSphere to freeware, open-source environments such as Linux, Apache, and PHP.

Setting up a technological backbone involves the adoption — among all sub-site owners—of:

• A operating system platform
• A Web server
• A development environment and language

Certain site applications will be better supported by one technology over another, so depending on the status of all your pre-existing sub-sites, it's perfectly alright to settle on a core set of standards rather than any one de facto, "this way or no way" standard.

Amicable Mergers

Choosing a standard design and technology to support your intranet is going to be your first hurdle; forming a consensus among all the sub-site owners is the second, third, and fourth.

Whether you decide to take a logical or physical approach to multi-site consolidation, you're likely going to run into a certain amount of resistance. There will be those in the open-source camp who will be reluctant to enter the Windows camp or vice versa. Trying to get all sub-site owners to agree on a set of technology and development standards is a fine art — a gentle balance between objective analysis of system requirements and subjective compromise among those who insist that their way is best.

But in order for a successful consolidation to take place, everyone involved must be a willing participant so take great care in avoiding hostile takeovers. Telling site owners that their site will be absorbed into a corporate intranet whether they like it or not will cause resentment and ill will. Instead, you should convince sub-site owners that consolidation will make their lives easier by providing them with a guideline for all Web development and centralizing server maintenance.

Conclusion

Multi-site consolidation allows you to build an intranet without having to reinvent the wheel. It's unfortunate that some needlessly invest time, money, and effort to build something from scratch when they already have the majority of their intranet available in the form of individual department or workgroup sites. All that's needed is some structure to turn the independent sites into one cohesive unit. Like building a jigsaw puzzle, an image already exists, you just need to put all the pieces in the right place.