Con esto concluye la serie SOA desde el punto de vista de gestión.

Hace tiempo, cuando los procedimientos y las rutinas eran el último grito, la gente no sabía si el uso de rutinas secundarias, con todas las bifurcaciones y el paso de datos que ellas implican, degradaban el desempeño más que la duplicación del código en el flujo. Actualmente, algunos talleres de tecnologías de la información (TI) tienen la misma preocupación con respecto al tráfico de mensajes en la arquitectura orientada a servicios (SOA). Los proveedores tratan de restarle importancia a esta preocupación explicando que las velocidades de procesamiento actuales compensan las llamadas de servicio y el uso de rutinas generalizadas. El problema es que hay que comparar manzanas con manzanas. Las mejoras a las velocidades de procesamiento beneficiarán tanto a los ambientes SOA como a los que no pertenecen a esta categoría. Hay que asegurarse de que en un ambiente SOA no se necesita tanto tiempo para terminar una transacción como se necesita actualmente en las empresas. De ahí la enorme importancia que tienen para el éxito de SOA las alertas de desempeño que se mencionaron antes.

La cultura de TI que prevalece en nuestros días es capaz de inhibir SOA. Por lo general, los talleres de TI se evalúan de acuerdo a las líneas de código que generen, y esto va en contra de la ventaja de la capacidad de reutilización que tiene SOA. Es necesario cambiar el paradigma para poder recompensar las implementaciones rápidas y ágiles en lugar de recompensar el tamaño y la complejidad de los programas.

La implementación de SOA es, sin duda, costosa. Para hacerlo, no sólo es necesario cambiar el diseño de la tecnología arquitectural existente, sino que hay que realizar una inversión importante en capital humano para que los analistas de negocios puedan definir los procesos de negocios finitos; los analistas de sistemas puedan convertir dichos procesos en especificaciones y los ingenieros de sistemas y los programadores puedan traducir todo esto en servicios funcionales y manejables.

Las herramientas que ofrecen terceras personas y que ayudan a supervisar y mejorar el desempeño en un ambiente definido por SOA, no han llegado a esta etapa de desarrollo, pero se están poniendo al nivel rápidamente. Los primeros usuarios en adoptar SOA deberán crear sus propios recursos o trabajar con los proveedores para probar las versiones beta de las herramientas. Es por ello que, por ejemplo, las empresas pioneras están usando cualquier aplicación -desde hojas Excel hasta simples bases de datos- como depósito para sus servicios. Al usar herramientas internas, las empresas pueden evaluar el panorama tecnológico con el propósito de determinar cuál es la mejor solución para su infraestructura.

Si bien existen diferentes opiniones sobre este tema, muchas personas están convencidas de que los servicios web son un elemento esencial de SOA. Quienes comparten este punto de vista creen que hay que implementar los servicios web correctamente para crear un ambiente SOA sólido. Es posible que algunas empresas prefieran esperar a ver qué sucede, pero este es el momento adecuado para organizar sus servicios web.

Ahora que las implementaciones de SOA empiezan a ser más comunes en las empresas, las soluciones tradicionales y manuales de gobernabilidad -como las revisiones estructuradas, las pruebas piloto que se llevan a cabo en las salas de juntas y los reportes que se generan después de los hechos- pueden resultar inadecuadas. Por consiguiente, será necesario revisar los elementos del enfoque al ciclo de vida del sistema si se quiere incorporar una estrategia de gobernabilidad más proactiva. Si cree formalmente que el ciclo de vida de su aplicación le ha servido bien a la empresa durante muchos años, es posible que deje pasar la oportunidad de SOA y los beneficios que ella conlleva.

¿Cómo llegar a SOA?

Ya está interesado en SOA. Está convencido de las ventajas que puede traerle y está ansioso por empezar. Pero hay que tomar las cosas con calma.

SOA no es algo que los ejecutivos de las empresas acepten fácilmente. Si bien le ayuda a su empresa a ser más flexible y ágil, no es fácil analizar su rentabilidad o concretizar la reducción de costos que puede producir usando únicamente el argumento de la flexibilidad y la agilidad. Salvo en los casos raros en que la capacidad de respuesta de una empresa puede ser el factor que determine si esta gana o pierde participación en el mercado, la justificación de un cambio tecnológico depende de que logre resolver os problemas del negocio o represente una ventaja competitiva. Recuerde cómo el problema del año 2000 trajo enormes actualizaciones a los sistemas, no porque permitiera hacer un uso más eficaz de la tecnología, sino porque amenazaba con cerrar los negocios.

Como se expresó antes, la capacidad de reutilización de los servicios es uno de los principales atractivos de SOA. Pero llevar este concepto a la realidad no es tan fácil. Si no fuimos capaces de hacerlo para los objetos, no podremos hacerlo para los componentes. ¿Por qué sería diferente con SOA? ¡Claro! La gobernabilidad corporativa será la fórmula mágica. Aún cuando la gobernabilidad corporativa es capaz de hacer cumplir la política de SOA, estaríamos agregando otro nivel de gestión y probablemente de personal. ¡Excelente! Ahora somos los responsables de un aumento en los gastos de mano de obra y los gastos generales.

SOA se puede explicar como informática empresarial, servicios reutilizables y una metodología de creación más rápida. SOA puede ser un concepto directo y fácil de comprender, pero implica una curva de aprendizaje pronunciada para aquellas empresas que quieren adoptarla y cosechar sus beneficios. Los desarrolladores tradicionales, que adoptan un enfoque mucho más general a la integración de aplicaciones, deben dividir los flujos y los procesos en partes más pequeñas si quieren que la capacidad de reutilización prospere. Si se desarrolla un grupo de base de profesionales de TI para encabezar el esfuerzo, no sólo se limitará su exposición a los obstáculos menos importantes, sino que se creará un grupo de discípulos de SOA que se encarguen de difundir el mensaje.

Existe otro paradigma que hay que cambiar, y es la imagen tradicional del profesional de TI. No es suficiente la imagen del ermitaño de “bits y bytes” que live en alguna cueva tecnológica y habla en un lenguaje de siglas. Si los profesionales de TI quieren trabajar junto con sus homólogos comerciales para modelar procesos finitos, es necesario que ambos grupos hablen el mismo idioma, es decir, la lengua del usuario final. Probablemente crea que su empresa ya ha superado este obstáculo, pero trate de corroborarlo con la comunidad de usuarios. No cabe duda de que los buses de servicios empresariales (ESB), los depósitos y los directorios son importantes para el éxito eventual de SOA, pero no deben ser un tema de preocupación para los usuarios.

Sin embargo, la pregunta del millón de dólares es ¿cómo implementar SOA? Algunos proveedores sugieren hacerlo de forma gradual, pero esto es como tener un pie en un barco (el ambiente SOA) y otro en tierra firme (la infraestructura de software actual). A medida que el barco se aleja, sus recursos deben estirarse más y más hasta llegar a un límite. Usted cae al agua y tanto su estado actual como su estado futuro empiezan a luchar por mantenerse a flote. Puede salvarse, pero sólo si es buen nadador y tiene algún empleado que tenga experiencia en resucitación... de programas de base.

Dependiendo de la edad de sus aplicaciones empresariales, puede ser difícil encontrar las interfaces de programación internas o externas con un solo programa, mucho menos en una biblioteca completa de aplicaciones. Para usar un servicio es necesario deshacerse de las interfaces actuales o neutralizarlas. Por ejemplo, piense en el servicio de revisión y actualización de crédito, que se puede usar para toma de pedidos estándar, procesamiento de devoluciones, generación de cotizaciones, pedidos únicos, ventas por promociones, descuentos y muchas otras situaciones. Ahora recorra cada uno de estos programas o módulos, rastree la lógica de la interfaz y determine qué cambios debe realizar. No es una tarea fácil. Es posible que tenga acceso al código fuente, pero puede no contar con los recursos técnicos necesarios para participar en este juego de escondidas tecnológicas. Su proveedor de software puede ofrecerle ayuda, pero ¿puede pagarla?

Ahora que estamos hablando de recursos técnicos, debemos aclarar que para aprovechar la agilidad de SOA puede ser necesario modificar los servicios o, dicho de otro modo, mejorarlos. Nuevamente, si cuenta con los recursos técnicos necesarios para llevar a cabo este tipo de modificación, es probable que esté a merced del proveedor de software. Si quiere demostrar la agilidad de SOA, asegúrese de que su empresa puede soportarla o, al menos, pagarla.

Desafortunadamente, SOA puede convertirse en un problema similar al problema del año 2000. SOA no se trata de migrar un sistema, sino de deshacerse de las bases tecnológicas y reemplazarlas con una base para toda la empresa. Si bien las grandes empresas gozan de muchas opciones, no sucede lo mismo con las pequeñas y medianas empresas (PYME). Si usamos una analogía, podemos decir que la llegada SOA es similar a la introducción de la transmisión automática en los automóviles. Sin duda que facilitó la conducción y la hizo más relajada,, pero estoy seguro de que usted no llevó su automóvil manual al mecánico para que le instalara una transmisión automática. Probablemente su automóvil no era el más avanzado tecnológicamente, pero funcionaba bien y cumplía su propósito. De la misma forma, lo más probable es que su software empresarial actual esté cumpliendo con su misión, y simplemente porque los proveedores de software tratan de venderle la tecnología nueva, no tiene que deshacerse de lo que tiene. Mejor espere a que pueda justificar el gasto que implica reemplazar el software. Puede ser que en un futuro necesite un procesamiento más rápido que le permita mantener el ritmo de los pedidos, mejores algoritmos de precios que reflejen las prácticas de su empresa o mejores herramientas para realizar análisis financiero y toma de decisiones. Cuando pueda hacer este análisis de rentabilidad, querrá determinar qué soluciones se crearon con tecnología SOA y tomar en cuenta sus ventajas durante su evaluación y selección de software.

Resumen

Algunos de ustedes pensarán que soy indeciso. Primero estoy a favor de SOA y luego cambio de opinión. Como hemos visto, no cabe duda de que SOA puede traer ventajas reales y tangibles en cuanto a reutilización de servicios y una implementación más rápida de las aplicaciones. Pero hay que ver si estas ventajas se pueden concretizar en este momento. No obstante, SOA no es una tecnología que pueda implementarse de forma gradual; hay que sumergirse completamente en ella. Cuando tenga los argumentos que logren convencer a sus directores para actualizar su cartera empresarial, es probable que SOA ya haya alcanzado la madurez suficiente para representar una alternativa razonable. En este momento, es mejor si los directores de informática permanecen como espectadores, siguen de cerca los avances de SOA y mantienen informados a sus gerentes. Así como sucede con el primer modelo de una línea nueva de automóviles, no es muy recomendable implementar la primera versión del software que usa SOA. Finalmente, algo que es especialmente interesante es que son pocos los proveedores que ya ofrecen una solución por SOA, sin embargo, ya se habla de SOA 2.0 y SOA avanzada.