SOA parece estar evolucionando con estándares, nuevas ofertas de software y fusiones / adquisiciones de proveedores. Pero existen riesgos tecnológicos con SOA que lo hacen particularmente desafiante para algunas organizaciones. ¿Puede hablar sobre algunos de los riesgos asociados con la transición a SOA y los pasos para mitigar los riesgos?
Por lo que vale, personalmente no estoy tan preocupado por las frecuentes actividades de fusiones y adquisiciones que ocurren en la industria del software cuando se trata del espacio de proveedores de arquitectura orientada a servicios (SOA). Si bien la adquisición de un proveedor ciertamente causa cierta ansiedad en una organización de TI, es importante recordar que SOA nació como un medio para inculcar la independencia del proveedor para el espacio de integración y middleware.
Hay varios pasos comunes que recomendamos cuando la gente está emprendiendo una iniciativa SOA para reducir o mitigar los riesgos SOA. Todos tienen su propia área de interés o enfoque cuando se trata de mejores prácticas y mitigación de riesgos. Para mantener el alcance de mis comentarios dentro de una extensión razonable, permítanme ofrecer algunas recomendaciones de servicios orientados a los datos.
Categorizar y documentar los servicios durante la fase de diseño. Es importante identificar las categorías (y subcategorías) de servicios como un medio para establecer un marco para la definición, el diseño y el desarrollo de los servicios. Esto también garantiza que los revisores puedan comprender rápidamente el alcance del diseño del servicio que se está llevando a cabo. A menudo alentamos a nuestros clientes a identificar sus servicios de datos por área temática (por ejemplo, cliente, producto, etc.) o capacidad funcional (limpiar, aumentar, combinar, etc.). Los servicios de procesamiento son los servicios iniciales más comunes a desarrollar. Es común diferenciar los servicios de alto nivel (o comerciales) (facturación, compras, etc.) de los servicios de nivel inferior (o funcionales) (búsqueda / búsqueda, recuperación de registros, etc.).
Diferenciar los datos de los servicios de procesamiento. Es importante que los servicios de datos se establezcan definidos por separado de sus hermanos de servicios de procesamiento. A menudo encontramos personas que implementan servicios basados en las convenciones e interfaces de llamadas de un proyecto de desarrollo de software individual. El resultado final tiende a reflejar un conjunto de convenciones funcionales centradas en la aplicación, no servicios que simplifican la comunicación de la aplicación y el desarrollo de la funcionalidad. Rara vez se presta atención a la definición de servicios relacionados con la recuperación, definición o modificación de datos comerciales. Sin servicios de datos bien definidos, su entorno SOA se verá obstaculizado en su capacidad para admitir diferentes áreas o aplicaciones comerciales.
Identifique una serie de escenarios de uso para cada servicio. Debido a la visibilidad y el entusiasmo que los servicios web y SOA reciben de los medios (e incluso internos de la mayoría de las empresas), es importante evitar que el esfuerzo de desarrollo de SOA se perciba como un «campo de sueños y soluciones mágicas». Con demasiada frecuencia, encontramos que los servicios están diseñados, desarrollados y entregados a una audiencia decepcionada. La decepción no se debe a que el personal técnico se aparta del plan o la meta del proyecto; el problema se debe a que las personas que dependen de los servicios individuales no comprendieron completamente el alcance de la funcionalidad que se iba a entregar. El valor de los escenarios de uso es que reduce drásticamente la probabilidad de que haya algún malentendido con respecto a las capacidades de los componentes SOA.
Aproveche el rigor de la gestión de datos existente. Dado que la premisa de SOA es establecer una infraestructura de procesamiento y datos compartidos, es importante que todos los que utilizan los servicios, ya sea desde una perspectiva de desarrollo o de uso, comprendan los detalles. No estamos hablando del funcionamiento interno del servicio; estamos hablando de las entradas, salidas y resultados de procesamiento del servicio. Si los datos se manipulan dentro del servicio, como una búsqueda de código postal, o se entregan, como proporcionar detalles de la dirección del cliente, es importante que los datos y los procesos se mencionen utilizando términos que ya están en uso dentro de su empresa. Si todo el mundo usa código postal, llamar a un servicio PostalCodeLookup es una mala idea.
