El mundo real: Aplicaciones heterogéneas y herencia histórica

Cualquiera que haya debido resolver el problema de cómo "informatizar" una empresa o institución de volúmen importante, sabe que la solución no es simple ni lineal. Una empresa es un cuerpo social, con actividades variadas, complejas, y en evolución constante, en interrelación con la sociedad, ya sea vista como mercado, como proveedores, como exigencias normativas, o como recursos humanos internos, por mencionar lo más evidente. Podríamos llamar a estos elementos, extensión de la empresa. A ellos les debemos agregar la dimensión temporal: La empresa, salvo que la hayamos incubado en nuestra cabeza como categorías kantianas, viene de una historia, y está sujeta a cambios constantes originados en la evolución del mercado, los condicionantes sociales, y las estrategias comerciales.
En este contexto, qué sucede invariablemente con los sistemas de información de la empresa: Comienzan coherentes y completos para un área y una necesidad determinada, y en el mejor caso, en el marco de un proyecto de sistemas delineado hacia el futuro. Luego, cuando se comienza a cubrir un nuevo área, cambia la legislación, los objetivos comerciales, los integrantes del equipo, y el primer módulo en producción no ajusta 100% con el siguiente. Luego la empresa crece o se achica, y el plan no sirve, y una parte es descartada, y reemplazada por otra con nuevos objetivos y tecnología. Pero los módulos preexistentes no pueden ser abandonados completamente, porque cubren confiablemente una parte de la actividad, y comienzan a coexistir productos heterogéneos. Y este ciclo se repite en una espiral de complicación.
Así se va construyendo la compleja arquitectura de información de una empresa mediana o grande: plataformas variadas, con un recurso principal para las actividades críticas, que a la vez alberga otras aplicaciones heredadas no reeplazadas, y aplicaciones de uso localizado (tareas de ingeniería, de Investigación de negocios, redes locales para tareas de oficina, etc); sistemas operativos variados dialogando, lenguajes principales y secundarios, equipos de personas manteniendo sistemas por vías imprevistas (un programador externo sosteniendo una aplicación de lectura de aparatos, una consultora a cargo de una aplicación de Inteligencia de Negocios, un equipo en el sistema de recursos humanos, etc, etc).

Los ERP son una solución?

Una difundida solución, tanto más difundida cuanto más presupuesto disponible tenga la empresa, es recurrir a un ERP (Enterprise Resource Planning, o Aplicaciones de Planeamiento de Recursos a nivel de la Empresa). Qué es un ERP?. Por tomar una, esta es la definición de Whatis, en SearchSap:

ERP (Enterprise resource planning) is an industry term for the broad set of activities supported by multi-module application software that helps a manufacturer or other business manage the important parts of its business, including product planning, parts purchasing, maintaining inventories, interacting with suppliers, providing customer service, and tracking orders. ERP can also include application modules for the finance and human resources aspects of a business. Typically, an ERP system uses or is integrated with a relational database system. The deployment of an ERP system can involve considerable business process analysis, employee retraining, and new work procedures. In a recent trend, SAP, Peoplesoft, and J. D. Edwards are among ERP product providers offering ERP outsourcing.

Es necesario aclarar que en esta página se restringe el significado de EAI al software comercial, ofrecido como solución. En sentido amplio, se debe considerar ERP a todo conjunto integrado de administración de una empresa, sea comprado o desarrollado internamente. Dicho esto, volvemos a la definición: como vemos en ella, la tentación consiste en tener solucionado en un solo paquete, con confianza en que fue planeado siguiendo una filosofía actualizada y exitosa para la gestión y el control de las operaciones, y todo esto, disponible "en un solo paso". Más aún, más de una vez, un gerente o una directiva sienten el alivio de que pasan a otro, comunmente a una consultora, el peso de la solución de aspectos vitales del negocio.

En pocas palabras, qué es lo positivo de un ERP?

• Solución completa e integrada: cada parte encaja con la otra
• Lo mejor del conocimiento en el paquete: La aplicación de la teoría y mejores prácticas para la gestión
• Toda la solución de una sola vez, llave en mano

Y qué es lo negativo:

• Costo directo en general sumamente alto
• Costo indirecto más o menos oculto: largas horas de consultoría, largas horas de reentrenamiento
• Por lo general, demasiado complejo para las necesidades medias, finalmente requiere hacer más de lo deseable, para que funcione
• Poco flexible al cambio; por lo general se entra en conflicto con la propiedad de las modificaciones, o con el costo de consultoría de modificaciones

Lo irónico o paradójico de todo esto es que frecuentemente, al final del proceso tenemos al ERP como otro sistema heredado más, si el costo de implantar el cambio en el producto es inviable. Entonces, las adecuaciones se realizan paralelas al tronco principal del ERP, y poco a poco queda obsoleto, con islas conectadas por puentes al sistema. Hoy podríamos agregar un nuevo elemento: uno de los argumentos en favor de contratar un ERP, es su estabilidad. Esta estabilidad ha sido puesta en cuestión tras la compra de JDEdwards por Peoplesoft, y el intento todavía en curso, de compra hostil de Peoplesoft por parte de Oracle. Peor aún, SAP mismo pareció trastabillar, tras trascender una oferta de compra de parte de Microsoft. Al día de hoy, podría preguntarse cuál es la opinión de los usuarios de JDEdwards, acerca del futuro de su compra.

Este mes (Agosto 2004), justamente refuerza las dudas la decisión de Ford Motor Company, de discontinuar su proyecto Everest, basado en una solución construída junto a Oracle, debido a insatisfacción en su rendimiento, tras más de cuatro años de desarrollo y dedicación de fondos. Una inversión de un volumen que traerá consecuencias: ochenta millones de dólares iniciales, hasta llegar a un total aproximado de 200 millones, con una participación de más de trescientos miembros de su equipo. Los anuncios no han sido muy específicos, pero traslucen desacuerdo con el resultado del producto; uno tal que vale 200 millones de dólares. El caso es que Ford vuelve atrás a su solución propietaria. Responsabilidad de quién? No hay duda de que por un buen tiempo será un caso de estudio. Más comentarios y referencias al proyecto en la página de noticias.

Es el desarrollo propio (in house) una solución?

Mucho más común y promedio es acudir a un equipo interno de desarrollo. Tradicionalmente, cualquier empresa mediana establecía su departamento de informática, y sostenía, con suerte diversa, sus propias aplicaciones. En la medida en que la informática devino una disciplina más rigurosa, otras soluciones se fueron ofreciendo como alternativa, y así la existencia de un departamento de informática, dependiendo del tamaño de la empresa, devino agencia externa, asesoría, o alguna otra forma de externalización. En cualquier otro caso en que el área informática se hubiera mantenido, su éxito depende de la adopción de criterios más rigurosos que el pionerismo de otras décadas. Hoy existen metodologías aceptablemente probadas, y las herramientas y productos han evolucionado hacia un modo de construcción y mantenimiento del software modular, riguroso, "componible", que permite hablar de "fábrica de software". En estas condiciones, la viabilidad del desarrollo interno depende de la adopción de buenas prácticas y una filosofía de desarrollo adherida a las tendencias corrientes a la componentización de los sistemas.

Integración de Aplicaciones en la Empresa (EAI)

Este material es el que ha sido la ocasión de desarrollo de una disciplina crecientemente importante: la integración de las aplicaciones del mundo real (es decir, el conglomerado heterogéneo resultante en el transcurso del tiempo) en la empresa. Nuevamente, la definición de Whatis:

EAI (enterprise application integration) is a business computing term for the plans, methods, and tools aimed at modernizing, consolidating, and coordinating the computer applications in an enterprise. Typically, an enterprise has existing legacy applications and databases and wants to continue to use them while adding or migrating to a new set of applications that exploit the Internet, e-commerce, extranet, and other new technologies. EAI may involve developing a new total view of an enterprise's business and its applications, seeing how existing applications fit into the new view, and then devising ways to efficiently reuse what already exists while adding new applications and data. EAI encompasses methodologies such as object-oriented programming, distributed, cross-platform program communication using message brokers with Common Object Request Broker Architecture and COM+, the modification of enterprise resource planning (ERP) to fit new objectives, enterprise-wide content and data distribution using common databases and data standards implemented with the Extensible Markup Language (XML), middleware, message queueing, and other approaches.

EAI es una disciplina de aplicación de conocimiento, recurriendo a herramientas diversas, para hacer coherente un conjunto heterogéneo de aplicaciones en escenarios cambiantes. Mientras que el problema se ha vuelto más complejo, la posibilidad de hechar mano a soluciones efectivas ha crecido simultáneamente: Como vemos en la definición, las variantes de tecnología de componentes (CORBA, COM, EJB), la utilización de patrones de diseño, la posibilidad de recurrir a un mercado de componentes, los conectores ODBC y JDBC, las nuevas arquitecturas de servicios Web, los sistemas de mensajes, entre otras facilidades, son la batería de recursos a la mano de quienes deciden integrar y unificar los sistemas de información en una empresa. En la definición de IT-ToolBox, estas son las áreas relevantes, y niveles de aplicación, de EAI:

What is involved in EAI?
EAI is very involved and complex, and incorporates every level of an enterprise system - its architecture, hardware, software and processes. As defined by ITtoolbox, EAI involves integration at the following levels:

• Business Process Integration (BPI): When integrating business processes, a corporation must define, enable and manage the processes for the exchange of enterprise information among diverse business systems. This allows organizations to streamline operations, reduce costs and improve responsiveness to customer demands. [6] Elements here include process management, process modeling, and workflow, which involves the combination of tasks, procedures, organizations, required input and output information, and tools needed for each step in a business process.
• Application Integration: At this level of integration, the goal is to bring data or a function from one application together with that of another application that together provide near real-time integration.[7] Application Integration is used for, to name a few, B2B integration, implementing customer relationship management (CRM) systems that are integrated with a company's backend applications, web integration, and building Web sites that leverage multiple business systems. Custom integration development may also be necessary, particularly when integrating a legacy application with a newly implemented ERP application.
• Data Integration: In order for both Application Integration and Business Process Integration to succeed, the integration of data and database systems must be tackled. Prior to integration, data must be identified (where it is located), cataloged, and a metadata model must be built (a master guide for various data stores). Once these three steps are finished, data can then be shared/distributed across database systems.
• Standards of Integration: In order to achieve full Data Integration, standard formats for the data must be selected. Standards of Integration are those that promote the sharing and distribution of information and business data – standards that are at the core of Enterprise Application Integration. These include COM+/DCOM, CORBA, EDI, JavaRMI, and XML.
• Platform Integration: To complete the system integration, the underlying architecture, software and hardware, the separate needs of the heterogeneous network must be integrated. Platform Integration deals with the processes and tools that are required to allow these systems to communicate, both optimally and securely, so data can be passed through different applications without difficulty. For example, figuring out a way for an NT machine to pass information reliably to a UNIX machine is a large task for integrating an entire corporate system.

En IT Toolbox, Ranbir, un colaborador del sitio, expresa en un artículo de su Blog, las características que un desarrollador dedicado a la integración de aplicaciones debiera tener. Por supuesto, la lista de requerimientos va a variar de un caso a otro, pero una ojeada a la lista es reveladora del esfuerzo que la actividad requiere: Java, C++, OO (Encapsulado, Interfaces), Arquitecturas, Patrones de Diseño, J2EE, Mensajería (MOM), SOAP, Metodos de manejo del ciclo de vida... Otro artículo suyo enumera el grado de dificultad y de heterogeneidad de los elementos que entran en juego: Variedad de Lenguajes, procedurales ú orientados a objeto, variados sistemas de base de datos, variados conjuntos de aplicaciones cliente/servidor u otros, variados componentes de middleware, diferentes modelos de datos y de compartir la lógica, para "poner las manzanas y las naranjas a hablar". Otro breve pero útil comentario lo brinda Scott Robinson en Developer.com, discutiendo las particularidades que implica trabajar con un ERP. Este artículo es recomendable si se proyecta diseñar, no comprar un paquete cerrado.

Model Driven architecture e Integración de Aplicaciones

De lo que vemos, está claro que resolver la integración de aplicaciones requiere ocuparse de múltiples plataformas, Bases de Datos, lenguajes de programación, y articular distintas arquitecturas como algunos de los desafíos más relevantes. En este contexto, los principios asociados a la iniciativa MDA (Model Driven Architecture) pueden cumplir un papel fundamental en la construcción de soluciones. Dos aspectos colaboran a ello: La mediación entre el código final y el modelo conceptual del problema que permite el uso de un generador de código específico a un problema o plataforma. Una importante ventaja de esta característica, es que permite disminuír las necesidades de conocimiento sobre una variante particular, acortando el tiempo de conocimiento, y su costo. Por supuesto, el acortamiento en tiempos de respuesta, al disponer de un generador. El otro aspecto, es la posibilidad de articular distintas visiones adecuadas al nivel de plataforma. De esta forma, bajo el paraguas de una sola solución, un solo modelo del problema, es posible establecer un plano articulado con su descripción en distintos ambientes. Existe un interesante trabajo que destaca la importancia de MDA en éste área, escrito por Sundar Vaidyanathan, publicado en Business Integration Journal, donde ofrece una visión de cómo efectuar esa aplicación, destacando el uso del modelo PIM (Platform Independent Model) para el diseño del modelo a nivel abstracto, correlacionado con las aplicaciones legacy que correspondiera, y el modelo específico de una plataforma determinada (PMS) incorporando las APIs específicas de cada plataforma articulada.
Sobre este mismo punto, un interesante papel de Metamatrix explica en mayor detalle la idea.

Patrones de Diseño en EAI

El uso de patrones de diseño crecientemente se ha convertido en un recurso de productividad en todos los campos de la construcción del software, e indudablemente son aplicables al universo de la Integración de Aplicaciones. Se trata de una especialización de los criterios de creación de patrones: aplicar soluciones probadas y aceptadas a problemas y escenarios recurrentes, en este caso, de la integración de funciones y sistemas heterogéneos. Muchas herramientas MDA son capaces de aplicar o crear patrones en el contexto de sus modelos, sea a nivel independiente de la plataforma, o no. Gartner llama ARAD a las herramientas que unen criterios de modelado abstracto con el uso de patrones (Architected Rapid Application Development, siendo RAD por el desarrollo rápido con un generador, y Architected, por el modelado abstracto y el uso de patrones). Una excelente aproximación al uso de patrones en EAI, lo da el sitio mantenido por Martin Fowler y Gregor Hohpe, Enterprise Integration Patterns, que aporta un buen número de patrones en áreas tales como Estilos de Integración, Sistemas de Mensajería, Canales, Ruteo, Transformación, Administración del Sistema, etc.

Nuevos estándares impactan la aproximación a EAI

Mas allá de las influencias comerciales (siempre es necesario empujar una nueva ola de ventas con un "nuevo" concepto), se está produciendo un desplazamiento o extensión, o reinterpretación, de la idea de componentes (Corba, COM) que resultara fundamental en años recientes (y continuará siéndolo), moviéndose hacia los estándares denominables "loosely coupled", al facilitarse el uso de la Web. La aparición de SOA (Service Oriented Architectures, Arquitecturas orientadas a Servicio) y de Servicios Web (Web Services) tiene como objetivo precisamente a las Aplicaciones de Empresa, y su integración tanto a nivel interno como a nivel de comunidades de Empresas (Una empresa con sus proveedores, una comunidad de empresas con un organismo de gobierno). Se trata de estándares en formación, quizá todavía no completos o insuficientes, pero prometedores por su característica de utilización abierta de un servicio publicado. Existe mucha literatura al respecto, y aquí se irán agregando referencias. Un caso apropiado, uniendo el uso de patrones visto arriba con estos estándares, se puede ver en el artículo de Sean Neville, en Enterprise Integration Patterns.

Plex como herramienta de integración

En este marco, Plex está en condiciones de actuar como integrador para un alto porcentaje de las tareas a resolver. Se podría incluso disentir con el alcance que le da a Plex su propietario, Computer Associates, que pareciera reducir su ambito de aplicación, o no destacarlo como integrador: sólo este año comenzamos a verlo estrechamente vinculado a la familia de productos destinados al manejo completo de ciclo de vida del software. Como se ha dicho detalladamente en otras páginas, la virtud principal de Plex es la de diseñar un modelo abstracto altamente cohesionado, con la capacidad de ser implementado sobre una gran variedad de alternativas. Ya de por sí, esta capacidad básica lo destaca como herramienta de integración, al permitir transladar a nuevos escenarios, o al permitir establecer puentes, con una gran variedad de plataformas y bases de datos. Aquí describiremos el conjunto de recursos disponibles en Plex utilizables como herramientas de integración. A continuación se enumeran, dentro de lo posible con casos, los principales recursos utilizables en Integración, y en entregas futuras iremos dando uno o más casos de cada una de las posibilidades existentes:

• El uso del utilitario Integrador de Aplicaciones.
Este es el componente explícitamente desarrollado para representar, dentro de un modelo de Plex, a procesos y almacenamientos de datos externos. Al decir "externos", partimos del hecho de un universo de aplicaciones desconectadas, ya sea por herencia histórica, o por aparición de nuevos actores, y nos referimos a la posibilidad de reencauzar los procesos o la lógica de negocios basados en las facilidades de Plex, incorporando al modelo lógico tanto a las estructuras de datos, como a las funciones que los manipulen. Cuál es la idea?: Tomar la base de datos de que se trate, y sus funciones de manipulación, y traducirlas en objetos del modelo. Por un lado, las tablas y otras fuentes de datos serán representadas como Entidades dentro del modelo. Por otro lado, los programas que manipulen los procesos y accesos a datos, pueden reescribirse usando las facilidades de Plex, o asimilarse como funciones. La función será tratada como una función tipo API dentro del modelo, y se tendrá como interfase a sus parámetros, si los hubiera, los que se convierten así en la bisagra de integración con el modelo. En el proceso de asimilación, es posible asignarle herencia a las entidades y funciones que se agregan, así como precisar los tipos de datos tan ajustadamente como se requiera, antes de que estén mapeados como objetos del modelo. Digamos que este proceso de asimilación es muy rápido, permitiendo, una vez que los objetos estan representados, tratarlos como una parte más del modelo interno, con las facilidades de diseño inherentes a Plex.
• La utilización de componentes.
Desde sus primeras versiones Plex soporta la utilización de ActiveX dentro de su modelo, y desde la época de Sterling (Plex 3.0 en adelante) el objetivo de importar componentes al modelo, y crear componentes, fue un objetivo declarado. La importación comenzó a ser viable a partir de la versión 5.1 como módulo separado, y está más madura en la versión 5.5, en proceso de comercialización. La importación de componentes es válida para Activex, COM+, Java Beans y EJB. La exportación es viable como EJB connectors. La importancia de cada una de las dos posibilidades es grande: Al importar al modelo, podemos crear una representación de los procesos y objetos del negocio dentro de Plex, permitiendo que éste articule la solución integrando actividades existentes, o agregando nueva funcionalidad comprada como partes específicas a un problema: Por ejemplo, la integración del uso de lecturas de barras o seguimiento GPS, hecho a través de conectores especializados, e integrados al modelo a través de sus interfases. La exportación permite integrar en una solución mayor, a un modelo de Plex, o establecer una estructura J2EE para integrar el conjunto de aplicaciones de la empresa.
• La integración en el marco COM.
Si bien está relacionado con el caso anterior, separamos esta posibilidad debido a que se trata de una utilización simple de funciones Plex en un marco OLE2, registrando la función para OLE. De esta forma cualquier función Plex que no sea un panel, puede ser llamada y controlada por un cliente de OLE Automation (controllers) usando el protocolo de OLE Automation. Así, una función Plex puede ser llamada por un programa Visual Basic, Excel, Word, u otras que usen OLE.
• El uso de conectores ODBC y/o JDBC
La posibilidad de recurrir a ODBC o JDBC es hoy generalizada, y Plex es una más entre las herramientas que lo pueden hacer, mediante clientes Visual C++ o Java, y recurriendo a combinaciones abiertas: Es posible combinar llamadas a múltiples bases de datos, y usar los dos conectores, y ambos integrados con otras soluciones (básicamente, con acceso articulado a un ISeries con DB2). Sobre un servidor Windows BAckoffice es posible construír un servidor de aplicaciones, que redirija a distintos servidores de datos las solicitudes, tanto para replicar datos, como para conectar distintas bases de datos, sobre cualquier plataforma que pueda dialogar con él. Es posible que la ubicación de las bases de datos sea determinada en el diseño, o directamente en tiempo de ejecución. Esta combinación permite que se conecten una base DB2, una SQLServer, una Oracle, una Sybase y cualquier otra, incluso accediendo a datos sólo texto.
• El empaquetamiento de funciones y fuentes de datos externas.
Esta posibilidad es el método principal al que recurre el utilitario Application Integrator, leyendo y representando en el modelo la estructura de bases de datos y funciones externas, declarándolas no implementables en el modelo, accediendo a las funciones como cajas negras que reciben y devuelven parámetros. Este medio puede usarse a todo nivel para representar en un modelo una aplicación o función externa, ya sea de nivel de sistema operativo, o de nivel de aplicación. Así cualquier actividad externa que deba ser reformulada o interpretada en el nuevo modelo, es factible de ser mapeada y utilizada.
• La utilización de sistemas de Colas de Mensajes.
Brevemente, y más adelante se explicará, es posible utilizar sistemas de colas de mensajes como MQSeries de IBM.
• La utilización de aplicaciones Web.
Desde la aparición de la variante Java, con la posibilidad de implementarla como Applets, y la posterior aparición de Websydian, es posible representar en un modelo extendido con el generador Java o con los patterns de Websydian, un modelo cualquiera para ser utilizado como aplicación Web, ya se trate de una Intranet, Extranet, o directamente sobre la Web. Esto no sólo permite extender un modeo Plex a la Web, sino pensar en el uso alternativo de un cliente fino Web en lugar de la ya clásica interfaz gráfica de usuario Cliente/Servidor (Fat client vs Thin Client), con las facilidades que implica desde el punto de vista de la distribución de la aplicación.
• La integración en servicios Web.
La aplicación de los patrones de diseño de Websydian permitió, a partir de su versión 3.0, utilizar y crear Servicios Web, mediante SOAP. Los servicios Web están siendo propuestos como la principal herramienta de integración en entornos empresarios heterogéneos, y es particularmente válido cuando esa integración supera el marco de la empresa, una situación que se está dando crecientemente. Así, la utilización de servicios Web facilita la vinculación de empresa y proveedores, empresa y servicos externos, sea provados u oficiales, mediante un marco abierto.
• La utilización de la plataforma .NET.
Puede verse como una continuidad de lo indicado para servicos Web, ya que ese es uno de los principales objetivos de la plataforma, con lo que se está agregando la posibilidad de que una apliación Plex sea generada para la plataforma .NET. Esto está disponible a partir de la versión 5.5, pendiente de entrega al día de hoy en el mercado.
• La incorporación a EJB y J2EE.
Como decíamos al hablar de componentes, es posible incorporar a aplicaciones construídas para J2EE. Veremos más adelante casos detallados.