Blog de JoseMPelaez

Aprendimiento: aprender del entorno con atrevimiento

Posts Tagged ‘SOA’

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 »

Maestros y estructuras

Posted by josempelaez en Viernes, 27 junio 2008

Hace pocos días estuve contrastando opiniones con Luis-tic616 y Rafa en el Diario de un Director de sistemas sobre la interacción entre aplicaciones empresariales. Luis decía:

«Creo que hay que resolver todavía como disponer de estructuras maestras comunes para las transacciones particulares – el caso típico es el de maestro de clientes.»

Para pensar un poco más y tratar de fundamentar las mías he regresado en buena medida al pasado, cuando aún no se hablaba de “aplicativos”. Para el que vaya a leer esta entrada en el blog, aviso de antemano que sólo va a ser la primera parte de mi argumentación.

Enlace entre bloques estructuralesEn 1973, mi padre cambió mi regla de cálculo por una calculadora científica para que ganara agilidad en la resolución de problemas de resistencia de materiales. Gastó unos 4.700€ de hoy (actualizando con el IPC) en una HP45, pero debió de pensar que merecía la pena si yo aprobaba finalmente la materia que amenazaba con retenerme en 2º de carrera. Desarrollé mucha destreza ejecutando algoritmos a mano con la curiosa RPN, y pasé de curso (no sólo gracias a la maquinita, claro).

Pocos meses después, ya en 3º, aprendí a programar procesos de cálculo en Fortran IV en un miniordenador de HP con tarjetas perforadas. Por cierto, recuerdo que, por aquella época, uno de nuestros profesores iba a uno de los famosos cursos de IBM para enterarse de lo que era el time-sharing. El Cobol sólo me sonaba de nombre, y así se quedó poco más o menos. Me dijeron que era para “programas de gestión”, y que nosotros éramos ingenieros. Además de resolver ecuaciones con métodos numéricos, nos adiestrábamos programando juegos, como el clásico del ahorcado, o calculando duraciones de proyecto e identificando caminos críticos en un grafo PERT. La “gestión” era otra cosa, y se aplicaba en la banca, seguros, administración pública….

En la primera mitad de los 80 tuve que utilizar ordenadores IBM en la ingeniería donde trabajaba. Me familiaricé con los lotes (batch processing), el JCL, los ficheros indexados (ISAM) y las bases de datos transaccionales jerárquicas (IMS). El análisis funcional y orgánico de la época me introdujo en los modelos de datos, el distingo entre transaccionales y maestros y en la «arquitectura de información».

De alguna forma reviví las estructuras resistentes y sus «muros maestros». Estas aplicaciones se sustentaban en datos y no en procesos. Los modelos de comportamiento rígido, elástico y plástico resurgieron como agradables recuerdos (me gradué en la especialidad de estructuras). Lo que ahora no veía en este marco era el aislamiento de elementos mediante condiciones de contorno, tan típico de mi querido análisis estructural. En éste, las acciones externas y elementos colindantes se aislaban mediante su representación con campos de fuerzas. Éstas “solicitaban” al elemento resistente, que respondía deformándose (si no se rompía) y reaccionando.

Programando en Fortran descomponíamos los problemas en módulos de flujo que codificábamos en bloques estructurados. También empleábamos muchas funciones y subrutinas, que devolvían resultados (request-response) sin saber cómo estaban programadas aquellas bibliotecas (libraries) de cálculo reutilizables. Era algo que me resultaba familiar.

Ahora ya no programaba, pero en los análisis que hacía —para “lo de la gestión”— echaba de menos los flujogramas que diagramaba antes. En este trabajo lo importante eran los «organigramas de datos», como yo los llamaba. Las relaciones entre elementos del sistema se habían reducido a las de las entidades de información, compuestas por ficheros o tablas de registros que variaban mucho (transacciones) o poco (maestros). Los “cálculos” que había que hacer eran «alta, baja y modificación» y, a todo tirar, teníamos que contar, sumar y dividir para sacar subtotales y medias. El súmmum eran los «totales de totales», también llamados “grandes totales”. Todo aquello, según IBM y Andersen Consulting, por lo menos, recibía el apelativo de Management Information System. ¡Qué curioso y sencillo me resultaba este enfoque, especialmente cuando soy de los que conserva sus viejos y apreciados instrumentos de cálculo (regla deslizante, HP45 y otras tres más, ya programables)!

Me perdí la entrada en la liza comercial de las bases de datos relacionales al cambiarme a la consultoría de dirección y a la gestión de personal. No obstante, recuerdo haber leído cosas sobre las reglas de Codd. Las simplifiqué mentalmente pensando que trataban, básicamente, de aportar flexibilidad, reducción de duplicados y consistencia de datos.

En 1992 escuché hablar por vez primera de la programación orientada a objetos. A mitad de esa década leí sobre el desarrollo basado en componentes: módulos encapsulados, débilmente acoplados y buenas abstracciones. En el “mundo real”, la BD Access de PC se popularizaba reemplazando al DBase III y Clipper en muchas empresas. Los lenguajes de programación 4GL habían hecho furor en las más grandes y pudientes de la mano de los SO Unix, y de la fulgurante expansión comercial de las BD relacionales (Oracle, Ingres, Informix, Sybase…) con sus 4GLs. Aparecieron los entornos RAD con Delphi, PowerBuilder, etc. que fueron cediendo terreno al Visual Basic. Ya en esta década, el auge de la web había catapultado a Java con su plataforma robusta y compleja, se popularizaron los lenguajes dinámicos (scripting) abiertos de internet, entró a competir la arquitectura .NET (un SO y varios lenguajes), y blablabla…

Por hoy lo voy a dejar aquí. Ya está bien de historieta. El próximo día pasaré raudo y veloz sobre flujogramas, organigramas, algoritmos, datos, maestros, profesores, consultores… y llegaré a mi destino, espero. ¿Será la SOA?

[Imagen: Equilibro estructural. Prof. Dr. Dimitris Theodossopoulos de la Universidad de Edimburgo. Ilustra dos sistemas estrucurales de la naturaleza que interactúan mediante un puente. Éste permite los intercambios entre ellos, además de soportarlos.]

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