GeneXus
USA levou adiante um desafiante projeto de desenvolvimento crítico para a
empresa
PayPlus que mesmo com GeneXus, mas sem os Patterns tivesse sido difícil
implementar, afirma Verónica Buitrón, Vice-Presidente de GeneXus USA.
A
PayPlus chegou á indústria PEO (Professional Employer Organization), ou seja, o
outsourcing da área de administração de recursos humanos e dominou o mercado. A
PayPlus tinha parte da indústria PEO com uma aplicação e comprou seu
concorrente, com o que passou a dominar quase exclusivamente o mercado com suas
duas aplicações. Mas o tempo passou e essas aplicações baseadas em tecnologia
obsoleta, eram difíceis de manter.
A
PayPlus preocupada por oferecer aos seus clientes, não só aplicações com muito
boa funcionalidade, mas também utilizando a última tecnologia, sabia que tinha
que mudar ou seu "market-share" ia mudar. Por outro lado, ao não contar com
exorbitantes recursos humanos nem financeiros, sabiam que tinham que encontrar
uma maneira de potenciar seus recursos provendo-os de ferramentas que lhe
permitissem produzir mais com menos. Assim foi como a PayPlus adotou GeneXus
como sua ferramenta para o desenvolvimento da sua nova suíte de
protudos.
Neste contexto a PayPlus solicitou a GeneXus USA o
desenvolvimento de uma aplicação de Recursos Humanos que refletisse pessoas,
organizações e sua interação cobrindo as áreas de recursos humanos, nômina,
benefícios, etc. Mas, além disso incluía requerimentos que implicavam a
implementação de uma base de dados temporária, entre outros desafios. Verónica
Buitrón, Vice-Presidente de GeneXus USA explica estes desafios e como os
superaram com o uso de Patterns.
Quais eram os desafios a cumprir
que os levou a usar
Patterns?
A situação não era fácil. Havia que construir uma
aplicação web de Recursos Humanos muito grande e complexa para um cliente novo e
toda a aplicação devia se ver e se comportar de forma simples e consistente
frente ao público usuário.
O cliente nos pediu que a aplicação
representasse as relações entre pessoas e organizações através do tempo passado,
presente e futuro, e com uma vista completa da base de dados. A idéia não era
simplesmente ter tabelas de histórias, senão que toda a base de dados, tabelas e
relações se mova no tempo, o qual basicamente implica a implementação de uma
base de dados temporária. Mas como a este problema as bases de dados relacionais
não nos dão uma boa solução, então toda a complexidade se transferia para a
programação.
Por outro lado, ao ser um outsourcing, a aplicação é por
definição multi-empresa, mas para minimizar o custo de manutenção de códigos, a
idéia era não duplicar a informação comum, senão substituir a implementação
comum de multi-empresa por uma relação indireta entre empresas e códigos e
implementar um conceito de grupo de códigos utilizado pelas
empresas.
Quando armamos o plano para este projeto descobrimos que as
três quartas partes do projeto eram tarefas repetitivas e que a implementação da
base de dados temporária era muito complexa. Então me preocupei porque não sabia
como ia conseguir a produtividade que estamos acostumados com GeneXus em outro
tipo de desenvolvimento.
Por sorte, justo por este mesmo tempo, Nicolás
Jodal foi nos visitar em Chicago e me falou da sua nova fórmula secreta: o
Pattern generator. Para mim ver a demo do Pattern generator, foi equivalente a
encontrar a saída para este desenvolvimento.
Que medida concreta
da produtividade do desenvolvimento com Patterns poderia dar deste
projeto?
Criamos uma aplicação de missão crítica, onde os
Patterns resolvem automaticamente toda a complexidade da base de dados
temporária e mantém tudo sincronizado. E o que fizemos ao mesmo tempo e
orçamento estipulado para o desenvolvimento da versão 1.0 da aplicação, mas
implementando muitas funcionalidade pensada e necessária para a versão 2.0.
A aplicação foi gerada utilizando o gerador Java ao ter que suportar
Unix e Windows, SQL/Server e Postgress SQL. Quase 5000 objetos foram gerados via Patterns e de 300
transações só para seis transações não se gera nada com Patterns. Além disso,
por cada transação que desenha o cliente, Patterns gera uma média de 30 objetos
relacionados.
En outras palavras, teremos uma aplicação de missão
crítica gerada em mais de um 95% automaticamente pelos
Patterns.
Em que casos aconselharia usar Patterns para
desenvolver?
Em aplicações grandes de negócios onde temos
comportamentos repetitivos ou seja em qualquer aplicação que tenha um Business
Pattern e que tenha suficiente porte para que tenha sentido o investimento em
customizar seu próprio Pattern. Acho que a chave está no tamanho da aplicação e
a relação com o comportamento repetitivo. Se repito em muitos lugares e a
aplicação é grande, então uso Patterns. Isto é falando de um Pattern
personalizado que tem que se programar, testar e adotar. Um Pattern "as-in" como
os que fornece a ARTech o usaria sempre que pudesse: para que reinventar a
roda?