Caso 1 Bom dia por qu?

Vocs so funcionrios de uma empresa de desenvolvimento de software, alocados em diferentes projetos nos diversos clientes. Um belo dia cada um de vocs foi convidado para participar de uma reunio emergencial aps o expediente, convocada pelo diretor de desenvolvimento a pedido de uma de suas equipes.

A equipe do projeto estava desenvolvendo um software e algumas funcionalidades j estavam em uso em ambiente de produo. Tratava-se de uma aplicao para um famoso teatro que tinha como objetivo automatizar os pontos de venda de ingressos e gerenciamento das apresentaes.

Sempre que havia uma atrao famosa o sistema de vendas aleatoriamente travava. Era preciso reiniciar o servidor para que tudo voltasse ao normal. O servidor estava hospedado em outra empresa, o que dificultava o restabelecimento do servio. O teatro no tinha interesse nenhum em trazer os servidores para dentro de casa, at mesmo porque todos indcios apontavam a aplicao e no a infraestrutura como o bicho-papo causador de problemas.

Na reunio, a equipe de desenvolvimento afirmou que a aplicao estava utilizando a arquitetura clssica de 3 camadas (apresentao, negcio e persistncia), sendo que havia duas apresentaes: uma web, para as atividades administrativas; e uma outra que provia servios remotos acessados pelos pontos de venda para sincronizao dos mapas das poltronas do teatro.

Segundo a equipe, o travamento s ocorre com as funcionalidades referentes sincronizao dos mapas. O sistema no possua casos de testes automatizados, a validao do sistema foi feita pelo prprio usurio. Como o usurio no consegue simular os momentos de pico, esta falha do sistema no foi detectada e nem consegue ser reproduzida em ambiente de homologao.

Um pequeno detalhe, o prazo para entrega do sistema j era piada de mal gosto, o projeto j estava dando prejuzo, o cliente estava puto da vida com aquela novela e o presidente da empresa decepcionado com a equipe do projeto. A equipe j tinha tentado de tudo, mas de nada adiantou. S resta agora passar a batata quente.

Para isso uma nova equipe foi criada, e vocs participantes desta reunio faziam parte dela. Vocs no tiveram escolha, j era! E agora Joss, como arquitetos do BOPE, quais medidas vocs tomariam para resolver esse perrengue?

Caso 2 Isso um Single Sign-On?

Um dia as coisas mudaram, a diretoria de sua empresa mudou. O mais novo diretor recebeu a incumbncia de reativar a Fbrica de Software da empresa e contratou vocs como equipe especializada de arquitetos para resolver um problema recorrente em toda organizao: o controle de acesso das aplicaes.

Todas as aplicaes produzidas pela Fbrica de Software necessitavam de um mdulo de segurana, responsvel por garantir a autenticao e o acesso seguro s funcionalidades de cada sistema. Na antiga fbrica, este mdulo era reconstrudo para cada aplicao. Mas se tinha uma coisa que o novo diretor no queria era retrabalho desnecessrio.

A antiga fbrica teve srios problemas com descumprimento de prazos e de altos custos com retrabalho. Para o presidente da empresa a impresso que ficou foi: vender software prejuzo certo. Graas a novas oportunidades de negcios no mercado local, surgiu a oportunidade de tentar de novamente. O novo diretor foi contrato para fazer dar certo desta vez e no podia decepcionar.

Aps diversas reunies entre vocs e o novo diretor, foi identificado que o problema do controle de acesso no era exclusividade da Fbrica de Software. Estava a uma oportunidade de matar dois coelhos com uma cajadada s: reduzir o custo da fbrica e tambm dos sistemas internos da empresa. Isso sim seria um timo carto de visitas.

Percebeu-se que cada sistema da empresa construdos com as mais diversas tecnologias possua uma base de segurana diferente. Olha s que coincidncia, todos os sistemas foram feitos pela antiga fbrica. Se tem algo de bom nisso que vocs possuem acesso ao cdigo-fonte e podem modificar o que quiserem. Com base em levantamentos, vocs identificaram que a base de dados da empresa era LDAP, mas cada cliente da fbrica poderia ter outra, desde banco de dados at simples arquivos de texto.

Sob a perspectiva de arquitetura de software, como vocs resolveriam este desafio?

Caso 3 Couve-flor no, Workflow!

Almoo no shopping, equipe reunida. De repente um dos diretores da empresa, por coincidncia, encontra todo mundo reunido e fala: surgiu um projeto novo que a cara de vocs. A primeira coisa que vocs pensaram, mas ningum pronunciou, foi: l vem bomba. Era um sistema para controle de fluxos de trabalho, utilizando uma tecnologia especfica que demandava bastante dedicao em pesquisas. Como era desafiador, vocs toparam!

Basicamente o objetivo do projeto era construir uma aplicao Web que reunisse a administrao dos fluxos de trabalho gerenciados por um motor de Workflow, mas no era s isso. A primeira atividade que vocs se dedicaram foi meter a cara nos livros para descobrir que diabo faz tal motor. E descobriram! Aprenderam que um motor de Workflow processa fluxos cadastrados e que em determinados momentos delegam atividades para programas externos. O incio de um fluxo tambm pode ser disparado por um programa externo.

Se o motor j faz tudo, para que serve este projeto? Por dois motivos bsicos. O primeiro que as telas Web providas pelo fabricante do motor para interagir com os fluxos bizarra, altamente toscas, complicadas de usar e completamente inviveis para o usurio final. O segundo que o motor precisa delegar atividades que ele no sabe fazer, tais como: acessar sistemas da empresa, buscar documentos na intranet e enviar mensagens para celular. Toda interao com o motor se ocorre via WebServices, seja ela de entrada (motivo 1) ou de sada (motivo 2).

Como vocs arquitetos de renome projetariam esta aplicao que interage com o motor do Workflow, com o usurio final e com os dados da organizao? Como dizia Edson Gomes: este sistema um vampiro, .

Caso 4 Era uma vez uma aplicao que nunca ficava pronta...

Era uma vez um projeto que nunca ficava pronto. Por ironia do destino (ou no), apelaram para a equipe de arquitetos da empresa e vocs foram escolhidos para para descascar o abacaxi. O turnover do projeto estava alto, a equipe era composta por novatos e apenas um remanescente dos primrdios do projeto.

Tratava-se de um sistema para apoiar atividades de fiscalizao de estabelecimentos comerciais. Os agentes levariam consigo um tablet que rodaria a dita cuja aplicao que nunca ficava pronta. O gerente do projeto estava desesperado e relatou que cada tentativa de corrigir um problema, outro pior aparecia. Sabe quando voc puxa o lenol curto para cobrir a cabea e descobre os ps e vice-versa? Era isso que acontecia.

Vocs iniciaram os trabalhos fazendo a verificao da arquitetura e inspeo do cdigo-fonte. Segundo o antigo membro da equipe, a aplicao seguia o modelo de 3 camadas, onde a apresentao utilizava a biblioteca de telas padro do tablet e a camada de persistncia utilizava uma tecnologia simples de armazenamento.

Aps muito penar, vocs descobriram que as camadas no seguiam as regras bsicas. A camada de negcio fazia referncia s telas e aos objetos de acesso aos dados, as telas acessavam a camada de persistncia diretamente, pulando a camada de negcio. Ou seja, tava uma tremenda tosqueira, pouca coisa estava como manda o figurino.

Vocs propuseram refazer a aplicao por completo, mas o gerente do projeto disse: nem pensar. O prazo do projeto j havia estourado e o cliente deu o ultimato. Se falhar desta vez, o projeto ser cancelado com aplicao de multas exorbitantes.

A aplicao alm de apresentar crash difceis de rastrear, o processo de sincronizao entre o tablet e o servidor (na Internet) estava mais perdido do que cachorro que cai de caminho de mudana. A sincronizao simplesmente no funcionava e essa era a principal preocupao do cliente.

A soluo era corrigir o que estava errado, que era praticamente tudo. Mas como fazer isso sem assumir que iria jogar a aplicao fora e fazer outra? Use a criatividade pois o cliente colocou um arquiteto da equipe dele para acompanhar o trabalho. Boa sorte!