I've been working with ECM customers for years designing, implementing, and maintaining large, complex architectures for ECM deployments facing all sorts of difficulties. Often the difficulties are summed up by those involved as "low bandwidth" and there are certainly many cases where low bandwidth is a problem to be addressed, however more often low bandwidth is only one problematic parameter to address.

There is only one reason to disconnect an otherwise connected web application and that is due to cost; if remote people find the performance of an application to be satisfactory and the tasks performed on that application to fit within whatever SLA applies to the process then there would be no reason to create a remote installation and good business sense says that the extra cost of a Multiple-site design is not warranted (even if it would be faster because fast enough is fast enough).

The first thing I would point out is that there is no pre-formed solution available to all multiple-site designs and there are certainly some problems associated with remote and distributed use that are still unsolvable. Anybody who suggests an easy route forward, regardless of which technologies you work with, isn't giving you the full story. MANY organizations want a distributed architecture that provides local-like access to all users but few actually implement their initial desires sometimes because what they want is impracticable, infeasible, impossible, but more often just too expensive.

Low bandwidth in and of itself does have solid solutions available but congested networks and long latencies are both far more difficult problems to deal with.  Situations that must inherently deal with low-bandwidth issues that cannot be addressed (either due to cost or lack of availability) must understand that the problem has to be addressed at the application layer; significant effort to localize content and minimize use of the connection is required. In  most chronic low bandwidth situations, a distributed model with limited use of Remote Cache is warranted.

One of the most difficult situations to work with is where the network quality is lacking. While many places in the world have come to see their Internet and data connections work as well as their telephone with true network outages a rare event, there are still many other places where the infrastructure is older, and not deployed with the same level of redundancy common elsewhere such that a network connection is not reliable. It is important to understand that Content Server and the 3rd party applications that it uses are not designed to work with problematic networks, Content Server was designed as an Intranet with an inherently sound network.

One of the most common and generally not well understood situations is that of large latency. It is latency itself that is often the reason for looking at an Enterprise model, though it isn't always recognized as the problem. The good news about latency issues is that many of the most problematic problems can be addressed with technology, the bad news is that generally there is nothing that can purchased or installed from an ISP that will change the latency values (of a well run network).

The Open Text Content Server provides a very flexible architecture that can, sometimes with some help, solve many of these problems  but it is vital that the architecture design makes sense of the business use of the solution. While often all ECM applications can be treated as equal within a local installation or when a low-larceny, high-bandwidth link is available, not all are equally affected by lowered bandwidth or longer latencies. The problems of a dispersed network are entirely physical in nature and can be calculated with mathematics but the solutions come from an understanding of information flow within an enterprise and how that flow is affected by and affects the physical parameters.

There are three distinct types of architectures to consider and of course each can be combined with another to make a hybrid solution. The three types are: Caching, Replication, and Distribution. I'll discuss each separately.