quinta-feira, 26 de abril de 2007

Separação ou Casamento de Desenvolvimento com Exploração

Segundo algumas tendências de gestão, Entre elas as definidas pela SOX - Sarbanes Oxley, é boa política separar o desenvolvimento da exploração dos sistemas.

Desconheço quais os reais argumentos que justificam tal procedimento. Aparentemente esta solução obriga a ter 3 ambientes distintos:
1. Desenvolvimento
2. Testes / Qualidade
3. Exploração

É nomeado um gestor de projecto, que faz as especificações do projecto. São feitos os desenvolvimentos, os testes descobrem os erros, que são corrigidos e quando o projecto chega a exploração corre tudo bem. Isto num mundo ideal até funciona bem. Pena que ninguém viva num mundo ideal.

No mundo real ... As especificações não estão completas, as aplicações têm sempre bugs, os dados nem sempre estão correctos. Há indisponibilidades de serviços que impedem a correcta execução da nossa aplicação, etc, etc, etc ... O mundo real ocorre em exploração/produção. Quando a aplicação encontra uma situação dessas que acontece? Pode até continuar a correr gerando dados errados para outras aplicações inadevertidamente, nestes casos o explorador não detecta esses erros. Pode abortar a execução, criando indisponibilidade de serviços. O Explorador não tem conhecimentos suficientes para identificar as potências razões dos erros, essencialmente porque não conhece os 572 formatos de dados que processa. Mesmo que os conhecesse dificilmente encontraria o registo mal formado nos 76.389.427 registos do lote processado que originou o erro. Principalmente quando os registos são binários. Nessa altura o explorador volta-se para o developer e pede-lhe ajuda. O developer que conhece a aplicação de lés a lés rapidamente analisando os sintomas descobre a razão de erro. Sugere a forma de resolver esse problema e fortalece a aplicação acrescentando validações que não tinham sido especificadas inicialmente devido a especificações incompletas. Essencialmente porque o gestor de projecto também não conhece a fundo as implicações desses desenvolvimentos.

Como é óbvio para este modelo funcionar bem, é necessário que todos os intervenientes conheçam muito bem as aplicações e os dados . E quem é que conhece bem as aplicações? E quem é que conhece bem os dados? Será possível que separando os desenvolvimentos da exploração haja alguém com o know-how necessário para a correcta implementação dos projectos?


Quantas e quantas vezes somos surpreendidos com comportamentos não especificados de aplicações? Os chamados BUGS? Mesmo em aplicações compradas e desenvolvidas por softwarehouses supostamente profissionais. Será que o modelo adoptado permite corrigir o problema em tempo útil?

Vamos imaginar que uma aplicação tem que produzir dados num tempo máximo de 24 horas. Ou seja se demorarmos mais 24 horas a processar esses dados, excusamos de os processar. Porque o passageiro já apanhou outro avião, ou já se registou noutro hotel, ou já mudou para outro prestador de serviços. Será que se consegue responder em tempo util que acrescentarmos uma extensa lista de formulários e autorizações e outras burocracias no meio?

Enfim, eu como developer acho que este modelo é muito fixe no papel! Fica bem, um tipo fica cheio de evidências que trabalhou, e não consegiu resolver o problema em tempo util. As empresas poderão quantificar exactamente quanto perderam. O que é muito bom no que toca a modelo de gestão. Mas é péssimo no que toca a disponibilidade de sistemas de informação.

É o que dá deixarmos gestores decidirem arquitecturas de Sistemas de informação.
Não prevejo nada de bom! Neste sector.