The Annotated SOA Manifesto – Spanish

PDF

El Manifiesto SOA Comentado

Comentarios y visión sobre el Manifiesto SOA por Thomas Erl

La Orientación a Servicios es un paradigma que enmarca lo que usted hace. La Arquitectura Orientada a Servicios (SOA) es un tipo de arquitectura que resulta de aplicar la orientación a servicios.

Desde el principio se entendió que éste sería un manifiesto sobre dos temas distintos pero estrechamente relacionados: el modelo de arquitectura orientada a servicios y la orientación a servicios, el paradigma a través del cual se define la arquitectura. El formato de este manifiesto fue modelado a partir del Manifiesto Ágil, el cual limita su contenido a declaraciones concisas que expresan ambiciones, valores, y principios orientadores para alcanzar dichas expectativas y valores. Dicho manifiesto no es una especificación, ni un modelo de referencia, ni un libro blanco, y sin opción para proporcionar definiciones reales, decidimos agregar este preámbulo con el fin de clarificar cómo y por qué estos términos se referencian en otras partes del documento del manifiesto.

Hemos estado aplicando la orientación a servicios…

El paradigma de la orientación a servicios se visualiza mejor como un método o una aproximación para alcanzar un estado objetivo específico, que se define más adelante por un conjunto de metas y beneficios estratégicos. Cuando aplicamos la orientación a servicios, modelamos programas de software y arquitectura de tecnologías en apoyo a la consecución de este estado objetivo. Esto es lo que califica a la arquitectura de tecnología como orientada a servicios.

… para ayudar a las organizaciones a entregar consistentemente valor a los negocios, de manera sostenida, con mayor agilidad y con efectividad en los costos…

Esta continuación del preámbulo destaca algunos de los beneficios estratégicos más prominentes y más comúnmente esperados de la computación orientada a servicios.

Entender estos beneficios contribuye a aclarar el estado objetivo que intentamos alcanzar como resultado de aplicar la orientación a servicios.

En la medida que una organización responda de manera más fácil y efectiva a los cambios en el negocio, será más eficiente y exitosa en la adaptación a los impactos del cambio (e impulsar los beneficios que el cambio pueda traer consigo).

La orientación a servicios define a los servicios como activos de TI que se espera proporcionen valor de manera repetida en el tiempo, en exceso significativo sobre la inversión inicial requerida para su entrega. La efectividad del costo se relaciona inicialmente con este retorno esperado de la inversión. De muchas formas un incremento en la efectividad del costo va de la mano con un incremento en la agilidad; si existe mayor oportunidad de reutilizar los servicios existentes, entonces normalmente se requiere un menor gasto para construir nuevas soluciones.

Valor de negocio “sostenible”, se refiere a las metas de largo plazo de la orientación a servicios de establecer programas de software como servicios, con la flexibilidad inherente para que sean compuestos continuamente en forma de nuevas configuraciones de solución, y evolucionen para acomodarse a los requerimientos siempre cambiantes del negocio.

… alineada con las necesidades cambiantes de los negocios.

Estas últimas ocho palabras del preámbulo son claves para entender la filosofía subyacente de la computación orientada a servicios. La necesidad de acomodar cambios en el negocio en forma permanente es fundamental para la orientación a servicios y es considerada como un objetivo estratégico fundamental y general.

A través de nuestro trabajo hemos llegado a priorizar:

Las siguientes afirmaciones establecen un conjunto base de valores, cada uno de los cuales se expresa como una priorización sobre algo que se considera también de valor. El propósito de este sistema de valores es enfocar las decisiones difíciles que deben tomarse de manera permanente, para que los objetivos estratégicos y los beneficios de la computación orientada a servicios se logren en forma consistente.

El valor del negocio por encima de la estrategia técnica

Tal como se estableció anteriormente, la necesidad de adaptarse a los cambios en el negocio es una meta estratégica general. Por lo tanto, la calidad fundamental de la arquitectura orientada a servicios y de cualesquiera programas de software, soluciones y ecosistemas que resulten de la adopción de la orientación a servicios, es que están orientadas hacia el negocio. No se trata de la tecnología determinando la dirección del negocio, sino que la visión del negocio es la que dicta la utilización de la tecnología.

Esta prioridad puede tener un profundo efecto en cascada dentro de las áreas del departamento de TI. Ella introduce cambios en prácticamente todas las fases de los ciclos de vida de la entrega de TI, desde cómo planificamos y financiamos soluciones de automatización, hasta cómo las construimos y las administramos. Todos los demás valores y principios en el manifiesto apoyan, de una manera u otra, el desarrollo de este valor.

Las metas estratégicas por encima de los beneficios específicos de los proyectos

Históricamente, muchos proyectos TI se enfocaron solamente en la construcción de aplicaciones diseñadas específicamente para automatizar los requerimientos de aquellos procesos del negocio que eran los normales en ese momento. Esto satisfacía las necesidades inmediatas (tácticas) pero, en la medida que se entregaban más de estas aplicaciones de propósito particular, se obtuvo como resultado un departamento de TI lleno de islas de lógica y de datos que se solían llamar aplicaciones “silos”. Con la aparición de nuevos requerimientos para el negocio, o bien se creaban nuevos silos o se establecían nuevos canales de integración entre estos silos. Mientras más cambios ocurrían en el negocio, se tenía que agregar más canales de integración, se tenía que crear aún más silos, y pronto, todo el panorama del departamento de TI se volvía completamente enredado e incrementalmente cada vez más difícil, costoso y lento para evolucionar.

De muchas maneras, la orientación a servicios emergió como una respuesta a estos problemas. Es un paradigma que provee una alternativa al desarrollo de aplicaciones integradas basadas en silos y específicas de un proyecto, al priorizar de manera intransigente el logro de objetivos de largo plazo, estratégicos, para el negocio. El estado objetivo abogado por la orientación a servicios no tiene los silos de las aplicaciones tradicionales. Y aún cuando los recursos heredados y las aplicaciones silos persisten, en ambientes donde se adopta la orientación a servicios, el estado objetivo es que estos mismos se armonicen en cualquier medida posible.

La Interoperabilidad Intrínseca por encima de la integración personalizada

Para que los programas de software puedan intercambiar datos, necesitan ser interoperables. Si los programas de software no están diseñados para ser compatibles, probablemente ellos no serán interoperables. Permitir la interoperabilidad entre programas de software incompatibles, requiere que ellos sean integrados. La integración es, por lo tanto, el esfuerzo requerido para lograr la interoperabilidad entre programas de software dispares.

Aunque sea frecuentemente necesaria, la integración personalizada puede ser costosa, consumir tiempo y conducir a arquitecturas frágiles que son una carga para evolucionar. Uno de los objetivos de la orientación a servicios es el de minimizar la necesidad de integración personalizada, conformando los programas de software (dentro de un cierto dominio) de manera que sean nativamente compatibles. Esta es una cualidad llamada interoperabilidad intrínseca. El paradigma de orientación a servicios abarca de un conjunto de principios de diseño específicos que son orientados hacia establecer la interoperabilidad intrínseca en diferentes niveles.

La interoperabilidad intrínseca, como característica de los programas de software que residen dentro de un cierto dominio, es clave para lograr los beneficios estratégicos, tales como mayor efectividad en los costos y mayor agilidad.

Los Servicios Compartidos por encima de las implementaciones de propósito específico

Tal como lo acabamos de explicar, la orientación a servicios establece un enfoque de diseño compuesto por un conjunto de principios de diseño. Cuando se aplican en un grado significativo, estos principios moldean un programa de software como una unidad de lógica orientada a servicio que puede ser descrita con toda legitimidad como un servicio.

Los servicios son equipados con características concretas (tales como las que permiten la interoperabilidad intrínseca) que apoyan directamente los estados objetivo descritos anteriormente. Una de estas características es la que encapsula la sesión de la lógica multipropósito que puede ser compartida y reutilizada en apoyo a la automatización de diferentes procesos del negocio.

Un servicio compartido se establece a sí mismo como un activo TI que puede proveer valor de negocio repetitivo, mientras reduce el gasto y el esfuerzo para entregar nuevas soluciones de automatización. Aunque haya valor en las aplicaciones tradicionales, de propósito particular y, que resuelven requerimientos tácticos del negocio, el uso de servicios compartidos proveen mayor valor en el logro de los objetivos estratégicos de la computación orientada a servicios (lo que, de nuevo, incluye un incremento en la efectividad de los costos y en la agilidad)

La Flexibilidad por encima de la optimización

De todas las declaraciones de priorización de valor, ésta es quizás la de mayor alcance, y debe verse mejor como una filosofía orientadora acerca de cómo priorizar mejor numerosas consideraciones durante la entrega y la evolución de servicios individuales y de inventarios de servicios.

La optimización se refiere principalmente a la satisfacción de beneficios tácticos al afinar el diseño de una aplicación en particular o acelerando su entrega para satisfacer las necesidades inmediatas. No hay nada indeseable acerca de esto, excepto cuando conduce a entornos como los mencionados anteriormente, basados en silos, cuando ellos son priorizados inadecuadamente en función de promover la flexibilidad.

Por ejemplo, la característica de flexibilidad va más allá de la capacidad de un servicio para compartir datos efectivamente (e intrínsecamente). Para ofrecer verdaderamente respuestas a los requerimientos del negocio siempre cambiantes, los servicios deben ser también flexibles en cuanto a cómo pueden combinarse y agregarse en soluciones compuestas. A diferencia de las aplicaciones distribuidas tradicionales, que con frecuencia han sido relativamente estáticas, a pesar del hecho que fueron elaboradas con componentes, las composiciones de servicios necesitan ser diseñadas con un nivel de flexibilidad inherente que permite incrementos constantes. Esto significa que cuando un proceso del negocio existente cambia, o cuando se introduce un nuevo proceso en el negocio, necesitamos ser capaces de agregar, quitar o extender servicios dentro de la arquitectura de la composición con un esfuerzo (de integración) mínimo. Esta es la razón por la cual la capacidad de componer servicios es uno de los principios claves del diseño orientado a servicios.

El refinamiento evolutivo por encima de la búsqueda de la perfección inicial

Hay un punto común de confusión cuando se trata del término “agilidad” en relación con la orientación a servicios. Algunos enfoques de diseño abogan por la entrega rápida de programas de software para obtener beneficios inmediatos. Esto se puede considerar como una “agilidad táctica”, ya que el enfoque está en lo táctico, de corto plazo. La orientación a servicios aboga por lograr la agilidad en el nivel organizacional o del negocio con la intención de dar a la organización, como un todo, la capacidad de responder rápidamente al cambio. Esta forma de agilidad organizacional también puede describirse como “agilidad estratégica” porque el énfasis está en la longevidad en la medida que, con cada programa de software que entregamos, queremos avanzar hacia un estado objetivo que fomente la agilidad con valor estratégico de largo plazo.

Para que una empresa de TI habilite la agilidad organizacional, ella debe evolucionar en paralelo con el negocio. Generalmente, no podemos predecir cómo un negocio necesitará evolucionar en el tiempo ni por lo tanto, construir desde el inicio los servicios perfectos. Al mismo tiempo, existe normalmente una abundancia de conocimientos que ya existe dentro de la inteligencia del negocio existente en la organización, que puede ser cosechada durante las etapas de análisis y modelado de los proyectos SOA.

Esta información, junto con los principios y las metodologías probadas de la orientación a servicios, pueden ayudarnos a identificar y definir un conjunto de servicios que capturan cómo el negocio existe y opera hoy, mientras son suficientemente flexibles para adaptarse a cómo cambia el negocio durante el tiempo.

Esto significa que aunque valoremos los elementos de la derecha, valoramos más los elementos de la izquierda.

Estudiando cómo son priorizados estos valores, nosotros ganamos profundidad en lo que distingue la orientación a servicios de otros paradigmas. Este tipo de profundización interna puede beneficiar a los practicantes de las TI de muchas maneras. Por ejemplo, esto puede ayudar a establecer los criterios fundamentales que podemos utilizar para determinar qué tan compatible es la orientación a servicios para una organización o departamento de TI. Además, esto puede ayudar a determinar la medida en la cual la orientación a servicios puede – o debería – ser adoptada.

Una apreciación de los valores básicos también pueden ayudarnos a entender lo difícil que puede ser llevar a cabo exitosamente los proyectos SOA en determinados entornos. Por ejemplo, varias de estas prioridades pueden chocar frontalmente con las creencias y preferencias establecidas. En tal caso, los beneficios de la orientación a servicios deben sopesarse frente al esfuerzo y el impacto que su adopción pueda tener (no sólo en la tecnología, sino también en la organización y la cultura de TI).

Los principios rectores, a continuación, fueron proporcionados para ayudarnos a abordar muchos de estos tipos de desafíos.

Nosotros seguimos estos principios:

Hasta el momento, el manifiesto ha establecido una visión completa, al igual que un conjunto de valores básicos asociados con la visión. El resto de la declaración está compuesta por un conjunto de principios que son proporcionados como guía para adherirse a los valores y completar la visión.

Es importante mantener en la mente que estos principios orientadores son propios de este manifiesto. Existe un conjunto distinto de principios de diseño establecidos que componen el paradigma de diseño de la orientación a servicios y existen muchas más prácticas documentadas y patrones específicos para la orientación a servicios y la arquitectura orientada a servicios.

Respetar la estructura social y de poder de la organización.

Uno de los errores más comunes de SOA es considerar su adopción como una iniciativa centrada en la tecnología. Hacer esto, casi siempre conduce al fracaso porque simplemente no estamos preparados para los inevitables impactos organizacionales.

La adopción de la orientación a servicios trata sobre la transformación de la manera como automatizamos los negocios. Sin embargo, sin importar los planes que tengamos para lograr este esfuerzo de transformación, siempre debemos comenzar con un entendimiento y una apreciación de la organización, su estructura, sus metas, y su cultura.

La adopción de la orientación a servicios es en gran medida una experiencia humana. Ella requiere del apoyo de las autoridades y luego exige una cultura de TI que adopte un modo de pensar estratégico y centrado en la comunidad. Debemos reconocer y planear completamente este nivel de cambio organizacional con el fin de recibir los compromisos de largo plazo requeridos para lograr el estado objetivo de la orientación a servicios.

Consideraciones de este tipo no sólo nos ayudan a determinar cómo proceder mejor con una iniciativa SOA, sino que ellas nos ayudan más allá a definir el alcance y el enfoque más apropiados para la adopción.

Reconocer que SOA en última instancia exige cambios en muchos niveles.

Hay un dicho que dice: “Éxito es estar preparado para la oportunidad.” Tal vez, la lección aprendida número uno de los proyectos SOA desarrollados es que debemos comprender completamente y luego planear y preparar el volumen y rango del cambio que resultará como consecuencia de la adopción de la orientación a servicios. Siguen algunos ejemplos.

La orientación a servicios cambia la manera como nosotros construimos soluciones de automatización, ubicando los programas de software como activos de TI a largo plazo, con un valor de negocio repetible. Es necesaria una inversión inicial para crear un ambiente compuesto por tales activos y se requiere un compromiso continuo para mantener y aprovechar su valor. Por lo tanto, desde el principio, se requieren cambios acerca de cómo financiamos, medimos y mantenemos sistemas dentro del departamento de TI.

Además, debido a que la orientación a servicios introduce servicios que son ubicados como recursos de la empresa, existirán cambios en la manera como nos apropiamos de las diferentes partes de los sistemas y regulamos su diseño y utilización, sin mencionar los cambios a la infraestructura requeridos para garantizar la escalabilidad y confiabilidad continua.

El alcance de la adopción de SOA puede variar. Mantenga los esfuerzos manejables y dentro de límites significativos.

Un mito común ha sido el que con el fin de alcanzar los objetivos estratégicos de la computación orientada a servicios, la orientación a servicios debe ser adoptada a lo ancho de toda la empresa. Esto significa establecer y hacer cumplir estándares de diseño y de la industria a través del departamento de TI con el fin de crear un inventario de servicios interoperables intrínsecamente para toda la empresa. Mientras no hay nada malo con este ideal, no es una meta real para muchas organizaciones, especialmente aquellas con grandes departamentos de TI.

El alcance más apropiado para cualquier esfuerzo de adopción SOA necesita determinarse como resultado de la planeación y análisis en conjunción con consideraciones prácticas, tales como los impactos previamente mencionados sobre las estructuras organizacionales, áreas de autoridad, y cambios culturales que se logren.

Estos tipos de factores nos ayudan a determinar un alcance de adopción que sea manejable. Pero para que cualquier esfuerzo de adopción resulte en un ambiente que apoye el progreso de la empresa de TI hacia el estado objetivo deseado, el alcance también debe ser significativo. En otras palabras, éste debe abarcar suficientemente a los silos de tal manera que las colecciones de servicios puedan ser entregadas en relación con ellas mismas dentro de un límite predefinido. O sea, queremos crear “continentes de servicios”, no las temidas “islas de servicios.”
Este concepto de construir inventarios de servicios independientemente apropiados y gobernados dentro de los dominios del mismo departamento de TI, reduce muchos de los riesgos que son comúnmente atribuidos al “big-bang” de los proyectos SOA y además, mitiga el impacto tanto de los cambios organizacionales y tecnológicos (debido a que el impacto está limitado a un alcance segmentado y gestionado). También es un enfoque que permite la adopción por etapas donde se pueda establecer, de a uno a la vez, un inventario de servicios del dominio.

Los productos y estándares por sí solos no le darán una SOA, ni le aplicarán por usted el paradigma de orientación a servicios.

Este principio se centra en dos mitos separados pero muy relacionados. El primero, es que usted puede comprar su propio camino hacia SOA con productos de tecnología moderna, y el segundo, es la suposición de que la adopción de estándares de la industria (tales como XML, WSDL, SCA, etc.), resultará de manera natural en una arquitectura de tecnología orientada a servicios.

Las comunidades de estándares de industria y vendedores han recibido el crédito por la construcción de innovación en las tecnologías modernas para servicios sobre marcos de trabajo y plataformas no propietarias. Todo, desde la virtualización de servicios hasta la computación en la nube y la computación por mallas ha ayudado a avanzar en el potencial para construir soluciones orientadas a servicios sofisticadas y complejas.

Sin embargo, ninguna de estas tecnologías es exclusiva para SOA. Se pueden construir, igual de fácil, sistemas basados en silos, en la nube, a como se puede hacer en servidores propios.

No existe tal cosa como “SOA enlatado” debido a que con el fin de alcanzar una arquitectura de tecnología orientada a servicios, se requiere aplicar exitosamente la orientación a servicios; esto, requiere en cambio que todo lo que diseñemos y construimos esté guiado por la dirección única, la visión, y los requerimientos del negocio.

SOA puede ser alcanzado a través de una variedad de tecnologías y de estándares.

La orientación a servicios es un paradigma independiente, en términos de tecnología y de vendedores. La arquitectura orientada a servicios es un modelo de arquitectura independiente de la tecnología e independiente de los vendedores. La computación orientada a servicios puede ser vista como una forma especializada de computación distribuida. Las soluciones orientadas a servicios pueden, por lo tanto, ser construidas utilizando casi cualquiera de las tecnologías y estándares de la industria disponibles para la computación distribuida.

Mientras algunas tecnologías (especialmente aquellas basadas en estándares de la industria) pueden incrementar el potencial para aplicar algunos principios de diseño de la orientación a servicios, es realmente el potencial para cumplir con los requerimientos del negocio lo que determina la selección más adecuada de estándares de tecnología y de industria.

Establecer un conjunto uniforme de estándares empresariales y de políticas basado en estándares de la industria, de facto, y de la comunidad.

Los estándares de la industria representan especificaciones tecnológicas no propietarias que ayudan a establecer, entre otras cosas, características básicas consistentes (tales como transporte, interfaz, formato de mensaje, etc.) de la arquitectura de la tecnología. Sin embargo, el uso de estándares de la industria solamente, no garantiza que los servicios sean intrínsecamente interoperables.

Para que dos programas de software sean completamente compatibles, se necesitan adherir a características adicionales (tales como modelos y políticas de datos). Esta es la razón por la cual los departamentos de TI deben establecer y re-forzar los estándares de diseño. El fracaso en estandarizar y regular apropiadamente la estandarización de servicios dentro de un dominio dado comenzará a desgarrar la estructura de interoperabilidad sobre la cual se basan muchos beneficios estratégicos.

Este principio no sólo aboga por el uso de estándares de diseño empresariales, también nos recuerda que, dondequiera que sea posible y factible, los estándares personalizados deben basarse e incorporar estándares que ya se encuentren en uso por la industria y la comunidad en general.

Perseguir la uniformidad hacia el exterior a la vez que permitir la diversidad internamente.

La federación se puede definir como la unificación de un conjunto de entidades diferentes. Mientras se permite que cada entidad sea independientemente gobernada por su lado, todas acuerdan adherirse a un frente común, unificado.

Una parte fundamental de la arquitectura orientada a servicios es la introducción de una capa de puntos de entrada federados, la que abstrae los detalles de implementación de servicios mientras se publica un conjunto de puntos de entrada que representan servicios individuales dentro de un dominio dado en una manera unificada. Alcanzar esto, involucra generalmente lograr la unidad con base en una combinación de estándares de diseño y de la industria. La consistencia de esta unidad a través de los servicios es la clave para alcanzar la interoperabilidad intrínseca.

Una capa de puntos de entrada federados ayuda aún más a incrementar las oportunidades de explorar las opciones de diversidad de los vendedores. Por ejemplo, un servicio puede necesitar ser construido bajo una plataforma completamente diferente de otra. Mientras que estos servicios mantienen puntos de entrada compatibles, la gobernanza de sus respectivas implementaciones puede permanecer independiente. Esto no sólo realza que los servicios puedan ser construidos utilizando diferentes medios de implementación (tales como EJB, .NET, SOAP, REST, etc.), pero también enfatiza que diferentes plataformas intermediarias y tecnologías pueden utilizarse conjuntamente, según se requiera.
Nótese que este tipo de diversidad tiene un precio. Este principio no aboga por la diversificación en sí misma – éste simplemente recomienda que permitamos la diversificación cuando sea justificada, de tal manera que se puedan aprovechar las plataformas y tecnologías “mejores de su clase” para maximizar el cumplimiento de los requerimientos de negocio.

Identificar los servicios a través de la colaboración con los interesados del negocio y de la tecnología.

Para que las soluciones de tecnología sean orientadas al negocio, la tecnología debe estar sincronizada con el negocio. Por lo tanto, otra meta de la computación orientada a servicios es alinear la tecnología y el negocio. La fase en la cual se realiza inicialmente esta alineación es durante los procesos de análisis y modelado que usualmente preceden las fases actuales de desarrollo y entrega.

El ingrediente crítico para llevar a cabo el análisis orientado a servicios es tener tanto expertos en tecnología como en el negocio trabajando hombro a hombro para identificar y definir los servicios candidatos. Por ejemplo, los expertos del negocio pueden ayudar con precisión a definir los contextos funcionales pertenecientes a los servicios centrados en el negocio, mientras los expertos en tecnología pueden proporcionar los insumos pragmáticos para asegurar que la granularidad y la definición conceptual de los servicios permanezcan realistas en relación con sus eventuales ambientes de implementación.

Maximizar el uso de servicios tomando en consideración el alcance de la utilización actual y futura.

El alcance de un proyecto SOA puede ser el contexto de toda la empresa o puede ser limitado a un dominio de la empresa. Sea cual sea el alcance, se establece un límite pre-definido para abarcar un inventario de los servicios que necesiten ser modelados conceptualmente antes de ser desarrollados. Al modelar múltiples servicios en su relación con otros, establecemos esencialmente un diseño preliminar (blueprint) de los servicios que a la larga, estaremos construyendo. Este ejercicio de modelado es crítico cuando se intenta modificar y definir servicios que pueden ser compartidos entre diferentes soluciones.

Existen diversas metodologías y enfoques que pueden ser utilizados para llevar a cabo las fases de análisis de la orientación a servicios. Sin embargo, un camino común entre todas ellas es que los límites funcionales de los servicios sean normalizados para evitar la redundancia. Aún así, los servicios normalizados no necesariamente hacen que los servicios sean altamente reutilizables. Otros factores entran en juego, tales como la granularidad del servicio, la autonomía, la gestión del estado, la escalabilidad, la compuestabilidad, y la medida en que la lógica del servicio es suficientemente genérica para que se pueda reutilizar efectivamente.

Este tipo de consideraciones, guiadas por los expertos en tecnología y negocios, proporcionan la oportunidad para definir servicios que capturen los requerimientos de utilización actual, mientras tienen la flexibilidad de adaptarse al cambio futuro.

Verificar que los servicios satisfacen los requerimientos y las metas del negocio.

Como con cualquier cosa, los servicios pueden ser mal utilizados. Al crecer y gestionar un portafolio de servicios, su uso y eficacia en el cumplimiento de los requerimientos de negocio deben ser verificados y medidos. Las herramientas modernas proporcionan varios medios para monitorear los servicios, pero existen intangibles que también necesitan ser tomados en consideración para asegurar que los servicios no sean utilizados sólo porque están disponibles, sino para verificar que ellos realmente están cumpliendo las necesidades de negocio y llenando las expectativas.

Esto es cierto, especialmente con servicios compartidos, que soportan múltiples dependencias. No sólo los servicios compartidos requieren una infraestructura adecuada para garantizar la escalabilidad y la confiabilidad para todas las soluciones que los reutilicen, sino que también necesitan ser diseñados y extendidos con gran cuidado para asegurar que sus contextos funcionales nunca estén sesgados.

Hacer evolucionar los servicios y su organización en respuesta al uso real.

Este principio rector se relaciona directamente, y de nuevo, con la declaración del principio “El refinamiento evolutivo por encima de la búsqueda de la perfección inicial”, al igual que el objetivo general de mantener una alineación del negocio con la tecnología.

Nunca podemos esperar caer en conjeturas cuando se trata de determinar la granularidad de los servicios, el rango de las funciones que los servicios necesitan desarrollar, o como los servicios necesitan organizarse en composiciones.
Basados en cualquier grado de análisis que seamos capaces de desarrollar inicialmente, a un determinado servicio se le asignará un contexto funcional definido y contendrá una o más capacidades funcionales que probablemente lo involucrarán en una o más composiciones de servicios.

Como los requerimientos de negocios del mundo real y las circunstancias cambian, el servicio puede requerir ser aumentado, extendido, re-factorizado, o tal vez inclusive reemplazado. Los principios de diseño de la orientación a servicios construyen nativamente la flexibilidad en las arquitecturas de servicios de tal manera que, como programas de software, los servicios son flexibles y adaptables al cambio y a ser modificados en respuesta al uso en el mundo real.

Separar los diferentes aspectos de un sistema que cambian con diferentes tasas de cambio.

Lo que hace inflexible a los sistemas monolíticos y basados en silos es que el cambio puede tener un impacto significativo sobre su uso existente. Esto es porque, a menudo, es más fácil crear nuevas aplicaciones basadas en silos en lugar de aumentar o extender las existentes.

La razón detrás de la separación de preocupaciones (una teoría de ingeniería del software comúnmente conocida) es que un problema más grande puede ser solucionado más efectivamente cuando se descompone en un conjunto de problemas o preocupaciones más pequeñas. Cuando se aplica la orientación a servicios a la separación de preocupaciones, nosotros construimos unidades correspondientes de lógica resolutiva(lógica de la solución) para resolver preocupaciones individuales, permitiéndonos agregar las unidades para solucionar el problema más grande, además de darnos la oportunidad de agregarlos en diferentes configuraciones con el fin de solucionar otros problemas.

Además de fomentar la reutilización de servicios, este enfoque introduce varias capas de abstracción que ayudan a proteger a los sistemas compuestos por servicios del impacto del cambio. Esta forma de abstracción puede existir a diferentes niveles. Por ejemplo, si los recursos heredados que están encapsulados por un servicio necesitan reemplazarse, el impacto de dicho cambio puede ser mitigado siempre y cuando el servicio es capaz de retener su punto de entrada original y su comportamiento funcional.

Otro ejemplo es la separación de la lógica agnóstica de la lógica no-agnóstica. El primer tipo de lógica tiene un potencial de alta reutilización si es multi-propósito y con menos probabilidad de cambio. La lógica no-agnóstica, por otra parte, representa típicamente los elementos de propósito particular de la lógica de procesos del negocio padre, las cuales a menudo son más volátiles. Además, separar los respectivos tipos de lógicas en diferentes capas de servicios introduce la abstracción que permite la reutilización de los servicios a la vez que los protege, y cualesquiera soluciones que los utilizan, de los impactos del cambio.

Reducir las dependencias implícitas y publicar todas las dependencias externas para incrementar la robustez y reducir el impacto del cambio.

Uno de los principios de diseño más conocidos de la orientación a servicios es el del bajo acoplamiento del servicio. La manera como se estructura internamente una arquitectura y la forma como se relacionan los servicios con los programas que los consumen (los cuales pueden incluir otros servicios), se resumen en las dependencias que son formadas sobre las piezas individualmente móviles que son parte de la arquitectura de servicios.

Las capas de abstracción ayudan a facilitar el cambio evolutivo mediante la localización de los impactos del cambio hacia regiones controladas. Por ejemplo, en las arquitecturas de los servicios, las fachadas de servicios pueden utilizarse para abstraer partes de la implementación con el fin de minimizar el alcance de las dependencias de la implementación.

Por otro lado, los contratos técnicos de servicios publicados deben dar a conocer las dependencias que los consumidores de servicios deben formar con el fin de interactuar con los servicios. Al reducir las dependencias internas que pueden afectar estos contratos técnicos, cuando se produce el cambio, evitamos la propagación del impacto de dichos cambios hacia los servicios consumidores con relación de dependencia.

En cada nivel de abstracción, organizar cada servicio alrededor de una unidad de funcionalidad cohesiva y administrable.

Cada servicio requiere un contexto funcional bien definido que determine cuál lógica pertenece -o no- al límite funcional del servicio. Determinar el alcance y granularidad de estos límites funcionales del servicio, es una de las responsabilidades más críticas durante el ciclo de vida de la entrega del servicio.

Los servicios con granularidad funcional gruesa también pueden ser demasiado inflexibles para ser efectivos, especialmente si se espera que sean reutilizables. Por otra parte, los servicios con granularidad demasiado fina pueden gravar una infraestructura en la medida que las composiciones de servicios requerirán constituirse con una cantidad creciente de miembros.

Determinar el balance correcto del alcance funcional y de la granularidad requiere una combinación de experiencia en negocio y tecnología, y además requiere un entendimiento de cómo los servicios se relacionan entre sí en un límite dado.

Muchos de los principios rectores descritos en este manifiesto ayudarán en la toma de esta determinación en apoyo para posicionar cada servicio como un activo de TI capaz de llevar a un departamento de TI hacia aquel estado objetivo con el cual se alcancen los beneficios estratégicos de la computación orientada a servicios.

Sin embargo, a fin de cuentas, siempre será la vinculación con el valor del negocio del mundo real quien dicte, desde la concepción hasta la entrega y hasta el uso repetido, el camino evolutivo de cualquier unidad de funcionalidad orientada a servicios.

Agradecimientos: Escribí el contenido de esta página en el fin de semana de Noviembre 21-22, de 2009 para el libro Next Generation SOA que estaba aún en fase de desarrollo. Me gustaría agradecer a Prentice Hall por permitir que este contenido sea abiertamente publicado en este sitio como un suplemento al Manifiesto SOA original. También me gustaría agradecer a los miembros del grupo de trabajo de la comunidad de SOAPatterns.org quienes proporcionaron realimentación con estos comentarios. Muchos de los miembros del grupo de trabajo han publicado sus propios artículos, blogs, y artículos acerca del Manifiesto SOA y los invito a todos a buscarlos externamente para encontrar más comentarios y puntos de vista.

– Thomas Erl

---

Traducción Al Español

Iván Alfonso Guarín V

Yves Chaix