A tomada de decisões sobre o que utilizar pode ser mais complexa do
que parece, apesar de já termos em mente algo que seria mais adequado
para uma arquitetura com base no que já utilizamos ou mesmo nas
novidades apresentadas pela comunidade, sempre temos que avaliar a
realidade do cliente e o foco do projeto, e isso pode mudar
completamente o direcionamento das decisões.

Entendam como cliente, uma empresa seja pública ou privada, que solicita a definição de arquitetura para um determinado escopo. Entendam como você, uma pessoa física (programador) ou jurídica (Software House e afins).

Vamos começar a pensar um pouco nas situações, onde agregaremos complexidade a cada caso:

Caso 1 – Sistema One

Um sistema simples, onde o cliente quer apenas funcionando sem integração com outros e não precisará fornecer os fontes.

Seria o melhor dos mundos para um serviço expresso, ou seja, utilizar
frameworks que forneçam geração de código, bibliotecas prontas e afins.
Como o sistema não terá que integrar com nenhum outro, seria o caso
perfeito para freelancers, afinal, não haveriam impacto nas escolhas. Se
houvesse suporte trabalharia dentro do seu centro de domínio de
conhecimento, o que facilitaria qualquer mudança.

Caso 2 – Sistema Two

Um sistema genérico, que será modificado conforme perfil do cliente, adicionando e removendo módulos.

Isso é muito comum em pequenas e médias empresas, que trabalham com
produtos específicos e agrega valor ao sistema adicionando módulos.
Nesse ponto a arquitetura a ser utilizada precisará fornecer suporte a
esta funcionalidade, é importante pensar se os módulos gerados manterão
integração com os demais projetos, testes de integração ajudarão
bastante na hora de determinadas mudanças, os módulos com peculiaridades
específicas de um cliente devem ser tratados de forma diferente dos
módulos genéricos.

Escolhas devem ser ponderadas pensando no reaproveitamento de módulos
para outros projetos. O centro de conhecimento envolve basicamente o
mesmo produto, o que possilita reuniões para discussões e decisões com
todos os envolvidos.

Caso 3 – Sistema Corp

Vários sistemas, com integração entre aplicações de diferentes
plataformas, manipulando informações corporativas e regras de negócios
específicas.

Situação comum nos ERPs e em empresas de grande porte e mesmo o
governo, onde há vários sistemas envolvidos, é onde se percebe a
efetividade das definições tomadas. É necessário pensar não apenas em um
projeto, mas em vários. Se cada equipe/projeto definir sua própria
arquitetura, os conflitos nos ambientes podem ter resultados
catastróficos, impactando em maior custo para migrar/alterar ambientes,
gerenciamento de componentes e afins.

As definições para integrações entre os sistemas não podem ser
unilaterais, devem contemplar outras plataformas! Nesse ponto começa-se a
ignorar discussões de linguagens: PHP, Java, .Net, Delphi, etc. Já
que as soluções precisarão atender qualquer uma, visto que há
possibilidades de integrações internas e externas, impossível não pensar
em webservices e eternizar as discussões: SOAP, REST, RESTful, WS-* e
equipes defendendo seus pontos de vista e tecnologias.

Área de Arquitetura

Já pensou em todas as equipes de projetos discutindo os assuntos
sobre linguagens, plataformas e soluções diferentes? Nessa hora é que
faz sentido ter uma área para cuidar dos problemas que surgirão,
filtrando as decisões unilaterais, fazendo tomadas de decisões com foco
no plano estratégico da empresa, pensando no melhor para a corporação e
não exclusivamente para o projeto.

Esta área que deve ser composta por representantes que tenham
conhecimento adequado para tais discussões, que sejam formadores de
opiniões, tenham domínio técnico suficientes e flexibilidade para
resolver conflitos.

Convenhamos, muitos desenvolvedores com nível elevado de
conhecimento, não aceitam facilmente o fato de um grupo definir essas
regras, mas não há como se concentrar em desenvolver um produto e
conhecer todos detalhes corporativos da empresa, inclusive dos que seu
projeto não se relaciona.

Uma área de arquitetura por sua vez, consegue focar os esforços em
estudar as melhores soluções, criar e definir regras que facilitem o
desenvolvimento, documentar e organizar os componentes, manter o que é
corporativo sempre atualizado, integrado e pensar em todos os outros
projetos: legados, atuais e novos.

A tarefa não é fácil, os prazos sempre são complicados, os sitemas
legados mal documentados são um fardo enorme e dificultam muito o
trabalho, mas com planejamento adequado consegue-se excelentes
resultados.

O que se ganha com isso?

• Padronizações de codificação, nomenclaturas, desenho de
  arquitetura, que auxiliarão os desenvolvedores a trabalhar em vários
  projetos de forma uniforme.
• Redução de tempo com definições e testes de componentes.
• Centralização de componentes/bibliotecas corporativas, melhorando manutenibilidade.
• Redução da curva de aprendizagem, já que todos trabalham no mesmo padrão;
• Melhor gerenciamento de recurso nas fábricas de software, já que o
  impacto de mudar um desenvolvedor de projetos fica restrito ao
  conhecimento de negócio.
• Melhoria na interoperabilidade, já que tendo uma equipe de
  arquitetura as comunicações de integrações corporativas são facilitadas,
  seguindo um padrão único é possível aninhar atividades para que se dê
  como concluídas apenas quando todas as plataformas sejam contempladas.

Considerações

Tenho certeza que o assunto merece muito mais conteúdo, mas o
objetivo é contextualizar os tópicos de forma simples e espero tê-lo
alcançado.

Até o próximo tópico. Aguardo seus comentários.