Aplicaciones empresariales CRUD

Desde la década de 1980, la gran mayoría de las aplicaciones empresariales han adoptado un diseño interno similar, conocido como CRUD, que significa Crear / Leer / Actualizar / Eliminar. Este diseño refleja la adopción de una base de datos relacional para persistir los datos empresariales. El diseño CRUD ha resistido varios grandes avances tecnológicos, desde terminales de consola conectados a mainframes hasta aplicaciones móviles conectadas a plataformas en la nube. Comprender el diseño CRUD es importante en campos complejos, como la cadena de suministro, que generalmente operan sobre un paisaje aplicativo completo compuesto por aplicaciones CRUD. Esta perspectiva es fundamental para navegar adecuadamente por este paisaje, desde la negociación con proveedores de software hasta la explotación de las entradas de datos recopiladas a través de todas estas aplicaciones.

Resumen

A principios de la década de 1980, las bases de datos relacionales habían surgido como el enfoque dominante para almacenar y acceder a los datos empresariales. A fines de la década de 1990, las bases de datos relacionales de código abierto emergentes habían solidificado aún más esta práctica. En la actualidad, el diseño CRUD refleja el enfoque más extendido para diseñar una aplicación empresarial 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 (también conocidas como campos). Cada campo tiene un tipo de dato: número, texto, fecha, etc. Una tabla contiene una lista de filas (también conocidas como registros). Como regla general, se espera que el número de columnas sea limitado, como máximo unas pocas cientos, mientras que el número de filas es ilimitado, pudiendo llegar a miles de millones.

Figura 1: una tabla simple que refleja una lista de productos y su situación de inventario, ilustrativa de lo que se encuentra típicamente en una base de datos relacional.

En la práctica, el enfoque relacional requiere varias tablas para reflejar algo de interés empresarial (por ejemplo, órdenes de compra). Estos “agrupamientos” de tablas se conocen como entidades. Una entidad refleja la comprensión a nivel alto del negocio.

Figura 2: una entidad simple de "carrito de compras" compuesta por dos tablas. Esta entidad refleja el estado del carrito de compras para el visitante de un sitio web de comercio electrónico.

Como se mencionó anteriormente, CRUD se refiere a Crear, Leer, Actualizar y Eliminar, las 4 operaciones fundamentales que se deben realizar en las tablas de una base de datos relacional.

• Crear: agregar nuevas filas a la tabla.
• Leer: recuperar filas existentes de la tabla.
• Actualizar: modificar filas existentes en la tabla.
• Eliminar: eliminar filas existentes de la tabla.

Estas operaciones se realizan a través de un lenguaje de base de datos dedicado, casi siempre un dialecto de SQL (Structured Query Language) en la actualidad¹.

El diseño CRUD consiste en introducir entidades junto con sus contrapartes de interfaz de usuario, generalmente denominadas “pantallas”. Una pantalla, que puede ser una página web, generalmente presenta las 4 operaciones para la entidad de interés.

La gran mayoría de las aplicaciones comerciales “transaccionales”, desde un simple rastreador de tiempo hasta un ERP (Enterprise Resource Planning) o CRM muy complejo, adoptan un diseño CRUD similar en su estructura, un patrón de diseño establecido hace más de 4 décadas. Las aplicaciones simples solo presentan unas pocas entidades, mientras que las complejas pueden presentar miles de ellas. Sin embargo, de lo simple a lo complejo, en términos de diseño inherente, es más de lo mismo.

La diversidad de interfaces de usuario, como se encuentra en las aplicaciones comerciales, puede ser engañosa en el sentido de que parece que las aplicaciones tienen muy poco en común. 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 los usuarios finales) que se utilizan para operar empresas y sus procesos son CRUD. En general, si un software empresarial se beneficia de un acrónimo de 3 letras como ERP, MRP, CRM, SRM, PLM, PIM, WMS, OMS, EDI (etc.), entonces casi invariablemente se implementa como CRUD. La excepción más notable a esta regla son los editores de documentos (por ejemplo, software de hojas de cálculo), que representan un tipo completamente diferente de tecnología de software.

Internamente, el departamento de TI utiliza una amplia gama de tecnologías que no son CRUD: redes, virtualización, herramientas de administración de sistemas, etc. Sin embargo, estas tecnologías tienden a ser en gran medida invisibles, o al menos discretas, para los usuarios finales.

Dichas aplicaciones CRUD contienen casi todos los datos históricos de transacciones relevantes que se pueden aprovechar para mejorar cuantitativamente la cadena de suministro (por ejemplo, optimizar los niveles de stock). Como resultado, muchas aplicaciones CRUD intentan², en algún momento, expandirse hacia capacidades analíticas (como para fines de planificación u optimización). Desafortunadamente, si bien CRUD presenta numerosas ventajas, también presenta graves limitaciones en cuanto a capacidades analíticas (consulte “Los límites de CRUD” a continuación).

Los beneficios de CRUD

CRUD ha sido el enfoque preferido para las aplicaciones comerciales durante décadas. Desde una perspectiva tecnológica, este enfoque se beneficia de marcos y herramientas de código abierto completos en todas las principales pilas de software. Como resultado, el camino tecnológico está excepcionalmente bien definido. Además, CRUD también se beneficia 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, hay un gran mercado de ingenieros de software con experiencia en CRUD. Además, CRUD es una de las partes más accesibles de la ingeniería de software, en gran parte debido a sus herramientas de desarrollo de alta calidad. Como resultado, CRUD es extremadamente accesible incluso para ingenieros de software junior (y menos talentosos). Como los principios subyacentes de CRUD han sido estables durante décadas, la transición hacia una pila tecnológica más nueva también se puede hacer con relativa facilidad, al menos en comparación con otros enfoques más tecnológicos.

Finalmente, desde una perspectiva de continuidad del negocio, CRUD ofrece todos los beneficios asociados con su base de datos relacional subyacente. Por ejemplo, siempre que la base de datos sea accesible para la empresa cliente, los datos seguirán siendo accesibles; esto es cierto incluso si el proveedor original de la aplicación CRUD ya no está operativo o cooperativo con la empresa cliente. Incluso en este caso extremo, la accesibilidad a los datos se puede lograr mediante modestos esfuerzos de ingeniería inversa.

Los límites de CRUD

Las aplicaciones CRUD enfrentan limitaciones inherentes asociadas a la forma en que aprovechan internamente la base de datos relacional en su núcleo. Estas limitaciones no se pueden evitar sin renunciar fundamentalmente a los beneficios asociados con CRUD. Estas limitaciones se dividen en dos categorías principales: 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 capturar adecuadamente una variedad más granular de intenciones. Por ejemplo, considere una situación en la que un empleado busca deduplicar varias entradas de proveedores que se han creado por error dentro del SRM (Gestor de Relaciones con Proveedores). El verbo apropiado para esta operación sería fusionar. Sin embargo, el diseño CRUD no tiene este verbo. De hecho, esta capacidad se implementa invariablemente como un proceso de dos etapas. Primero, actualizar todas las líneas que solían apuntar hacia las entradas de proveedores que se eliminarán pronto, para que ahora apunten a la que se conservará. En segundo lugar, eliminar todas menos una de las entradas de proveedores adicionales. No solo se pierde la intención original (la fusión), sino que la transformación es destructiva en términos de datos. Anecdóticamente, cuando las aplicaciones CRUD advierten a sus usuarios que están a punto de realizar algún cambio irreversible en los datos, casi siempre es una limitación de CRUD³ la que está interfiriendo en la experiencia del usuario.

La limitación de rendimiento refleja el hecho de que cualquier operación de larga duración, es decir, cualquier operación que lea más que una fracción pequeña de la base de datos, pone en riesgo la capacidad de respuesta de la aplicación CRUD. De hecho, para una aplicación CRUD, los usuarios finales esperan que la latencia sea apenas perceptible para casi todas las operaciones mundanas. Por ejemplo, actualizar un nivel de stock en el WMS (Sistema de Gestión de Almacenes) debería ocurrir en milisegundos (para mantener las operaciones fluidas). Como todas las operaciones dadas a la aplicación CRUD consumen recursos informáticos de la misma base de datos relacional subyacente, casi cualquier operación no trivial pone en riesgo este núcleo de quedarse sin recursos informáticos. De manera anecdótica, en grandes empresas, las aplicaciones CRUD suelen volverse no responsivas durante segundos (incluso minutos) a la vez. Estas situaciones casi invariablemente son causadas por algunas operaciones “pesadas” que terminan acaparando los recursos informáticos durante un corto período de tiempo, retrasando así todas las demás operaciones, incluidas las “ligeras”. Este problema explica por qué las operaciones no triviales generalmente se segregan en trabajos por lotes que se ejecutan por la noche. También explica por qué las aplicaciones CRUD suelen ser malas en análisis, dado que las cargas de trabajo analíticas son impracticables de ejecutar solo fuera del horario de oficina.

Modernas variantes de CRUD

Durante las últimas décadas, el software empresarial ha experimentado evoluciones sustanciales. Durante la década de 1990, la mayoría de las aplicaciones pasaron de las terminales de consola a las interfaces de usuario de escritorio. Durante la década de 2000, la mayoría de las aplicaciones pasaron de las interfaces de usuario de escritorio a las interfaces de usuario web. En la última década aproximadamente, la mayoría de las aplicaciones se han orientado hacia SaaS (software como servicio) y se han migrado hacia computación en la nube en el proceso. Sin embargo, el diseño CRUD ha permanecido en gran medida sin cambios en estas evoluciones.

La transición de un único inquilino a un multi-inquilino⁴ obligó a los proveedores de software a controlar el acceso a los datos de las entidades a través de APIs (Interfaces de Programación de Aplicaciones). De hecho, el acceso directo a la base de datos, incluso si es solo de lectura, crea la posibilidad de agotar los recursos informáticos del núcleo transaccional a través de un pequeño número de solicitudes pesadas. La API mitiga este tipo de problemas. Controlar el acceso a los datos de la aplicación a través de una API también anula algunos de los beneficios de CRUD, al menos en lo que respecta a la empresa cliente. Extraer de manera confiable una gran cantidad de datos de una API generalmente requiere más esfuerzo que componer una serie comparable de consultas SQL. Además, la API puede estar incompleta, es decir, no exponer datos que existen en la aplicación, aunque la base de datos directa debería haber otorgado acceso completo a los datos por diseño.

La principal evolución de CRUD se encuentra en las herramientas. Durante la década de 2010, surgieron una amplia variedad de ecosistemas de código abierto de alta calidad para respaldar el desarrollo de aplicaciones CRUD. Estos ecosistemas han commoditizado ampliamente el desarrollo de aplicaciones CRUD, reduciendo en gran medida las habilidades necesarias para desarrollarlas y reduciendo las fricciones asociadas con el proceso de desarrollo.

Dinámica de los proveedores

El costo de desarrollo de una aplicación CRUD está determinado en gran medida por el número de entidades. Cuanto mayor sea el número de entidades, más pantallas deben desarrollarse, documentarse y mantenerse. Por lo tanto, el camino natural para un proveedor de software que promueve una aplicación CRUD consiste en comenzar con un número limitado de entidades y agregar más con el tiempo.

Agregar entidades desbloquea nuevas capacidades y brinda al proveedor la oportunidad de aumentar sus precios, reflejando el valor adicional creado para la empresa cliente. Además, los módulos⁵, es decir, agrupaciones de entidades relacionadas con el negocio, se introducen con frecuencia como un mecanismo de fijación de precios para cobrar más (según el alcance del uso del producto de software).

Como resultado, las aplicaciones CRUD tienden a volverse más complejas con el tiempo, pero también menos relevantes. De hecho, a medida que se agregan nuevas entidades para servir al interés de toda la base de clientes, muchas (si no la mayoría) de las entidades recién introducidas no son relevantes para ninguna empresa cliente individual. Estas entidades “muertas” -desde la perspectiva de la empresa cliente- representan una creciente complejidad accidental que contamina el CRUD.

Las aplicaciones CRUD vendidas como SaaS tienden a volverse más caras a medida que crecen en capacidad y notoriedad. Sin embargo, como hay muy pocas barreras de entrada⁶, nuevos proveedores emergen con frecuencia, cada uno enfocándose en casos de uso a precios mucho más bajos, y el ciclo se repite ad infinitum.

Opinió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 empresarial que las venden, el costo de desarrollo es solo una fracción pequeña del gasto total de la empresa, muy por detrás de los costos involucrados en la comercialización y venta de las aplicaciones en sí. En particular, los proveedores que desarrollan aplicaciones CRUD con frecuencia deslocalizan sus equipos de ingeniería en países de bajo costo, ya que el enfoque CRUD (dada su accesibilidad general) puede tolerar una fuerza laboral de ingeniería menos talentosa y menos costosa.

Hoy en día, hay muy pocas razones para pagar grandes cantidades por aplicaciones CRUD. Como regla general, cualquier aplicación CRUD que cueste más de 250.000 USD al año es un candidato serio para ser reemplazada por software interno. Cualquier aplicación CRUD que cueste más de 2,5 millones de USD al año debería, casi sin excepción, ser reemplazada por software interno (posiblemente a partir de una base de código abierto preexistente y personalizando desde allí).

Los proveedores de software empresarial que venden aplicaciones CRUD son muy conscientes de este problema (y lo han sido durante mucho tiempo). Por lo tanto, es tentador para el proveedor agregar funcionalidades/aplicaciones/elementos no CRUD a la solución e intentar convencer a los clientes (a) de que estas piezas son importantes y (b) de que estas piezas representan una especie de “salsa secreta” que el cliente no podrá replicar. Sin embargo, este enfoque casi nunca tiene éxito, principalmente porque el proveedor no tiene el ADN de ingeniería adecuado⁷. Como evidencia anecdótica, casi todos los ERP notables y establecidos tienen capacidades extensas de pronóstico y planificación, casi todas las cuales se utilizan muy poco debido a lo mal que realmente realizan estas tareas.

Lokad es un proveedor de software empresarial especializado en la optimización predictiva de la cadena de suministro. Nuestra tecnología ha sido diseñada para aprovechar los datos transaccionales históricos, del tipo que se puede extraer 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 de trabajo transaccionales de una empresa, no tiene ninguna relevancia para el modelado predictivo ni para la optimización matemática de una cadena de suministro.

Notas