Arquitetura de Software

Arquitetura de software para desenvolvimento e para produçãoTenho vivido em vários clientes uma situação que é no mínimo a base das equipes de

desenvolvimento no País: O pessoal desenvolve num ambiente que normalmente não tem nada a

ver com o ambiente onde a aplicação vai viver. E mais: nas pesquisas que fiz junto a comunidade

Microsoft, normalmente o pessoal do desenvolvimento nem tem contato com o pessoal de

produção, a não ser quando os problemas aparecem, nada preventivo.

Isto nos leva a dois problemas: Um é o planejamento da aplicação sem o conhecimento necessário

do ambiente de produção e o outro, do pessoal da produção, é receber uma aplicação que, ou não

está completamente compatível com o que existe, ou que precisa ser muito ajustada. O segundo

problema é que na produção a aplicação vai consumir recursos que podem não ter sido

considerados, que podem já estar no limite e/ou impactar outras aplicações já existentes.

Levando em consideração processos como RUP e etc, não se costuma tratar os requisitos de

hardware da aplicação, até porque muitas vezes se ignora totalmente o comportamento da

aplicação, já que raramente se fazem os testes necessários para descobrir isto. E também a

separação que as próprias empresas impõe sobre as equipes dificulta a obtenção destas

informações.

O quê os clientes têm descoberto é que muitas vezes os problemas que vivem são frutos da falta

de integração das equipes de desenvolvimento e produção.

Nesta página

A visão do Desenvolvimento

A visão da Produção

Sugestões

A visão do DesenvolvimentoO padrão para as equipes de desenvolvimento é receber as especificações para a construção da

aplicação, seus componentes e etc., segundo vários modelos (quando há), definidos por alguém

que está pensando nas funcionalidades que a aplicação implementará e mais raramente nas

condições reais de utilização futura. Fica um pouco pior quando a aplicação tem seu

desenvolvimento terceirizado, é dividida em componentes distribuídos entre várias empresas e

outras situações onde fica impossível para quem está desenvolvendo ter a mais remota noção de

onde a aplicação rodará, a não ser pela tecnologia usada.

Além disto, muitas vezes acontecem mudanças de requisitos que têm impactos fortes sobre

aspectos da arquitetura da aplicação, muitas vezes comprometendo até mesmo aplicações já em

produção.

Quando vamos nos preparar para fazer algum serviço nos clientes, costumamos fazer uma série

de perguntas sobre as condições esperadas de utilização da aplicação e sempre que as respostas

voltam, dependendo de quem responde, vêem com disparidades incríveis! Quando é o pessoal do

desenvolvimento, eles até conseguem entrar em contato com o usuário, mas nem sempre este

contato, que foi a interface na fase de desenvolvimento, está atualizado com a realidade da

aplicação. A regra é vir um monte de informações desatualizadas, que mostram claramente como

a aplicação mudou (evolui, se deformou e etc...), mas sem que com elas se possa de fato tomar

decisões importantes.

O quê acontece é termos que incluir uma fase de análise prévia no projeto para verificarmos uma

série de informações junto à produção ou aos usuários.

Início da página

A visão da ProduçãoAo contrario do desenvolvimento, normalmente o pessoal da Produção tem muitas respostas

pouco úteis em relação às aplicações. Costumo brincar (sem deixar de reconhecer a importância

deles) que as métricas que eles costumam ter são as de lata: memória dos servidores, acessos a

disco, consumo de CPU, de rede, literalmente um monte de informações muito úteis quando se

está fazendo um plano de capacidade, mas que não são tão úteis assim quando o objetivo é

resolver um problema na aplicação.

Além disto, apesar deles segurarem a barra de manter as aplicações no ar, costumam ser os

últimos a saber dos problemas das aplicações, uma vez que as SLA’s que normalmente têm

mostrar as métricas que mencionei acima. É mais fácil justificar um investimento para monitorar

algo tangível como os servidores, rede e etc do que uma abstrata transação, apesar desta ser o

fator determinante de sucesso de uma aplicação.

Habitualmente nas conversar com os clientes pergunto se eles têm seguro da sua infra-estrutura,

sites backup e etc. Sempre têm algum tipo, mas quando pergunto se fizeram segura da aplicação

que gera um montante X de receita, a resposta invariavelmente é não, além da pergunta: como

assim?

Como assim? Simples: Testando a aplicação de várias maneiras para que se conheça um mínimo

em relação aos pré-requisitos de consumo, concorrência e etc da aplicação. Quem não conhece a

teoria da ultima gota no copo cheio? É ela sempre que derruba tudo! Mesmo que a aplicação

esteja ok, sempre vai ser a última a entrar no ar a culpada pelo desastre, e os responsáveis por ela

os culpados!

Nos casos onde tenho como clientes as equipes de produção, além do stress normal, eles ainda

têm 2 desafios: 1) identificar rapidamente os problemas, 2)resolvê-los o mais rápido possível. É

desta forma que são avaliados pelas organizações onde trabalham.

Ainda na lista dos problemas, não adianta jogar uma aplicação projetada para suportar X usuários

simultâneos quando ela só suporta metade ou nem isto. É uma falha total, sem falar que quando a

aplicação é para consumo interno da organização, ela ainda pode cair em desgraça.

Início da página

SugestõesApesar de não ser exatamente uma novidade, uma das sugestões que usualmente dou, é fazer

reuniões de integração entre as equipes de desenvolvimento e produção para criar um time real,

unido e comprometido com os resultados da organização. Não adianta uma parte fazer um belo

projeto se ele contiver problemas para a outra parte.

Quando estava na Rational, e ainda hoje, vejo um monte de gente falando de ciclo de vida da

aplicação como sendo somente a fase de desenvolvimento e testes, mas a realidade é que esta é

a fase de gestação da aplicação. Em inglês o termo que identifica o momento de entrega é o

mesmo do parto: Delivery, e é a partir daí que a aplicação vai mostrar de fato a que veio, gerar

seu ROI e Pay-back, entre outras coisas.

Outra sugestão interessante, é deste o momento de concepção da aplicação, capturar-se o

ambiente onde ela rodará, de forma que os desenvolvedores possam conversar com os da

produção para que possam usar o máximo da infra-estrutura, evitar o máximo de desperdício de

recursos e ajustar o máximo de componentes pré-existentes aos novos serviços que terão que

suportar.

E mais do que tudo: testar, testar, testar.... como alguns ainda vão lembrar: um processo iterativo

controlado para os muito técnicos e um processo dialético para os filósofos.

Abraços

Mauricio Medina tem 22 anos de experiência no mercado de software, e é o diretor executivo da

Consequor Tecnologia, empresa especializada em qualidade de software, monitoração e análise de

transações. Foi o fundador da subsidiária da Rational Software no Brasil, diretor de serviços e

responsável pelos produtos de testes da Compuware.

Início da página

  Versão para Impressão   Enviar esta Página  Adicionar a Favoritos

Fale Conosco |Imprima esta página |Adicione aos Favoritos©2005 Microsoft Corporation. Todos os direitos reservados. Nota Legal |Marcas comerciais |Política de Privacidade