Todos nosotros, y en casi toda empresa, conoce a un gerente y/o un director que gestiona la totalidad de sus tareas con una Excel mega-fantástica con macros en cada celda. O que se ha creado una aplicación en MS Access, y confía más en ello que en el software corporativo de la compañía. Este tipo de animal corporativo es bastante común, más de lo que podamos creer. He llegado a ver ficheros XLS dignos de una exposición de arte, y que me hace cuestionarme que la persona en cuestión ha errado su profesión.
Una Excel para gobernarlos a todos,
Una Excel para encontrarlos,
Una Excel para atraerlos a todos,
Y en la TI Oculta atarlos
Este tipo de software empresarial es conocido como la “TI Oculta“ (Shadow-IT), y representa un verdadero problema para las compañías y en especial para la práctica de la arquitectura empresarial. En este tipo de desarrollo no se tienen en cuenta cuestiones como la seguridad, GDPR, datos maestros, integraciones, arquitectura de despliegue, etc. Además, suele pasar que no se ha involucrado a los arquitectos (EA) en su definición y diseño. Y casi siempre están por debajo del radar de TI y no aparecen registradas en ningún repositorio de aplicaciones y/o sistemas. Con todo esto se entiende mejor lo de la “TI Oculta“ (Shadow-IT).
Pero ahora nuevas tendencias en el mundo del desarrollo parecen que les estén dando la razón: las plataformas Low-code / Zero-code / No-code y el Citizen Developer.
Este tipo de software empresarial es conocido como la “TI Oculta“ (Shadow-IT), y representa un verdadero problema para las compañías y en especial para la práctica de la arquitectura empresarial. En este tipo de desarrollo no se tienen en cuenta cuestiones como la seguridad, GDPR, datos maestros, integraciones, arquitectura de despliegue, etc. Además, suele pasar que no se ha involucrado a los arquitectos (EA) en su definición y diseño. Y casi siempre están por debajo del radar de TI y no aparecen registradas en ningún repositorio de aplicaciones y/o sistemas. Con todo esto se entiende mejor lo de la “TI Oculta“ (Shadow-IT).
Pero ahora nuevas tendencias en el mundo del desarrollo parecen que les estén dando la razón: las plataformas Low-code / Zero-code / No-code y el Citizen Developer.
¿Qué son las plataformas Low-code? ¿Zero-code? ¿No-code?
El Low-code, traducible como poco código o poca programación, es un término acuñado por Clay Richardson y John Rymer (“New Development Platforms Emerge For Customer-Facing Applications”, Forrester 2014) y que habla de herramientas o plataformas que ayudan en el ciclo de vida del desarrollo de software y permiten ahorrar en tiempo, esfuerzo y costes.
Básicamente suelen estar compuestas de una interfaz gráfica donde se colocan elementos visuales predefinidos en un formulario / página web / mobile canvas, para después modificar los parámetros de dichos elementos que afectan su comportamiento.
Clay y John definieron cuatro características para clarificar si una plataforma era Low-code o no: Modelado gráfico, reutilización, siempre en la nube y soporte más allá del desarrollo. Y ¿qué ventajas les suponen a estas plataformas? Bueno, los analistas de Forrester mencionaron ventajas como velocidad del desarrollo, sencillez, reducción de costes, mayor flexibilidad, y mejores estándares de calidad. Resumiendo: el “desarrollador Low-code” utiliza componentes que han sido desarrollados y optimizados por super expertos.
Y ¿cuáles son las diferencias entre Low-code y las plataformas Zero-code o No-code? La idea es la misma pero estas últimas no permiten desarrollar nada mediante codificación (en las Low-code es posible crear scripts, clases a invocar, etc.). Se gana en robustez y se pierde en flexibilidad.
¿Qué significa el término «Citizen Developer«?
El término Citizen Developer está alambicado con la transformación digital que está en el centro de las organizaciones en este momento. Se refiere a una especie de democratización del mundo, hasta ahora cerrado, de la programación. Esta potente idea, aboga por que cualquier persona puede desarrollar sistemas y/o aplicaciones sin necesidad de tener conocimientos de programación.
El concepto en inglés, aunque suena poderoso, se refiere más bien a un desarrollador aficionado (amateur) en contraposición a un desarrollador profesional. Alguien que de forma proactiva colabora en el desarrollo de aplicaciones o sistemas para la compañía y que afectan a los ciclos de desarrollo tradicionales.
Entonces, ¿Dónde está el problema?
Los problemas que acarrean el Low-code y por ende los Citizen Developers es que siguen incrementando el tamaño de la TI Oculta (Shadow-IT) en las compañías. Estamos pasando de un fichero XLS a un Excel con esteroides, pero seguimos permitiendo la creación de aplicaciones y sistemas que pasan bajo el radar de gobernanza TI y esto solo traerá más problemas en el futuro.
Además, este tipo de desarrollos permiten romper con las líneas maestras decididas por la dirección TI de la compañía: replicación de datos, seguridad o inseguridad, reutilización de activos corporativos, sinergias, UX, estrategia de dispositivos móviles, etc.
Y habría que añadir el concepto “caja negra”, puesto que un desarrollador aficionado puede hacerlo todo en el desarrollo de una aplicación o sistema, sin tener que lidiar con nada ni con nadie dentro de la organización. Puede crear pantallas que vayan en contra de lo decidido en la organización en temas UX. Puede modelar procesos que no representen la realidad de la compañía. Puede contravenir regulaciones o leyes en términos de protección de datos. En definitiva, puede hacer lo que quiera y como quiera, y lo que es peor nadie podrá chequear lo desarrollado puesto que se trata de una verdadera caja negra, que puedes usar, pero no sabes cómo ha sido construida y que hay dentro de la misma.
La movilidad (retiro, abandonar la compañía) del personal supone otro problema en este escenario, ya que la persona se va con el conocimiento de cómo funciona la aplicación, como fue construida, que se tuvo en consideración en su construcción, y en definitiva el análisis de la aplicación se va con el empleado. Cambiar de una Excel o de una base de datos en Access a una aplicación Low-code no soluciona este problema. Los fanáticos de estas plataformas argumentaran que “acabas antes construyéndola de nuevo” pero es el mismo mensaje que cuando defendían las hojas Excel pobladas de macros.
Pero ¿Hay solución? O ¿no la hay?
Si claro que hay solución, aunque no es sencilla. La solución es poner una gobernanza TI lo suficientemente estricta que permita reducir la TI Oculta (Shadow-IT) sin afectar a la agilidad que aportan este tipo de plataformas. Al final es una balanza en equilibrio, si los procesos de gobernanza son demasiado pesados o inflexibles, los desarrolladores Low-code o los Citizen Developer intentarán escapar de dichos procesos. Pero si son demasiado flexibles y muy ligeros, serán buenos para fomentar la agilidad y favorecer la transformación digital de las organizaciones, pero no ayudarán al objetivo de reducir y/o eliminar la TI Oculta (Shadow-IT).
Primero habrá que categorizar la aplicación que se quiere desarrollar, es para una sola persona, para un grupo, para un departamento, es a nivel corporativo, tiene acceso externo, etc. Respondiendo a todas estas preguntas se podrá decidir si Low-code es la solución para el problema planteado, o debería ser desarrollado de forma tradicional.
Tras esta decisión, vendrá la siguiente que es la reutilización: se debe insistir que lo prioritario será reutilizar servicios y componentes que ya existan en la organización en lugar de volverlos a construir. No importa que hacerlos bajo una plataforma Low-code sea menos costoso, si ya existen el coste es 0 o casi. Esto es también aplicable a lo construido dentro de la plataforma, que se deberá construir con el concepto “Reusable por defecto“-reusable by default- en mente. Al final, y de forma conceptual, la reutilización es manejada por la organización y no por la plataforma Low-code.
Lo mismo se ha de aplicar a los datos: habrá que decidir cuáles son los datos maestros de una entidad (y tanto si están dentro de la plataforma como si esta fuera) se respetará el principio de no duplicidad (data once). Nuevamente si los datos maestros están en la plataforma, se definirán y modelarán con la mente puesta en la reutilización de datos maestros.
La gobernanza también deberá tener en cuenta las pantallas y formularios, la navegabilidad de la aplicación, e incluso lidiar con conceptos más avanzados de una estrategia UX. Es decir, la organización deberá adaptar la plataforma para que el front-end de todas las aplicaciones sea homogéneo y corporativo, sea o este muy cerca de la UX de las aplicaciones tradicionales, y siga punto por punto la estrategia de la compañía en términos de “Look & feel”. Siendo muy visionario, las pantallas deberían ser reutilizadas de forma corporativa, es decir que un sistema TI tradicional sea capaz de invocar una pantalla dentro de la Plataforma Low-code y volver al sistema IT original, de forma transparente para el usuario.
Y lo mismo es aplicable a la seguridad, a la topología de despliegue, a la relación con la oficina de proyectos, etc.
Recapitulemos
¿Son las nuevas tendencias de Low-code y Citizen Developers buenas para las organizaciones? Si lo son.
¿Prohibimos las hojas Excel o las aplicaciones en MS Access? No, pero sería conveniente migrarlas hacia plataformas Low-code, donde la dirección de IT pueda controlarlas y monitorizarlas.
¿Cómo luchamos contra la TI Oculta? Estableciendo una gobernanza TI para las aplicaciones Low-code que abra las “cajas negras” en las que se podrían convertir sin dicha gobernanza.
¿Es la gobernanza TI un obstáculo para la agilidad? Puede serlo, por ello la gobernanza deberá ser lo suficiente ligera para que no suponga un obstáculo, pero lo suficiente estricta para que nada se escape al radar de la dirección de TI.
Resumiendo: un “si” rotundo a las plataformas Low-code que vienen a ayudar en la transformación digital, que darán más agilidad en el desarrollo de aplicaciones, pero tiene que venir acompañada de gobernanza TI o estaremos repitiendo los errores del pasado. Pero si, las tendencias de Low-code vienen para quedarse como un “estándar de facto” y hay que empezar a pensar en cómo introducirlas en las organizaciones.
Deja tu comentario