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.