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.
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.
Há um livro fundamental na biblioteca de qualquer informático que lide com grandes sistemas: The Mythical Man-Month, de Fred Brooks. É um livro escrito nos anos 70, mas com ideias muito válidas. O autor começa por afirmar que desenvolver sistemas grandes em tempo útil exige equipas grandes, mas as equipas grandes dão sempre enormes confusões! Infelizmente não há soluções simples. ("No Silver Bullet", é um ensaio inserido na reedição feita em 1995)
ResponderEliminarO SOA é, de facto uma abordagem complexa. Mas a verdade é que, para sistemas grandes, não há grandes alternativas. A "informalidade" que defendes tem diversos inconvenientes que começam a aparecer logo que tu queres ir de férias! ;-)
No livro, o Fred Brooks compara um sistema grande com um "tar pit" (poço de alcatrão). Quando se cai num, é uma grande porcaria! Mas a verdade é que as organizações precisam mesmo deles. E, tendo consciência que a sua gestão é complexa e a produtividade da equipa cai a pique à medida que a dimensão aumenta, os profissionais de TI não podem fugir à responsabilidade de os construir da melhor forma possível.
No mundo real... as organizações têm que se defender, formalizando o essencial e garantindo que o sistema não depende só de uma pessoa.
Concordo que às vezes não há maneira de escapar à complexidade. Contudo às vezes caem-se em soluções rebuscadas para problemas simples. KISS.
ResponderEliminarEu tento sempre simplificar as coisas. Quando olho para o histórico de código meu não é estranho ver o número de features a aumentar ao mesmo tempo que o número de linhas de código diminui nos ficheiros mais antigos ao longo do projecto.
Sinceramente acho que o WSDL é demasiado complexo para 90% das aplicações. Montes de texto e pouca informação útil. Tem de haver uma maneira melhor de fazer isto. Há muita gente a fugir do XML para JSON por estas e outras razões.
Se há coisa que aprendi com a história é que as soluções simples tendem a vencer. Hoje em dia programar é mais complexo que devia ser, e as comunicações entre aplicações também são mais complexas que deviam ser.
O Perl 6 e o Ruby 2.0 vão ter VMs. Penso que vamos ver coisas interessantes na próxima década.
Há sempre espaço para melhorar as coisas complexas. Mas o movimento SOX/SOA vai para além da questão da programação. Não há linguagem de programação que resolva:
ResponderEliminar- a rotação de pessoal que domina o conhecimento
- a necessidade de auditar qualquer ponto do sistema
- a necessidade de interligação de sistemas de origens e tecnologias diferentes
- a necessidade de substituição de partes do sistema por outras mais funcionais, com impacto mínimo
- e muitos mais...
Certamente que haverá evoluções interessantes no futuro, mas não vale a pena desistir de tentar organizar melhor o desenvolvimento e manutenção dos sistemas só porque é difícil e os standards não estão exactamente como nós gostávamos... :-)
O JSON existe hoje e é disponibilizado, entre outras empresas, pelo Google para web services (JSON-RPC).
ResponderEliminarPara muitas aplicações, em que o desempenho não é problema, o Ruby pode ser usado hoje. Uso um website, tadalist.com, todos os dias que é feito em Ruby.
De qualquer modo, o óptimo é inimigo do bom. Penso que é melhor escolher algo consensual que avançe a actual situação em que existem uma data de aplicações que não sabem falar umas com as outras, nem que seja via o WSDL, a ficar emperrado a discutir os prós e contras de qual a melhor solução para o problema, não produzindo nada.
Talvez não tenha ficado explicito. Eu defendo formalismos. Defendo que tudo deve de ser especificado. Apenas não acredito que seja possível alguém especificar correctamente conhecendo a aplicação apenas pelo ponto de vista do desenvolvimento, ou apenas pelo ponto de vista de produção. Porque vão sempre haver problemas na aplicação que só serão detectados demasiado tarde. Aí invariavelmente a empresa vai perder Dinheiro (para os gestores perceberem). Apenas defendo que quando a área de desenvolvimento está entrosada com a área de produção, a solução será encontrada mais depressa. Logo as perdas serão muito menores.
ResponderEliminarQuanto ao formalismo, continuo a defender que uma aplicação deve de ser bem documentada e que isso requer tempo. Manuais de desenvolvimento, manuais de exploração, de entradas em exploração, etc.
Acontece que mais uma vez no mundo real, esse tempo não é respeitado. Principalmente, numa empresa que faz software para uso "doméstico", em que o utilizador está proximo do developer e em que a aplicação está a sofrer constantes alterações(talvez devido a especificações incompletas, ou apenas falta de visão). A documentação acaba por ser sempre a ultima coisa a ser feita. Não raras vezes é sacrificada por "projectos" mais prioritários.
O mundo real é prolixo na diversidade. Idealmente tudo seria diferente.
Ah como gostava de viver num mundo Ideal.