Hace más de 30 años surgían los RAD (Rapid Application 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- conocida hasta entonces- de construir soluciones.

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, técnicos que se especializan en las áreas funcionales, desligándose de la tecnología. Usualmente hay brechas generacionales entre estos dos actores y la comunicación se ha transformado en un problema en si mismo.
 

Este acercamiento no parece ser el óptimo y es por eso que los RAD toman fuerza nuevamente como 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 de 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 han sido el condimento ideal para que los RAD emerjan con más fuerza.

¿Qué tiene que tener un RAD HOY para ser válido?

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 modelan 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 como 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 como 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 qué pasa si saco el RAD del medio ¿puedo seguir viviendo o quedo atrapado a un runtime del fabricante?

Otro detalle es tener en cuenta el respaldo de la empresa, saber qué clientes tiene y cuánto 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 cuáles son los indicadores de éxito, como 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.