Low Code: facilitando la transformación digital

Los conceptos Low Code y No Code y las soluciones que los soportan vuelven a estar de moda.

Los retos que el proceso de transformación digital está planteando a las organizaciones en términos de velocidad de respuesta, reducción de coste y adaptabilidad hacen que todas las bondades que ofrecen estas plataformas sean muy atractivas y necesarias, siempre y cuando abordemos adecuadamente su implantación.

En este artículo revisaremos las experiencias del pasado, lecciones aprendidas y cómo aplicarlas para hacer de nuestra Low Code Application Platform una historia de éxito.

1. ¿Qué es Low Code?
   1. El Low Code no es nuevo...
   2. ... pero ahora ha encontradu su lugar en el mundo
2. Ventajas y riesgos de la filosofía Low Code
3. Cómo afrontar la incorporación del Low Code
   1. Introducir la filosofía Low Code en una organización
   2. Muy bien, y ahora ¿cómo abordo un desarrollo sobre mi LCAP?
4. Claves para el éxito: Nuestro enfoque
   1. Low Code como estrategia
   2. Expectativas realistas del cliente
   3. Low Code no es Low Architecture
5. Conclusiones

La filosofía Low Code y su extremo No Code surgen de trasladar los principios de fabricación industrial al mundo del desarrollo de aplicaciones.

En esta línea, las soluciones que soportan esta filosofía buscan dotar al usuario de:

• Bloques de construcciones (OoTB) estándares que se adapten a las necesidades concretas de cada usuario vía parametrización y combinación, fácilmente replicables y mantenibles.
• Herramientas de construcción fáciles de usar, muy visuales, que no requieran de de especialización en IT (ni conocimientos previos de programación para No Code).
• Herramientas para la explotación y monitorización de las aplicaciones construidas: Gestión global de los diferentes entornos (1-click staging), Objetos OoTB para monitorización del consumo de recursos, uso de flujos, etc.
• Herramientas para la extensión del OoTB y la integración con el resto de la plataforma vía exposición/consumo de servicios. En este área se concentran los requerimientos de especialización en IT.

Así pues, la filosofía Low Code podemos verla como la vía para evolucionar la industria del desarrollo IT hacia la madurez productiva que podemos encontrar en los sectores de automoción, naval, etc.

La búsqueda de la automatización y reutilización a nivel industrial en IT no es algo nuevo: las plataformas RAD de finales de los 80, los lenguajes y plataformas 4GL de los 90, las plataformas tipo lotus Notes o los CRM de principios de este siglo son ejemplos claros. Todas estas soluciones prometían:

• Reducción del tiempo de desarrollo respecto al desarrollo a medida.
• Disminución de la inversión en IT tanto como consecuencia por la reducción de los tiempos de desarrollo, como por evitar la implicación de perfiles especializados y caros, además de una reducción de los costes de operación y mantenimiento.
• Cualquiera puede construir aplicaciones, sin necesidad de conocimientos de programación. El usuario final es el que conoce el negocio y lo plasma directamente sobre la aplicación sin intermediarios.

Pero la realidad es tozuda y aparecieron graves problemas:

• El ecosistema de aplicaciones sufría de un fuerte acople a la plataforma, además de unos costes altos de integración por donde se fugaban todas las reducciones de costes prometidas.
• El efecto BlackBox generaba la pérdida de la trazabilidad de las soluciones e introducía problemas de seguridad
• No se contemplaba ningún tipo de filosofía de lock in, con lo que cambiarlas implicaba costosos proyectos de migración.
• La falta de personalización y el concepto de todo es posible provocaba la explosión de “Wild Custom Code” que normalmente contenía toda la lógica de negocio, sin documentar y con graves problemas de compatibilidad con la evolución de la plataforma que hacía que todo el sistema se quedara anclado en una versión concreta pronto obsoleta.

Así pues, se generaron graves dudas respecto a la viabilidad de su utilización en aplicaciones de misión crítica y generó desconfianza en los CIOs por los peligros de apalancamiento tecnológico y financiero. Además, los problemas de integración y malas prácticas de desarrollo comprometían, cuando no anulaban, los ahorros en inversión.

Por todo ello, la soluciones Low Code / No Code iniciaron su travesía del desierto.

En la última década, con la explosión de la transformación digital, la situación del mercado ha cambiado drásticamente. Los ciclos de vida de las aplicaciones se han acortado significativamente con lo que los tiempos para obtener un ROI aceptable son muchos menores. Aparecen grandes oportunidades y necesidades de negocio a las que hay que dar una respuesta rápida pero efímera basada en aplicaciones oportunistas difícilmente abordables desde un enfoque tradicional. Las unidades de negocio están íntimamente implicadas en toda la fase de concepción y desarrollo, extendiéndose la práctica de la utilización de prototipos que prueben la bondad de las ideas en situaciones reales para su rápida evolución o desechado.

Por otro lado, las plataformas Low Code han salido de su travesía fortalecidas con un cambio de enfoque que, en función del fabricante, busca resolver los problemas de sus antecesoras: disminución del peligro de acoplamiento, apertura a la comunidad, énfasis en el no Lock-in, evolución de las capacidades de integración, etc.

Así pues, la opción Low Code / No Code vuelve a estar encima de la mesa con fuerza, pero para no volver a caer en los mismos errores hay que abordarlas con un enfoque diferente.

Tal y como hemos visto en el anterior capítulo, las soluciones basadas en la filosofía Low Code tiene grandes ventajas, de las que destacamos:

• Significativa reducción de los tiempos de desarrollo y puesta en producción
• Mayor implicación del usuario en todo el proceso de definición y construcción, consiguiendo afinar y ajustar mejor el resultado a las necesidades del negocio.
• La definición visual de los flujos en la propia plataforma permite la “autodocumentación”, evitando los costosos procesos de ingeniería inversa para saber qué hace un módulo, librería o aplicación.
• Reducción de los costes de desarrollo al requerir equipos más pequeños.

Una respuesta rápida, enfocada en las necesidades de negocio donde desde el minuto uno todos los actores de la organización estén implicados es posible y facilitada por las soluciones Low Code si controlamos los riesgos que las hicieron zozobrar en el pasado, destacando:

• La facilidad de uso y extensibilidad proporciona la falsa sensación de “navaja suiza”. La orientación de “solución para todo” da lugar a un exceso de personalización, a mal diseño y rotura de esquemas que supone la conjunción de lo peor de los dos mundos: Un código difícilmente mantenible, mal documentado y donde se ha trasladado la lógica de negocio que hace que nos apalanquemos versión obsoleta de la plataforma.
• La confusión entre disminución drástica en los requerimientos de desarrollo con puentear la supervisión de IT genera el desarrollo integraciones sin control y sin gobierno. Éstas no solo comprometen la estabilidad de toda la arquitectura, sino su evolución futura. Aparece el temido lock-in.

La maximización de los primeros y minimización de los segundos pasa por un proceso controlado de introducción global de la filosofía Low Code en la organización así como de una metodología eficaz y eficiente en el desarrollo de proyectos sobre la plataforma implantada.

La adopción de la filosofía Low Code implica un cambio en la forma de pensar las posibles soluciones IT a los problemas de negocio. Estamos ante un proyecto estratégico en el que su éxito depende, en buena medida, de un correcto proceso de implantación que estructuraremos en cuatro fases:

• Fase 1: Estudio arquitectónico / Negocio
• Fase 2: Solicitar información a diferentes fabricantes (RFI)
• Fase 3: Prueba de concepto  (POC)
• Fase 4: Plan de despliegue

[FASE 1: ESTUDIO ARQUITECTÓNICO / NEGOCIO]

En este primer estadio haremos un análisis desde diferentes perspectivas de cómo llevar a cabo la implantación de la futura LCAP y si realmente es útil a nuestra organización:

• Perspectiva OPS: Los responsables de arquitectura identificaran las necesidades de adaptación en la plataforma actual para poder encajar la nueva LCAP. Así mismo, definiremos los requerimientos tecnológicos de despliegue, operación e integración a satisfacer por la LCAP.
• Perspectiva IT: Los responsables de IT identificarán las necesidades de desarrollo y mantenimiento que se generan con la implantación de la LCAP en su globalidad: coste de licencias, desarrollos de interfaces, procesos de ingeniería inversa, migraciones, etc.
• Perspectiva Negocio: Conjuntamente con IT, identificamos aquellas áreas de negocio que por sus necesidades o implicaciones son candidatas para la nueva LCAP. Por ejemplo, la opción Low Code puede ser acertada en el caso de una actualización global de los proceso de back office soportados por una tecnología obsoleta y amortizada.

La primera y fundamental decisión que hemos de tomar es go/no go en función a la relación coste/beneficio definida en el trabajo de las tres perspectivas. En caso de seguir adelante, con este estudio conoceremos el contexto donde nuestra nueva LCAP va a ser útil e identificaremos los requerimientos tecnológicos de la LCAP y de nuestro ecosistema actual.

[FASE 2: SOLICITAR INFORMACIÓN A DIFERENTES FABRICANTES (RFI)]

Aunque se trate de una fase opcional, si que es recomendable pedir a los fabricantes preseleccionados en la fase 1 información adicional sobre los principales requerimientos arquitecturales, de desarrollo y de negocio que complemente la recogida de requerimientos realizada en el estudio.

Como resultado de esta RFI recomendamos seleccionar dos ó tres candidaturas para la fase 3.

[FASE 3: PRUEBA DE CONCEPTO (POC)]

Ya sabemos que el papel lo aguanta todo. Por ello la Fase 3 es fundamental para comprobar que todo lo analizado en las dos fases anteriores se ajuste con la realidad, sabiendo que la verdad sufre cuando se la examina.

Para ser realmente útil, esta POC debe:

• Basarse en caso de uso realista, a ser posible un proceso real de negocio de los seleccionados para ser soportados por la LCAP
• Contener un número razonable de interacciones con el resto de componentes de la arquitectura de la organización (CRM, ERP, bus de eventos, etc.)
• Estar limitada en el tiempo para comprobar realmente las bondades de la LCAP y disponer de información en un plazo adecuado
• Estar limitada en coste, pues no deja de ser una prueba y no una implantación real, a la que nos intentaremos acercar en lo posible

Las diferentes plataformas preseleccionadas las estudiaremos en varias dimensiones, evaluando diversos aspectos de la LCAP:

• Desarrollo: Analizaremos el coste, tiempo y equipo necesario respecto a un desarrollo a medida, perfiles implicados, requerimientos y facilidades para la migración, bondad de las herramientas de soporte al desarrollo, o la adaptación a diferentes metodologías (Waterfall, Agile...).
• Arquitectural: Siguiendo los requerimientos identificados en fases anteriores, estudiaremos aspectos como la integrabilidad, pruebas de estrés, entornos de despliegue (cloud, on premise, hybrid), lock in y acoplamiento, y los aspectos de DevOps definidos.
• Fabricante: Evaluaremos aspectos como la política de licenciamiento, el soporte técnico prestado o la política de versionado (majors releases, minor releases, patchs, política de actualización, etc).
• Funcional: Revisaremos características como la cobertura del OoB respecto a las necesidades de negocio, la adaptabilidad y extensibilidad de la plataforma o la capacidad de personalización.

Como resultado de esta prueba, tendremos seleccionado el fabricante que proveerá nuestra nueva LCAP acorde a nuestros requisitos y necesidades.

[FASE 4: PLAN DE DESPLIEGUE]

En esta fase definiremos cómo vamos a implantar nuestra nueva LCAP. Para asegurar su éxito, en su construcción tiene que estar implicada toda la organización desde el primer momento, liderados por IT.

Este plan debe incluir, como mínimo, los siguientes elementos:

• Roadmap de migración del área de negocio seleccionada, con un especial énfasis en la gestión de la expectativas del cliente, para lo que le involucraremos en todo el proceso.
• Roadmap de todas las adaptaciones, evoluciones y cambios dentro de la arquitectura para encajar la nueva LCAP
• Guía de gobernanza de la LCAP, donde se defina claramente cómo vamos a utilizar la LCAP para la implementación de las nuevas soluciones. En este contexto aparece dentro de la organización una nueva figura, el Arquitecto de Soluciones LC. Entre sus responsabilidades encontramos:
  • Velar por el cumplimiento de los criterios de buena gobernanza
  • Seleccionar y validar qué aplicaciones realmente son candidatas a ser soportadas por la LCAP
• Análisis de coste/beneficio que permita hacer realidad este proyecto.

Los proyectos candidatos a desarrollar sobre nuestra nueva LCAP suelen tener una o varias de las siguientes características:

• Alta indefinición de los requerimientos
• Corto tiempo de salida al mercado
• Alta implicación de usuario
• Necesidades de negocio cambiantes

La metodología Agile es la que mejor para encarar estos proyectos. La naturaleza iterativa de los mismos, la integración de usuario y la gestión exigente de sus expectativas hacen que aplicar una estrategia waterfall sea el preludio de un fracaso.

Por otro lado, el equipo que va a implementar la nueva solución varía por su nivel de participación y no tanto por ser un desarrollo a medida. En concreto:

• La implicación de UX/UI: Es conveniente su presencia a lo largo de todo el proyecto. Asegurar los criterios de usabilidad, la definición del user journey y contar dentro del equipo con personas que hablen el mismo idioma que los usuarios garantiza el éxito del proyecto.
• La figura del Business Analyst: Es clave en la implementación. Es el encargado del correcto mapeo de las User Stories dentro de OoTB, así como detectar las necesidades de “custom development”, alineado con las directrices marcadas en la guía de gobernanza.
• La figura del Arquitecto: Complementaria a la del Business Analyst e igualmente clave. Es el que revisará y definirá todas las necesidades de conectividad y extensibilidad que la nueva aplicación exige de la LCAP.
• Los equipos de desarrollo son más reducidos, siendo sus tareas fundamentales:
  • Implementación del custom code definido
  • Implementación o adaptación de las API y conectores necesarios para consumir recursos del ecosistema

Desde Opentrends estamos convencidos de que el éxito de la incorporación de la filosofía Low Code descrita anteriormente está soportado en tres grandes pilares o paradigmas:

• Low Code es una decisión estratégica
• Gestión de las expectativas del cliente y unidades de negocio
• Low Code no es Low Architecture

El éxito de la adopción de una Low Code Application Platform (LCAP) require que sea considerada una decisión estratégica dentro de la compañía. Considerar la implantación de una LCAP como una táctica para resolver un problema o urgencia aislada o una simple reducción de coste es una condena al fracaso.

La implantación de una LCAP se debe abordar de una forma global pues:

• Las LCAP tiene unos costes de salida importantes en forma de licencias, curva de aprendizaje, formación y comunicación interna que requieren de tiempo para obtener el ROI deseado. Es fundamental definir el área objetivo de negocio donde aplicarla atendiendo a volumen y número de aplicaciones, recursos implicados...
• Implica un cambio en la forma de afrontar como dar el soporte tecnológico necesario a los requerimientos del mercado. El balance de implicación de los diferentes actores se desplaza desde desarrollo a negocio pasando por arquitectura.
• Requieren movilizar recursos en los ámbitos de IT y áreas de negocio.
• Requiere crear nuevas figuras y prácticas dentro de los departamentos de IT y negocio
• La formación de todos los actores implicados en el conocimiento de las capacidades de la plataforma es fundamental para aprovechar toda su potencia, maximizar beneficios y minimizar riesgos.

Toda la organización debe estar implicada en el cambio y ser partícipe de él.

Aprovechar la rapidez de respuesta a las necesidades de negocio y la reducción significativa de costes que brindan las LCAP pasa por involucrar e ilusionar de una forma realista a todos los futuros usuarios. No puede ser visto como una decisión meramente táctica de IT.

Uno de los mensajes más potentes y más repetidos cuando hablamos de qué es Low Code”es que estas plataformas nos permiten construir aplicaciones sin tener conocimientos de programación (No Code) o muy básicos (Low Code). La consecuencia directa es generar en los usuarios el síndrome del “bálsamo de fierabrás”: las LCAP son la panacea que permite solucionar todos los problemas por mí mismo, sin contar con ningún tipo de supervisión por parte de IT. No tener en cuenta este fenómeno y mitigarlo desde un buen comienzo es tener el fracaso servido.

Es vital gestionar las expectativas del cliente final sobre qué puede hacer y qué no en la plataforma. Y son fundamentales las acciones de comunicación interna que conciencie a perfiles de negocio sobre la flexibilidad de la herramienta: menos requerimientos de desarrollo que les permite abordar con eficiencia y eficacia las necesidades que se presentan.

Aunque debemos ser muy estrictos en la observancia de unos criterios de buena gobernanza y en los criterios de selección de qué soluciones son candidatas a ser soportadas sobre la LCAP. En la resolución de todas estas necesidades la participación de IT es crítica para el éxito.

Un error clásico es considerar la Low Code Application Platform como un ente autónomo, una caja negra aislada del resto de soluciones que componen el ecosistema IT de la organización. Nuestro enfoque considera la LCAP como un elemento más dentro de la infraestructura IT, que debe seguir los paradigmas arquitectónicos definidos y debe responder a los siguientes criterios:

• Acople débil: La LCAP no puede convertirse en un punto de apalancamiento tecnológico que genere una pérdida de agilidad en la respuesta a requerimientos, así como condicionar la evolución de la misma.
• Lock - in: La LCAP debe incorporar mecanismos y/o estrategias que permitan no sólo prescindir de ella en un futuro, sino incorporar un soporte eficaz y eficiente a la gestión de incidencias de la plataforma o de la política de actualizaciones.
• Integración: La LCAP debe ser capaz de consumir y exponer servicios al resto de los componentes de la arquitectura siguiendo los estándares definidos (API REST / SOAP, webhook...)
• Personalización: La imagen de marca que transmitimos al mercado es hoy en día crucial para cualquier organización. La LCAP debe dar respuestas a todas las exigencias en UX/UI contempladas en secciones anteriores: Pixel Perfect, reutilización de patrones, generación de nuevos patrones de diseño, etc.
• DevOps (CI/CD): La LCAP debe cumplir los requerimientos de operaciones bajo la estrategia CI/CD como integración con herramientas como Jenkins, compatibilidad con el despliegue en contenedores, soportar estrategias Cloud, On premise e Híbridas, monitorización del uso y de consumo de recursos.
• Seguridad: La LCAP ha de integrarse con sistemas SSO, de autenticación y autentificación, así como proveer mecanismos de gestión de Roles.
• Trazabilidad: La LCAP ha de proporcionar mecanismos que minimicen el efecto Black Box. Debe permitir recoger y explotar información sobre el uso de los flujos creados, objetos, recursos consumidos, etc.

El éxito de una iniciativa Low Code sólo es posible con un buen pilotaje desde IT y su encaje suave dentro de la arquitectura tecnológica.

La filosofía Low Code ha llegado a la madurez. Es una buena estrategia para abordar las necesidades actuales y futuras del mercado, facilita la transmisión de conocimiento y la democratización de la generación de soluciones dentro de la organización, acercando a los departamentos de IT y negocio, que dejan de ser unos extraños.
    
No repetir los errores del pasado pasa por abordar la LCAP como una estrategia global y no como respuesta a un problema aislado. La gestión de las expectativas del usuario y la implicación de IT en su correcta gobernanza para no desbordar sus límites permiten poder aprovechar toda la potencia de unas soluciones que facilitan a las organizaciones afrontar los retos de la cambiante realidad del huracán de la transformación digital.

Definitivamente, la filosofía Low Code ha vuelto para quedarse.