A la hora de identificar servicios surgen las siguientes preguntas:
- ¿El servicio es demasiado genérico?
- ¿El servicio es demasiado específico?
- ¿El servicio tiene una granularidad demasiado grande?
- ¿El servicio tiene una granularidad demasiado pequeña?
Uno de los métodos más comunes para la identificación y la obtención de servicios, utiliza los procesos de negocio como punto de partida. El proceso de negocio se divide en sub-procesos o se descompone en actividades y tareas. Las tareas de menor nivel pueden estar formadas por pequeñas y cohesionadas “unidades lógicas de trabajo” que son soportadas por la funcionalidad que ofrecen distintos servicios.
Una gran ventaja de este enfoque es que los servicios resultantes tienen garantizado el ajuste con las necesidades funcionales de la organización. Este método es muy intuitivo, permitiendo a los equipos de proyecto usarlos para realizar pruebas de concepto y pilotos de proyectos.
Se puede dar una brecha entre procesos de negocio y aplicaciones si los servicios son sólo el modelo de negocio de acuerdo a las especificaciones de la definición del proceso y sin tomar en cuenta las consideraciones de implementación.
Además, a menos que se realice un esfuerzo de modelado en iterar a través de múltiples procesos empresariales, los servicios se pueden ajustar muy específicamente a las tareas y actividades de un proceso de negocio concreto, lo que da lugar a servicios que no se pueden reutilizar.
Incluso cuando se derivan los servicios de múltiples procesos, varias actividades pueden requerir funciones similares. Es necesario realizar una coordinación para evitar la redundancia entre los servicios definidos para los equipos de proyecto que trabajan en paralelo.
Hay que tener en cuenta el contraste entre:
- La identificación de servicios basándose en un único proceso de negocio con lo que significa de estrecho vínculo entre el proceso y estos servicios.
- La idea subyacente de que los servicios deben proporcionar los medios para separar la lógica de negocio de servicios de TI.
Conlleva los mismos riesgos que el anterior método.
El propósito de la mayoría de los servicios es el procesamiento de la información de negocio. Al modelar servicios de acuerdo a los modelos de los objetos de negocio, suelen aparecer servicios del tipo CRUD. Debido a esto, se recomienda establecer modelos de datos canónicos que estandarizan el intercambio de datos entre servicios (se debe evitar que existan entidades que referencian la misma información con diferente estructura).
La dificultad principal de este método es la necesidad de modelos de datos estandarizados.
Nota: ¿Qué es un modelo de datos canónico?: Es un modelo que define la estructura de la información en una organización, siendo su objetivo no solo el limitarse a modelar los datos dentro de una sola base de datos, sino servir de referencia para todas las entidades y sus relaciones a través de todas las bases de datos de la empresa.
SOA requiere de una estructura bien definida para la toma de decisiones, dónde los roles y responsabilidades de los procesos y servicios están claramente distribuidas y asignadas. Cuando se identifican servicios, la parte que tiene la responsabilidad de poner a disposición la funcionalidad requerida determina qué servicios serán ofrecidos.
Los enfoques de diseño desempeñan un papel importante en este proceso, pero hay otras cuestiones que se deben tener en cuenta a la hora de decidirse por la opción final: Costes de desarrollo, costes de mantenimiento, gestión de ciclo de vida de las aplicaciones subyacentes, prioridades, disponibilidad de los recursos humanos, etc.
La mayor ventaja es que siempre está claro quién es propietario de un servicio. En otros métodos este tema puede convertirse en un punto de debate, e incluso puede derivar en consecuencias políticas. En el lado negativo, los servicios de diferentes ámbitos pueden acabar superponiéndose debido a la estructura de la propiedad requerida.
Con este enfoque, un equipo de proyecto descompone los objetivos de la empresa hasta el nivel de servicios. En este contexto, un servicio se considera como un objetivo que puede ser ejecutado a través de soporte automatizado. Por ejemplo, una meta como “aumentar la retención de clientes”, puede dar lugar a un servicio llamado “registro de clientes para el programa de fidelización”.
La ventaja es la fuerte relación establecida entre los servicios y la estrategia de la empresa. Sin embargo, surgen dos problemas: Los objetivos suelen ser subjetivos, y una buena cantidad de servicios tecnológicos no pueden ser directamente alienados con los objetivos de negocio.
La subjetividad puede provocar que dos objetivos de negocio se descompongan en dos servicios distintos, a pesar que la funcionalidad deseada es idéntica (lo que significa que hubiera sido preferible el uso de un único servicio). Además, debido a que muchas de las características TI no pueden estar directamente relacionadas con los objetivos de negocio, hay un riesgo constante de que muchos de los servicios potencialmente útiles, simplemente se pasen por alto.
La esencia de la utilización de componentes TI, consiste en dividir la funcionalidad TI en unidades con máxima cohesión interna y mínimo acoplamiento externo. Los componentes son realmente unidades autónomas de funcionalidad.
Hay varios métodos para identificar componentes, pero un principio que guía estos métodos es que cada componente tiene exactamente un dueño y que las responsabilidades de cada componente tienen que ser definidas con la mayor precisión posible. Estas responsabilidades pueden ser utilizadas como punto de partida para la identificación de los servicios.
En la actualidad los proveedores de las grandes aplicaciones monolíticas (como los sistemas ERP y CRM), tienden a organizar sus aplicaciones de forma más modular y ponerlos a disposición a través de los servicios. Estos módulos se corresponden aproximadamente con los componentes.
La ventaja de basarse en los componentes es que el proceso de identificación de servicios se simplifica mucho. La mayor parte del trabajo de análisis ya se ha llevado a cabo como parte del método de desarrollo basado en componentes. Sin embargo, esto dar lugar a varios problemas: los componentes que pueden estar hechos hace tiempo, no encajen con la orientación a servicio o simplemente no respondan a la funcionalidad de negocio que se necesita.
Un método pragmático para una rápida definición de los servicios consiste en basarse en las necesidades inmediatas de información y funcionalidad. En este caso, el punto de partida es la funcionalidad proporcionada por las aplicaciones heredadas existentes. Se seleccionan los sistemas que proporcionan el grueso de la funcionalidad requerida por los principales procesos de negocio. Usando herramientas y asistentes, los interfaces existentes, las pantallas, transacciones, consultas y tablas son accesibles a través de los servicios.
La principal ventaja de este método es que requiere poco tiempo para llegar a una primera definición de los servicios. Se trata de un enfoque apropiado si se requiere con urgencia la funcionalidad de las aplicaciones existentes.
Se reaprovecha el software actualmente existente en la empresa aunque se hace problemático el orientar los servicios resultantes a una verdadera orientación a servicios de negocio ya que el resultado normalmente da lugar a servicios muy específicos y poco reusables.
Analizando la aplicación web o de escritorio que sirve de interfaz con el usuario se puede ver rápidamente los servicios que necesita. Por ejemplo, si en una pantalla se muestran las pólizas que tiene un determinado cliente, obviamente se necesitará un servicio al que se le pasa el identificador del cliente y que devolverá un listado con la consulta que se necesita para presentar los datos al usuario.
Sin embargo, este enfoque tiene un problema importante, se están acoplando los servicios a una aplicación de frontal cuando los servicios deben desconocer quién los convoca. Además casi con total seguridad, los servicios resultantes serán muy específicos para ese caso concreto de frontal.
Este método utiliza los requisitos no funcionales como la entrada principal para identificar servicios. No es un método como tal, sino más bien un conjunto de técnicas que se pueden utilizar sobre los otros métodos.
Después de la identificación preliminar de un conjunto de servicios a través de las otras aproximaciones de identificación, el futuro proveedor de servicios verifica la viabilidad de los requisitos no funcionales de un futuro consumidor de servicios. Si los requisitos no funcionales son inviables, es más importante que los servicios puedan ser rediseñados que los principios de diseño que se han seguido en los métodos de identificación.
En la fase de Diseño Técnico, dos requisitos no funcionales que normalmente se tienen que tener en cuenta son seguridad y rendimiento. Por ejemplo: Se descubre que la funcionalidad que aporta el servicio X es necesaria para las aplicaciones A y B. Si la aplicación A se ajusta a los requisitos de seguridad impuestos en el servicio X y la aplicación B no puede, quizás tenga sentido dividir el servicio X en dos servicios separados, servicio securizado y servicio no securizado.
Por otra parte, si una organización decide implementar SOA a través de servicios Web, algunos servicios pueden no ser capaces de ofrecer el rendimiento necesario. Las opciones que se pueden realizar son la fusión de múltiples servicios (reduciendo la cantidad de necesidades de comunicación entre los servicios).
No hay comentarios:
Publicar un comentario