Las consultoras internacionales y GeneXus

En varios proyectos llevados adelante por Concepto, nos hemos encontrado con algunas empresas internacionales (Consultoras o empresas de desarrollo) que no utilizan GeneXus y que tampoco lo entienden.

Para explicar un poco la situación, creo que es mas fácil contar el ciclo de pasos que se realizan.

• El cliente ve el producto, le gusta y lo quiere.
• Se conversa, conversa, negocia, conversa, pelea y se logran firmar los contratos necesarios para llevar adelante el proyecto. Una parte importante de estas conversaciones consisten en explicar que es GeneXus. Cuesta bastante a quienes no conocen Genexus captar la idea de desarrollar con é. No lo logran encasillar en ninguna de las categorías que tienen formadas para las herramientas de desarrollo.
• Se capacita al personal del cliente en GeneXus, los cuales rápidamente valoran las ventajas de tener dicha herramienta.
• Se hacen las adaptaciones del producto (período de 12/18 meses) donde se hacen cambios y se pueden empezar a poner en funcionamiento algunos módulos.
• Se planifica la puesta en producción.
  
• Se pone en funcionamiento el proyecto.
  

Entre la la planificación de la puesta en producción y la puesta en producción, es bastante común, o al menos a nosotros nos ha pasado, que el cliente llame a alguna otra empresa que realice algún tipo de auditoría o consultoría del diseño de la aplicación, del diseño de la base de datos y de posibles problemas que se puedan presentar en el funcionamiento.

Los informes realizados por estas consultoras que me han tocado responder tienen algunas cosas en común. Voy a tratar de enumerarlas de forma de hacerle mas fácil el trabajo a las consultoras (para que copien los problemas) y para quienes tengan que responderlo.

1) La base de datos no esta normalizada
2) No se utilizan "stored procedures" para la consulta y actualización de la base de datos.
3) La base de datos no tiene integridad referencial.
4) Hay sentencias que realizan demasiadas entradas salidas.
5) El perfil de uso de la base de datos se asemeja mas a una Data Warehouse que a una base de datos operacional.
6) Las tablas tienen demasiados índices. Los índices ocupan demasiados espacio.
7) La aplicación no tiene la tecnología XXXXXXXX ( Aca hay que sustituir las XXX por alguna tecnología que salio el año pasado) que es lo que se recomienda en todos los foros de desarrolladores y esta en la lista de "Best Practices".
8) No se tienen todos los fuentes de la aplicación.
9) Se recomienda NO PONER LA APLICACIÓN EN PRODUCCIÓN.

Paso a comentar cada una de ellas.

1) La base de datos no esta normalizada.
Aunque sea difícil de tragar, esta es común. El problema que sin usar herramientas que ayuden es muy difícil tener bases de datos con 500 o 600 tablas, como tenemos con GeneXus. Por lo tanto, cuando alguien se enfrenta a una base de datos con tantas tablas, es mas fácil dar una rápida mirada, y decir que no esta normalizada, que entender que en realidad, esta normalizada por Genexus. Simplemente no lo entiende, por lo que no conviene entrar en grandes discusiones. Se puede decir que en general esta en tercera forma normal y que en algunos casos se tienen redundancias para optimizar la performance. No es un argumento que le importe mucho al cliente y se justifica razonablemente van a aceptarlo. El último informe que contestamos decía que habia tablas no normalizadas porque tenían mas de 20 columnas!. Sin palabras.

2) No se utilizan "stored procedures" para la consulta y actualización de la base de datos.
Este punto, por suerte va perdiendo fuerza con los años. Es verdad que no se realizan la mayoría de las actualizaciones y recuperación de datos con SP, pues no es la forma natural de trabajar con GeneXus. Si se quieren invocar puntualmente a SP, se puede realizar y lo hacemos en casos indispensables. Los mas bravos en este aspecto son los DBA de SQLServer, pero se pueden buscar argumentos por la ventaja de no tener que usar siempre el mismo plan de ejecución para las diversas corridas de un SP.

3) La base de datos no tiene integridad referencial.
Esta es difícil de defender.
Si bien con GeneXus se puede declarar la IR en la base, es una feature que nunca (antes de la 9.0 al menos) funcionó bien. Muchas veces cancelaban las reorganizaciones o los programas no insertaban y daban errores poco claros.
Se puede decir que la aplicación controla la integridad por código cuando se utilizan transacciones y que las demás actualizaciones (las que se realizan con procedures) están bien programadas y no borran cosas que no deberían borrar.

4) Hay sentencias que realizan demasiadas entradas salidas.
Esto es muy común en aplicaciones que recién se están poniendo en producción. Como las sentencias no se hacen a mano, es fácil que se cuele alguna que tenga alguna navegación espantosa. También es probable que sentencias que funcionan bien en el ambiente de testeo tengan problemas en el ambiente de producción. En otras metodologías no GeneXus, cada sentencias compleja, pasa por el control de un DBA. En los desarrollo realizados con GeneXus esto es menos probable, pues la sentencia no la escribe nadie a mano, por lo que mas facil que llegue algún sentencia complicada a producción. Es bueno saber que puede pasar y tener forma de identificarlas en forma temprana. Lo mejor es destinar alguna persona para que utilice herramientas de monitoreo en la base de datos y solucionar los problemas que se detecten.
Una vez detectada la sentencia hay que buscarla en los fuentes y corregir el objeto GeneXus que la contiene. Con pocos cambios, muchas veces se logran resultados espectaculares.

5) El perfil de uso de la base de datos se asemeja mas a una Data Warehouse que a una base de datos operacional.
Esta también es parte de las diferencias naturales de la forma de programar. Es posible que la relación de reads/write en las aplicaciones GeneXus sean mayores que las aplicaciones hechas a mano. Creo que esto mejoro con GX 9.0. También creo que cuando se programa a mano, como a todo el mundo le da pereza se generan menos prompts y consultas.
Esto se va normalizando a medida que pasa el tiempo y que los usuarios saben como usar el sistema, pues al principio consultan mucho mas que cuando están entrenados.

6) Las tablas tienen demasiados índices. Los índices ocupan demasiados espacio.
Esta es bastante cierta. Muchas veces en GeneXus tenemos tablas de 10 registros, que tienen 7-10 índices. La base de datos posiblemente no los utilice nunca, porque puede cargar toda la tabla en memoria una vez y después operar desde ahí.
Creo que es un área donde hay que trabajar para borrar índices que no se utilizan (de los definidos por el usuario) y dejar los que se precisen.
Es mucho mas fácil para un desarrollador GeneXus crear un indice que mandarselo a crear a un DBA, por lo que la cantidad de índices es entendible, pero no es justificable.
Conviene tomar las tablas con mas de 1 millón de registros y ajustarle los indices que necesitan. Es un trabajo que vale la pena.

7) La aplicación no tiene la tecnología XXXXXXXX ( Aca hay que sustituir las XXX por alguna tecnologia que salio el año pasado) que es lo que se recomienda en todos los foros de desarrolladores y esta en la lista de "Best Practices".
Esta es una carrera que nunca se puede ganar.
Si la aplicación es 2 capas, la van a pedir en 3 capas.
Si es tres capas y utiliza protocolo Corba, van a pedir VisiBroker o RMI o lo que sea.
Si usa tomcat, será necesario Websphere.
Si usa Remoting, van a pedir porque no utilizan WS-* para comunicarse
Si se usan Webservices, el pedido será WCF
Si se tiene aplicaciones win, sera utilizar WPF
Si es web, la van a pedir Ajax, Silverlight, Apolo, o lo que sea.
Si usa ODBC, sera necesario ADO.NET.
Si usa IIS n, es recomendable migrar a IIS n+1

Es fácil estar una generación atras, y generalmente aplicaciones de miles de objetos, lo estarán . GeneXus se ha adaptado bien a estos cambios tecnológicos y es una oportunidad para diferenciarse, pero no hay que menospreciar el esfuerzo de dar los saltos. Conviene conocer las nuevas tecnologías y adoptarlas cuando se perciban la ganancia suficiente.

Es imposible y a veces contraproducente tener todas las "ultimas" tecnológicas pero conviene tenerlas probadas

8) No se tienen todos los fuentes de la aplicación.
Esto es algo que muchas veces plantean. Tanto en aplicaciones java como con .NET hay DLL o clases que son parte de GeneXus y no se tienen los fuentes.
En algunos casos conviene hablar con Artech y pedir específicamente los fuentes de dichos programas. Una vez que se dicen que van a estar disponibles, ya nadie mas los reclama, porque en realidad no lo quieren para nada, sino solamente para tener la tranquilidad de no quedar rehenes de ninguna empresa.

9) Con todos los problemas encontrados, es imposible entrar en produccion, pues el fin del mundo esta cerca.
Generalmente viene acompañado de la recomendación de que los contraten a ellos o alguna otra empresa para que le optimice todos los inconvenientes encontrados.
Este ultimo punto es jorobado, pues siempre van a existir problemas, pero si uno tiene confianza en la aplicación desarrollada, no hay que dar mucha bola y seguir para adelante, dándole tranquilidad al cliente que se va a poder sobrevivir y que todo se va a normalizar en 15 días.

Conclusiones y recomendaciones
Bueno, si alguien llegó a leer hasta aca, ya lo considero un milagro. A mi me cuesta mucho leer post tan largos.

Recomendaciones:
Leer el informe con cuidado y contestarlo punto a punto.
Después tener una reunión con el cliente, para explicarlo y comentarlo en detalle. Hacerle notar que con todo lo importante que es la tecnología, mucho mas importante son los resultados del uso del sistema, por lo que es mejor ponerlo en funcionamiento y solucionar los problemas que surjan.

Otra recomendación es que cuando se respondan estos informes, conviene juntar todas las siglas de tres letras que hayan pasado cerca de ustedes y ponerlas bajo la firma del informe, porque es también lo que hacen quienes realizan los informes. Generalmente tienen muchos títulos, pero poca experiencia práctica, por lo que las respuestas "desde la trinchera" los dejan sin argumentos.

Enrique Almeida
PDA, JTA, MVA, VPN, SSP, SSL, HTM, SPC y VCP (significa Voluble de Calidad Preferente)

UPDATE: En realidad es mas sobre aplicaciones desarrolladas con GeneXus, que sobre GeneXus mismo.