Blog de JoseMPelaez

Aprendimiento: aprender del entorno con atrevimiento

Estructuras maestras

Posted by josempelaez en Lunes, 30 junio 2008

El comentario con que arrancaba mi reflexión sobre Maestros y estructuras es el que me había llevado a preguntarme: ¿por qué las distintas aplicaciones empresariales tienen que «disponer de estructuras maestras comunes para las transacciones particulares»? En esta anotación voy a avanzar en la exposición de mi pensamiento, pero su conclusión quedará para la siguiente, por lo que ya advierto de que tampoco voy a llegar a mi destino en este segundo intento.

Creo que, con datos maestros, nos estamos refiriendo a los atributos de entidades tales como clientes, proveedores, empleados, materiales, productos, vehículos, rutas, ubicaciones, centros, operarios, cursos, unidades de obra, cuentas… Es decir, aspectos de la realidad empresarial que tienen cierta estabilidad, si es que esto sigue existiendo hoy. Es preciso que se introduzcan o modifiquen en un sólo sitio, o mejor dicho, una sola vez en cada ocasión en que se requiera. Tienen que ser consistentes y no depender de las aplicaciones. No obstante, con el estado de la técnica moderna, opino que no deben sacrificarse ciertas cosas (flexibilidad, creatividad, innovación, agilidad, adaptabilidad, economía…) a fin de evitar copias duplicadas para ganar espacio, tiempo o robustez del sistema.

grid computingNo es que estos últimos factores no sean ya importantes, sino que se pueden conseguir unos niveles adecuados para ellos a base de replicar, publicar-suscribir, propagar, emular, etcétera. Las computadoras en cluster, los gestores de bases de datos distribuidas, la tecnología grid, las redes de intercambio entre pares, la sincronización de agendas, la “virtualización” de sistemas operativos, el utility/cloud computing… nos brindan posibilidades que antes sólo conocían muy pocos ya que eran aplicables en ambientes reducidos.

Ahora, el almacenamiento y el procesamiento son baratos y bien conocidos. Se puede trabajar perfectamente de forma interactiva y con alta disponibilidad empleando sistemas distribuidos, lo que a veces requiere duplicaciones controladas y datos “desnormalizados”. Me parece que los mayores defensores de los supercomputadores de multiproceso simétrico herederos del mainframe (IBM, Sun…), frente a los más partidarios del proceso masivamente paralelo (Intel, HP, Fujitsu, Dell…) —que emplean granjas de «estaciones de trabajo», redes de servidores estándar baratos, armarios compactos con blades, etcétera— no pueden esgrimir otro argumento mejor que el de la eficiencia energética, y de manera discutible.

También me parece que SAP nos brinda un ejemplo muy ilustrativo en el campo de las aplicaciones y sus datos. Su producto integrado —R/2-R/3-MySAP ERP, para entendernos, ya que en la praxis tienen el mismo núcleo interno— comenzó a implantarse para ofrecer una respuesta financiera inmediata en las grandes empresas alemanas muy estructuradas y dispersas territorialmente por el mundo. Aunque SAP tardó mucho en cambiar su discurso comercial por otro menos limitante, lo hizo finalmente con el anuncio de Netweaver a primeros de 2003. La rigidez puede llegar a ser muy eficiente, pero no suele generar eficacia, que es lo primero que hay que lograr.

No fueron muchos los que se dieron cuenta que su cambio rompía el enfoque de paquete con modelo integrado de datos que aseguraba estructuras maestras comunes para las aplicaciones, lo que habían defendido a ultranza durante casi 30 años. Al nacer el mercado del business software en 1969 —tras “segregar” IBM las aplicaciones y servicios del hardware de sus mainframes— lo que se ofrecía eran soluciones best-of-breed inconexas para los paquetes empresariales (contabilidad, nómina, almacén…). Los problemas de inconsistencias y demoras de consolidación de información que SAP resolvió en sus comienzos tienen ahora mejor respuesta. Y ésta fue adoptada por quienes habían propagado un enfoque previo monolítico y cerrado, pero que resolvió un problema real, al menos para los directores financieros que tardaban meses en consolidar las cuentas anuales de su grupo.

Los planteamientos alternativos a los problemas derivados del ERP integrado no se habían consolidado como una buena opción. Las programaciones de interfaces a medida, el empleo de estándares derivados de EDIFACT, la ejecución de proyectos de «integración de sistemas» con paquetes de EAI dotados de conectores, y la promoción de algunas capacidades de los portales B2B (exchanges) han sido soluciones caras y complejas de implantar y mantener. No han llegado a ser útiles de manera general porque los estándares EDI son rígidos y de mínimos, los proyectos ad hoc emplean mucho tiempo y dinero, y los marketplaces, además de facilitar el intercambio de datos, también pretenden reintermediar los negocios existentes, lo que no gusta a sus agentes.

Entreprise Service Bus Las herramientas de integración basadas en sistemas de mensajería referidas (EAI) nacieron a mitad de los 90 con la proliferación de aplicaciones departamentales. Ésta se apoyó en la difusión de la arquitectura C/S —que también potenció extraordinariamente el despliegue de R/3—, y a su consolidación se aplicaron los enfoques utilizados en la automatización de fábricas y diálogos entre sistemas financieros de los 70 y 80. En la década actual han ido evolucionando hacia los llamados ESB y BPM, planteamientos derivados de los gestores de workflows documentales (difundidos con Lotus Notes) y de las herramientas ingenieriles para diagramar procesos. Creo que estos productos comerciales, junto a las suites de aplicaciones a las que me referiré en otro momento, se van a seguir considerando buenas opciones. Están introduciendo el mismo tipo de middleware que permite conformar un sistema integrando fácilmente muchos componentes «débilmente acoplados». Otra cosa es que puedan mantener sus precios dadas las alternativas disponibles en programación de código abierto.

En cualquier caso, considero que en la base de estos movimientos está el hecho de que, a finales de los 90, el “viejo” lenguaje XML y los estándares de «servicios web» para el intercambio automático de información en internet entre aplicaciones (una forma de interfaz M2M) empezaron a modificar radicalmente el panorama. Después del posterior abandono de Microsoft del grupo de empresas tecnológicas que apoyaban el lenguaje Java multiplataforma para desarrollar aplicaciones empresariales en internet, el XML ha quedado como la herramienta más efectiva de programación orientada a datos de entre las consensuadas en el mundo. Frente a otras de este tipo, como SQL, XML tiene la ventaja de ser extensible y autodefinible. Por tanto, es más capaz de salvar las diferencias que caben al interpretar o implementar los estándares de consenso, por naturaleza lentos en su avance.

Termino esta reflexión con la idea de referirme en la siguiente a algunas implicaciones relevantes del actual enfoque adoptado por la mayoría de las grandes empresas suministradoras de sistemas empresariales, así como a su impacto en las «estructuras maestras comunes» de sus aplicaciones.

[Ilustración 1: arquitectura grid promovida por el CERN.]
[Ilustración 2: tomada de la nota sobre ESB, BPM y SOA en el blog La vida en bytes.]

2 comentarios to “Estructuras maestras”

  1. Caray, si que da de sí un comentario “inocente”. Pero que conste antes de que concluyas que lo hice para un contexto determinado donde el tipo de aplicaciones ERP posibles era restringido. No tenía (tengo) libertad de recomendación total.

    A ver, a ver, el siguiente …

  2. Ya sabes la tormenta que desató el “inocente” aleteo de una mariposa en Brasil según eso del caos… Son simples reflexiones en negro sobre blanco por aquello de aprovechar para pensar mientras se escribe.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

 
A %d blogueros les gusta esto: