Arquitetura de Software

Arquitetura de software para desenvolvimento e para

produo

Tenho vivido em vrios clientes uma situao que no mnimo a base das equipes de
desenvolvimento no Pas: O pessoal desenvolve num ambiente que normalmente no tem nada a
ver com o ambiente onde a aplicao vai viver. E mais: nas pesquisas que fiz junto a comunidade
Microsoft, normalmente o pessoal do desenvolvimento nem tem contato com o pessoal de
produo, a no ser quando os problemas aparecem, nada preventivo.
Isto nos leva a dois problemas: Um o planejamento da aplicao sem o conhecimento necessrio
do ambiente de produo e o outro, do pessoal da produo, receber uma aplicao que, ou no
est completamente compatvel com o que existe, ou que precisa ser muito ajustada. O segundo
problema que na produo a aplicao vai consumir recursos que podem no ter sido
considerados, que podem j estar no limite e/ou impactar outras aplicaes j existentes.
Levando em considerao processos como RUP e etc, no se costuma tratar os requisitos de
hardware da aplicao, at porque muitas vezes se ignora totalmente o comportamento da
aplicao, j que raramente se fazem os testes necessrios para descobrir isto. E tambm a
separao que as prprias empresas impe sobre as equipes dificulta a obteno destas
informaes.
O qu os clientes tm descoberto que muitas vezes os problemas que vivem so frutos da falta
de integrao das equipes de desenvolvimento e produo.
Nesta pgina
A viso do Desenvolvimento

A viso da Produo

Sugestes

A viso do Desenvolvimento
O padro para as equipes de desenvolvimento receber as especificaes para a construo da
aplicao, seus componentes e etc., segundo vrios modelos (quando h), definidos por algum
que est pensando nas funcionalidades que a aplicao implementar e mais raramente nas
condies reais de utilizao futura. Fica um pouco pior quando a aplicao tem seu
desenvolvimento terceirizado, dividida em componentes distribudos entre vrias empresas e
outras situaes onde fica impossvel para quem est desenvolvendo ter a mais remota noo de
onde a aplicao rodar, a no ser pela tecnologia usada.
Alm disto, muitas vezes acontecem mudanas de requisitos que tm impactos fortes sobre
aspectos da arquitetura da aplicao, muitas vezes comprometendo at mesmo aplicaes j em
produo.
Quando vamos nos preparar para fazer algum servio nos clientes, costumamos fazer uma srie
de perguntas sobre as condies esperadas de utilizao da aplicao e sempre que as respostas
voltam, dependendo de quem responde, vem com disparidades incrveis! Quando o pessoal do
desenvolvimento, eles at conseguem entrar em contato com o usurio, mas nem sempre este
contato, que foi a interface na fase de desenvolvimento, est atualizado com a realidade da
aplicao. A regra vir um monte de informaes desatualizadas, que mostram claramente como
a aplicao mudou (evolui, se deformou e etc...), mas sem que com elas se possa de fato tomar
decises importantes.

O qu acontece termos que incluir uma fase de anlise prvia no projeto para verificarmos uma
srie de informaes junto produo ou aos usurios.
Incio da pgina

A viso da Produo
Ao contrario do desenvolvimento, normalmente o pessoal da Produo tem muitas respostas
pouco teis em relao s aplicaes. Costumo brincar (sem deixar de reconhecer a importncia
deles) que as mtricas que eles costumam ter so as de lata: memria dos servidores, acessos a
disco, consumo de CPU, de rede, literalmente um monte de informaes muito teis quando se
est fazendo um plano de capacidade, mas que no so to teis assim quando o objetivo
resolver um problema na aplicao.
Alm disto, apesar deles segurarem a barra de manter as aplicaes no ar, costumam ser os
ltimos a saber dos problemas das aplicaes, uma vez que as SLAs que normalmente tm
mostrar as mtricas que mencionei acima. mais fcil justificar um investimento para monitorar
algo tangvel como os servidores, rede e etc do que uma abstrata transao, apesar desta ser o
fator determinante de sucesso de uma aplicao.
Habitualmente nas conversar com os clientes pergunto se eles tm seguro da sua infra-estrutura,
sites backup e etc. Sempre tm algum tipo, mas quando pergunto se fizeram segura da aplicao
que gera um montante X de receita, a resposta invariavelmente no, alm da pergunta: como
assim?
Como assim? Simples: Testando a aplicao de vrias maneiras para que se conhea um mnimo
em relao aos pr-requisitos de consumo, concorrncia e etc da aplicao. Quem no conhece a
teoria da ultima gota no copo cheio? ela sempre que derruba tudo! Mesmo que a aplicao
esteja ok, sempre vai ser a ltima a entrar no ar a culpada pelo desastre, e os responsveis por
ela os culpados!
Nos casos onde tenho como clientes as equipes de produo, alm do stress normal, eles ainda
tm 2 desafios: 1) identificar rapidamente os problemas, 2)resolv-los o mais rpido possvel.
desta forma que so avaliados pelas organizaes onde trabalham.
Ainda na lista dos problemas, no adianta jogar uma aplicao projetada para suportar X usurios
simultneos quando ela s suporta metade ou nem isto. uma falha total, sem falar que quando a
aplicao para consumo interno da organizao, ela ainda pode cair em desgraa.
Incio da pgina

Sugestes
Apesar de no ser exatamente uma novidade, uma das sugestes que usualmente dou, fazer
reunies de integrao entre as equipes de desenvolvimento e produo para criar um time real,
unido e comprometido com os resultados da organizao. No 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
aplicao como sendo somente a fase de desenvolvimento e testes, mas a realidade que esta
a fase de gestao da aplicao. Em ingls o termo que identifica o momento de entrega o
mesmo do parto: Delivery, e a partir da que a aplicao vai mostrar de fato a que veio, gerar
seu ROI e Pay-back, entre outras coisas.
Outra sugesto interessante, deste o momento de concepo da aplicao, capturar-se o
ambiente onde ela rodar, de forma que os desenvolvedores possam conversar com os da
produo para que possam usar o mximo da infra-estrutura, evitar o mximo de desperdcio de
recursos e ajustar o mximo de componentes pr-existentes aos novos servios que tero que
suportar.
E mais do que tudo: testar, testar, testar.... como alguns ainda vo lembrar: um processo iterativo
controlado para os muito tcnicos e um processo dialtico para os filsofos.

Abraos
Mauricio Medina tem 22 anos de experincia no mercado de software, e o diretor executivo da
Consequor Tecnologia, empresa especializada em qualidade de software, monitorao e anlise de
transaes. Foi o fundador da subsidiria da Rational Software no Brasil, diretor de servios e
responsvel pelos produtos de testes da Compuware.
Incio da pgina
Verso para Impresso

Enviar esta Pgina

Adicionar a Favoritos

Fale Conosco |Imprima esta pgina |Adicione aos Favoritos

2005 Microsoft Corporation. Todos os direitos reservados. Nota Legal |Marcas
comerciais |Poltica de Privacidade