paulchinonline.com

Strength in Numbers: Multi-Site Consolidation

By Paul Chin

Originally published in Intranet Journal (19-Feb-2004)

back back to portfolio


At what point do numerous corporate Web sites make that jump from being a mixed bag of heterogeneous jelly beans into a single unified entity we call an intranet?

Some may argue that the combination of all internal Web sites—although outwardly dissimilar—may constitute an intranet. But a dozen disjointed Web sites under the same corporate banner doesn't necessarily qualify it to be an intranet. A dozen Web sites is simply a dozen Web sites.

In the most true context, an intranet is not an intranet unless all of the various sub-sites contained within it share a common goal and are connected by a standard design, navigational structure, and a pool of shared resources (see my previous article Intranet Standardization: All For One, and One For All for more on this). And it's important to make this distinction—emphasizing the difference between a true intranet from a motley assortment of internal Web sites—if you want to have any hope of quantifying the success of your system.

While some companies build intranets from the ground up to fulfill a very specific requirement, many others retrofit or build upon pre-existing departmental and workgroup sites, merging the various sub-sites into a one "super-site." But how do we know when it's time to merge multiple internal sites into an intranet, and more importantly, which sites do we include?


Consolidation: The Why's and When's

The purpose of an intranet, in many cases, is to promote interdepartmental collaboration, information sharing, and the coordination of effort among various groups. And in order for this to happen, users need a centralized system rather than a scattering of independent sites that have little or nothing to do with the others.

And while it's true that each department or workgroup has requirements that are specific to their own operation, there's always an information overlap; what proves useful to one may very well prove useful to another. Choosing to consolidate these sites into an intranet will help tie the company's information structure together and make the entire process of data retrieval much simpler.

It's easy to lose site of your goal by trying too hard to assimilate every internal sub-site—in short, to become a vacuum cleaner. You need to know when it's appropriate to include or exclude certain sub-sites from your intranet:


Do the Sites Belong Together?

Multi-site consolidation should occur only when there's a logical relationship among the sites to be merged. Unfortunately, many first-time intranet developers make the mistake of padding their system with sites that have no real reason being there. This causes intranet bloat and takes away from the very definition of what an intranet is—not simply a collection of internal corporate Web sites, but rather a collection of interrelated sites. It's this close relationship that sites have among one another that gives an intranet its real purpose.

Before you even consider consolidation, however, your proposed intranet needs to have a goal, a raison d'ętre. A well-planned intranet contains individual components that contribute to the whole, but if you don't even know what that whole is, how will you know which sites to include and which to leave out?

It often helps to read your intranet mission statement aloud; if the site you want to merge into your intranet doesn't contribute to that mission statement, it probably doesn't belong, and if it doesn't belong, don't force it. After all, it's always possible to squeeze a square peg into a round hole by chiselling away at it and sanding it down, but where does that lead you? The square peg was a square peg for a reason, and now—even though you managed to force it in—you're simply left with a disfigured and improperly fitted square peg.


Effort Versus Payoff

The time, effort, and resources required to merge several internal, corporate sites will depend largely on how far you plan to take your intranet. It's your job, as developers and content owners, to weigh the advantages of site consolidation with the effort required to carry out the task. You'll need to take into consideration:

Regardless of your reasons for merging—whether it's the implementation of a uniform design or a complete overhaul of existing applications—you need to ensure that there's real benefit to the user community. It will be difficult to justify to management your plans to spend several weeks and a dedicated team to accomplish what they may perceive as busywork. Consolidating multiple sub-sites needs to serve a purpose; it shouldn't be done for the sake of doing it.


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 is the 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:

However, the most important thing to realize is that the adoption of a platform and development standard doesn't mean you have to adopt a single standard. The goal of consolidation is not to become overly restrictive by forcing everyone to use the same platform or language, but rather to keep an intranet from turning into a runaway train composed of every imaginable technology and product on the market.

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.


Copyright © 2004 Paul Chin. All rights reserved.
Reproduction of this article in whole or part in any form without prior written permission of Paul Chin is prohibited.