As empresas descobriram que a transição da arquitetura tradicional (terminais burros) para configuração Cliente/Servidor envolve mais que simplesmente comprar PC´s e usar novas ferramentas de programação. Migrar para Cliente/Servidor é evolutivo, um processo de várias etapas, não uma única mudança. As primeiras gerações de aplicações Cliente/Servidor em duas camadas (two-tiers) não atendem às necessidades das empresas em muitos tipos de aplicações, mas as empresas estão procurando ferramentas mais robustas e técnicas que podem dotar o novo mundo Cliente/Servidor com integridade e gerenciamento, que são requeridos para grandes aplicações. Novas arquiteturas alternativas e ferramentas estão surgindo para este desafio.

Aplicações básicas Cliente/Servidor (colunas 2a 2b/fig1) introduziram os benefícios dos PCs e interfaces gráficas, mas se assemelham às aplicações tradicionais (coluna 1/fig1).

Aplicações Cliente/Servidor mais sofisticadas (colunas 3a e 3b/fig1) são mais duráveis porque utilizam três ou mais camadas lógicas de software. Entretanto, à medida em que o software vai ficando mais complexo, vai aumentando a necessidade de se construir aplicações com segmentos de códigos de múltiplas fontes. Isto implica a busca de mecanismos de "linking" mais flexíveis que os "middleware" tradicionais.

Futuras aplicações Cliente/Servidor (coluna 4/fig1) usarão objetos distribuídos, Orientação a Objetos ou tecnologia de software "component", no cliente e no servidor. Microsoft OLE e CORBA ORB´s possibilitam esta conectividade. Estas aplicações Cliente/Servidor componentizadas estão sob as mesmas considerações de desenho que as Cliente/Servidor tradicionais: múltiplas camadas de hardware, DBMS no servidor, lógica de apresentação no cliente e camadas de aplicação para isolar acesso a dados da lógica do negócio.

É o "Middleware" que possibilita a arquitetura em 3 camadas. O Middleware básico de três camadas ("three-tiers-lite") permite a um programa cliente chamar um programa de aplicação servidor independente. Cada aplicação independente possui seu próprio link no DBMS, que coordena a integridade da transação.

Ferramentas incluem: RPC´s, messaging tools e um subset de TPM´s.

O modelo "three-tiers-heavy" tem todas as capacidades do anterior mas também expande o limite da integridade de transação além de um único programa; isso é feito pela adição ao ambiente de um gerenciador de transação aumentando flexibilidade. Inclui TPM´s (por exemplo, TUXEDO, CICS, Encina).

A tendência é de que a proliferação de novos canais de acesso de usuários finais como Internet, computação móvel, Cliente/Servidor, conduza os usuários para longe da arquitetura tradicional de TI para reduzir complexidade e redundância. Antes de 1990, existiam, basicamente, dois modos de processamento: batch e on-line. Agora, as empresas disputam uma crescente variedade de modos de aplicação, fazendo também crescer o desejo e necessidade de compartilhamento dos dados e códigos através de múltiplas formas de acesso.

Entretanto, a topologia atual raramente compartilha dados diretamente (diagrama do meio/fig2) e não compartilha lógica de programa (diagrama de baixo/fig2). A maioria das aplicações ainda é uma mistura de "shared nothing" e "shared data" (os dois gráficos de cima).

Até 2000, as aplicações estratégicas Cliente/Servidor devem focar em partição no servidor. Arquiteturas "granular-server three-tiers" serão o estado da arte na computação "core business." Algumas aplicações hoje já estão sendo desenvolvidas em modo "three tiers", onde uma única transação requer a chamada de no mínimo dois programas independentes - um que contém as regras de negócio e outro a lógica de acesso aos dados.

Para essa arquitetura, são necessários TPMs, que permitem que vários programas independentes concorram numa única transação. As ferramentas emergentes de desenvolvimento de aplicações levam uma granularidade ainda maior. Surge uma nova classe de produtos que combinam as funcionalidades de monitores de TP e ORBs, que são os OTMs (Object Transaction Monitors).