SOA, ha surgido como una arquitectura emergente, un paradigma enfocado en el negocio y no en la tecnología. Sus beneficios, están orientados en necesidades de negocio como: protección de la inversión, disminución de costos en proyectos de integración, adaptabilidad ante un mercado TIC tan cambiante, etc. Esta visión la hace muy atractiva para los CIO (Gerentes) de las organizaciones.
Estas promesas de negocio, están sustentadas en la utilización del reuso como pieza clave, mientras mas reuso, menos recursos se dispondrán para el desarrollo de nuevas aplicaciones y funcionalidades en la organización, por ende; se disminuyen los costos, y hay un mayor nivel de proteccion en inversiones y recursos.
Por ejemplo, la organización A tendría un directorio de aplicaciones y funciones ya existentes, que están en cierto grado desacopladas de las aplicaciones que las alimentan. Este desacoplamiento es lo que permite que la compañía A pueda realizar un cambio en la aplicación proveedora sin que sus servicios expuestos sean afectados. Todos los servicios son reusables.
Cuando se pretende iniciar un proyecto SOA, es verdaderamente difícil buscar un equilibrio entre un modelo anterior de desarrollo de proyectos de integración y un modelo que ciertamente no representa una visión pragmática, pero a la larga son innumerable los beneficios que este tipo de arquitecturas proporciona.
Actualmente, en el mercado existen muchas empresas que están desarrollando proyectos bajo este nuevo modelo de arquitectura; la dificultad mas importante para su implantación, es la gran cantidad de especificaciones alrededor y las pocas empresas que las han adoptado dentro de sus soluciones de integración. Otro problema importante es la madurez de las especificaciones y sus implementaciones.
En conclusion, un modelo de agilidad operacional y totalmente desacoplado de las tecnologías, es un norte posible, pero se necesitan un conjunto de estrategias para asegurar el éxito. Basado en mi experiencia en proyectos de integración bajo SOA, les presento algunas recomendaciones para disminuir los riesgos y asegurar una implementación exitosa en su organización:
Recomendaciones:
- Internalizar y comprender los conceptos detrás de SOA y transmitirlo a todos los niveles de la organización.
- Crear un documento de diseño de alto nivel (Blueprint), antes de emprender un proyecto piloto, donde se incluya por ejemplo: modelo vertical, capas, formato de mensajes, protocolo de transporte, formas de interaccion (sincronía / asíncrona), reglas y políticas, atomimicidad transaccional, etc.
- Alinear los servicios con los procesos de negocio, no hay que olvidar que la meta no es tecnología.
- No es suficientes adoptar las tecnologías SOA, es importante conocer las mejores practicas para asegurar, la viabilidad, la visibilidad de las operaciones, y un mínimo esfuerzo ante los cambios.
- Definir un lenguaje común para la organización, es decir un modelo de objetos que representen todos o un conjunto de los conceptos de la organización basado en un modelo canónico, por ejemplo “cuenta, debito, ajuste, etc.”.
- Establecer conversiones de nombrado para la empresa: por ejemplo, como nombrar los servicios, interfaces, endpoint de sistemas legados, o cualquier otro componente que ayuden a los arquitectos, administradores, y desarrolladores en proporcionar servicios consistentes.
- Definir las interfaces de servicios, las implementaciones después: Las interfaces de servicios web son más importantes que las implementaciones.
- Establecer una categorización de servicios: Una organización debe decidir una taxonomia de servicios.
- Categorizar las reglas (reglas de procesos versus reglas de negocio.
- Definir estrategias de interoperabilidad para sistemas basados en plataformas heterogéneas.
- Incluir estrategias para pruebas de carga, stress y monitoreo de recursos.
- Para proporcionar mayor agilidad y propiedades de configuración, la utilización de un ESB y un UDDI es vital.
