Desde hace algún tiempo la gente no deja de hablar de la arquitectura orientada a servicios, o SOA, por sus siglas en inglés. Actualmente existen muchas empresas importantes de software que ya están empezando a diseñar sus planes y sus estrategias para SOA; algunas hasta están pensando en fijar fechas de entrega. Ninguna empresa puede ignorar la SOA, ya que constantemente estamos escuchando que, desde el punto de vista del software, es el mejor invento desde que se creó el control remoto, por usar una analogía. No obstante las opiniones, los directores de informática de las empresas tienen que diseñar sus planes y prepararse para responder a la pregunta que hacen los directores ejecutivos: ¿qué estamos haciendo? Esta pregunta pone en evidencia el por qué cambiar a SOA no es una transición fácil y no se puede lograr usando trucos. En este artículo exploraremos las bases de SOA, los planes que tienen los principales proveedores de software para introducirla en el mercado, sus ventajas, las preocupaciones que se han generado en torno a ella y los factores que hacen que su implementación no sea cosa fácil.

Esta es la primera parte de la serie SOA desde el punto de vista de gestión.

¿Qué es SOA?

SOA es un conjunto de servicios o grupos de componentes que se encargan de llevar a cabo los procesos de negocios, tales como verificación de crédito, conversión de monedas o disponibilidad de inventario. SOA utiliza un estilo arquitectural para crear aplicaciones usando servicios de bajo acoplamiento que pueden operar entre sí. Este bajo acoplamiento hace que una aplicación no tenga que comprender, ni siquiera conocer, los detalles técnicos de un servicio para poder invocarlo. Así, SOA trata de promover una plataforma independiente y no está ligada a una tecnología específica.

Diariamente estamos en contacto con ejemplos de SOA. Uno muy común es un reproductor de DVD, que permite reproducir diferentes DVD. También se puede usar otro reproductor de DVD, aunque es posible que la calidad del sonido no sea la misma. Pero no debemos confundir SOA con la programación orientada a objetos (OOP). Siguiendo con el ejemplo del DVD, en OOP el DVD incluiría su propio reproductor, y no podría ser reproducido en otro aparato. Esto elimina una de las ventajas principales de SOA, la capacidad de reutilización. Si desea comprender la evolución de SOA, consulte el artículo Evolución de la arquitectura: desde la arquitectura de los marcos principales hasta la arquitectura orientada a los servicios.

El bajo acoplamiento también ayuda a ocultar un poco la complejidad técnica de la programación, y esto puede dar un impulso a la productividad. Por ejemplo, no es necesario saber cómo se realiza una revisión de crédito para completar una orden de venta. Sólo hay que saber qué información, tal como identificación del cliente y monto de la orden, necesita el servicio de revisión de crédito para aprobar o rechazar una solicitud. Es como aquellos tiempos en que las televisiones se armaban con componentes electrónicos distintos y la reparación implicaba únicamente reemplazar un componente, no toda la televisión.

SOA introduce términos y conceptos nuevos, o conceptos viejos con un léxico nuevo, y ambos implican que vendrán decisiones difíciles en el futuro. El uso de servicios conlleva un alto tráfico de mensajería. Por eso, es necesario contar con la tecnología que permita manejar dicho tráfico y su flujo en la carretera de la información. Un bus de servicio empresarial (ESB) facilita la conexión entre los sistemas legados y los servicios. Los ESB son especialmente eficaces con los procesos que funcionan a largo plazo, los que invocan varios servicios como compras, los que pueden comprender búsqueda de artículos, precios, condiciones de descuento, etc. Los servicios que ya han sido desarrollados y probados deben residir en alguna parte.

Por lo general, los servicios se publican en registros o directorios y se almacenan en depósitos. Esta combinación de infraestructura sirve para controlar el acceso, especificar los parámetros de introducción de información y hacer cumplir los parámetros de desempeño en tiempo de ejecución. La generación de reportes y de alertas, que está relacionada con el desempeño y los servicios posteriores, goza de una aceptación cada vez mayor y es necesaria para garantizar que las aplicaciones aprovechan SOA al máximo. Sin embargo, siguen presentándose decisiones difíciles, tales como la plataforma de desarrollo, la integración con los servicios web y los protocolos de pruebas y depuración, y estas cuestiones deben coexistir con la tecnología y la topología de red con que usted cuenta actualmente.

Los principales proveedores ya están empezando a delinear sus visiones de SOA. Por ejemplo, SAP, que se basa en su plataforma de desarrollo e integración NetWeaver (consulte el artículo SAP NetWeaver para múltiples propósitos), se enfoca en ofrecer modelos o paquetes definidos con mucha precisión, en lugar de ofrecer actualizaciones a gran escala de componentes que están enlazados entre sí. Al ofrecer modelos de los procesos de negocios, SAP da a los usuarios un medio para iniciar su funcionamiento en poco tiempo, suponiendo que los modelos se adaptan a las restricciones de sus negocios.

Oracle trata de fusionar el código del software que resultó de su adquisición reciente de PeopleSoft, y lanza Project Fusion para ofrecer un ambiente más abierto. De la misma forma, el enfoque de Oracle es proporcionar herramientas que le ayuden a modelar sus procesos de negocios. Entre estas herramientas se encuentran una plataforma de desarrollo de procesos de negocios y componentes de middleware y base de datos, que Oracle ofrece abiertamente a los proveedores externos. Este enfoque en la gestión de los procesos de negocios (BPM) puede producir un esquema de trabajo más abierto que dé como resultado componentes que se adaptan a su ambiente. Así, mientras el enfoque de SAP puede ayudar a simplificar y agilizar el proceso general de implementación de SOA, el plan de Oracle puede dar una mayor capacidad de adaptación de los aspectos únicos que llevan a una empresa al éxito.

Microsoft, que afirma tener el “verdadero enfoque” en SOA, defiende un método más gradual en el que usa avances en .Net Framework, SharePoint, 2007 Microsoft Office System, Exchange Server y Vista (consulte el artículo Los sutiles (o no tan sutiles) matices de la habilitación de Microsoft .NET). A diferencia del enfoque que se centra en la infraestructura empresarial, Microsoft adopta un enfoque por olas para ofrecer la interoperabilidad de SOA de forma gradual a las líneas de productos Microsoft Dynamics. Microsoft Dynamics, que se conocía como Microsoft Business Solutions, está formado por Axapta, Great Plains, Navision y Solomon. Al adoptar este enfoque, hará que algunas funciones estén disponibles antes para que los usuarios no tengan que esperar la introducción de la serie completa. Microsoft se ha comprometido con una etapa inicial llamada Wave 1, antes conocida como Project Green, que está a punto de completarse. Se espera que logre una apariencia común en todo Microsoft Dynamics. Obviamente, Office 2007 y Vista serán quienes definan el tono. Podemos esperar ver barras de navegación en el panel izquierdo que permitan un acceso más fácil, rastros en la parte superior de la página para regresar a los puntos de referencia anteriores y listones para los usuarios, que reemplazarán los menús tradicionales y las barras de herramientas con un conjunto de pestañas de los comandos comunes y más importantes. Se espera que Wave 2 se publique en el 2008 o el 2009, cuando las líneas de productos sigan alejándose de la codificación para el desarrollo por modelos usando herramientas y lenguajes Visual Studio .NET. Una vez que esta transición se complete, Microsoft podrá pensar en fusionar sus líneas de productos. Microsoft comparte dos posibles obstáculos con Oracle. En primer lugar está la integración uniforme de los paquetes de software adquiridos, para presentar un tema constante y familiar, mientras que en segundo lugar está la adopción de una capacidad de creación de modelos que le permita dejar de entregar los modelos, arriesgándose a sacrificar la velocidad de entrega por el bien de la flexibilidad. Si bien la visión de la arquitectura que tiene Microsoft parece más clara gracias al lanzamiento de Office y Visat y a nuestra familiaridad con ellos, el punto de partida para fusionar las líneas de productos no está muy claro, sobre todo cuando se le compara con SAP y Oracle.

SAP se interesa cada vez más en penetrar el mercado de las pequeñas y medianas empresas (PYME), por lo que su enfoque en proporcionar modelos de procesos listos para ser implementados tiene mucho sentido. La disponibilidad de las herramientas de modelado de Oracle da a las empresas que tienen recursos de tecnologías de la información (TI) la facilidad para aumentar sus propios servicios y personalizarlos de acuerdo a sus requisitos de negocios. Sin embargo, el enfoque similar de Microsoft resulta un tanto desconcertante, debido a que predomina en el espacio de las PYME.

En el mejor de los casos, los planes de los proveedores son poco precisos, sobre todo ahora que está aumentando el número de proveedores que se están subiendo al carro de SOA en su intento por generar nuevos ingresos por software. Ahora que lograron digerir el tan exagerado fenómeno del año 2000, muchas empresas están adoptando una actitud razonable de espera antes de lanzarse sobre la tecnología. ¿Quién puede culparlos?

¿Cuáles son los beneficios que aporta SOA?

No cabe duda de que SOA trae beneficios importantes y fáciles de lograr, que deben ser evaluados y analizados cuidadosamente. Esta prudencia se verá justificada al revisar algunos de los beneficios más sustanciales.

Capacidad para reutilizar los servicios

Actualmente, casi ningún programa se escribe desde cero. Por lo general, se inicia con un programa familiar que emula la funcionalidad que se está tratando de crear o que proporciona una uniformidad estructural. Ahora, tomemos esta filosofía y agreguémosle servicios y rutinas incluidos. El verdadero poder de SOA reside en la capacidad para reutilizar los servicios. Las empresas se están dando cuenta de que se reduce drásticamente el tiempo de desarrollo, se simplifica mucho el flujo de la lógica del programa y se elimina el esfuerzo de duplicación. Un servicio bien mantenido y probado puede reutilizarse en toda la empresa. Algunos estudios realizados recientemente indican que la capacidad para reutilizar los servicios es el beneficio de SOA más conocido. Esto no debe sorprendernos, porque el concepto de capacidad de reutilización ha sido el nirvana que persiguen los grupos de TI desde que se codificó el enunciado SI... ENTONCES... O. Sin embargo, falta ver si SOA logrará este objetivo. No debemos olvidar que TI puede ser temperamental e independiente.

Agilidad

Recordemos que uno de los problemas relacionados con el cambio al año 2000 era interpretar el uso de dos cifras para designar el año. Se creía que buscar todas las rutinas que involucraban una fecha en cada programa sería una pesadilla, y que sería la fórmula segura para el reemplazo de todos los sistemas legados. Supongamos que el manejo de datos se consideraba como un servicio capaz de garantizar la precisión del formateo y el cálculo de periodos. El asunto del año 2000 no habría sido la tan grande preocupación que todos pensaban. Esta analogía puede aplicarse a los procesos de negocios que cambian con mayor frecuencia. ¿Quiere cambiar la política de precios para atraer más clientes? ¿Sus deudas aumentan sin control y lo hacen pensar en hacer sus procedimientos de revisión de crédito más estrictos? Si estos procesos se suministraran como servicios centralizados, sería posible aceptar estos cambios al negocio de forma rápida e inmediata. Cuando SOA se lleva a cabo correctamente, le da un nuevo significado a la agilidad y al concepto de cambio repentino de dirección.

Gobernabilidad y seguridad de la empresa

Desafortunadamente, esta ventaja deplora el triste estado de TI, pero es necesaria para que SOA funcione con eficacia. La gobernabilidad de la empresa promueve la conformidad con las políticas y los estándares y asegura que todos están en el mismo canal. Es posible persuadir, impulsar o forzar a los desarrolladores para que usen servicios basados en depósitos si quieren que sus aplicaciones vean la luz. Así, SOA puede facilitar el cumplimiento de la ley Sarbanes-Oxley (SOX) y los reglamentos específicos de la industria, dando una mayor importancia a la gobernabilidad de SOA. Y cuando el personal que modela los procesos de negocios comprende que hay que usar los servicios, la necesidad de proporcionar un acceso seguro a estos últimos viene naturalmente. Pero esto puede ser un arma de dos filos. Cuando el uso de servicios es necesario, hay que establecer un canal de comunicación que permita que todas las personas conozcan y puedan buscar aquéllo que se puede reutilizar. Si bien los registros y los directorios pueden facilitar esta comunicación, hay que agregar métodos proactivos que complementen estas herramientas pasivas.

Capacidad de graduación y de manejo

La capacidad de graduación y la capacidad de manejo se traslapan cuando se refieren a los beneficios que explicamos antes. Sin embargo, hay que poner especial atención a estos dos beneficios, principalmente porque son esenciales para una que una empresa de TI funcione de forma eficaz y eficiente. Cuando se hace un cambio a una interfaz de programación de aplicaciones (API) en un ambiente de SOA, la actualización sólo debe aplicarse en un lugar. El hecho de proporcionar una ubicación central para los servicios debe hacer que la gestión sea más fácil y uniforme. Además, a medida que los servicios adquieren popularidad en la empresa, su introducción se vuelve más directa y se va convirtiendo en una rutina.