Aplicaciones Empresariales CRUD

Desde la década de 1980, la gran mayoría de las aplicaciones empresariales han adoptado un diseño interno similar, a saber, CRUD, que significa Create / Read / Update / Delete. 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 saltos tecnológicos, desde terminales de consola conectados a mainframes hasta aplicaciones móviles conectadas a plataformas en la nube. Entender el diseño CRUD es importante en campos complejos - como supply chain - que típicamente operan sobre un paisaje aplicativo conformado por apps CRUD. Este conocimiento es fundamental para navegar correctamente este paisaje, desde negociar con proveedores de software hasta la explotación de los registros de datos recolectados a través de todas estas aplicaciones.

Visión general

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 finales de la década de 1990, las bases de datos relacionales de código abierto emergentes habían consolidado aún más esta práctica. Hoy en día, el diseño CRUD refleja el enfoque más extendido para desarrollar una aplicación empresarial sobre una base de datos relacional.

Una base de datos, en sentido relacional, incluye una lista de tablas. Cada tabla incluye una lista de columnas (también denominadas 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 el número de columnas se mantenga limitado, a lo sumo unos pocos cientos, mientras que el número de líneas es ilimitado, pudiendo llegar potencialmente 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 típicamente se encuentra 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 denominan entidades. Una entidad refleja la comprensión a alto nivel del negocio.

Figura 2: una sencilla entidad de “carrito de compras” compuesta de dos tablas. Esta entidad refleja el estado del carrito de compras para el visitante de un sitio web ecommerce.

Como se mencionó anteriormente, CRUD se refiere a Create, Read, Update y Delete, las 4 operaciones fundamentales que se deben realizar en las tablas dentro de una base de datos relacional.

• Create: agregar nuevas líneas a la tabla.
• Read: recuperar las líneas existentes de la tabla.
• Update: modificar las líneas existentes de la tabla.
• Delete: eliminar las líneas existentes de la tabla.

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

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

La gran mayoría de las aplicaciones empresariales “transaccionales”, desde un simple rastreador de tiempo hasta un ERP o CRM muy complejo, adoptan un diseño CRUD similar bajo el capó — un patrón de diseño establecido hace más de 4 décadas. Las aplicaciones simples cuentan con solo unas pocas entidades, mientras que las complejas pueden tener miles de ellas. Sin embargo, de lo simple a lo complejo, en términos de diseño inherente, es simplemente lo mismo.

La diversidad de interfaces de usuario, como se encuentra entre las aplicaciones empresariales, 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 supply chain

Casi todas las aplicaciones (expuestas a los usuarios finales) que se utilizan para operar empresas y sus procesos son CRUD. En términos generales, 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, el software de hojas de cálculo), que representan un tipo de tecnología de software completamente diferente.

Internamente, el departamento de TI utiliza una amplia variedad 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 parte invisibles, o al menos discretas, para los usuarios finales.

Dichas aplicaciones CRUD contienen casi todos los datos históricos transaccionales relevantes que pueden aprovecharse para mejorar cuantitativamente la supply chain (por ejemplo, optimizando los niveles de inventario). Como resultado, muchas aplicaciones CRUD intentan², en algún momento, ramificarse en capacidades analíticas (como para fines de planificación u optimización). Lamentablemente, aunque CRUD presenta numerosas ventajas, también presenta notables deficiencias en lo que respecta a las capacidades analíticas (véase “Los límites de CRUD” a continuación).

Los beneficios de CRUD

CRUD ha sido el enfoque preferido para las aplicaciones empresariales durante décadas. Desde una perspectiva tecnológica, este enfoque se beneficia de marcos y herramientas open-source integrales 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, existe un gran mercado de ingenieros de software experimentados en CRUD. Además, CRUD se encuentra entre las partes más accesibles de la ingeniería de software, en gran medida debido a sus herramientas de desarrollo de alta calidad. Como resultado, CRUD es extremadamente accesible incluso para ingenieros de software junior (y para los senior menos talentosos). Dado que los principios subyacentes de CRUD han sido estables durante décadas, la transición hacia una pila tecnológica más reciente también se puede realizar con relativa facilidad, al menos en comparación con otros enfoques más tecnológicos.

Finalmente, desde una perspectiva de continuidad empresarial, 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 permanecerán accesibles; esto es válido incluso si el proveedor original de la aplicación CRUD ya no opera ni colabora con la empresa cliente. Incluso en este caso extremo, la accesibilidad de los datos se puede lograr mediante modestos esfuerzos de ingeniería inversa.

Los límites de CRUD

Las aplicaciones CRUD enfrentan limitaciones inherentes asociadas con la forma en que aprovechan internamente la base de datos relacional en su núcleo. Estas limitaciones no se pueden eludir sin renunciar fundamentalmente a los mismos beneficios asociados con CRUD. Estas limitaciones se dividen en dos grandes categorías: expresividad y rendimiento.

La limitación de expresividad refleja el hecho de que las cuatro acciones (o “verbos”) — create, read, update y delete — no pueden capturar adecuadamente una gama 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 (Supplier Relationship Manager). El verbo apropiado para esta operación sería merge. Sin embargo, el diseño CRUD no cuenta con este verbo. De hecho, dicha capacidad se implementa invariablemente como un proceso de dos etapas. Primero, actualice todas las líneas que solían apuntar a las entradas de proveedores que pronto se eliminarán, de modo que ahora apunten a la que se debe conservar. Segundo, elimine todas menos una de las entradas adicionales de proveedores. No solo se pierde la intención original (el merge), 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 un cambio irreversible en los datos, casi siempre es una limitación de CRUD³ la que interfiere 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 de una pequeña fracción de la base de datos — pone a la aplicación CRUD en riesgo de volverse poco sensible. De hecho, para una aplicación CRUD, se espera que los usuarios finales perciban la latencia casi como si no existiera en casi todas las operaciones rutinarias. Por ejemplo, la actualización de un stock level en el WMS (Warehouse Management System) debería ocurrir en milisegundos (para mantener las operaciones fluidas). Dado que todas las operaciones realizadas en la aplicación CRUD consumen recursos de cómputo de la misma base de datos relacional subyacente, casi cualquier operación no trivial pone en riesgo que este núcleo se vea privado de recursos de cómputo. Anecdóticamente, en las grandes empresas, las aplicaciones CRUD comúnmente se vuelven poco sensibles durante segundos (incluso minutos) a la vez. Estas situaciones casi invariablemente son causadas por unas pocas operaciones “pesadas” que terminan monopolizando los recursos de cómputo por una breve duración, retrasando así todas las demás operaciones — incluidas las “ligeras”. Este problema explica por qué las operaciones no triviales se suelen segregar en trabajos por lotes que se ejecutan de noche. También explica por qué las aplicaciones CRUD suelen ser malas en analítica, dado que las cargas de trabajo analíticas resultan impracticables de ejecutar únicamente fuera del horario de oficina.

Variantes modernas 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 se actualizaron de terminales de consola a interfaces de usuario de escritorio. Durante la década de 2000, la mayoría de las aplicaciones se actualizaron de interfaces de usuario de escritorio a interfaces web. En la última década, la mayoría de las aplicaciones se orientaron hacia SaaS (software as a service) y migraron hacia computación en la nube en el proceso. Sin embargo, el diseño CRUD permaneció en gran medida intacto frente a estas evoluciones.

La transición de inquilinos únicos a multi-inquilinos⁴ obligó a los proveedores de software a restringir el acceso a los datos de las entidades detrás de APIs (Application Programming Interfaces). De hecho, el acceso directo a la base de datos, incluso si es de solo lectura, crea la posibilidad de agotar los recursos de cómputo del núcleo transaccional a través de tan solo un pequeño número de solicitudes pesadas. La API mitiga este tipo de problemas. Restringir el acceso a los datos de la aplicación detrás de una API también anula algunos de los beneficios de CRUD, al menos desde la perspectiva de la empresa cliente. Extraer de manera confiable una gran cantidad de datos de una API típicamente requiere más esfuerzo que componer una serie comparable de consultas SQL. Además, la API puede estar incompleta — sin exponer datos que existen en la aplicación — a pesar de que la base de datos directa debería haber garantizado un 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, surgió una gran variedad de ecosistemas open-source de alta calidad para apoyar el desarrollo de aplicaciones CRUD. Estos ecosistemas han comoditizado extensamente el desarrollo de aplicaciones CRUD, reduciendo enormemente las habilidades necesarias para desarrollarlas y disminuyendo las fricciones asociadas con el proceso de desarrollo.

Dinámicas de proveedores

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

Agregar entidades desbloquea nuevas capacidades y ofrece al proveedor la oportunidad de incrementar sus precios, reflejando el valor añadido creado para la empresa cliente. Además, los módulos⁵, es decir, agrupaciones de entidades relacionadas con el negocio, se introducen frecuentemente como un mecanismo de precios para cobrar más (dependiendo del grado de 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 atender el 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 complejidad accidental creciente 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, dado que existen muy pocas barreras de entrada⁶, surgen nuevos proveedores con frecuencia, cada uno centrado en casos de uso a precios mucho más bajos, y el ciclo se repite ad infinitum.

La visió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 no es más que una pequeña fracción del gasto total de la empresa, muy por detrás de los costos involucrados en el marketing y la venta de las propias aplicaciones. En particular, los proveedores que desarrollan aplicaciones CRUD frecuentemente delocalizan 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 sumas elevadas por aplicaciones CRUD. Como regla general, cualquier aplicación CRUD que cueste más de 250k USD al año es un serio candidato para ser reemplazada por software interno. Cualquier aplicación CRUD que cueste más de 2.5M USD al año debería, casi sin falta, ser reemplazada por software interno (posiblemente partiendo de una base preexistente de código abierto y personalizando a partir de ahí).

Los proveedores de software empresarial que venden aplicaciones CRUD son muy conscientes de este problema (y lo han sido durante mucho tiempo). Así, resulta tentador para el proveedor agregar funcionalidades/aplicaciones/elementos no CRUD⁷ a la solución e intentar convencer a los clientes de (a) que estas piezas importan y (b) 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⁸. A modo de evidencia anecdótica, casi todos los ERPs notables y establecidos tienen amplias capacidades de forecasting y planificación, casi todas de las cuales en gran medida permanecen sin usarse dado lo mal que en realidad desempeñan estas tareas.

Lokad es un proveedor de software empresarial que se especializa en la optimización predictiva de supply chain. Nuestra tecnología ha sido diseñada para aprovechar los datos transaccionales históricos – el tipo que se puede extraer de las aplicaciones CRUD que soportan las operaciones diarias de una empresa. Sin embargo, Lokad en sí misma no es una aplicación CRUD. Nuestro entorno de producción ni siquiera incluye una base de datos relacional. Aunque CRUD es una respuesta tecnológica válida para la gestión de los workflows transaccionales de una empresa, no tiene ninguna relevancia para la modelización predictiva o la optimización matemática de una supply chain.

Notas