El renacer de los RAD

Hace más de 30 años surgían los RAD (Rapid Applications Development) como respuesta a un mundo de tecnología en ebullición que encontraba la metodología en cascada muy pesada para conseguir lograr agilidad. La promesa de poder construir aplicaciones de forma iterativa dio fuerza a estas herramientas que cambiaba la forma de construir soluciones conocida hasta entonces.

Con el tiempo muchos de los jugadores de RAD del mercado fueron perdiendo validez y muriendo por el camino, solo sobreviviendo unos pocos. (Por suerte GeneXus ha sido uno de ellos)

Hoy es normal que en los procesos de construcción de software haya desarrolladores expertos en distintas y nuevas tecnologías que se han desconectado de la visión del negocio y por otro lado otra técnicos se especialicen en las áreas funcionales, desligándose de la tecnología. Usualmente hay brechas generacionales entre estos dos actores y la comunicación sea transformado en un problema en si mismo.

Este acercamiento no parece ser el óptimo y es por eso que los RAD toman fuerza nuevamente cómo una forma de democratizar la construcción de aplicaciones.

A tal punto que según Gartner para el 2020 el 50% de las aplicaciones serán construidas por esta clase de herramientas.

Hoy es normal encontrar empresas que utilizan RAD para construir sus soluciones, ya sea el 100% o al menos alguna parte, por ejemplo la Mobile.

Claro que han sido muchas las razones por las cuales el escenario se ha ido preparando para este panorama y haya tomado fuerza nuevamente el concepto de RAD.

Por un lado cada vez es más valioso el tiempo de entrega sobre otros aspectos en el proyecto, aquello del método lean de que tener lo más rápido posible un mínimo producto viable. Las metodologías ágiles parecen ser hoy el camino. 

Por otro lado la misma evolución tecnológica ha hecho que la capacidad procesamiento aumente mucho, si bien todos deseamos que el código sea óptimo, hoy el procesamiento no es el recurso más escaso. Protocolos de comunicación cada vez más livianos como REST y metodologías basadas en servicios ha sido el condimento ideal para que los RAD emerjan con más fuerza en un mundo dónde características cómo el multiplataforma es siempre deseable, producto de la evolución de las tecnologías mobile más que nada.

¿Qué tiene que tener un RAD hoy para ser valido?

Surge esta pregunta ante la variedad de herramientas que hay en el mercado. Muchas son startups y otras productos que se han mantenido a lo largo de los años. Es importante ver algunos aspectos a tener en cuenta a la hora de tomar la decisión.

Aquí algunos puntos que se me ocurren:

• Herramientas que den prioridad al modelo sobre el código. Poder definir un modelo y que al menos el CRUD se genere de forma automática se hace vital. No perder tiempo en cosas que se pueden automatizar.
• Poder usar código también es importante, porque no todo es modelaba de forma gráfica, procesos sumamente complejos deben tener la posibilidad de ser declarados y parece imposible hacerlo de manera gráfica. Ya sea código propietario o código standard cómo JS.
• Poder hacer deploy de la aplicación a producción de forma sencilla sin importar lo complejo de la aplicación ni la tecnología de la misma. El time to market hoy es vital.
• Poder prototipar de forma sencilla, aquello del método lean.
• Trabajar con distintas nubes, tanto públicas cómo privadas
• Capacidad de leer y exponer servicios, en especial REST
• Capacidad de interactuar con varias bases de datos
• Poder interactuar de forma nativa con ERP, CRM y otros sistemas worldclass
• Poder realizar testing sobre las aplicaciones generadas
• Tener una forma de trabajo colaborativa. 
• Posibilitar la administración y el control de la puesta en producción de las aplicaciones, poder hacer rollback, etc
• Poder generar aplicaciones en ambientes WEB y Mobile, preferentemente de forma nativa en este último segmento.
• Tener mecanismos para construir o integrar excelentes UX. 
• Tener claro que pasa si saco el RAD del medio ¿puedo seguir viviendo o quedo atrapada a un runtime del fabricante?

Otros detalles es tener en cuenta el respaldo de la empresa, saber que clientes tiene y cuanto hace que está en el mercado. 

Y por último si le tenemos un poco de recelo a esto de las herramientas RAD, mi consejo siempre desde que trabajo en GeneXus es que la única forma de sacarse el pre-concepto es probar. Definir una prueba de concepto y trabajarla con alguien que domine la tecnología para entender los beneficios que tiene se hace vital para tomar la mejor decisión.

Sugiero definir cuales son los indicadores de éxito, cómo productividad, calidad, UX, multiplataforma, o los que sean pertinentes y puntuar cada una de las herramientas en cada categoría. No se olviden de probar GeneXus!

Y si ninguna convence a caer en el 50% que en el 2020 estará picando código a mano.