Cómo abordar un proyecto SOA
La industria financiera es un ejemplo de cómo debe ser la adopción de esta arquitectura
SOA es una tendencia tecnológica muy en boga entre las organizaciones de todo el mundo. Sin embargo, a la hora de llevar a cabo su adopción es importante tener en cuenta que los desarrolladores suelen distinguir entre implementaciones SOA internas y externas con formas de actuación diferentes y etapas identificables.
Las discusiones a la hora de implantar un proyecto SOA (arquitectura orientada a servicios) suelen centrarse en conceptos, ideales, magnitudes y líneas maestras. Pero, sólo con ellos, no es posible cumplir objetivos. En una implementación ideal, los responsables conocen toda la información disponible y comprenden las interacciones entre los datos más relevantes. Así, cada elemento individual existe sólo en un único lugar y puede recuperarse de forma eficiente. En este escenario, se pueden diseñar fácilmente servicios asociados para adquirir y presentar la información en el formato más conciso y apropiado. De esta forma, todos los datos, hardware y software se integran y comportan de forma perfecta, consiguiendo que el equipo humano sea el adecuado, las necesidades de mantenimiento mínimas y las contribuciones al servicio perfectas.
Esto sería lo ideal, pero volvamos a poner los pies en el suelo. En realidad, pocas soluciones tecnológicas consiguen esta meta. La mayoría de los proyectos de TI necesitan un acceso compartido, lo que implica compromiso, superposición de datos y procesos duplicados en lugar de una eficiencia óptima. Quizás un acercamiento más práctico sea evaluar el camino hacia los ideales SOA, en lugar de centrar toda la atención en el objetivo, y considerar la diferencia entre implementaciones SOA internas y externas.
Sector financiero
La industria financiera se cita como ejemplo de lo que debe ser una implementación SOA, ya que sus soluciones prestan soporte a las necesidades de clientes tanto externos como internos. Pero, ya sea intencionadamente o por accidente, los esfuerzos no comenzaron con un diseño formal de SOA. Muchas organizaciones financieras se dieron cuenta, casi por accidente, de las ventajas de proporcionar información adicional sobre sus clientes a través de una sencilla interfaz. Tuvieron que trabajar para recopilar la información a partir de sistemas dispares para conseguir un producto utilizable. Los distintos elementos proporcionaron encapsulación, abstracción, reusabilidad y autonomía antes de que estos conceptos fuesen definidos como parte de SOA.
Los desarrolladores suelen distinguir entre implementaciones SOA internas y externas, o al menos identifican los proyectos por separado. Los resultados sugieren formas de actuación diferentes, con etapas identificables, cronogramas y la probable ruta de una evolución SOA.
Internas
La mayoría de los desarrolladores centran sus esfuerzos en los proyectos de SOA internos, lo que significa que la infraestructura debe estar preparada antes de poder implementar soluciones externas completas. Los conceptos de infraestructura, arquitectura y tecnología son los que dirigen los esfuerzos de las iniciativas SOA internas, que se centran en la migración de datos y se aplican de forma regular. Los desarrolladores modifican cada sistema hasta que proporcione una rudimentaria interfaz común, con el objetivo de compartir en su totalidad datos y servicios.
Es posible desarrollar una SOA interna por partes, que permita el acceso simultáneo utilizando antiguas interfaces mientras se consigue migrar hacia una prestación de servicios integrada. Pero no es sencillo. Muchos sistemas internos se diseñaron o adquirieron para propósitos muy concretos y sin posibilidad de proporcionar la interoperabilidad necesaria para SOA. Además, este propósito puede suponer grandes presupuestos. La justificación del coste de SOA es más complicada cuando los datos son voluminosos y se generaron para un departamento específico. Los esfuerzos para realizar implementaciones SOA internas suponen costosas migraciones de datos o sistemas, que hacen difícil medir con precisión el ROI.
Por el lado positivo, las implementaciones SOA internas tienden a ajustarse mejor a los controles y líneas maestras de la gestión operativa. Promueven la uniformidad corporativa y la consistencia y posibilitan hacerlo bien a la primera. Además, una vez en materia, las implementaciones SOA internas pueden adaptarse a múltiples ofertas de productos, gestionadas y medidas para satisfacer objetivos corporativos.
Externas
Las implementaciones SOA externas requieren que la empresa establezca un calendario completo de entregas. La solución con frecuencia debe enfrentarse a envíos de pedidos, seguridad y auditorías, facturación y procesos de pago, así como adquisición y mantenimiento de los perfiles de clientes, todo de forma simultánea.
A veces, es más fácil identificar y satisfacer necesidades de clientes externos que tratar con las especiales necesidades de departamentos y divisiones internas divergentes. Una vez que se diseña una pipeline externa en torno a conceptos de servicio SOA, es posible mantener contento al cliente cambiándola regularmente para satisfacer las demandas. Y lo que es más importante, seguramente alguien le esté pagando para desarrollar el software, así que podrá acompasar los esfuerzos en desarrollos SOA externos con la generación de ingresos.
Desde el punto de vista negativo, las metodologías basadas en el consumidor hacen que la empresa sea más susceptible a cambios de mercado y no siempre soporte correcciones de rumbo. La duplicación de las funciones del sistema y la información es algo común, ya que pocas veces se tiene el tiempo suficiente para esperar a la migración del sistema interno.
