Sin embargo, es muy probable que la existencia de un modelo de datos común y transversal sea más la excepción que la regla, y que la mayor parte de las organizaciones de gran tamaño tengan bases de datos con esquemas redundantes. También puede que la documentación de los modelos de datos no esté disponible, o sea propietaria. Por último, es muy probable que el grado de acoplamiento, o dependencia estructural, entre las aplicaciones de software y sus respectivos modelos de datos sea tan alto que haga imposible su modificación a un costo razonable. Debido a todo lo anterior, una iniciativa de adopción de SOA debe tomar la estandarización de datos desde otro ángulo, buscando la estandarización de las estructuras a nivel de mensajería. Como paso concreto, la organización debiera instaurar mecanismos para estandarizar y gobernar todos sus esquemas XML.
Antes de empezar a realizar un levantamiento de todas las estructuras de datos relevantes, y de comenzar generar un modelo de datos común para toda la organización, se debe investigar si existen modelos estándares aportados por la industria para el dominio concreto del negocio (por ejemplo, modelos para la industria de seguros, naviera, financiera, etc.,) o para un dominio transversal, como por ejemplo el de recursos humanos. Existen organizaciones como OASIS (www.oasis-open.org) que se dedican a la creación de estándares abiertos, y cuentan con sitios tales como www.xml.org enfocados en áreas específicas de negocios.
De existir tales modelos, debe privilegiarse su uso, pues facilitará la interoperación con organizaciones externas y la integración entre sistemas internos. Un modelo levantado sin esta consideración muy probablemente requerirá de transformaciones para interoperar fuera del ámbito en que fue concebido, lo que llevará a múltiples problemas que pueden ser evitados, como mayores costos de hardware y middleware, y perdidas de desempeño en las aplicaciones que requieran de tales transformaciones.
En caso de adoptar la estrategia de adoptar modelos estandarizados para una industria o negocio específico, se deben tomar acciones para mitigar el riesgo de que, debido al tamaño y la complejidad que muchas veces tienen estos modelos, los proyectos SOA se vean inesperadamente impactados en su avance. La adopción de esta estrategia es una apuesta al largo plazo, que fácilmente puede poner en peligro un proyecto con plazos y presupuesto limitados, y que tenga un acercamiento ingenuo en torno al esfuerzo que implica adoptar estos modelos.
Referencias:
SOA Governance: Achieving and Sustaining Business and IT Agility
Referencias:
SOA Governance: Achieving and Sustaining Business and IT Agility
No hay comentarios.:
Publicar un comentario