Blog de JoseMPelaez

Aprendimiento: aprender del entorno con atrevimiento

Posts Tagged ‘integración’

Nudos entre comunicaciones

Posted by josempelaez en Miércoles, 26 noviembre 2008

Las redes de ordenadores siguen incrementando su protagonismo en la sociedad y culturas actuales. A sus usos en proyectos científicos y aplicaciones técnicas con presencia en los medios de comunicación hay que añadir el empleo extensivo de internet para diseminar mensajes de forma distribuida. Las innovaciones en la conectividad entre unidades de procesamiento de información permitirán avances que pocos pueden intuir, pero algunos sí que los ven, y la «tercera cultura» ayudará en su difusión.

grid-light

Grid para una luz fluorescente (cc RobertFrancis, Flickr)

Hace tres semanas me hice eco de la noticia de que el regulador estadounidense había aprobado la asignación del «espacio blanco» del espectro radioeléctrico —las frecuencias que quedaban libres al cambiar a la TV digital—. Ello me parece relevante porque va a facilitar el despliegue del acceso a internet mediante otra “banda ancha sin cables”. Algunos le denominan una “Wi-Fi con esteroides” ya que tendrá una mayor capacidad que la actual, y que las redes celulares 3G que el empleo de los nuevos terminales tipo iPhone están saturando.

Bueno, en realidad, hablar sólo de acceso es poco veraz. Internet es una red y, como tal, está formada por enlaces o líneas, además de por los nudos o conexiones entre ellos que, en sentido estricto, serían tan sólo sus intersecciones o puntos de cruce. Por consiguiente, los canales de comunicación de este espacio “liberado” serán una parte importante de internet, que el DRAE define como: «Red informática mundial, descentralizada, formada por la conexión directa entre computadoras u ordenadores mediante un protocolo especial de comunicación.» 

Malla, parrilla, enrejado, celosía, trama, cuadrícula, tamiz… son vocablos relacionados con red que, en unos casos, enfatizan los hilos, líneas o canales de unión, mientras que en otros resaltan los huecos que se forman entre ellos. Ahora bien, curiosa y extrañamente, los nudos o nodos parecen carecer de interés en todas sus acepciones. Como pocos saben de su papel crucial en muchos tipos de estructuras para una distribución correcta de cargas, me resulta una paradoja su reducido protagonismo semántico ya que esos puntos fueron los protagonistas iniciales de internet, que nació para conectar ordenadores heterogéneos formando una red de topología distribuida. Por cierto, que los exploradores de la Sociedad de las Indias Electrónicas han explicado las diferencias entre descentralizado y distribuido a estos efectos, distingo que no han hecho los miembros de la Real Academia Española en su diccionario de la lengua.

cern_eege-grid

Algunos nodos del EGEE (datos del Imperial College London sobre Google Earth)

Cuando miro las imágenes que usé para ilustrar las dos anotaciones de hace veinte días en que me referí al proyecto del CERN «LHC Computing Grid», observo que todas ellas  ponen más de relieve los nodos que las líneas de conexión. Si miro al otro proyecto grid computing del CERN, el de infraestructura «Enabling Grids for E-sciencE», concluyo que, durante su difusión, el énfasis se puso en que su software permitió conectar más de 2.000 computadoras en abril de 2006 (con motivo de la crisis mundial de la gripe aviar). Recuerdo que esta red permitió, en sólo 1 mes de colaboración, hacer un trabajo de computación que hubiera demandado 1.200 meses de proceso en 1 ordenador (no decían de qué tamaño, así que debían de referirse al promedio). 

La página informativa del centro público que inventó la web explica que la Grid se basa en la misma idea: compartir recursos entre ordenadores distribuidos geográficamente. Aclara que, mientras la web simplemente compartía información entre ellos, la nueva red, que algunos asocian con la “internet del futuro”, también comparte capacidad de proceso y de almacenamiento. En septiembre de 2006, la EGEE Grid financiada por la Unión Europea estaba formada por más de 200 centros y conectaba más de 20.000 computadoras repartidas por el globo.

Por consiguiente, a diferencia de las parrillas de acero corrugado que arman el hormigón, o de las redes que se emplean para pescar, internet dota de un gran protagonismo a sus nodos. No debemos olvidar que un buen número de ellos se dedican exclusivamente a regular el tráfico y la confidencialidad de los paquetes de datos que transitan por sus líneas cableadas e inalámbricas: encaminadores, pasarelas, conmutadores, cortafuegos, cifradores, traductores, repetidores, moduladores, emisoras, captadores, centralitas digitales…

grid-poles_cloud

Líneas y postes de electricidad (cc einarfour, Flickr)

Bien, vale, quizá resulte que los cables de cobre, los de fibra óptica, los pulsos lumínicos, las ondas electromagnéticas, los transductores y acopladores, las claves de señales, los protocolos de transmisión, los algoritmos de cifrado… son menos importantes que los nudos de cómputo que también conforman la trama de internet. Será que éstos deben de ser los elementos clave de las redes aplicadas a las TIC. Será que los vocablos de nuestro pasado sociotécnico —que se refieren a las conexiones y espacios vacíos entre líneas más que a los nodos materiales donde se cruzan— deberán de adaptar su significado para poder reflejar lo importante en las nuevas TIC. ¿Y a mí qué?, podría preguntarme.

Pues resulta que considero importante no perder de vista que no hay redes de ordenadores sin conexiones y comunicaciones. Las unidades de almacenamiento y procesamiento de datos servirán de poco si formamos islas de información accesibles sólo desde “ventanillas” dentro del perímetro delimitado por una especie de foso de aislamiento infestado de cocodrilos, o por una profunda zanja cortafuegos o contra asaltadores del tesoro de la información. Sería como si los aeropuertos fueran hubs & spokes completamente aislados, sin aeronaves que los conectaran, o como si las estaciones o terminales de tren no tuvieran redes ferroviarias que las enlazaran. 

La lógica del tamaño del hueco de una red que permite no atrapar al “pezqueñín” es una cuestión básica para el sostenimiento de la vida marina. El lenguaje humano —nuestros protocolos de comunicación—, también es clave para nuestro desarrollo, como enseñan la experiencia y la biolingüística.

internet-mapping_mit

Representación de la periferia del 'universo on-line' (Lanet-vi program of I. Alvarez-Hamelin et al. - MIT Technology Review)

Sin comunicación no habría grupos de personas, ni tribus, ni aglomeraciones urbanas, ni sociedades, ni culturas, ni Civilización Humana (en singular). La nanotecnología, la física cuántica, la genética molecular, la neurociencia… van descubriendo nuevas estructuras dentro de órganos que antes se estudiaban en niveles superiores. Siguiendo “hacia arriba”, ¿qué nos depararán las nuevas redes de ordenadores como el Grid del CERN, o la extensión de una computación en la nube que hoy lastran algunos armados de mitos interesados que montan alrededor de la seguridad, disponibilidad, integración, dependencia…?

Para terminar quiero anotar el desencadenante inmediato para escribir esta entrada en el cuaderno, y así poder recordarlo. Tenía rondando por mi cabeza varias ideas sobre “espacios vacíos”, grids, datos en la nube, islas de información, protecciones culturales y lenguajes de comunicación cuando leí un artículo sobre Ray Ozzie en Wired. Se extiende sobre su actual papel en Microsoft como Chief Software Architect, para lo que se remonta a los orígenes de su posición a favor de la computación en la nube y, por consiguiente, fuera del firewall. Al final del mismo se dice:

«To Ozzie, software’s soul does not lie in the accumulation of features. Instead, it lies in his dream of connectivity. “Live Mesh is very Ray,” Mitch Kapor [Lotus founder] says. “It’s the son of Groove, which is the son of Notes.” Which was, of course, the son of Ozzie’s beloved Plato [an early interactive system to connect people]. Thirty-three years later, Ozzie is still trying to build on what he saw in sophomore year. But it’s no longer the Ray Ozzie vision. It’s Microsoft’s.» [negrita del editor]

Interesante, ¿no?

Entradas relacionadas: Conmutación a la nube, El «espacio blanco» de la televisión, Sistemas operativos en la web

Suscribirse en un lector a este cuaderno. El servicio co.mments permite seguir los eventuales comentarios por correo electrónico.

Posted in computación, web | Etiquetado: , , , , , , , | Leave a Comment »

Integración vertical industrial

Posted by josempelaez en Sábado, 11 octubre 2008

Hay ocasiones donde aún se defiende la integración vertical para alcanzar o asegurar algo: productividad, calidad, experiencia de usuario… No obstante, la globalización actual, facilitada por el desarrollo de las técnicas de transporte de mercancías y de información, permite lograr lo anterior de forma más flexible y económica. Salvo en los casos de mercados reducidos o nacientes, los grandes sectores industriales de bienes y servicios suelen funcionar mucho mejor en entornos horizontales bien conectados.

open-handset-alliance

Representación de la alianza de móvil abierto promovida por Google (cc dannysullivan)

Acabo de ver una entrada de Antonio Ortiz donde especula sobre el sentido que podría tener para Microsoft, la compra de RIM y las Blackberry. La ocurrencia de ponerme a escribir me ha surgido al leer que:

«A pesar del solape con la propia plataforma móvil, para Microsoft sería un enorme refuerzo en el correo corporativo y la entrada en el mercado de dispositivos. Este último punto es estratégico, supone sumarse a la tendencia de “controlar la experiencia completa del usuario” y no estar a expensas de que terceros […] apuesten por tu sistema y articulen una nueva capa de presentación sobre el mismo.»

En un sistema económico cada vez más global y abierto (para lo bueno y lo malo), me intriga bastante que siga habiendo proponentes de enfoques de producción de bienes o servicios que defiendan la necesidad de estar perfectamente integrados para controlar la «experiencia de uso» (más allá de unas etapas iniciales de innovación).

Entiendo que haya admiradores de sistemas cerrados como el Mac o el iPhone promovido y controlado por Apple, que ha merecido mucha atención e interés del mercado. Ahora bien, debemos recordar que no deja de ser una opción bastante minoritaria, como los son los artículos que simbolizan lujo y distinción.

cuartel-general_gmc_detroit

Los cuarteles de General Motors Corporation en Detroit (© France Presse)

Lo que no comprendo es que Microsoft, un suministrador que se interesa por mercados masivos, pueda pretender conquistarlos de manera sostenible con soluciones propietarias de “extremo a extremo” en aras de tener un control que, supuestamente, logre la mejor experiencia posible para el cliente. Siempre he creído que el precio y la adaptabilidad juegan un papel considerable en su satisfacción. Entiendo que un proveedor así contemple estas opciones, pero no que se ponga seriamente a implementarlas gastando mucho dinero en ponerlas a prueba en los mercados.

Dejando a un lado los riesgos de eventuales acusaciones monopolistas, hay dos tipos de consideraciones que me hacen dudar mucho del éxito de este tipo de estrategias en los móviles (y en todos los mercados de cualquier tipo que no sean muy reducidos o incipientes).

Por un lado está el hecho de la naturaleza de internet, y de la requerida aplicación de estándares para sus interacciones. Es claro que los “corralitos” que han tratado de imponer algunos servicios, tipo Movistar Emocion o Vodafone Live!, no gozan del favor de los usuarios, y las empresas que los promueven han tenido que recular. ¿Qué pasó con las redes de suscriptores de AOL o Prodigy en defensa de una mejor experiencia frente a la apertura, gratuidad y variedad de la “internet fija”? La “internet móvil” no es más que una parte de “la red” (o de la “nube”), donde ya existen unos usos y costumbres que no se van a cambiar por mucha mercadotecnia que se aplique, ni siquiera influyendo o presionando a los reguladores. Las campañas y movilizaciones pro neutralidad de la red han puesto de manifiesto que es una materia que goza de un interés notable por parte de la mayoría de los ciudadanos.

Por otra parte tenemos las muchas experiencias habidas en el último siglo. Los cien años transcurridos desde que arrancó la segunda revolución industrial han mostrado la enorme potencia de la estandarización de procedimientos, útiles, herramientas, máquinas, piezas, partes, conjuntos, subsistemas, etcétera. Ford, General Motors y Chrysler, empresas fuertes que comenzaron a producir masivamente con una organización empresarial e infraestructura física muy integradas verticalmente para controlar la productividad y calidad, hace tiempo que cedieron su liderazgo a esquemas industriales muy descentralizados (el JIT de Toyota). Como los humanos cambiamos nuestros principios y valores con mucha dificultad, el lastre de esas culturas corporativas integradas ha llevado a dichas empresas al borde de la quiebra mucho después de la aparición de los enfoques competidores más abiertos.

¿Será Google el Toyota de los Apple, Nokia y Microsoft?

Entradas relacionadas: Productos y soluciones de los clientes

Posted in integración | Etiquetado: , , , , , , , | 4 Comments »

Paradojas en el proceso

Posted by josempelaez en Viernes, 4 julio 2008

Tras lo escrito en las tres anotaciones previas, creo que ya hay bastante consenso en que las estructuras maestras de datos no “han de ser” comunes en las aplicaciones empresariales —ni en otros tipos—. Obviamente pueden serlo, pero probablemente sea mejor que no lo sean. ¿Por qué?: porque así hay más…

  • flexibilidad, para reaccionar mejor ante los cambios,
  • rapidez de despliegue, al combinar y reusar componentes,
  • adaptación a distintos problemas, al configurar y reemplazar elementos,
  • control de riesgos, al poder evolucionar paulatinamente y emplear métodos ágiles de desarrollo,
  • economías, al aplicar estándares y no requerirse proyectos de integración complejos, etcétera.

CBDOtra de las grandes paradojas de los sistemas de información (SI) empresariales es que las consultoras de negocio y sistemas, que promovían su empleo con el discurso de la reorganización por procesos, luego solían prescribir sistemas más orientados a datos y documentos.

Lo primordial en los procesos son las relaciones, comportamientos y estados de los objetos que interaccionan como abstracciones de la realidad. Me refiero a planos, especificaciones, órdenes, acciones, tareas, movimientos, pedidos, viajes, cargas (mercancías), inventarios, entregas, facturas, apuntes… Cada uno de estos elementos sigue unas secuencias de pasos dependiendo de ciertos eventos (workflow), pasa por una serie de situaciones (states), y tiene una vida determinada con principio y fin (lifecycle).

Los típicos documentos de un sistema administrativo (partes, albaranes, listas…) se pueden considerar subproductos de información generados durante la ejecución de los procesos —según las fórmulas de la ingeniería y las reglas de los negocios— a partir de un suceso desencadenante (orden, petición, incidencia…). Teniendo el registro histórico de las transacciones detalladas se pueden extraer luego toda clase de informes estadísticos, paneles de indicadores operacionales, cuadros de mando directivos, análisis de rentabilidad por actividades, información agregada para decisiones…

Aquí encuentro otra paradoja porque, si un SI está orientado a los procesos, el tratamiento requerido de los documentos asociados (registros de información) se produce como una consecuencia lógica, pero ésto no suele suceder en sentido opuesto. Creo que hay un mal enfoque de muchos SI que se deriva de la simple mecanización de los viejos procedimientos administrativos. ¿Cuántas veces los programadores de los System/38, AS/400 y System i de IBM, tan usados en las medianas empresas industriales y comerciales, han tenido que borrar transacciones de movimiento de fondos o de mercancías porque alguien no quería que se viera lo que había sucedido realmente durante el proceso? ¿Es útil esta información adulterada?

Network SynchroEn los procesos, los datos maestros que se repiten en muchos documentos son secundarios. Incluso los que aplican el principio de unicidad de maestros no pueden impedir que existan datos duplicados. ¿No son también entidades proveedoras las clasificadas como clientes, aunque lo sean de otras organizaciones del «ciclo productivo»? ¿No debiera tener el componente “cliente” un comportamiento distinto según las circunstancias? El que sus atributos más estables puedan estar almacenados de manera consistente en varios sitios es un problema técnico que hoy ya está bien resuelto. Que se hable de replicación de bases de datos, coordinación de agendas, alineamiento de maestros, red global de sincronización de datos (GSDN )…, debiera de ser una cuestión menor.

En el diseño moderno de SI, ¿vamos a seguir empleando como restricciones las de la informática antigua?: ahorrar espacio de almacenamiento, normalizar datos para evitar redundancias e inconsistencias, programar sin parámetros ni reglas contingentes para procesar rápido, trabajar en local para eliminar indisponibilidades o latencias de red… ¡Qué paradoja que un sector de innovación tan acelerada siga lastrado por dificultades técnicas superadas!

En el campo empresarial de las operaciones —el que conozco mejor—, desde la extracción de la materia prima hasta su recuperación al final de su ciclo de vida útil, hay muchas actividades concatenadas que afectan a numerosas empresas de diversos tamaños y especialidad. ¿Cómo ha de tratarse la información asociada a esos procesos para gestionarlos mejor?

La visión de la empresa que se apoya en estructuras organizativas y maestras de información es anticuada. Replica organigramas y formularios propios de una organización tradicional ya superada. ¿De qué empresa hemos de tomar la “visión dominante” en una «demand-driven supply network»? ¿Por qué no pueden gestionarse directamente los procesos (comerciales, ingeniería, operativos, de personal, de sistemas, contables…) en lugar de los documentos, ya sean de una empresa o de una red de organizaciones? Cada abstracción de la realidad tiene sus datos de referencia y reglas asociados. Éstos no tienen por qué ser visibles desde el exterior del componente si se emplean esquemas de «petición-respuesta» en el funcionamiento de los SI. ¿Por qué han de estar agrupados en maestros comunes?

Service Oriented ArchitectureMe parece que las grandes consultoras industriales, que hace tiempo que aparcaron el discurso del BPR, ahora hablan mucho de SOA, BPM, ESB… Tengo dudas acerca de que sepan realmente, o de que quieran explicar bien, lo que ello implica, que es más que integrar servicios de aplicación. Me temo que sólo traten de seguir vendiendo jornadas de servicios profesionales a espuertas bajo una nueva etiqueta, como sucedía en los grandes proyectos de implantación de ERPs de hace pocos años.

A mí, la «arquitectura orientada a servicios» me refresca lo que aprendí en la universidad sobre resistencia de materiales, como recordaba en Maestros y estructuras. Las flexibles no se oponen de forma rígida a las acciones derivadas de los cambios del entorno que actuan sobre su periferia; se acomodan para no colapsar bajo su presión y poder conducir el esfuerzo resistente hacia unas bases sólidas de sustentación, servicio prestado por los cimientos. ¿Qué relación veo entre el análisis estructural y la arquitectura de servicios?

Para mí, un enfoque de SOA para los SI transaccionales debiera permitir trabajar con todos los variados y variables detalles que intervienen en las diferentes partes de los procesos. Es lo que considera un arquitecto o ingeniero cuando contempla las posibles acciones de viento, nieve, agua, vibración… que pueden impactar en las distintas partes de la estructura para calcular sus efectos. El análisis también debería contemplar servicios para guiar las acciones de cada agente participante (persona, equipo, máquina), registrar lo ocurrido en cada lugar e instante relevantes, y transmitir todos esos datos precisos, puntuales y plenos para su consolidación, como cuando se instrumenta una estructura resistente. Así se lograría una base de información real, no organizada necesariamente en documentos, sino más orientada a procesos, acciones o servicios. Ello permitiría decidir y dirigir mejor las empresas en todos los escalones de sus actividades sin tener que esperar obligadamente al final de cada semana o mes para que se hayan “cocinado” los datos relevantes.

Parafraseando a Eduardo Torroja, un tipo estructural de «sistema monolítico» basado estructuras maestras de datos comunes no va a adaptarse bien a los cambios; uno flexible armado con componentes que interactuan, encapsulando sus datos y reglas de comportamiento, sí que puede hacerlo. Se adapta sobre la marcha y no hay que post-procesar nada.

[Ilustración 1: Component-Based Development Cycle © OIG Ltd 2002-2003]
[Ilustración 2: XC Bridge, © Xchange Network]
[Ilustración 3: Service Oriented Architecture © eSchool News]

Posted in integración | Etiquetado: , , , , , | 3 Comments »

Paradojas en la arquitectura maestra

Posted by josempelaez en Miércoles, 2 julio 2008

En las dos notas precedentes reflexioné sobre los programas orientados a procesos y a datos, y sobre la integración de aplicaciones empleando estructuras comunes de datos, entre otros medios. En ambos casos eché mano de mis recuerdos informáticos con la idea de explicar-me —”a mí, mismamente”, a mi penfriend Luis y a quienquiera leerlas— por qué no comulgo con la idea de que los datos maestros de las aplicaciones transaccionales deben estar en un sitio común.

ERP monoliticoCierto es que los llamados ERPs (Enterprise Resource Planning), que también se han denominado «paquetes integrados de gestión empresarial» precisamente por ello, resolvieron varios problemas derivados de las lagunas e inconsistencias de la información procesada con aplicaciones que formaban sistemas deslavazados. Por cierto, que quien empleó lo de planificación para referirse a estos sistemas transaccionales no debía de saber mucho de operaciones, o le encantaban las paradojas. Además, hubiera sido mucho más veraz referirse a controlar, y no a planear.

No obstante, en la misma década de los 90 en que se propagaron los anteriores, también se difundían modelos de interoperabilidad de sistemas. El CORBA del OMG en el plano de la aplicaciones, y el DCE/RPC del OSF en un nivel más bajo, fueron promovidos por algunas empresas relevantes de tecnología como alternativas flexibles al monolitismo de la base y modelo de datos únicos.

Sin embargo, a pesar del buen nombre de sus promotores, se impuso el modelo integrado de datos para construir los nuevos sistemas de información (SI) empresariales frente al de las interfaces técnicas entre aplicaciones especializadas. Ello sucedió, de nuevo paradójicamente, en el marco de una gran expansión del empleo de las redes locales (LAN) y la arquitectura C/S derivada. Creo que la clave está en que SAP, como gran propulsor de modelo triunfador, era una empresa de programación que nació para resolver un problema importante de los financieros.

Además, en 1993, tras haber logrado el apoyo de las dos grandes empresas de miniordenadores de la época (HP y DEC), supo ceder servicios de implantación para poder crecer más rápido aliándose con las grandes empresas de consultoría de negocio. Éstas vendían el BPR a los miembros (y “miembras”, según Aído) de los comités de dirección de sus clientes empresariales. Prometían que la “nueva” herramienta (R/3) de SAP, que promovían y en la que habían formado a su gente, iba a materializar los deseados cambios. ¡Y vaya si tuvieron que cambiar para adaptarse al modelo funcional del nuevo paquete, aunque no creo que fueran exactamente esos sus ansiados deseos!

Las suites de aplicaciones comenzaron a aparecer al poco por dos motivos adicionales a los tradicionales de especialización y flexibilidad. Por un lado, como resultado de las adquisiciones de business software hechas para crecer más rápido por empresas como Oracle, Descartes Systems, i2 Technologies, SAP, etc. Había que integrarlas con las existentes y, con sus bases de clientes, no se podían permitir el rehacerlas desde el núcleo para que tuvieran las mismas estructuras maestras que las aplicaciones del adquirente.

Por otro, los ERP transaccionales derivados de los programas de contabilidad (FABS), o de los de planificación de la producción (MRP), no cubrían importantes áreas de actividad cotidiana (CRM, SRM, PLM…). Ni para el director financiero ni el de producción las visitas comerciales debían de ser relevantes para “sus negociados”. Tampoco cubrían las funciones más propias de los DSS, que sí interesaban a ambos, pero que se dejaban fuera porque entonces podían “tumbar” los servidores con algunas de sus “potentes queries“.

Creo que la situación actual es la descrita al final de la entrada sobre Estructuras maestras. El uso de internet (una arquitectura C/S abierta, al fin y al cabo) ha determinado que los «servicios web», herederos del CORBA, estén predominando en la interacción entre sistemas modernos, que ya no son los ERPs. HP llegó a llamar e-speak a este enfoque a mediados de 1999. Microsoft comenzó a referirse a un concepto similar con la etiqueta .Net un año después. IBM hablaba de e-business desde años antes.

Las necesidades del comercio internacional (OASIS y UN/CEFACT), y el apoyo del consorcio de estándares de internet (W3C), han ido afianzando la difusión del XML como elemento esencial de dichos servicios de conectividad e interacción. En el terreno de las aplicaciones para consumidores, los agregadores de contenido (RSS) y las interfaces gráficas de usuario (GUI) basadas en Ajax también lo difunden con profusión.

¿Quieres saber las implicaciones y lo que opino sobre todo lo anterior? Por favor, lee la entrada siguiente y última de esta serie sobre estructuras de datos maestros comunes titulada «Paradojas en el proceso».

[Ilustración 1: Software as a concrete block. Blog ZDNet Phil Wainewright]
[Ilustración 2: Esquema de mySAP Business Suite. SAP]

Posted in integración | Etiquetado: , , , , , , , | Leave a Comment »

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.]

Posted in software | Etiquetado: , , , , | 2 Comments »