Publicado June 25, 2008

¿MAL CON ELLA, PEOR SIN ELLA?

Email | ¿Desea imprimir? Regístrese ahora

Mientras que la teoría, y los vendedores, hablan maravillas de la arquitectura orientada a servicios, la realidad muestra que existen algunos problemas y riesgos a considerar.

El discurso detrás de la arquitectura orientada a servicios (SOA, por sus siglas en inglés) es atractivo para casi todas las empresas hoy en día: reutilizar la tecnología para adecuarla a los objetivos del negocio.

“Pocos lo saben, pero se calcula que alrededor de 50% de los procesos de cualquier organización ‘moderna’ son primordialmente los mismos, como generar una factura, imprimir un estado de cuenta o procesar una orden de compra”, asevera Víctor Manuel Anda, gerente de cuenta de e-SOA de SAP para México y Centroamérica.

“¿Por qué, entonces, no reutilizar todos estos componentes en lugar de crear nuevos? El efecto de tal transformación consistiría en un aumento de la productividad con beneficios reales a corto y largo plazo”, responde el directivo y, enfático, agrega: “SOA no es una metodología, no es un producto, no es una mejor práctica ni es una tecnología o una certificación. Es un marco de referencia que permite integrar personas, información y procesos de negocio.

SIN SOA, EN LA TEORÍA. Las razones más comunes utilizadas para implementar una arquitectura orientada a servicios incluyen un catálogo amplio de buenas intenciones: estandarización, automatización de procesos de negocio, recorte de gastos operativos, satisfacción del cliente, desarrollo más eficiente de aplicaciones, mejor entrega de servicios, comunicación mejorada con los socios de negocio y, por supuesto, costos más bajos.

Lo cierto es que las ventajas hipotéticas abundan a la hora de promover sus bondades entre las organizaciones. Para dar a conocer sus aspectos positivos, las empresas IT (BEA Systems, IBM, Oracle, SAP) suelen recurrir a esquemas que muestran un “antes y después” de SOA. Su propósito: provocar una mejor comprensión comparativa de todas sus ventajas potenciales.

En el mundo idealizado de la teoría, ¿cómo se concibe un ambiente empresarial tradicional sin SOA? La respuesta más común es que, por lo regular, se le visualiza como un conjunto de “islas” o “silos” de aplicaciones desconectadas. Por tal motivo, los problemas se presentan de manera aleatoria y no correlacionada desde el punto de vista global del negocio.

Tal como menciona un webinar de Progress Software, un sistema de silos inconexos significa que el área IT pierde: el contexto en el cual funciona; la visibilidad de cuándo ocurren los problemas y cuáles son sus causas, métricas e impacto, y los servicios compartidos que potencialmente se pueden utilizar para propósitos múltiples.

En razón de todos estos factores, un departamento IT sin SOA no podría -bajo esta visión tradicional- decir qué tan urgente o importante es un problema o cómo afecta al negocio.

En consecuencia, las empresas que no recurren a una arquitectura orientada a servicios dejarían de lado el desarrollo de múltiples ventajas competitivas; entre ellas: mayor integración interna, creación de código modular reutilizable, rápida adaptación a las necesidades de cambio de los negocios y menos tiempo de mantenimiento y desarrollo.

Hasta aquí los rasgos básicos del enfoque comparativo. El problema es que no siempre queda claro cómo se da el proceso de transición desde el “antes” hasta el “después” en las empresas. O se está en uno o en el otro.

Otra estrategia relacionada consiste en indicar qué podría suceder cuando un negocio carece de una iniciativa de este tipo. Judith Hurwitz, co-autora del libro “Service oriented architecture for dummies“, plantea que sin SOA, el desarrollador IT y el administrador del negocio típicamente emplean palabras muy diferentes para describir el proceso de crear, digamos, una factura. El primero se refiere a interfaces de programación de aplicaciones (API) y cómo crear expedientes del cliente a partir de 10 tablas de la base de datos de Oracle; el segundo, en tanto, describe los procesos de negocio usados para crear la factura”.

CON SOA, EN LA PRÁCTICA. En la vida práctica de las empresas, sin embargo, la construcción de una arquitectura orientada a servicios puede ser más ardua de lo que pregonan sus impulsores. Aun cuando muchas organizaciones no saben darse por vencidas, SOA en ocasiones tiene el peculiar don de desesperar a los más pacientes, sobre todo cuando le da por implicar más problemas de los que ya de por sí la organización esperaría.

De entrada, no basta con dominar la complejidad de SOA para estar del otro lado en materia de administración de servicios IT. “Desde luego, esta labor requiere mucho más que ITIL y SOA; puede abarcar muchas otras metodologías, como COBIT, COSO, Six Sigma, ISO, etc.”, señala Rebeca Pimentel, consultora de Inteli.

Del mismo modo es necesario saber que, pese a sus renombrados beneficios, la arquitectura orientada a servicios no es para todo tipo de empresas. Al respecto, Fabiola Cruz, subdirectora analista de Select, dice: “SOA sólo es posible cuando una organización presenta una cierta madurez en sus servicios y se complementa con otras metodologías”.

Tal vez ahí está la explicación de por qué una de las más importantes firmas mineras en México (cuya fuente prefiere mantenerse anónima a sí misma y a la organización para la que trabaja) fracasó al intentar entrar en los caminos de SOA.

Esta empresa inició el proyecto para alinear la demanda de información que resultaba de distintos puntos de extracción y producción, pero la responsabilidad pasaba por varios sistemas y mucha gente responsable, lo que habla de un cierto nivel de desorganización en los procesos. “Había varias respuestas para un mismo problema, y éstas surgían en diferentes tiempos”, dice el entrevistado. “No había estándares, ni gobierno o un modelo a seguir. Teníamos soluciones de principio a fin, pero muchas formas de responder en tiempo y forma a una misma solicitud de información.”

El asunto es que, tras un año de iniciado el proyecto todo se detuvo y la compañía debió regresar al principio: definir objetivos, establecer responsables de gestión y costos, poner orden en la administración de servicios, etc.

¿Por qué se dio el fracaso? El ejecutivo de la empresa considera que por atender lo mejor posible los ciclos del negocio derivados de una alta demanda de requerimientos se enfocaron los resultados en el corto plazo, y ahí estuvo el error. Ni qué decir de las grandes inversiones, tanto económicas como de tiempo, que se fueron a la basura.

¿DÓNDE ESTÁN LAS BARRERAS? Como ya se vio, para algunas organizaciones SOA no es miel sobre hojuelas. Diversos estudios recientes demuestran que este tipo de iniciativas enfrentan cuatro obstáculos principales a considerar:

1.- Mayores complejidades y costos. Los problemas con SOA no son nuevos. Desde hace dos años, un estudio del área de investigación de la revista hermana InformationWeek ya lo alertaba, pues para 24% de entre 273 encuestados, sus proyectos de SOA estuvieron “por debajo de las expectativas”. El dato resulta significativo, pues 55% de ellos afirmaba incluso que la implementación agregó más complejidad en su entorno IT, y 41% opinó que costó más de lo esperado. Sólo 7% aseguró que los resultados excedieron las expectativas.

Sin duda, la arquitectura orientada a servicios puede ser complicada. Los servicios Web intentan ligar datos de sistemas informáticos complejos, y hay pocos productos pre-empacados en el mercado (como los que ofrece SAP, por ejemplo). En la mayor parte de los casos, implementar SOA sigue siendo un arduo trabajo personalizado.

2.- Problemas de gobernabilidad. Las vicisitudes con iniciativas de este tipo no sólo se relacionan con la tecnología propiamente dicha. Lograr el buen gobierno corporativo es también una preocupación fundamental a tomar en cuenta. Da hecho, muchos intentos podrían resultar fallidos a partir de un inadecuado gobierno corporativo.

El año pasado, un estudio del Foro SOA encontró que 88% de los ejecutivos reconoció tener un nivel de gobernabilidad “escaso”, además de que para 80% su organización está en riesgo significativo al desplegar servicios sin un gobierno corporativo eficaz.

No basta, pues, con desarrollar proyectos de SOA; también se requiere de una estrategia acorde de governance. Aun cuando existe la posibilidad de que una empresa pueda alcanzar cierto éxito con una arquitectura orientada a servicios dentro de proyectos individuales, podría fallar al no lograr sinergias a lo largo de toda la organización. ¿La razón?: no hay un punto de vista central que sirva para coordinar proyectos, evite esfuerzos duplicados y anime a la reutilización de servicios. Y es allí donde suelen “mentir” los valores verdaderos del impacto de SOA.

3.- Insatisfacción del cliente. Sin duda, los altos costos y la complicación creciente no agradan a nadie. En una encuesta elaborada en Estados Unidos por InformationWeek, 69% de los 278 participantes sólo atina a decir que la adopción de SOA y los Web services les permitió alcanzar sólo algunas de sus metas de negocio, mientras que para 15% ninguna meta se alcanzó gracias a la arquitectura orientada a servicios. Asimismo, para más de la mitad de los encuestados (58%) SOA introdujo mayor complejidad a sus sistemas IT, en lugar de aminorarla, y una tercera parte afirmó que la implementación de esta iniciativa costó más de lo estimado.

Lo cierto es que aún existe gran disparidad entre las compañías en torno a qué tan ampliamente logran poner en uso la arquitectura orientada a servicios. En ello pudiera ser de ayuda el estudio de Aberdeen Group, que concluye que las organizaciones que están construyendo una infraestructura completa de middleware de SOA han conseguido mejores resultados que aquellas que sólo despliegan aplicaciones basadas en servicios Web”.

4.- Pugnas entre el desarrollo y la infraestructura. Para tener el éxito deseado, la opinión de Gerardo Reyes-Retana, director general de Pink Elephant para América Latina, es que la implementación de SOA debe descansar sobre una infraestructura de operaciones eficiente. “Sin una buena administración de servicios y best practices no se puede monitorear ni medir el impacto real de una iniciativa de este tipo en la empresa”, menciona.

Cabe hacer notar que, en ocasiones, las áreas internas de desarrollo e infraestructura dan lugar a “guerras políticas y técnicas” que van en contra de una eficiente implementación de una estrategia como esta. El caso de algunas luchas entre SOA e ITIL lo ilustra de manera adecuada. “Para evitar esto, ITIL debe involucrar a los desarrolladores, y SOA debe contemplar una participación activa de los encargados de la operación de infraestructura”, aconseja Reyes-Retana.

¿Se puede vivir sin SOA? La respuesta es que la arquitectura orientada a servicios no es para todos; una compañía moderna puede ser competitiva sin pasar por la necesaria implementación de esta iniciativa tecnológica. Mientras logra prepararse adecuadamente, hay estrategias y metodologías alternativas que pueden eficientar eficiente a una empresa que decida continuar con su clásico esquema de operación IT. Por otro lado, las organizaciones con cierto nivel de madurez en sus servicios podrían encontrar en esta opción una buena forma de optimizar sus procesos.

EXECUTIVE SUMMARY

Las tres cosas que el CEO debe saber acerca de SOA:

1.- SOA es una estrategia de negocios que llegó para quedarse. Mantiene buenas expectativas de crecimiento futuro en el mercado y cuenta con el apoyo decidido de grandes empresas, como BEA Systems, IBM, Microsoft, Oracle y SAP. Todas estas compañías se esfuerzan por brindar una oferta integral de soluciones cada vez más completa.

2.- Sin embargo, se han documentado casos fallidos de adopción. Diversas empresas que han implementado una arquitectura orientada a servicios han quedado desangelados con la iniciativa, hallándola costosa, no muy confiable y más difícil de mantener que las aplicaciones independientes construidas por silos. Entonces, ¿qué es lo que hace la diferencia?

3.- Las posibilidades de éxito aumentan cuando se cumplen algunas precondiciones; por ejemplo, elegir una estrategia apoyada en otras metodologías de gobierno corporativo, o tener en cuenta la importancia de factores como una adecuada infraestructura de operación, madurez en los servicios y procesos de la organización, un buen seguimiento de las mejores prácticas en la industria en que se encuentre la empresa y capacitación suficiente de recursos humanos. Bajo estas consideraciones, las luces amarillas al momento de desarrollar un proyecto de SOA podrían convertirse en verdes.

SOA, UN MERCADO OPTIMISTA

“Para 2008 se espera que SOA crezca 31.6% y para 2009, 36%. Estos datos contrastan favorablemente con el crecimiento registrado en 2007, de 24.2%”, Fabiola Cruz, subdirectora analista de Select
“En una encuesta reciente sobre prioridades de CEO latinoamericanos para este año, la alta administración ya considera a los productos basados en SOA dentro de los cuatro principales aspectos a considerar de un proveedor IT”, Cristina Rivas, gerente de investigación de IDC México.
Según IBM, el mercado de la arquitectura orientada a servicios (SOA) representa alrededor de $160,000 millones de dólares

AVANCE LENTO

Estime en qué porcentaje caerán las aplicaciones de su organización en las siguientes categorías.

Actualmente En dos años más

Monolíticas (ejemplo: mainframe) 18% 17%

Cliente-servidor 32% 26%

De tres capas 19% 18%

Multi capas 27% 29%

Arquitectura orientada a servicios 4% 10%

Fuente: IDC Developer Collaborative

¿LES GUSTÓ?

¿Cómo se desarrolló la adopción de SOA y servicios Web en su empresa?

58% Se adecuó a las expectativas