A infraestruturas é dividida em blocos chamados plataformas. Plataformas são modos de distribuição de informação e reutilização de componentes. Definir estes componentes e a sua organização é uma das tarefas mais importantes do arquiteto, pois são eles que sedimentam como o software poderá ser desenhado. Esta é a semelhança com a arquitetura de edificações, onde a planta define os alicerces da edificação. Tal como o edifício nunca poderá ir além do suporte dos seus alicerces, um software não pode ir além dos componentes da sua arquitetura.

A expressão uma arquitetura, abreviação para _ uma *Configuração de Arquitetura*_ refere-se a um conjunto específico desses componentes organizados de uma forma especifica.

A definição de arquitetura que será utilizada em um software é tanto mais importante quanto maior for o tempo de vida previsto para esse software. Se o software se destina a ser um produto, e a evoluir naturalmente sob demanda dos seus utilizadores, ele tem que ser capaz de comportar modificações com baixo esforço e que acompanhem a evolução natural da tecnologia, ou, então, o software ficará obsoleto antes do tempo previsto.

Tempos de vida diferentes, ditam configurações de arquitetura diferentes. Escolher a configurações de arquitetura adequada significa proteger o investimento feito no software. Assim, a escolha assenta num conjunto de decisões que contém as expectativas futuras para o software, para todo o seu ciclo de vida, e não apenas as expectativas imediatas relacionadas à construção da primeira versão. Uma má arquitetura, uma arquitetura inexistente ou torpe torna o software obsoleto antes do tempo. Muitas vezes o tornam obsoleto antes mesmo de ser terminada a primeira versão.

O software será construído por pessoas: os desenvolvedores. A configuração de arquitetura escolhida tem que, também, ser adequada às pessoas que a irão construir. Configurações muito antigas ou muito modernas que estão fora do conhecimento dos desenvolvedores podem atrapalhar e tornar o investimento insuficiente ou consumir em demasia o retorno esperado.

Embora nem a construção nem o planejamento de um software possam ser comparados aos de um edifício, ambos se baseiam na utilização de um suporte físico, um substrato. O edifício assenta em um solo cuja composição, história e propriedades determinam em grande medida o que pode ser, ou não, edificado naquele local. Para o software o solo é o hardware: a máquina, ou máquinas, em que o software será executado.

Há uma ampla diversidade de tipos de máquinas disponíveis para se executar software: telefones, tablets, set-top boxes, laptops, desktops, mainframes e até aparelhos menos comuns embarcados a bordo de automóveis, aviões ou em eletrodomésticos e que possuem capacidade para executar um software. Até mesmo em sondas espaciais.

O hardware é o conjunto de peças que fisicamente suportam o funcionamento de um software. Em ultima análise, tudo não passa de um conjunto de sinais eletromagnéticos viajando em condutores e semi-condutores. É esta a primeira plataforma a ser escolhida: a Plataforma Física. Esta Pataforma é normalmente vinculada ao local onde o software poderá ser utilizado. Se, por exemplo, se desejar que o software possa ser utilizado em viagem, em qualquer ponto do planeta, o software poderá ter que ser executado em um tablet ou um telefone. Contudo, talvez, a capacidade de processamento de um laptop seja necessária.

Acima da plataforma física jaz uma plataforma dedicada a abstrair todos esses sinais eléctricos e lógicos necessário para o controle e instrução da máquina. O nível de abstração é variado e se divide normalmente em três outras plataformas: Sistema Operacional (Plataforma Inferior), middlewares (Plataforma Superior) e às API diretamente utilizadas na programação do software (Plataforma Virtual).

A Plataforma é um dos componentes da arquitetura e, por isso, para que esta esteja completa várias são as plataformas necessárias. Não apenas isso, mas a estrutura específica da plataforma obriga que exista um natural empilhamento das plataformas. Esta pilha de plataformas - chamada stack- define as capacidades máximas de um software. O software será tão rápido, eficiente, produtivo, quanto a pilha de plataformas permitir, sendo limitada pelos recursos disponíveis em cada parte.

A pilha de plataformas está para o software como as várias camadas de solo estão para o terreno onde assenta o edifício. Elas não são o software e não são específicas para um software, mas determinam em larga medida o que o software pode, ou não, fazer e como ele pode, ou não, evoluir. O stack pode limitar a utilização do software em formas imprevistas ou indesejáveis. Por exemplo, uma aplicação construída com C++ (Plataforma Superior) e compilada para funcionar no sistema operativo Linux (Plataforma Inferior) não funcionará, sem ajustes, no sistema operativo Windows. Por outro lado, utilizando uma Plataforma Superior como Java este problema não existirá.

Todo o software tem um objetivo. Ele faz algo por alguém. Esse é o seu objetivo funcional. Contudo, não se espera que o software apenas cumpra o objetivo funcional. Espera-se que o software cumpra outros objetivos como ser: confiável, seguro, durável, de fácil manutenção, fácil evolução, fácil manuseio e aprendizagem, consistente, etc.

Para que todos esses objetivos sejam cumpridos certas qualidades têm que ser levadas em consideração. Estas qualidades não são empilháveis. Cada uma atua por si mesma. Contudo, ao tomar uma decisão durante o desenvolvimento do software, todas elas têm que ser levadas em consideração e ponderadas. Este é um trabalho difícil e nem sempre é possível incorporar todas as qualidades. Muitas vezes, uma ou outra têm que ser sacrificada em benefício das demais. É esta escolha - o trade-off - que requer a experiência dos arquitetos, pois, neste momento, decisões erradas geralmente acarretam o abandono do desenvolvimento do software.

Eis um conjunto das qualidades mais comuns, mais requisitadas, e normalmente mais prioritárias no desenvolvimento de um software:

Em cima da plataforma de aplicação é montado um conjunto de regras que ao serem executadas irão prover ao usuário a resposta que ele espera aos seus comandos. Nem todas estas regras têm o mesmo objetivo. Algumas são puramente estéticas e estão lá para que o usuário ache prazeroso utilizar o software. Algumas são regras que dão utilidade ao software. Desde cálculos complexos até tocar um vídeo ou processar imagens, passando pela manipulação de arquivos e dados. Algumas regras prendem-se com a comunicação com outros software ou com partes distribuídas do mesmo software

Estas regras prendem-se de alguma forma com o fluxo de informação de e para o software, e são divididas em andares. Andares - stories - são para o fluxo lógico da informação o que as plataformas são para o fluxo de comandos que têm que ser instruídos à máquina física. Os andares são as divisões lógicas de responsabilidade para as várias partes do software.

Apenas existe um nodo e ele contém apenas uma pilha de plataformas e uma pilha de andares. Este tipo de arquitetura é utilizada por softwares de uso privado, tais como programas de edição de documentos, tocadores de mídia e antivírus. Este foi o padrão de arquitetura durante muito tempo, especialmente antes do advento da comunicação em rede.

Nesta arquitetura existem vários nodos. Um deles é chamado de servidor e os outros de clientes. Os nodos-clientes contêm os andares de visualização destinados a seres humanos, apresentação, domínio e integração; sendo que o andar de domínio é quase inexistente e apenas contém regras simples relacionadas à apresentação/visualização condicional.

O nodo-servidor contém um andar de visualização que comunica com o andar de integração dos clientes. Além disso, contém toda o andar de domínio, o de integração com outros softwares e o de recursos, sendo que o de integração com outros softwares normalmente não tem funcionalidade e/ou esta integração acontece no andar de integração dos próprios clientes.

Este modelo foi muito utilizado durante a década de 80 e princípios de 90 com o advento do Sistemas de Gerenciamento de Bando de Dados (SGBD) capazes não apenas de armazenar dados, mas também processá-los e operar sobre eles de diferentes formas programáveis (Procedimentos).

Esta arquitetura é baseada na existência de vários nodos. Cada nodo se comunica com pelo menos um outro nodo através de um protocolo que não diferencia entre a responsabilidade do nodos (não há destinção entre nodos servidores e clientes), embora seja possível que alguns nodos contenham mais funcionalidades ou diferentes responsabilidades que outros.

A grande diferença deste tipo de arquitetura é que o andar de integração de cada nodo está munido de ferramentas para encontrar os andares de integração dos outros nodos e dessa forma uni-los em rede.

A arquitetura de 3-níveis, também conhecida como 3-camadas ou 3-tier é uma evolução da arquitetura cliente-servidor. Nesta arquitetura existe um conjunto de nodos com o papel de clientes, um conjunto com o papel de servidor de aplicação e um conjunto com o papel de servidor de dados. Esta arquitetura tornou-se popular pelo seu uso em sistema web.

Em sistemas web os nodos-cliente são munidos de um navegador que é um software mais ou menos padronizado que consegue interpretar documentos HTML e comunicar-se através do protocolo HTTP. O servidor de aplicação contém uma camada de visualização que consegue entender comandos HTTP e repassá-los ao andar de apresentação onde esses comandos são intepretados. No fim do processo um documento HTML é gravado e enviado de volta ao navegador via HTTP.

O servidor de aplicação contém ainda os andares de domínio e integração. Em particular, é comum ter um andar de integração com algum SGDB. A grande diferença é que o SGDB atua mais como um sistema de arquivamento de dados e menos como um processador desses dados.

Esta arquitetura permite, por um lado, que as aplicações seja escritas de uma forma independente do banco de dados e da tecnologia de acesso ao SGDB e, por outro, que os usuários possam acessar o software a partir de qualquer navegador em qualquer máquina.

Recentemente com o advento do uso de JavaScript para a programação do navegador é possível manter, além do andar de visualização, o andar de apresentação, utilizando um conjunto de tecnologias que são referidas como Ajax. O uso de Ajax permitiu portar para as máquinas-cliente o processamento e o andar de apresentação. Isso não só libera recursos valiosos no servidor de aplicação como torna a experiência do uso muito mais interessante para o usuário.

Observe-se que este tipo de arquitetura não tem que ser apenas utilizada com navegadores e sistemas web, podendo ser também utilizada por sistemas com clientes criados na plataforma nativa da máquina-cliente, tal como eram os antigos sistemas-cliente da arquitetura cliente-servidor. Este tipo de arquitetura é ainda mais importante para softwares que precisam comunicar com periféricos conectados nas máquinas-cliente como é o caso de Pontos de Venda (PDV) em supermercados.

A Arquitetura Orientada a Serviço (SOA - Service Oriented Achitecture) é baseada no conceito de software como serviço, e permite que um software seja constituído pela interação e integração de softwares diferentes e especializados.

A arquitetura é baseada no compartilhamento da camada de integração que, à semelhança da arquitetura peer-to-peer , permite que todos os nodos comuniquem. A diferença é que todos têm que comunicar não apenas usando um protocolo comum, como nenhum deles pode assumir o papel de comando do processo. Na arquitetura SOA existe um nodo responsável por inciar, controlar e terminar o processo de invocar os serviços certos nos nodos certos , normalmente chamado de orquestrador

A Arquitetura de Micros-serviços é uma evolução mais recente da arquitetura SOA. A diferença principal é o uso de um nodo para cada propósito. Esse propósito é chamado de Serviço que é o conjunto de todas as funcionalidades alinhadas a aquele propósito. Por exemplo, um serviço de crédito apenas analise se o cliente tem ou não crédito para realizar a compra, enquanto o serviço de estoque apenas lida com as quantidades presentes no inventario.

Nesta arquitetura cada nodo pode conter um stack diferente e andares diferentes dependendo do seu propósito. A ideia é que dependendo do propósito existem stacks mais adequados que outros.

Esta arquitetura também utiliza protocolos de comunicação menos padronizados em vez de protocolos consistentes como SOAP e tráfego de informação é normalmente feito usando JSON em vez de XML, embora isso não seja um requisito. Em tese cada nodo - que representa apenas um serviço - pode usar os protocolos que bem entender.

Uma outra vertente que diferencia a Arquitetura de Micro-serviços é o forte uso de containers - como Docker - e orquestradores de containers - como Kubernetes- que de certa forma empacotam e virtualizam plataformas assim como nodulos empacotam andares e servidores de aplicação virtualizam a execução desses nodulos.