Aplicaciones de negocios CRUD

Por Joannes Vermorel, febrero de 2023

Desde los años 80, la gran mayoría de las aplicaciones de negocios han ido adoptando un diseño interno similar: CRUD, que es el acrónimo que forman las palabras Create (crear), Read (leer), Update (actualizar) y Delete (eliminar), las operaciones fundamentales de estas aplicaciones. Este diseño refleja la adopción de un base de datos relacional para almacenar los datos de negocios de forma persistente. El diseño CRUD ha logrado sobrevivir al paso de varios importantes avances tecnológicos, desde las terminales de consola que se conectaban a grandes sistemas principales hasta las aplicaciones móviles que se conectan a plataformas en la nube. Comprender el diseño CRUD es importante en campos complejos como el de la cadena de suministro, que generalmente funcionan sobre un entorno aplicativo formado por aplicaciones CRUD. Esta información es esencial para conducirse adecuadamente en este entorno, ya sea para negociar con proveedores de software como para aprovechar las entradas de datos recopilados a través de estas aplicaciones.

Resumen    Aplicaciones CRUD en la cadena de suministro    Los beneficios de CRUD    Los límites de CRUD    Tipos de CRUD modernos    Dinámica de proveedores    La solución de Lokad    Notas

Resumen

Para principios de los años 80, las bases de datos relacionales ya se habían establecido como método dominante para almacenar datos de negocios y acceder a ellos. Para fines de los años 90, las nuevas bases de datos relacionales de código abierto habían consolidado aún más esta práctica. En la actualidad, el diseño CRUD representa la forma más utilizada para desarrollar una aplicación de negocios sobre una base de datos relacional.

Una base de datos, en el sentido relacional, incluye una lista de tablas. Cada tabla incluye una lista de columnas (a las que también se denomina campos). Cada campo viene con un tipo de dato: número, texto, fecha, etc. Una tabla contiene una lista de líneas (también llamadas filas). Como regla general, se espera que la cantidad de columnas sea limitada, unas cien como máximo, mientras que la cantidad de líneas no tiene límite y puede potencialmente llegar a los miles de millones.


En la práctica, el enfoque relacional necesita varias tablas para reflejar algo que pueda ser de interés comercial (por ej., pedidos de compra). Estas "agrupaciones" de tablas se conocen como entidades. Una entidad refleja la comprensión de alto nivel de un negocio.


Como se mencionaba anteriormente, CRUD es el acrónimo de Crear, Leer, Actualizar y Eliminar, las cuatro operaciones fundamentales que se realizan en las tablas dentro de una base de datos relacional.

• Crear: agregar nuevas líneas a la tabla.
• Leer: recuperar líneas existentes de la tabla.
• Actualizar: modificar líneas existentes de la tabla.
• Eliminar: eliminar líneas existentes de la tabla.
  

Estas operaciones se realizan hoy en día a través de un lenguaje de base de datos específico, casi siempre un dialecto de SQL (Structured Query Language o lenguaje de consulta estructurado)^[1].

El diseño CRUD consiste en introducir entidades junto con sus contrapartes de lado de la interfaz de usuario, que a menudo se denominan "pantallas". Una pantalla, que puede ser una página web, generalmente incluye las cuatro operaciones para la entidad en cuestión.

La gran mayoría de las aplicaciones de negocios "transaccionales", desde un simple medidor de tiempo hasta un ERP o un CRM complejo, adoptan un diseño CRUD similar, un patrón de diseño que se estableció hace más de cuatro décadas. Las aplicaciones simples incluyen solo unas pocas entidades, mientras que las complejas pueden incluir miles. No obstante, ya sean simples o complejas, en términos de diseño subyacente, es todo más de lo mismo.

La diversidad de interfaces de usuario que presentan las aplicaciones de negocios puede ser engañosa, ya que puede dar la impresión de que tienen poco en común entre ellas. Sin embargo, en la práctica, la mayoría de las aplicaciones tienen un diseño interno casi idéntico alineado con la perspectiva CRUD.

Aplicaciones CRUD en la cadena de suministro

Casi todas las aplicaciones (expuestas a usuarios finales) que se usan para operar empresas y sus procesos son CRUD. En general, si un software empresarial contiene un acrónimo de tres letras, como ERP, MRP, CRM, SRM, PLM, PIM, WMS, OMS, EDI, etc., es casi seguro que se implementa como CRUD. La excepción más notable a esta regla son los editores de documentos (por ej., software de hojas de cálculo), que representan un tipo completamente diferente de tecnología de software.

Internamente, el departamento de TI usa una amplia variedad de tecnologías que no son CRUD: funciones de red, virtualización, herramientas de administración de sistemas, etc. Sin embargo, estas tecnologías tienden a ser casi invisibles o muy discretas a los ojos de los usuarios finales.

Estas aplicaciones CRUD contienen casi todos los datos transaccionales históricos relevantes que pueden aprovecharse para mejorar cuantitativamente la cadena de suministro (por ejemplo, optimización de niveles de stock). Por eso, muchas aplicaciones CRUD intentan^[2], en algún momento, desviarse hacia funciones analíticas (como la planificación o la optimización). Lamentablemente, si bien el diseño CRUD tiene muchas ventajas, también viene con significativas limitaciones en lo que a funciones analíticas se refiere (ver "Los límites de CRUD" más abajo).

Los beneficios de CRUD

CRUD es, desde hace décadas, el método preferido para las aplicaciones de negocios. Desde un punto de vista tecnológico, este abordaje goza del beneficio de marcos y herramientas integrales de código abierto en todas las estructuras de software más importantes. Como resultado, esta ruta tecnológica está excepcionalmente bien definida. Además, CRUD también saca provecho de herramientas de desarrollo de alta calidad y, como resultado, la productividad tiende a ser alta para los ingenieros de software involucrados en el desarrollo de una aplicación basada en CRUD.

Desde una perspectiva de personal necesario, el mercado de ingenieros de software con experiencia en CRUD es muy amplio. Además, CRUD se encuentra entre las partes más accesibles del desarrollo de software, en gran medida gracias a sus herramientas de desarrollo de alta calidad. Como resultado, CRUD es extremadamente accesible incluso para ingenieros de software junior (y para ingenieros sénior menos talentosos). Los principios subyacentes de CRUD se han mantenido estables durante décadas, por lo que la transición hacia una estructura tecnológica más nueva puede hacerse con relativa facilidad, al menos cuando se lo compara con otros métodos que requieren un mayor dominio de la tecnología.

Por último, desde una perspectiva de continuidad del negocio, CRUD ofrece todos los beneficios asociados con su base de datos relacional subyacente. Por ejemplo, mientras la base de datos sea accesible para la empresa cliente, los datos seguirán siendo accesibles; esto es así incluso si el proveedor original de la aplicación CRUD deja de operar o cooperar con la empresa cliente. Incluso en ese caso extremo, será posible acceder a los datos con esfuerzos relativamente moderados de ingeniería inversa.

Los límites de CRUD

Las aplicaciones CRUD presentan limitaciones vinculadas con con la forma en que aprovechan la base de datos relacional que contienen. Estas limitaciones no pueden superarse sin renunciar a los beneficios mismos que CRUD ofrece. Estas limitaciones entran en dos grandes categorías: expresividad y rendimiento.

La limitación de expresividad refleja el hecho de que las cuatro acciones (o "verbos") —crear, leer, actualizar y eliminar— no pueden captar adecuadamente una serie de intenciones más granulares. Por ejemplo, consideremos una situación en la que un empleado busca eliminar varias entradas duplicadas de varios proveedores que se crearon por error en el SRM (software de gestión de relaciones con proveedores). El verbo apropiado para esta operación sería fusionar. Sin embargo, el diseño de CRUD no tiene este verbo. De hecho, esta función solo puede implementarse como un proceso de dos pasos. Primero, se actualizan todas las líneas que solían llevar a las entradas de proveedores que se eliminarán, de modo que ahora lleven a la que se mantendrá. Segundo, se eliminan todas las entradas adicionales del proveedor menos una. No solo la intención original (la de fusionar) se pierde, sino que la transformación es destructiva en términos de datos. A título anecdótico, cuando las aplicaciones CRUD les advierten a sus usuarios que están a punto de hacer cambios irreversibles en los datos, se trata casi siempre de una limitación de CRUD^[3] que se entromete en la experiencia del usuario.

La limitación de "rendimiento" refleja el hecho de que cualquier operación prolongada —es decir, cualquier operación que lea más que una pequeña fracción de la base de datos— pone a la aplicación CRUD en riesgo de volverse incapaz de responder. De hecho, los usuarios finales esperan que la latencia de una aplicación CRUD sea casi imperceptible para casi todas las operaciones de rutina. Por ejemplo, actualizar un nivel de stock en el WMS (Sistema de gestión de almacenes) debería ser algo que toma milisegundos (para que las operaciones continúen de modo fluido). Debido a que todas las operaciones que se le dan a la aplicación CRUD consumen recursos informáticos de la misma base de datos relacional subyacente, casi todas las operaciones no triviales ponen este núcleo en riesgo de quedarse sin recursos informáticos. A título anecdótico, en las grandes empresas, las aplicaciones CRUD a menudo pierden la capacidad de respuesta durante segundos (o incluso minutos) cada vez. La causa de estas situaciones casi siempre son causadas unas pocas operaciones "pesadas" que acaban monopolizando recursos informáticos durante un período breve, con lo que retrasan todas las demás operaciones, incluidas aquellas "livianas". Este problema explica por qué las operaciones no triviales a menudo se segregan en trabajos en lote que se ejecutan durante la noche. Y también explica por qué las aplicaciones CRUD se consideran malas en las analíticas, porque no es práctico que las cargas de trabajo analítico se ejecuten solo fuera del horario laborable.

Tipos de CRUD modernos

Durante las últimas décadas, el software empresarial ha evolucionado enormemente. Durante los años 90, la mayoría de las aplicaciones pasaron de terminales de consola a interfaces de usuario de escritorio. A partir del año 2000, la mayoría de las aplicaciones pasaron de interfaces de usuario de escritorio a interfaces de usuario web. En la última década, la mayoría de las aplicaciones pasaron a SaaS (software como servicio) y migraron hacia la computación en la nube en el proceso. Sin embargo, estas evoluciones prácticamente no modificaron el diseño CRUD.

La transición del entorno de arrendatario único al de multiarrendatario^[4] obligó a los proveedores de software a limitar el acceso a entidades a través de API (interfaces de programación de aplicaciones). De hecho, el acceso directo a la base de datos, incluso de solo lectura, podría agotar los recursos informáticos del núcleo transaccional con solo una pequeña cantidad de solicitudes pesadas. La API mitiga este tipo de problema. Limitar el acceso a los datos de la aplicación a través de una API también elimina algunos de los beneficios de CRUD, al menos en lo que se refiere a la empresa del cliente. Extraer de modo fiable muchos datos de una API en general requiere mucho más esfuerzo que componer una serie comparable de solicitudes SQL. Además, la API podría estar incompleta —y no exponer datos que existen en la aplicación—, aún cuando, por diseño, la base de datos hubiera debido otorgar acceso total a los datos.

La principal evolución de CRUD se encuentra en las herramientas. Durante la década de 2010, surgieron numerosos ecosistemas de código abierto de alta calidad para respaldar el desarrollo de aplicaciones CRUD. Estos ecosistemas han comoditizado en gran medida el desarrollo de aplicaciones CRUD, lo que a su vez ha reducido significativamente las habilidades necesarias para desarrollarlas y las fricciones asociadas con el proceso de desarrollo.

Dinámica de proveedores

El costo del desarrollo de una aplicación CRUD depende principalmente de la cantidad de entidades. Cuanto mayor es el número de entidades, más pantallas deben desarrollarse, documentarse y mantenerse. Por eso, el recorrido natural de un proveedor de software que promociona una aplicación CRUD consiste en comenzar con una cantidad limitada de entidades e ir agregando más con el tiempo.

Agregar entidades habilita nuevas funciones y le da al proveedor la oportunidad de subir los precios para reflejar el valor adicional creado para la empresa cliente. Además, los módulos^[5], es decir, los conjuntos de entidades relacionadas con el negocio, generalmente se introducen como mecanismo de fijación de precios para cobrar más (dependiendo de la medida en que se use el software).

Como resultado, las aplicaciones CRUD tienden a volverse cada vez más complejas con el tiempo, pero también menos relevantes. De hecho, a medida que se agregan más entidades en el interés de toda la base de clientes, muchas (si no la mayoría) de las entidades que se agregan no resultan relevantes para ninguna empresa individual. Estas entidades "muertas" —desde el punto de vista de la empresa cliente— representan una creciente complejidad accidental que contamina el CRUD.

Las aplicaciones CRUD que se venden como SaaS tienden a volverse más costosas a medida que crecen en capacidad y notoriedad. Sin embargo, debido a que prácticamente no hay barreras para ingresar al mercado^[6], con frecuencia aparecen nuevos proveedores, cada uno de los cuales se concentra en casos de uso específicos a precios más bajos, y el ciclo se repite al infinito.

La solución de Lokad

Muchas, si no la mayoría, de las grandes empresas subestiman el grado de comoditización de las aplicaciones CRUD. Para la mayoría de los proveedores de software que las venden, el costo de desarrollo no representa más que una pequeña fracción del gasto total de la empresa, muy por debajo de los costos de marketing y venta de la aplicaciones en sí. En particular, los proveedores que desarrollan aplicaciones CRUD a menudo deslocalizan sus equipos de ingeniería en países de bajo costo, ya que el método CRUD (debido a su accesibilidad) puede permitirse un personal de ingeniería menos talentoso (y menos costoso).

Hay pocos motivos hoy en día para pagar cifras exorbitantes por aplicaciones CRUD. Como regla general, cualquier aplicación CRUD que cueste más de USD 250 000 por año es una buena candidata a ser reemplazada por un software interno. Cualquier aplicación CRUD que cueste más de USD 2,5 millones por año debería, casi sin lugar a dudas, reemplazarse por un software interno (posiblemente comenzando con una base preexistente de código abierto que luego se personalice).

Los proveedores de software empresarial que venden aplicaciones CRUD conocen muy bien y desde hace tiempo esta cuestión. Por eso, resulta tentador para el proveedor agregar funciones/aplicaciones/elementos no CRUD^[7] a la solución e intentar convencer a los clientes (a) de que estas piezas son importantes y (b) de que representan algún tipo de "receta secreta" que el cliente no puede replicar. Sin embargo, este abordaje casi nunca tiene éxito, principalmente porque el proveedor no tiene el ADN de ingeniería adecuado^[8]. A título anecdótico, casi todos los ERP conocidos y establecidos tienen amplias funciones de pronóstico y planificación, la mayoría de las cuales casi no se utilizan debido a lo mal que realizan estas tareas.

Lokad es un proveedor de software empresarial que se especializa en la optimización predictiva de la cadena de suministro. Nuestra tecnología ha sido diseñada para aprovechar los datos transaccionales históricos, el tipo de datos que pueden extraerse de las aplicaciones CRUD que respaldan las operaciones diarias de una empresa. Sin embargo, Lokad en sí no es una aplicación CRUD. Nuestro entorno de producción ni siquiera incluye una base de datos relacional. Si bien CRUD es una respuesta tecnológica válida para la gestión de los flujos transaccionales de una empresa, no tiene relevancia alguna para el modelado predictivo ni para la optimización matemática de una cadena de suministro.

Notas

1. Cada proveedor de base de datos tiende a tener su propio dialecto de SQL. Los detalles de la sintaxis varían entre uno y otro, pero estos lenguajes son muy similares. Existen herramientas para traducir automáticamente entre dialectos.

2. El acrónimo ERP corresponde a Enterprise Resource Planning (planificación de recursos empresariales). Sin embargo, es un nombre equívoco, Este tipo de software empresarial debería llamarse Enterprise Resource Management (gestión de recursos empresariales). De hecho "planificación" fue un término introducido en los años 90 como truco publicitario por algunos proveedores de software para diferenciarse a través de la introducción de funciones analíticas. No obstante, tres décadas después, los ERP siguen siendo poco adecuados para las cargas de trabajo analítico, precisamente debido a su diseño CRUD.

3. Con suficiente esfuerzo, es posible hacer que todas las operaciones sean reversibles con CRUD. Sin embargo, esto generalmente deja sin efecto los beneficios de adoptar CRUD, es decir, su simplicidad y productividad para el equipo de ingeniería de software.

4. Se dice que una aplicación es de arrendatario único si una instancia de la aplicación sirve a un solo cliente, generalmente una empresa cliente en el caso de una aplicación de negocios. Se dice que una aplicación es multiarrendatario si una sola instancia sirve a varios clientes (posiblemente todos los clientes del proveedor de software).

5. La terminología varía. Los proveedores de SaaS tienden a usar el término planes o ediciones en lugar de módulos para hacer referencia al mecanismo de fijación de precios que da acceso a entidades adicionales y, por lo tanto, a funciones adicionales.

6. Generalmente, es posible hacer ingeniería inversa completa en una aplicación CRUD a través de la inspección cuidadosa de las diferentes "pantallas" que ofrece a los usuarios finales.

7. La parte no CRUD tiende a designarse con la palabra de moda del momento. A principios de los años 2000, las aplicaciones contaban con funciones de "minería de datos": Desde 2010, las aplicaciones en boga eran aquellas con funciones de "big data". A partir de 2020, las aplicaciones comenzaron a adoptar funciones de "IA". Lamentablemente, el abordaje CRUD no se combina bien con alternativas más sofisticadas. Para los proveedores de aplicaciones CRUD, esas funciones no son más que trucos publicitarios.

8. Pocos ingenieros de software talentosos están dispuestos a trabajar para un proveedor que vende aplicaciones CRUD. Los salarios son demasiado bajos, y el talento de un ingeniero resulta bastante irrelevante debido al recorrido tecnológico adoptado. La brecha de talento entre los ingenieros de software CRUD y no CRUD es tan grande como la que existe entre los fotógrafos de bodas y los fotógrafos de marcas de lujo.