GeneXus USA llevó adelante un desafiante proyecto de
desarrollo crítico para la empresa PayPlus que "aún con GeneXus pero sin los
Patterns hubiera sido difícil de implementar", afirma Verónica Buitrón,
vicepresidente de GeneXus USA.
PayPlus llegó a la industria PEO (Professional Employer
Organization) es decir el outsourcing del área de administración de recursos
humanos, y dominó el mercado. PayPlus tenía parte de la industria PEO con una
aplicación y compró a su competidor, por lo que pasó a dominar casi
exclusivamente el mercado con sus dos aplicaciones. Pero el tiempo pasó, y esas aplicaciones basadas en tecnología
obsoleta, eran difíciles de mantener.
PayPlus preocupado por ofrecerles
a sus clientes no sólo aplicaciones con muy buena funcionalidad pero también
utilizando la última tecnología, sabia que tenían que cambiar o su
"market-share" iba a cambiar. Por otro lado, al no
contar con exorbitantes recursos humanos ni financieros, sabían que tenían que
encontrar una manera de potenciar sus recursos proveyéndoles de herramientas que
le permitieran producir más con menos. Así fue como PayPlus adoptó GeneXus como
su herramienta para el desarrollo de su nuevo suite de productos.
En este contexto, PayPlus solicitó a GeneXus USA el
desarrollo de una aplicación de Recursos Humanos que reflejara personas,
organizaciones y su interacción cubriendo las áreas de recursos humanos, nomina,
beneficios, etc. Pero además incluía requerimientos que implicaban la
implementación de una base de datos temporal, entre otros desafíos. Verónica Buitrón, vicepresidente de GeneXus USA explica estos
desafíos y cómo los superaron con el uso de Patterns.
¿Cuáles eran los desafíos a cumplir que los llevó
a usar Patterns?
La situación no era
fácil. Había que construir una aplicación web de Recursos Humanos muy grande y
compleja para un cliente nuevo y toda la aplicación debía verse y comportarse en
forma simple y consistente frente al público usuario.
El cliente nos pidió que la aplicación representara las
relaciones entre personas y organizaciones a través del tiempo pasado, presente
y futuro, y con una vista completa de la base de datos. La idea no era
simplemente tener tablas de historia, sino que toda la base de datos, tablas y
relaciones se mueva en el tiempo, lo cuál básicamente implica la implementación
de una base de datos temporal. Pero como a este problema las base de datos
relacionales no nos dan una buena solución, entonces toda la complejidad se
trasladaba a la programación.
Por otro lado, al ser un outsourcing, la aplicación es por
definición multi-empresa, pero para minimizar el costo de mantenimiento de
códigos, la idea era no duplicar la información común, sino sustituir la
implementación común de multi-empresa por una relación indirecta entre empresas
y códigos, e implementar un concepto de grupo de códigos utilizado por las
empresas.
Cuando armamos el plan para este proyecto descubrimos que
las tres cuartas partes del proyecto eran tareas repetitivas y que la
implementación de la base de datos temporal era muy compleja. Entonces me
preocupé porque no sabía cómo iba a conseguir la productividad a que estamos
acostumbrados con GeneXus en otro tipo de desarrollo.
Por suerte, justo por ese mismo tiempo, Nicolás Jodal fue
a visitarnos a Chicago y me habló de su nueva fórmula secreta: el Pattern
generator. Para mi ver la demo del Pattern generator, fue equivalente a
encontrarle la vuelta a este desarrollo.
¿Qué medida concreta de la productividad del
desarrollo con Patterns podría dar de este proyecto?
Creamos una aplicación de misión crítica, donde los Patterns
resuelven automáticamente toda la complejidad de la base de datos temporal y
mantienen todo sincronizado. Y lo hicimos en el mismo tiempo y presupuesto
estipulado para el desarrollo de la versión 1.0 de la aplicación, pero
implementando muchísima funcionalidad pensada y necesaria para la versión
2.0
La aplicación se generó utilizando el generador Java al
tener que soportar Unix y Windows, SQL/Server y Postgress SQL. Casi 5000 objetos
fueron generados via Patterns y de 300 transacciones sólo para seis
transacciones no se genera nada con Patterns. Además, por cada transacción que
diseña el cliente, Patterns genera en promedio 30 objetos
relacionados.
Es otras palabras, tendremos una aplicación de misión
critica generada en mas de un 95% generada automáticamente por los Patterns.
¿En qué casos aconsejaría usar Patterns para
desarrollar?
En aplicaciones grandes de
negocios donde tenemos comportamientos repetitivos o sea en cualquier aplicación
que tenga un Business Pattern y que tenga suficiente porte para que tenga
sentido la inversión en customizar su propio Pattern. Creo que la clave está en
el tamaño de la aplicación y la relación con el comportamiento repetitivo. Si
repito en muchos lugares y la aplicación es grande, entonces uso Patterns. Esto
es hablando de un pattern personalizado que hay que programar, testear y
adoptar. Un Pattern "as-is" como los que provee ARTech lo usaría siempre que
puedo ¿para que reinventar la rueda?