Blog de JoseMPelaez

Aprendimiento: aprender del entorno con atrevimiento

Posts Tagged ‘arquitectura’

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 »

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 »