However, though the client-server architecture was vastly superior to the monolithic architecture, the approached forced developers to locate the three main development layers in just two locations (in the client or in the server).

Typically, presentation and business rules logic would always remain within the purview of the client-side application.

For example, Decisions on locking, updating, deleting and information presentation were encoded in the client application directly. This enabled the client application to 'short-cut' the UI to produce clever designs.

The data however, became the responsibility of the database or messaging subsystems. As such they were accessed either via direct API or through thin layers of 'enabling technology' such as ODBC. In some instances, this provided limited flexibility enabling designers to substitute like database for like without creating large amounts of work.

The presentation layer would exist as a single layer within the client side application but the business and database layers could exist in the database or messaging server. This enabled the client side application to respond quickly to cosmetic changes without having to test all business logic cases, and at the same time allowed the business rules to change without requiring mass rollouts at every such occasion.

The client-server model presented a major paradigm shift when compared to monolithic applications. However, it remained far from ideal.

In one scenario, the presentation layer and business layer are constantly diametrically opposed. Fewer updates to the GUI engender familiarity with an application (and makes it simple in deployment) but restrict the ability to change the business rules. Frequent changes to the business rules cause deployment and testing headaches.

The alternative approach is to locate the business rules within the database/messaging layers. However this tactic means that it is hard to uncouple the business logic from the data and messaging structures.

The Client-Server architectures also suffered under constant maintenance strains due to proprietary standards, technologies and, most importantly, a lack of scalability.

Client/Server applications performed best in a corporate environment where groups of users require a focal application which integrates tightly to key technologies such as database engines, email server, work flow and document management systems.

As a result, most Client-Server application were little more that file and database sharing applications. In fact, early Client/Server solutions were often oblivious to other clients, behaving in a singular fashion.

While the Client-Server approach does much to create good solutions there followed a painful growth period during which applications were built, deployed and maintained. It was during this "growth" that the issues with Client/Server development became apparent.

In the client server model all clients have access to nearly all the services. This forces the services, like email and the database servers, to ensure that they can maintain large numbers of permanently connected users.

Every connection requires processing, memory resources and extra network traffic - even when the clients are busy doing nothing of significance against the servers. Load balancing tools were scarce and the underlying technology proved problematic to maintain.

From a development perspective there are also issues of maintaining software that often needs updating when new versions of API arrive, especially when the new version fixes existing issues. When this situation occurs the process of deployment becomes a major issue.

How best do you deploy to hundreds (maybe thousands) of clients? How can the developers ensure that there are no conflicts with other installations? How do you deploy all the supporting APIs and connectivity libraries?

Certainly, there are solutions to most of these problems, however, one specific problem remains a constant problem for all multi-client solutions; scalability. As users are added to a solution it becomes more and more difficult to maintain a consistently good level of service without diverting significant resources.

Technology moves and grows but occasionally a conceptual shift occurs (a paradigm shift). A shift of this magnitude arrived in the form of the Internet. With the arrival of the 'net' many of the client-server problems could be solved. If not solved, they were meliorated.