¿El poder del low-code es real o está pasado de moda? ¿Cómo podemos evaluarlo?

Una situación imposible

Imagina esta situación, en una empresa tecnológica, hay un equipo que está en un gran aprieto: tienen que crear una aplicación para gestionar las relaciones con los clientes y sólo disponen de unas semanas para hacerlo. Casi parece una misión imposible, ¿verdad? Sin embargo, aquí están, tres semanas después, no sólo terminados antes de lo previsto, sino que además han creado un sistema CRM que funciona estupendamente y adaptado a sus necesidades. Nada de trasnochar escribiendo código ni de trucos de mago informático, sólo la magia de las plataformas de bajo código.

Estas herramientas están cambiando por completo las reglas del juego, convirtiendo el desarrollo de software en un proceso rápido, eficaz y asequible. Impresionante, ¿no? Pero, ¿es esto realmente cierto?

Leemos en la red que las plataformas de bajo código son herramientas de desarrollo de software que permiten crear aplicaciones escribiendo poco o nada de código tradicional. Mediante un entorno visual, en el que los usuarios pueden utilizar interfaces de arrastrar y soltar y plantillas preconstruidas, pueden montar y configurar la funcionalidad de una aplicación. El objetivo es simplificar el proceso de desarrollo, haciéndolo accesible incluso a quienes no tienen conocimientos avanzados de programación.

Son especialmente útiles para el desarrollo rápido de aplicaciones empresariales, la automatización de procesos y la creación de soluciones personalizadas para satisfacer necesidades empresariales específicas. Gracias a estas plataformas, empresas de todos los tamaños pueden innovar a un coste aceptable y adaptarse rápidamente a un mercado en constante cambio.

Entonces, ¡a trabajar con el low-code! ¿O no?

¿Qué se entiende por plataforma de bajo código?

Aunque existe un concepto común de código bajo, no hay una definición unívoca. Puede leer las posiciones de algunas de las principales marcas haciendo clic en sus nombres:

KPMG

KPMG invierte tanto en low-code que en 2021 creó el Centro de Excelencia Low-Code. Pero no he podido encontrar una definición de low-code. O mejor dicho, responde a la pregunta Qué es el low-code con palabras que no son suyas, sino de la empresa ServiceNow:
El bajo código es una forma refinada de que las empresas desarrollen aplicaciones de alta gama que, según ServiceNow, pueden rendir hasta 10 veces más rápido en comparación con las desarrolladas de forma tradicional.

Sinceramente, no encaja con muchas plataformas de bajo código que conozco.

En otra página habla del low-code como “una de las tecnologías más disruptivas que han llegado a las empresas desde la nube. Permite crear potentes aplicaciones de software utilizando una sencilla interfaz gráfica en lugar de arcanos conocimientos de programación.

Gartner

Con un enfoque más estructurado, Gartner ofrece su propia definición tanto en su sitio Peer Insights“Gartner define las plataformas de aplicaciones de bajo código (LCAP) como plataformas de aplicaciones que se utilizan para desarrollar y ejecutar rápidamente aplicaciones personalizadas abstrayendo y minimizando el uso de lenguajes de programación.”

A continuación, comparte sus reflexiones sobre el crecimiento del mercado de bajo código y, por último, pone a disposición de los usuarios uno de sus famosos Cuadrantes Mágicos, en el que“Gartner define las soluciones LCAP como plataformas de aplicación utilizadas para desarrollar rápidamente aplicaciones personalizadas.” Es decir, desaparece la referencia a la carrera.

IBM y Kindryl

Para IBM “
Low-code es un enfoque visual del desarrollo de software que permite una entrega más rápida de las aplicaciones mediante una codificación manual mínima.
“. En la misma página, se hace una observación interesante sobre las diferencias entre low-code y no-code: “Sin embargo, los productos sin código se dirigen específicamente a los usuarios empresariales, permitiéndoles crear aplicaciones personalizadas sin necesidad de conocimientos y habilidades de desarrollo expertos.

Mientras que Kindryl, la parte de los servicios de IBM que se reunió en una empresa ad-hoc, no gasta energía en la parte conceptual sino que opera directamente anunciando que Microsoft concedió recientemente a Kyndryl la Especialización en Desarrollo de Aplicaciones de Bajo Código.

Estas definiciones muestran cómo cada una de ellas conforma la definición de código bajo destacando diferentes criterios. Quienes destacan la rapidez del
proceso de desarrollo
los que también tienen en cuenta aspectos del
entorno de producción
los que tienen en cuenta las
competencias necesarias
y los que sólo se dirigen a los
desarrolladores
. Sin embargo, todos ellos ponen los aspectos visuales y de arrastrar y soltar en el centro de todo.

En mi opinión, las definiciones anteriores son erróneas porque todas se refieren a un desarrollo genérico de aplicaciones que se acelera, sin tener en cuenta sus múltiples aspectos. Esto hace que la gente crea que el low-code tiene su propia capacidad mágica para hacer que el desarrollo de cualquier aplicación vaya mejor.

Creo que esta es la principal razón por la que el low-code es visto con desconfianza por quienes tienen experiencia en el desarrollo de aplicaciones, tanto como técnicos como responsables de la toma de decisiones.

¿Qué elementos del desarrollo de aplicaciones se ven afectados por el low-code?

Creo que no se pueden evaluar objetivamente las innovaciones introducidas por el low-code sin tener un marco de referencia que lo que se necesita para el desarrollo de aplicaciones convencionales.

Por lo tanto, si no estás familiarizado con este mundo, en las siguientes secciones describo un modelo de infraestructura y un modelo de arquitectura de software que utilizo para enmarcar las plataformas de bajo código.

Haga clic en los siguientes títulos para ver los modelos tomados como punto de partida.

La pila de infraestructuras: un modelo

Cómo es

Empecemos con una descripción trivial de la pila de infraestructuras que necesitan las aplicaciones.

El hardware: es la parte física de la tecnología informática. Son los
dispositivos que permiten la ejecución de programas, la conexión entre ellos y la transferencia de datos
. Por ejemplo, nuestro PC, portátil o de sobremesa, apagado o encendido es el hardware.

El Sistema Operativo – Es un software, bastante genérico, necesario para
realizar interacciones básicas con el hardware
. De hecho, oculta la complejidad del hardware a los usuarios, ya sean humanos o de otros programas informáticos. En nuestros PC es Windows o MacOS para los que tienen un Apple.

Middleware – Esta es una categoría de software extraña de definir, porque
hace que un conjunto de funcionalidades específicas estén disponibles de forma genérica
a un usuario. Un buen ejemplo en nuestros ordenadores es el software de hojas de cálculo, ya sea EXCEL, Sheets o Numbers. Prueba a abrirlo sin hacer nada más, verás una tabla vacía sin que pase nada más. Tu programa te ofrece un montón de funciones para gestionar datos en tablas, pero si no empiezas a utilizarlas, a modelarlas, a personalizarlas, ¡no sirven para nada! El middleware de tu hoja de cálculo pone a tu disposición infinidad de funciones para manipular tablas con todos los fines: científicos, estadísticos, económicos, etc. Podríamos definir el middleware como aquel software que, una vez iniciado, no hace nada a menos que le pongas otro software.

Aplicaciones: son los programas informáticos que dependen directamente del sistema operativo o del middleware para proporcionar una funcionalidad específica. Un ejemplo son navegadores como Edge, Safari, Chrome, Firefox, que se ejecutan directamente en el sistema operativo y permiten navegar por Internet. Otra puede ser una hoja de cálculo Excel diseñada para calcular el Código Fiscal o una más compleja para gestionar una Primera Nota. ambos son programas que se basan en el middleware de Excel.

En las aplicaciones web, gran parte de esta

Pero el modelo no acaba ahí. Debemos tener en cuenta otros dos niveles que atraviesan los anteriores.

Gestión – Herramientas de software para gobernar y controlar todos los niveles de pila descritos anteriormente. Estas herramientas son indispensables, sobre todo cuando crece el número de sistemas. Para ello, mantener el ejemplo con nuestro PC es más difícil, pero podemos hacer la analogía con la Gestión de Tareas de Windows.

Seguridad – Este es un nivel que ha visto aumentar exponencialmente su importancia en los últimos veinte años. Se ocupa de proteger los datos de accesos no deseados(confidencialidad), mantenerlos válidos(integridad) y disponibles(disponibilidad).

Se trata de dos niveles muy importantes y vitales, el primero a medida que aumenta la complejidad, el segundo siempre.

¿Dónde está?

¿Dónde está este modelo en la realidad? ¿Qué sistemas puede representar este modelo?

El primer ejemplo que tenemos delante es nuestro PC o Mac con Windows. El hadware es lo que se enciende y el sistema operativo es Windows o MacOS. De middleware real no tenemos ninguno, conceptualmente conviene usar Excel como ejemplo, pero en realidad Excel también es una aplicación.

Tenemos muchas aplicaciones en nuestro PC: para el correo electrónico, para escuchar música, para ver o editar fotos, para escribir, etc.

El otro lugar donde este modelo se materializa es en los centros de datos de las empresas. Dentro de ellos hay a menudo miles de servidores que podemos ver representados de esta manera.

Obviamente, los elementos de estos entornos son diferentes como tecnologías de software. Todos ellos están orientados a la prestación de servicios de aplicación.

Como hardware, hay dispositivos de clase empresarial que difícilmente podrían funcionar en casa, ya sea por los requisitos de alimentación o refrigeración.

Entre los Sistemas Opearativos encontramos Windows pero en una configuración totalmente diferente a la que estamos acostumbrados a utilizar en nuestros PCs. Luego hay muchos tipos de Lunux como Debian, Ubuntu, RedHat, CentOS e incluso algunos dedicados a hardware específico como AIX de IBM.

El middleware desempeña el papel principal, tenemos Apache HTTP, Apache Tomcat, Nginx para que las páginas web estén disponibles y para ejecutar proyectos capaces de interactuar con ellas, pero también middleware para construir bases de datos como MySQL, PostgresQL, Oracle. Microsoft SQL Server o IBM DB2

La pila de infraestructuras: cómo ha evolucionado

Para cada nivel se pueden elegir diferentes opciones tecnológicas. Pero no hay que olvidar que una decisión tomada en un nivel puede influir o limitar los demás niveles. Por ejemplo, si decides utilizar el software MS SQL Server para tus bases de datos, estás obligado a utilizar Windows como sistema operativo.

Para superar estas limitaciones, con el tiempo se introdujeron nuevas tecnologías para desvincular un nivel del otro. En los primeros años del nuevo siglo, la
tecnología de virtualización
.

Mediante el software de virtualización, el hardware se abstrae, es decir, los sistemas operativos se instalan dentro de máquinas virtuales, que a todos los efectos se comportan como el hardware real. La tarea del virtualizador es gestionar los distintos dispositivos y asignarles recursos como procesador, memoria, discos y puertos de red, optimizándolos.

Las dos ventajas inmediatas de los centros de datos llenos de servidores eran:


  1. Optimización de los recursos de hardware
    – Los servidores físicos asignados a un sistema, pero sólo utilizados en un 10% eran una realidad generalizada que desaparecía en 3-5 años.

  2. Mejorar las actividades de gestión
    – de hecho se ha producido un salto de época en este campo. Si antes una aplicación necesitaba un sistema de pruebas, podían pasar hasta meses antes de que se adquiriera el hardware necesario, se instalara y configurara como requería la aplicación. Con la virtualización, un simple comando permite clonar un entorno existente en cuestión de minutos.

En resumen, los virtualizadores han logrado un “enmascaramiento” del hardware a niveles superiores. Podemos añadir nuevos servidores a los virtualizadores modernos y ellos se encargarán de distribuir los recursos de forma transparente a los sistemas que tengan por encima.

Entre 2008 y 2015 se produjo otra innovación, de nuevo vinculada al concepto de virtualización: los contenedores. Nacidos conceptualmente para crear un entorno perfectamente aislado para una aplicación, virtualizan de hecho los Sistemas Operativos.

El concepto de contenedor es crear una unidad estandarizada de software que agrupe el código de la aplicación junto con todas sus dependencias (como bibliotecas, frameworks y herramientas del sistema) en un único paquete. Esto permite que la aplicación se ejecute de forma fiable y coherente en cualquier entorno informático, ya sea un ordenador personal, un servidor en un centro de datos o una instancia en un entorno de nube.

¿Es una coincidencia que la explosión de los servicios en la nube no empezara hasta después de 2007?

Arquitectura de software (y otras reflexiones)

Algunos promotores piensan que los temas de la parte de infraestructuras no son de su interés y no les conciernen. Quien tenga esta idea, ¡que haga sonar las sirenas de alarma y empiece a pensar! Quienes diseñan una aplicación están llamados, en mayor o menor medida, a tomar decisiones que influirán en la calidad del resultado, independientemente de cómo esté escrita la aplicación.

Un modelo de arquitectura de software

Estas son las decisiones que perfilan la
arquitectura del software
de la que una muy buena definición es esta:

La arquitectura de software es el conjunto de decisiones de diseño
que, si se hacen incorrectamente, pueden hacer que su proyecto
cancelarse.

Eoin Woods

Transmite bien el concepto de lo importante que es definir una arquitectura adecuada que no nos lleve a arriesgarnos a rehacerlo todo desde el principio. Así que las dos preguntas fundamentales son: ¿Qué debe incluir una arquitectura? ¿Con qué fin? El objetivo principal es
establecer y describir, en su conjunto, la estructura del programa informático
. Pero qué debe describirse y con qué nivel de detalle es también una elección que hay que hacer. Existe una enorme bibliografía para orientarnos en esta elección.

Para lo que es funcional para nuestra evaluación del low-code, simplificamos la arquitectura, de forma no académica y totalmente genérica, en un modelo que describe las principales áreas en las que dividimos una aplicación.

Lógica de presentación – Es la parte en la que se construye la interfaz con el usuario-humano. Se perfeccionan los mecanismos de interacción con la aplicación. Esto es importante porque tener capacidades de procesamiento complicadas de usar es un requisito previo para el fracaso del software.

Lógica empresarial: encapsula todos los mecanismos que permiten realizar la funcionalidad requerida. En este nivel se encuentran los cálculos, verificaciones, comprobaciones y validaciones de los datos de entrada. Pero también el tipo y la organización de las posibles operaciones. Es decir, los flujos de trabajo con los que se opera y la definición de las funciones de los distintos usuarios que realizan las operaciones. Es la lógica impulsada principalmente por el ámbito al que se dirige el software diseñado. Así, por ejemplo, una aplicación para hacer declaraciones de la renta tendrá un conjunto de operaciones y un control totalmente distintos a los de una para gestionar un almacén o una consulta médica.

Lógica de datos – Es la lógica con la que se almacenan los datos, ya sea de forma persistente dentro de las bases de datos o de forma temporal para su uso en diferentes operaciones. Esta área define los datos necesarios para las operaciones y cómo se representan.

¿Cómo encaja en la infraestructura?

Lo que podría parecer un paso sencillo, es decir, situar las áreas de nuestro modelo de arquitectura dentro de la infraestructura, es otra elección arquitectónica. Veámoslo para cada aspecto lógico de nuestro modelo.

Dónde implantar Presentation Logic es una elección que limita o se ve limitada por la infraestructura. De hecho, si queremos utilizar páginas dinámicas con el lenguaje PHP, tendremos que disponer de un Middleware que lo permita. Si, por el contrario, optamos por realizar esta parte de forma que todo resida en el navegador de los usuarios. podríamos desarrollarlo todo en Javascript.

Para Business Logic hay más posibilidades de colocación. Podemos codificarlo en el navegador, de nuevo utilizando Javascript; en el Middleware que realiza el diálogo web, utilizando PHP, Java u otros lenguajes; o dentro del Middleware de las bases de datos con scripts o procedimientos SQL. También directamente en el sistema operativo, con scripts y tareas programadas (personalmente, es una opción que encuentro anticuada y que hay que evitar en la medida de lo posible). Difícilmente toda la lógica empresarial se realiza en una sola capa de infraestructura, pero se aprovechan las ventajas de cada una para lograr el mejor resultado.

El aspecto de los datos a simple vista parece sencillo: tenemos bases de datos, así que dependiendo del Middleware utilizado para la estructura de nuestra base de datos (no en vano se llaman DBMS, DataBase Management System) describimos nuestros datos en tablas y relaciones y ya está. Nada más lejos de la realidad. Los datos utilizados en las aplicaciones tienen vida propia y se emplean en distintas operaciones, por lo que su ubicación vuelve a ser una elección no tan obvia.

Por lo tanto, la lógica de datos se ubicará en gran medida en el middleware de base de datos, para los datos que necesiten persistencia entre diferentes operaciones, sesiones y usuarios. Sin embargo, muchos suelen colocar algunos datos persistentes directamente en el sistema operativo. Dos ejemplos bien conocidos son el sistema de gestión documental Alfresco (ahora de Hyland), que almacena todos los documentos en un árbol de subcarpetas prácticamente imposible de navegar. O el más conocido sistema de gestión de contenidos WordPress para crear sitios web, que organiza gran parte de su contenido en subcarpetas tan fáciles de navegar que deben protegerse adecuadamente de accesos no deseados.

Ciertas estructuras de datos, normalmente las que cobran vida en las interacciones de los usuarios, pueden realizarse en los navegadores de quienes acceden a la aplicación.

¿Qué es la arquitectura de software? ¿Es lo mismo que la arquitectura de aplicaciones?

Es extraño poner este título en último lugar, pero instrumentalmente hemos construido un modelo de arquitectura de software sin darle una definición. Más bien hemos esbozado niveles, que son bastante comunes y fáciles de entender, para comprender cómo se relacionan con la infraestructura. Pero, ¿es ésta la arquitectura del software? Podemos ver esto como la descripción:


  • estructura de alto nivel de un sistema de software
    . Esto incluye las decisiones relativas a la división del sistema en componentes y la definición de las responsabilidades, funcionalidades e interacciones de cada componente.

  • organización y disposición de las partes del software
    como módulos, componentes, interfaces y datos, para satisfacer requisitos específicos del proyecto.

  • opciones que dan lugar a directrices y restricciones para la codificación de software
    .

Pero no hablamos de patrones, de qué bibliotecas, qué frameworks utilizar, de cómo organizar nuestro software en componentes (o módulos, o clases, o funciones, o lo que prefieras…), de cómo nuestro software debe integrarse con otros. En resumen, parece que faltan muchas cosas.

No faltan en la Arquitectura de Software, sino que pertenecen a otra arquitectura más específica denominada Arquitectura de Aplicaciones. podemos ver esta última como una serie de opciones que abordan aspectos más detallados que varían en función de las necesidades específicas de la aplicación. Por ejemplo:

  1. Estructura y Componentisación:
    • Definición de componentes de la aplicación, como módulos, servicios, bibliotecas, etc.
    • División de la aplicación entre niveles lógicos (por ejemplo, presentación, lógica empresarial, acceso a datos).
  2. Comunicación e integración:
    • Modelos de comunicación interna y externa (por ejemplo, REST API, SOAP, gRPC).
    • Integración con sistemas externos, como bases de datos, servicios web o sistemas ERP.
  3. Gestión de datos:
    • Esquema de base de datos y estrategias de acceso a datos (ORM, Direct SQL, NoSQL, GraphQL).
    • Políticas de gestión de transacciones e integridad de datos.
  4. Interfaz de usuario:
    • Diseño de interfaz de usuario y experiencia de usuario (UI/UX).
    • Frameworks y tecnologías para la realización de interfaces (React, Angular, Vue.js).
  5. Seguridad:
    • Autenticación, autorización y control de acceso.
    • Protección de datos y cumplimiento de la normativa sobre privacidad (GDPR, HIPAA).
  6. Rendimiento y escalabilidad:
    • Optimización del rendimiento y gestión de la carga.
    • Escalabilidad horizontal y vertical, equilibrio de carga.
  7. Fiabilidad y disponibilidad:
    • Estrategias para la gestión de errores y la resistencia de las aplicaciones.
    • Copias de seguridad, recuperación en caso de catástrofe y alta disponibilidad.
  8. Mantenibilidad y Evolucionabilidad:
    • Prácticas de desarrollo para facilitar el mantenimiento y la evolución del software (por ejemplo, programación modular, uso de patrones de diseño).
    • Documentación y normalización del código.
  9. Despliegue y gestión del entorno:
    • Estrategias de despliegue (integración continua/despliegue continuo).
    • Gestión de la infraestructura y del entorno de ejecución (nube, local).
  10. Cumplimiento y normas:
    • Cumplimiento de las normas y protocolos del sector.
    • Cumplimiento de la normativa y las mejores prácticas del sector.

Uno se da cuenta de que hay una diferencia, en contenido y propósito, entre arquitectura de software y arquitectura de aplicaciones. Pero esta diferencia es una zona gris, que ni el mundo académico ni el de los fabricantes de software delimitan con claridad y sin ambigüedades. La misma jerarquía entre los dos términos se considera a menudo a la inversa, de modo que la parte de descripción del software no es siempre, ni necesariamente, una visión más general de la descripción de la aplicación. Es una cuestión de terminología, los que utilizan software como término más genérico que el de aplicación, y los que lo utilizan al revés. La tan cacareada Wikipedia recoge, sin fuente, esta definición:

La arquitectura de las aplicaciones define cómo están preparadas las múltiples aplicaciones para trabajar juntas. Es diferente de la arquitectura de software, que se ocupa de los diseños técnicos de cómo se construye un sistema.

WikiPedia

Me parece lógico considerar los dos términos con estos significados:

Software: el término “software” es un término genérico que hace referencia a cualquier programa o conjunto de instrucciones ejecutadas en un ordenador. Incluye
todo lo que no es físico y es necesario para realizar una función en un ordenador
como sistemas operativos, utilidades, programas de tratamiento de textos, juegos y códigos de bases de datos.

Aplicación (App): Una aplicación, a menudo llamada “app”, es
un tipo de software diseñado para ayudar al usuario a realizar tareas específicas
. Las aplicaciones tienen usos más específicos que el software en general y suelen estar diseñadas con una interfaz de usuario que facilita estas actividades, como editar documentos, navegar por Internet o gestionar el correo electrónico.

Omitiremos aquí la arquitectura de la aplicación, ya que no queremos hacer un texto académico sobre arquitecturas. Sólo necesitamos tener una idea general, para poder hacer evaluaciones meditadas del mundo del bajo código.

Otros aspectos (que pasamos por alto) del desarrollo de aplicaciones

Metodología de desarrollo

Modelos y arquitecturas aparte, en el desarrollo de aplicaciones hay otro aspecto fundamental que no debe pasarse por alto:
la metodología de desarrollo
. Yo lo veo como la arquitectura de los aspectos humanos del desarrollo de aplicaciones.

Sin entrar en cuestiones de psicología o inteligencia emocional, hay elementos puramente humanos que deben gobernarse y coordinarse para garantizar el avance de las actividades de desarrollo. Cómo comunicarse dentro del equipo; cómo comunicarse con el exterior; cómo, si y cuándo compartir los problemas que surgen en el desarrollo de aplicaciones; cómo resolver desacuerdos, etc.

Leo el intento de abordar estos aspectos en las metodologías de desarrollo que pueden ser explícitas y declaradas (“seguimos la metodología ágil”) o implícitas con un conjunto de normas y procedimientos utilizados “por tradición”. Pero pueden ser antiguos (“nos ceñimos al horario o al gantt”) o modernos.

Metodología de pruebas y transición a la producción

Una vez que hemos desarrollado nuestra aplicación, ¿cómo la probamos? ¿cómo está disponible? Estos aspectos no son tan obvios para los desarrolladores unipersonales, pero para los equipos de desarrollo articulados y las aplicaciones complejas son muy delicados. Y para mí un equipo de desarrollo articulado es un equipo de más de tres personas.

En resumen bajo el nombre de
Metodología de las pruebas
están los procedimientos que definen quién, cómo, dónde y por qué deben realizarse las pruebas:

  • porque -suena ingenuo pero es lo primero que, incluso de forma no explícita, se establece. Solemos decidir realizar las pruebas “para saber que todo va bien”. Pero los objetivos podrían ser: ver que no hay errores en la ejecución del código; comprobar que se cumplen los requisitos; evaluar el rendimiento; evaluar cuántos usuarios podemos tener.
    La razón también puede ser negativa. NO realizamos pruebas: porque cuesta demasiado; porque no tenemos datos con los que realizarlas; porque no se dispone de un entorno de pruebas; etc.
  • who – identifica trivialmente quién realiza las pruebas para decir que la aplicación puede estar disponible (pasar a producción).
  • cómo – definir cómo probar una aplicación y qué pruebas llevar a cabo es quizá la parte más delicada, porque cuanto más se defina formalmente este aspecto, más justificado estará no profundizar o ampliar las pruebas.
  • dónde: ¿necesita distintos entornos para probar distintos aspectos? Recuerdo a un cliente que, además del entorno de desarrollo, tenía estos entornos: pruebas funcionales, pruebas de integración, pruebas de regresión, pruebas de calidad, pruebas de usuario y formación. Había un entorno dedicado a la formación de usuarios, de modo que para cada línea de aplicación había un entorno de producción, uno de desarrollo, cinco de prueba y uno de formación.

La complejidad de los diferentes entornos hace necesaria, no tanto para el desarrollo inicial como para el desarrollo de modificaciones, una
metodología de transición a la producción
. Imaginemos que tenemos que hacer un cambio en la aplicación del ejemplo anterior: el cambio debe aplicarse a seis entornos antes de aplicarse en producción. Los entornos no pueden modificarse de forma improvisada y sin planificar.

Las metodologías de desarrollo, testing y passing on son otros temas en los que no profundizamos aquí, sino que sólo queremos situar correctamente porque, queremos entender si están influenciadas, o no, por el mundo del low-code.

Los que tengan más experiencia, en cambio, pueden saltarse estas descripciones porque entenderán muy bien los modelos utilizados. A estos últimos les pido indulgencia consciente. Es decir, les pido que no se centren en las deficiencias de los modelos propuestos. No son modelos para guiar a un equipo de desarrollo, son recintos en los que situar nuestras consideraciones para hacer comparables a los distintos miembros del mundo del bajo código. Aunque las innovaciones en los componentes de infraestructura han introducido una mayor flexibilidad, éstas no han influido significativamente en las metodologías de desarrollo de aplicaciones. La ventaja de la abstracción entre los distintos niveles se limita esencialmente a los sistemas operativos. De hecho, no existe ninguna virtualización capaz de liberarnos de las restricciones y limitaciones inherentes al desarrollo de aplicaciones. La flexibilidad de la infraestructura sirvió a los equipos de desarrollo para eliminar lentitudes que lastraban el proceso de desarrollo pero que no tenían nada que ver con él. La posibilidad de clonar entornos enteros para convertirlos en entornos de laboratorio sobre los que realizar pruebas, la posibilidad de establecer un momento en el tiempo de los propios sistemas (snapshot) y poder volver a ese momento, han sido formidables herramientas de eficacia para los equipos de aplicación, pero no han cambiado, ni mucho menos, su forma de desarrollar.

¿Cuál es el objetivo de las plataformas de bajo código?

Aunque cada plataforma tiene un enfoque específico, podemos afirmar, a riesgo de causar decepción entre los programadores experimentados, que la intención principal del código bajo es la siguiente:

Objetivos del low-code

hacen que las actividades, del desarrollador de la aplicación, se centren únicamente en la finalidad de la propia aplicación, eliminando todos los esfuerzos y el tiempo debidos a los aspectos tecnológicos del entorno en el que se ejecutará la aplicación.

El hecho de que esta simplificación se aplique en todos los aspectos o sólo en algunos caracteriza y diferencia a las plataformas de bajo código. Hay plataformas de bajo código que sólo se ocupan de la lógica empresarial, otras que sólo se ocupan de aspectos de la comunicación entre distintas aplicaciones. El panorama de las ofertas de bajo código es inmenso.

A evitar

Considerar el low-code como un mero sustituto de la programación, rechazarlo o utilizarlo como un atajo hacia el conocimiento del lenguaje de programación.

Para entender cuántas y qué tipos de plataformas de bajo código existen, un buen punto de partida es el sitio NoCodeJournal, en su página State of Nocode. Iniciado en 2021, este proyecto pretende enumerar y actualizar todas las plataformas de bajo código disponibles. Es una tarea difícil, porque el sector está en rápido movimiento: constantemente surgen nuevas plataformas, mientras que otras desaparecen con la misma rapidez. Aunque no está actualizada, la web da una idea de la enorme variedad y dinamismo de este interesante sector tecnológico.

Cómo analizar las plataformas de bajo código

Hoy no hablaremos de las mejores plataformas xx low-code de 2023. Veamos más bien cómo analizar algunas de estas plataformas.

Las plataformas que examinaremos no son necesariamente las más populares o las mejores en términos de velocidad, facilidad de uso, etc. Son simplemente las que he tenido la oportunidad de probar personalmente durante un periodo de tiempo suficiente para realizar un análisis en profundidad. Son simplemente los que he tenido la oportunidad de probar personalmente durante un periodo de tiempo suficiente para realizar un análisis en profundidad. Me he centrado en plataformas que ofrecen planes gratuitos o que me han permitido utilizarlas el tiempo suficiente para entender sus características y funcionalidades.

Criterios de análisis

Examinemos ahora los criterios de análisis y evaluación de las plataformas de bajo código, completando los modelos ya mencionados con otros factores como el coste, el soporte, etc. La intención es definir un método de análisis que facilite futuras evaluaciones.

Creo que no se puede juzgar una plataforma, o más en general un software, sin considerar primero el contexto específico en el que se utilizará. Este contexto incluye las necesidades que hay que satisfacer, el tipo de usuarios de la aplicación y el presupuesto disponible. Dado que el contexto puede cambiar drásticamente, las clasificaciones generales en Internet no suelen ser especialmente útiles para orientar la elección.

El modelo propuesto para el análisis es el siguiente:

Las zonas utilizadas para el análisis son:

Funcionalidad de desarrollo
  • Lógica de presentación: funcionalidad proporcionada para la realización de la interfaz de usuario.
  • Lógica empresarial: funcionalidad proporcionada para la realización de flujos de trabajo, controles de transacciones y datos y eventos.
  • Lógica de datos: funcionalidad disponible para la realización de estructuras de datos.
  • Documentación: funcionalidad disponible para describir y hacer comprensible cómo se desarrolla la aplicación y cuáles son sus dependencias internas.
Portabilidad
  • Portabilidad de datos: funcionalidad disponible para extraer datos de la aplicación.
  • Integración externa: funcionalidad puesta a disposición para la realización de integraciones con servicios o aplicaciones externas.
  • Infraestructura: tipo de infraestructura en la que puede ejecutarse la aplicación producida.
Seguridad
  • Seguridad – funcionalidad prevista para la aplicación de mecanismos de seguridad
  • Pruebas y despliegue: funciones previstas para las pruebas y la gestión de los entornos de producción.
Otros servicios
  • Soporte: cómo se accede al soporte de la plataforma.
Costes
  • Modelo de precios: los mecanismos que influyen en el precio

Conclusiones

Una vez definido el modelo, sólo queda ponerlo a prueba. Así que empezaré a evaluar algunas plataformas, pero la verdadera prueba serán los comentarios y las críticas. No tanto para ver si es bueno, sino para identificar cómo se puede mejorar.

Referencias útiles para profundizar en el tema.

more insights