Convergencia soa – api. Estrategia y tácticas.

En el pasado cuando nació la SOA-manía, los defensores de esa nueva corriente de diseño y desarrollo de sistemas distribuidos atribuían multitud de beneficios en aspectos
de negocio y perspectivas técnicas. Los beneficios son reales, pero sin embargo, en la mayoría de ocasiones difíciles de obtener, ya que requieren un gran cambio de mentalidad
en los departamentos TIC y en la mayoría de aspectos corporativos. En la actualidad sorprendentemente los defensores de las API, en sus argumentaciones expresan beneficios similares a aquellos que se otorgaban a SOA, pero más enfocados a la ejecución.

El paradigma SOA puede ser usado como estrategia para alinear los activos de TIC con las capacidades, los recursos y los procesos de negocio. El enfoque principal de la filosofía
SOA es el intercambio y la reutilización para optimizar el uso de los activos disponibles TIC en la empresa. En origen algunas de las promesas de SOA eran desconcertantes, ya
que prometía la reinvención de las interacciones business-to-business, permitir mejores relaciones entre partners y dar soporte a las redes de procesos. Los servicios externos
fueron vistos como un mecanismo para mejorar aspectos económicos empresariales mediante la reducción de costes de integración e interacción, facilitando la incorporación
de capacidades de negocio externas, permitiendo la especialización en las aplicaciones empresariales y creando soluciones de alto valor añadido para extender los procesos propios de la empresa a través de una red de socios¹.

El actual negocio de la Economía API² recoge las propuestas de valor de negocio que ofrece SOA a lo que se le añade lecciones ya aprendidas anteriormente sobre SOA, y usa
tendencias tecnológicas populares en la industria cómo REST, Internet of Everything, móvil y Servicios en la nube.

Desde una perspectiva técnica, una arquitectura SOA debe presentar tres principios clave en su diseño; orientación al servicio, separación clara de conceptos y bajo acoplamiento.
La orientación al servicio se mide por la reutilización de servicios, la granularidad y la simplicidad arquitectónica.

La separación de conceptos la podemos evaluar mediante pruebas de separación entre la lógica de negocio y la infraestructura, entre la interfaz y la aplicación y entre la interfaz y
las competencias. Por último un débil acoplamiento se evalúa por la interoperabilidad, el control de las transacciones, y la mediación de las interacciones.

Superficialmente las API REST son simplemente una versión especializada de servicios web y proporcionan beneficios técnicos similares. Tanto el diseño de la API REST como de los
servicios SOA tienen la intención de exponer funcionalidades individuales a través de una interfaz bien definida. El endpoint de una API y el de un servicio sirven ambos como una
pieza core de diseño, y los equipos de desarrollo ofrecen soluciones técnicas mediante el acceso, la agregación, la composición y la orquestación de las interacciones entre ellos.

Una solución exitosa y escalable ya esté cimentada en API o en servicios SOA requiere una óptima infraestructura mensajería, gestión de niveles de servicio y seguridad.

A pesar de que ambas propuestas API y SOA tienen objetivos de negocio y técnicos similares, se está produciendo una ruptura cada vez más evidente entre las dos tecnologías.
El cisma desde el punto de vista pragmático API REST y SOA está causado por las diferencias en el enfoque estratégico.

Los equipos de desarrollo ‘que hacen REST’ y ‘construyen APIs’ habitualmente se enfocan en superar las barreras de adopción tecnológicas y de negocio mediante
build-outs incrementales y demos concretas de casos de uso del core de negocio sin la introducción de complejidades (y complicaciones) tecnológicas. En cambio los equipos
SOA comúnmente se centran en: la obtención de eficiencias a escala para lograr la estandarización de los sistemas empresariales, la centralización de las decisiones, y en satisfacer complejos requisitos no funcionales.

REST es un estilo de arquitectura de desarrollo de sistemas que impone una serie de restricciones entre las interacciones de servicios. Todas juntas, estas restricciones
permiten que emerjan propiedades como la simplicidad, la escalabilidad, la capacidad de modificación, la fiabilidad, la visibilidad, el rendimiento y la portabilidad. Los Sistemas que
satisfacen estas restricciones son RESTful. Un diseño RESTful puede fomentar muchos beneficios:

• Hacer que los datos y los servicios sean accesibles al máximo.
• Entrada en el entorno, sencilla y con pocas barreras.
• Ampliación del alcance dirigido a la mayor audiencia posible.
• Hacer que los servicios/API sean consumidos por el mayor número de agentes posibles.
• Hacer que datos y los servicios evolutivos.
• Extender el sistema en tiempo de ejecución.
• Alterar los recursos sin impactar a los clientes.
• Dirigir el comportamiento del cliente dinámicamente.
• Hacer los sistemas escalables, fiables y de alto rendimiento.
• Simplificación.
• Cacheable.
• Atomización.

Mientras que los beneficios del diseño RESTful soportan los objetivos SOA, el foco de la estrategia pragmática REST difiere de muchas iniciativas SOA. Los equipos de diseño
de REST API se centran en adopción de escenarios bottoms-up , formatos y protocolos accesibles (p.ej. HTTP, JSON, DNS), definición de interfaces permisivas y modelos de interacción simples.

El enfoque pragmático SOA se centra en los patrones de la orientación a servicios para aumentar el valor de los recursos del software.

Los fundamentos de los patrones de la orientación a servicios son:

• Compartir y reutilizar recursos.
• Consolidar las funcionalidades redundantes para conseguir un menor número de partes “transportables”.
• Conformar los proyectos pensando en estándares comunes y buenas prácticas.

La aplicación estos tres patrones reducirá la complejidad dentro de un entorno TI y proporcionará mayor agilidad de desarrollo, es decir, la habilidad de construir aplicaciones
en el menor tiempo posible y modificarlas rápidamente para redirigir los cambios requisitos que se produzcan. El patrón de orientación a servicios fuerza a los equipos de desarrollo a
evaluar como las capacidades de los recursos de software satisfacen las necesidades de los intereses de negocio. Los equipos con enfoques SOA Pragmáticos ofrecen capacidades de
negocio útiles, reducen las fricciones en la adopción del sistema y proporcionan valores de servicio excepcionales.

Estos equipos no predican difíciles buenas prácticas. Simplifican su adopción haciendo mentoring y entregando el gobierno del servicio de manera automatizada que hace fácil de
hacer al equipo, lo que hay que hacer. Los equipos de SOA “pragmático” son conscientes de las carencias en las capacidades
que pueden sufrir sus integrantes y los obstáculos y dificultados en la adopción de las tecnologías, y es por este motivo que habitualmente ofrecen packs de “aceleración”
(infraestructuras, herramientas, frameworks, bloques de construcción de API/service) que reducen la formación, aumentan la “auto-adopción” y, por lo tanto, aceleran la entrega del proyecto.

Para conseguir esos resultados se debe de equilibrar la balanza entre el gobierno “de negocio” y la autonomía del proyecto. En lugar de erigir barreras de registro y desarrollo,
estos equipos tienen éxito cuando promueve el desarrollo, intercambio y adopción del servicio mediante la introducción de mecanismos que promuevan su uso, que medien
las interacciones, que endurezcan los niveles de servicio y que faciliten la adopción vía el autoservicio. Estos mecanismos se reconocen como el núcleo de la gestión de la API.

REST es diferente a, aunque no incompatible con, SOA. Los servicios pueden ser RESTful, y los recursos RESTful pueden ser servicios. Como SOA, REST es una disciplina
arquitectónica definida por un conjunto de principios de diseño, y también impone un conjunto de restricciones. REST usa un modelo centrado en los recursos el cual es lo
contrario a un modelo centrado en los objetos, es decir, comportamientos encapsulados por recursos. En REST cada “cosa” de interés es un recurso. Cuando se modela un servicio
RESTful (aka API), las capacidades del servicio están encapsuladas y expuestas como un conjunto de recursos.

Debido a que SOA presenta una arquitectura cuyo objetivo es contrario a un portfolio de sistemas legacy TI de largo recorrido, se convierte en un viaje arquitectónico a largo
plazo, y no una iniciativa puesta en práctica para obtener un resultado a corto. A causa de las capacidades de interconexión interna y externa de las APIs, éstas pueden proveer
una plataforma para las empresas sponsors TI interesadas en renovarse y una ejecución empresarial pragmática.

SOA representa un cambio de paradigma significativo en las técnicas de desarrollo
de aplicaciones. SOA es una disciplina de diseño de software en la cual aplicación y la funcionalidad de la infraestructura están implementadas como como servicios compartidos
y reusables. Cada servicio implementa una tarea concreta, y cada aplicación que necesita realizar la tarea usa el servicio compartido para hacerlo. Los equipos de desarrollo crean
aplicaciones ensamblando los servicios apropiados, posteriormente se implementan las funcionalidades de negocio como servicios, para que una organización, sus partners, y sus
clientes puedan ser capaces de mezclar y encontrar esos servicios y rápidamente crear una aplicación que soporte requisitos de negocio cambiantes. La economía API y los
mensajes API negocio/desarrollador refuerzan la propuesta tradicional de valor de SOA. Los beneficios de usar la plataforma WSO2 para implementar estos servicios incluyen:

Debido a que SOA presenta una arquitectura cuyo objetivo es contrario a un portfolio de sistemas legacy TI de largo recorrido, se convierte en un viaje arquitectónico a largo
plazo, y no una iniciativa puesta en práctica para obtener un resultado a corto. A causa de las capacidades de interconexión interna y externa de las APIs, éstas pueden proveer
una plataforma para las empresas sponsors TI interesadas en renovarse, una ejecución empresarial pragmática y beneficios económicos rápidos.

Los últimos diez años de promoción, implementación y evaluación SOA han cultivado
dos caminos diferentes de aproximación a esta arquitectura; La mentalidad “Big SOA” y la mentalidad “Small SOA”. En relación a las estrategias API actuales existen dos aproximaciones la mentalidad API-Access y la mentalidad Empresarial API-Centric.

Las organizaciones que quieren adoptar “Big SOA” requieren escalar el proceso de adopción a través de múltiples consumidores estableciendo un conocimiento compartido
para dominar la lógica de negocio y la tecnología. Cada servicio es una parte de la gran fotografía, y un servicio bien diseñado conecta con procesos de negocio existentes y da solución a requisitos de negocio definidos.

Una adopción de servicios efectiva en na empresa requiere un esfuerzo significativo en la planificación, la coordinación y el gobernó de la solución.

Las iniciativas “Big SOA” se enfocan en el gobierno de los procesos empresariales, en la reutilización global empresarial y la consolidación del portfolio de servicios. La consecución
de estos grandes objetivos requiere cambios estructurales en tiempo de diseño de los procesos y la superación de significativas diferencias culturales que conducen a la
inhibición de diseño, contabilidad, control y ramificaciones operacionales. Las iniciativas “Big SOA” tradicionales pueden tener éxito, pero solo si tienen apoyo de la organización
al más alto nivel que permita superar la inercia organizacional y los silos de los equipos de proyecto para crear puentes entre ellos y operar como un solo equipo

Cuando un equipo de desarrollo se plantea el uso de Big SOA, es necesario encontrar un punto de entrada efectivo. Algunos equipos comienzan con una iniciativa impulsada
desde el propio departamento TI o siguiendo la estela de alguna importante iniciativa de transformación impulsado por la misma lógica de negocio. El acercamiento a Big
SOA a través de iniciativas salidas de TI puede ser muy efectivo cuando se centra en construir infraestructuras de servicios compartidas, tales como seguridad, identidad,
autoría, monitorización o gestión de la nube. Estos esfuerzos pueden proporcionar rápidas recuperaciones de la inversión (ROI), y no requieren una extensa colaboración con las
unidades de negocio para el éxito. Por otro lado, este acercamiento retrasa la participación de los departamentos de negocio y puede que se reconozca una rentabilidad de la
inversión mínima, a no ser que se incorpore en iniciativas empresariales más visibles como la gestión de riesgos, ciber-seguridad o la experiencia de usuario.

El acercamiento a Big SOA cuando se impulsa desde negocio es muy a menudo se desencadena por imperativo de la cúpula para rediseñar los procesos de negocio y/o la
experiencia de usuario. Por diseño, estos esfuerzos de transformación de negocio deben ser fuertemente coordinados a través del departamento TI y de las distintas unidades de
negocio implicadas. Big SOA, en este caso sigue la estela de una inversión en la cartera de servicios que ofrece la empresa.

Una iniciativa Big SOA es debe ser tomada como un proyecto corto de tres o cuatro meses,
sino un que debe seguir un programa de varios años, que contará con muchos pasos en su roadmap. Para maximizar y acelerar el éxito, el equipo que se embarque camino a Big SOA debe incorporar un programa de transformación estructurada:

• Elaborar un grupo multifuncional de trabajo.
• Desarrollar un plan de adopción SOA.
• Definir la cartera de servicios objetivo.
• Desarrolla un Caso de Negocio.
• Planificar y recaudar fondos para una infraestructura SOA.
• Establecer los nuevos roles.
• Planificar la formación y el plan de “mentoring” para el personal.
• Desarrollar políticas corporativas, guías y Buenas prácticas.
• Instituir los procesos de Gobierno SOA.
• Establecer nuevas iniciativas buscando un buen comportamiento.
• Identificar proyectos Candidatos.
• Establecer prioridades.
• Re-evaluar el Ciclo de Vida de Desarrollo de Software (SDLC).

Muchos equipos que se aventuran hacia el establecimiento de una arquitectura SOA no tienen la autoridad, el control del ámbito dónde se quiere instaurar, o la influencia para
implementar las actividades necesarias Big SOA. Sin posibilidad de obtener éxito en la instauración de Big SOA que muchas organizaciones padecen, los miembros de los equipos
que quieren “hacer SOA” y demostrar el valor que ello aporta al negocio focalizan sus esfuerzos en el Small SOA.

Una aproximación a Small SOA implementa los principios SOA basado en Proyecto-porproyecto. Esta aproximación incurre en menos riesgos, pero produce un retorno más
pequeño. Típicamente hay coordinación limitada entre proyectos y además no requiere “forcejeos” entre departamentos o cambios en la política global de la empresa. El uso de
un proceso Small SOA permite a la organización crear la cartera de servicios más despacio, pero con una coordinación limitada, los procesos son menos propensos a ser reusados o
compartidos entre múltiples consumidores.

Las iniciativas Small SOA a menudo se focalizan en aspectos “run-time” en lugar de en
aspectos “design-time”, es decir se busca más el resultado en ejecución y no se realiza un diseño profundo de la solución.

Las inquietudes más frecuentes en entornos “run-time” es habilitar un estilo de comunicación flexible, patrones de interacción y mecanismos de mediación que faciliten la integración y promuevan una articulación flexible. Los ejemplos de estilos de comunicación
incluyen sincronía, a sincronía y peticiones de mensajes de respuesta.

Los patrones de interacción soportados más comunes incluyen peer-to-peer, entrega
negociada (broker delivery), hub-and-spoke, publicación/subscripción (publish/subscribe) y orquestación de procesos, los cuales son usados como puente para cerrar el espacio
entre la disponibilidad, la confiabilidad y la topología consumidor-proveedor

Los mecanismos de mediación reducen la necesidad de proveer plataformas de mensajería
simétrica dónde ambos, consumidor y proveedor se comunican usando el mismo protocolo, formato de mensaje y estilo de comunicación. Los mecanismos de mediación también
encapsulan los detalles de la implementación relacionados con la localización, el versionado y el dominio de identidades (identity domain).

Con la adopción de Small SOA conducido desde el punto de vista TI requiere una aproximación cautelosa para no dejar que el esfuerzo se focalice exclusivamente en la
tecnología en lugar de en diseño, cultura y objetivos TI.

Los equipos que quieran adoptar Small SOA desde una aproximación TI tendrán éxito cuando fomenten seguimientos de adopción de consumo de los servicios y de
subscriptores, as fomentar historias de adopción de consumo, los suscriptores del servicio de pista, y dar a conocer el crecimiento del uso de los servicios en la organización.

Con la adopción de Small SOA conducido desde el punto de vista TI requiere una aproximación cautelosa para no dejar que el esfuerzo se focalice exclusivamente en la
tecnología en lugar de en diseño, cultura y objetivos TI.

Los equipos que quieran adoptar Small SOA desde una aproximación TI tendrán éxito cuando fomenten seguimientos de adopción de consumo de los servicios y de
subscriptores, as fomentar historias de adopción de consumo, los suscriptores del servicio de pista, y dar a conocer el crecimiento del uso de los servicios en la organización.

Un enfoque Small SOA impulsada desde negocio, puede dar lugar a casos de éxito atractivos, los cuales ayudarán y propiciarán la adopción de SOA. Sin embargo los activos
de negocio son de dudosa reutilización sin la colaboración entre equipos y la promoción. Los esfuerzos descoordinados y sin gobierno de proyecto-a-proyecto pueden generar una
situación caótica que resulta en un poco e incluso nula, reutilización de lo implementado, ¿Cuántos de los servicios desarrollados son compartidos?, y ¿Cuántos servicios son
simplemente una forma de facilitar integraciones punto a punto?

Similar al Small SOA conducido desde negocio, la aproximación API-Access es el resultado
de casos de éxito convincentes, lo que favorece aún más la adopción. Proporcionando una plataforma tecnológica API-Restful accesible para que los equipos que integren TI
y conocimientos de negocio con apps móviles, aplicaciones Javascript basadas en el navegador o Shell scripts máquina-máquina (M2M).

Mientras que la tecnología API puede ser un adelanto de una estrategia SOA, las APIs no necesitan seguir los principios SOA (por ejemplo, débil acoplamiento, separación de intereses, orientación a servicio), y los equipos API se pueden fija de manera predominante
en preocupaciones derivadas de las integraciones que refuerzan los silos de capacidades. Los equipos de proyectos API abarcan el control de dominios e integran APIs externas para
dar soluciones al proyecto.

En lugar de centrarse en el intercambio de información y en las inquietudes por la reusabilidad
(un enfoque más SOA), los defensores de la tecnología API evangelizan cómo los equipos pueden rediseñar su negocio, aumentar el crecimiento de los ingresos y retener
a los clientes mediante de una Empresa API-Centric. (Empresa con la tecnología API como centro de sus esfuerzos TI y de negocio)

Las empresas API-Centric se mueven más allá de un destino ecommerce para abrazar
descentralización, personalización, contextualización, gamification, y los canales de
distribución dinámicos. Las tendencias tecnológicas engloban estos conceptos incluyendo
los canales móviles, M2M (machine-to-machine), P2P (person-to-person), B2D (businessto-developer).
En cada caso, las APIs son el pegamento que conecta los distintos actores
y componente distribuidos de la solución. Los equipos tecnológicos en las empresas
API-Centric usan las API para montar rápidamente soluciones utilizando bloques de
construcción internos y externos. Debido a que las API extienden la accesibilidad, facilitan
el consumo y reducen las barreras técnicas, los usuarios avanzados de negocio y los
desarrolladores pueden ajustar rápidamente soluciones conjuntas. Estos bloques preconstruidos
API incluyen, por ejemplo, módulos de clientes, pedidos, productos, logística,
mapas, email, SMS, clima o tráfico.

En adición a los beneficios de ganancia interna en la productividad, las empresas APICentric
consiguen más clientes y generan una actividad de negocio mayor. Las APIs
facilitan la interconexión de procesos de negocio a través de una cadena de valor
extendido. Socios, proveedores, distribuidores y clientes pueden aprovechar rápidamente
una capacidad de negocio ofrecida como una API, y aumentar la interacción de negocio
sobre el canal API.

Los equipos de desarrollo, en lugar de crear una arquitectura consistente de servicios y
demostrar la capacidad de re-utilización de los servicios, a menudo producen de manera
inadvertida solo un conjunto de Web Services (Just a Bunch of Web Services, JBOWS) o un
conjunto de Servicios REST (Just a Bunch of REST Services, JBORS).

Una aplicación frecuentemente consume un servicio y una web de conexiones “spaghetti”
uno-a-uno entre los endpoints del proveedor del servicio y los consumidores. Muchos
equipos encuentran que un desarrollo enfocado en SOA o REST puede no mejorar la
agilidad TI, pero esto resulta en un simple intercambio de herramientas TI, formatos de
mensajes y protocolos.

La infraestructura TI, el diseño de procesos, el gobiernos, la cultura y los incentivos
deberían ayudar a conseguir los objetivos de negocia SOA y API incentivando la
compartición de recursos y la reutilización, consolidando la funcionalidad y la conducción
de la adopción tecnológica por parte del equipo de desarrollo.

Para crear un mejor entorno para la arquitectura y ganar agilidad API-Centric, los equipos
deben entender:

• Cuándo crear servicios
• Cuándo crear APIs
• Cómo acercar gobierno de servicio y de API
• Cómo los servicios y las APIs impactan en el gobierno de la aplicación

Se debe crear un servicio cuando se quieren compartir capacidades o información de
negocio entre aplicaciones de red o limitar las aplicaciones en tiempo de ejecución. Un
servicio debe implementar una tarea de negocio autónoma de manera razonable y no estar
diseñado de manera excesivamente granular como un componente con interdependencias
con otros componentes. Desarrolladores y analistas de negocio son más cercanos a
entender el propósito del servicio cuando éste expone una tarea ligada con un proceso de
negocio. Diseñando servicios para tareas de negocio la granularidad reduce la complejidad
de las interacciones del servicio y simplifica el mantenimiento de la aplicación.

Ejemplos de tareas de negocio que son compatibles con una aproximación orientada
a servicio incluye “tramitar un pedido”, “recuperar un registro de cliente” y “pagar una
factura”. El servicio debe exponer sus competencias a través de múltiples estilos de
interfaces (HTTP/JSON, XML/JMS, SOAP/SML, asíncrono, síncrono), y las APIs RESTful
son solo un estilo de interfaz. Idealmente, el estilo del interfaz es solo un tipo de
implementación con características de gestión importantes (seguridad, cumplimento del
nivel del servicio, seguimiento de uso) estarán disponibles entre todos los canales de los
interfaces (por ejemplo, orientación a recurso, publish/subscribe, método de invocación).
La Ilustración 1 Ilustra el patrón de implementación de fachada (facade)

La separación del contrato y los protocolos externos de la representación interna impacta
positivamente en la habilidad de evolución de la implementación del servicio en el tiempo.
Cuando existe una clara separación de la interfaz con respecto a la implementación, un
desarrollador puede modificar la implementación sin impactar las aplicaciones que llaman y
usan el servicio.

Sin embargo, desacoplar el consumidor y el proveedor desde una plataforma de aplicación
compartida, y desacoplar interfaz de implementación hace que surjan aspectos adicionales
a tener en cuenta. Por ejemplo, las dificultados aparecen cuando se intentan flujos
continuos en operaciones semánticas (seamlessly flowing), es decir, identidad, niveles de
servicio, autorización entre plataformas diferentes y entornos distribuidos. Los equipos
confían en infraestructuras middleware para enlazar las semánticas entre todas las partes
participantes y los componentes.

Porque separar interfaz de implementación introduce complejidad y esfuerzos de
desarrollo extra, muchos equipos deciden vincular estrechamente la interfaz a la
implementación. Siguiendo buenas prácticas arquitectónicas e introduciendo fachadas API
o Proxy endpoints (con desarrollo automatizado), los equipos aumentan la capacidad de
mantenimiento y adaptación de la solución.

En general se crea una API Restful cuando compartimos un servicio fuera de un dominio
controlado, es decir, unidades de negocio, organización, etc…, considerando que va dirigido
y orientado a conseguir al mayor alcance y consumos posibles, ofreciendo el servicio
a través de una infraestructura web nativa o con el interés de maximizar la evolución
asimétrica entre los clientes de servicios, interfaces e implementación.

Cuando los equipos de desarrollo publican fachadas API delante de los servicios existentes,
explícitamente separan el interfaz del servicio de la implementación del servicio. Los
endpoints API son proxies ligeros que refuerzan la seguridad, monitorizan el uso y
distribuyen el tráfico. El proxy permite una clara separación de conceptos entre el contrato
del interfaz de consumo y la implementación del “back-end” del servicio.

Mientras los servidores de aplicación, los nodos del bus de servicios empresarial o los hosts
de servicios de datos pueden publicar API endpoints, las API gateways son el mecanismo
preferido para la entrega. Una API gestionada está:

• Publicitado activamente y es suscribible.
• Disponible con un SLA asociado y publicado.
• Asegurado, Autenticado, Autorizado y protegido.
• Monitorizado y monetizado con analíticas.

Las APIs RESTful exponen un interfaz orientado a recurso. El interfaz es un conjunto de
recursos, cada uno exponiendo una API uniforme. Para crear una API RESTful:

1. Dar a todo un “ID”.
2. Enlazar todas las cosas entre ellas.
3. Usar métodos HTTP estándar.
4. Permitir la representación en múltiples formatos de mensaje.
5. Reducir el estado compartido.

El éxito de una iniciativa SOA requiere la creación de conexiones consumidor-proveedor
poco acopladas, rebajando la separación de aspectos en los que estén involucrados ambos,
exponiendo un conjunto de servicios reusables y compartibles y consiguiendo la adopción
tecnológica por parte del consumidor del servicio.

Muchos equipos de desarrollo publican servicios, mientras en paralelo siguen peleando
por crear una arquitectura de servicios que pueda cumplir los requisitos SOA, compartida,
reusable y adoptable entre los distintos equipos de desarrollo internos. En su lugar,
sin proponérselo, en lugar de crear esa arquitectura de servicios consistente de la que
hablábamos producen sólo un grupo de servicios web o de servicios REST (JBOWS o
JBORS).

Una aplicación frecuentemente consume un servicio y una web de conexiones “spaghetti”
uno-a-uno entre los endpoints del proveedor del servicio y los consumidores. Muchos
equipos encuentran que un desarrollo enfocado en SOA o REST no mejoraría la agilidad
TI, y el resultado es en un simple intercambio de herramientas TI, formatos de mensajes y
protocolos. El Gobierno SOA, el Gobierno API y el Gobierno de la Aplicación pueden cerrar
la brecha y mejorar la coherencia en la arquitectura del sistema.

En muchas organizaciones, las iniciativas SOA acaban siendo soluciones en integraciones
punto-a-punto en lugar de arquitecturas, generalmente porque no existen programas de
gobierno que mitiguen los factores de riesgo y soporten los principios SOA. Retrasar la
creación del gobierno en los proyectos a menudo resulta en la creación de servicios que
no pueden ser re-utilizados posteriormente, la proliferación de múltiples definiciones de
dominios de negocio y el aumento del mantenimiento del coste del catálogo de servicios
de la empresa.

Un Gobierno SOA efectivo controla el desarrollo y el operativo de los sistemas orientados a
servicios, y está implementado usando políticas, procesos, métricas y organización:

• Las políticas especifican la forma “correcta” de hacer las cosas, éstas codifican leyes,
  regulaciones, guías corporativas y buenas prácticas.
• Los procesos son actividades que proporcionan una oportunidad de probar un
  proyecto o artefacto conforme a las políticas y permiten tomar la decisión de avanzar
  o no. Algunos procesos son automáticos y son dirigidos por el sistema y otros
  requiere esfuerzo humano.
• Las métricas proporcionan visibilidad en el programa de Gobierno y son requeridas
  para medir y verificar cómo se cumple la aplicación de las políticas.
• La organización debe alentar una cultura empresarial que de soporte y aliente unas
  buenas prácticas en el Gobierno.

Un programa de Gobierno SOA debería proporcionar la guía para el ciclo de vida integral
del servicio, incluyendo la creación, las pruebas, el aprovisionamiento, el uso, la gestión y
el versionado. Los componentes de una infraestructura de Gobierno SOA proporcionan
herramientas y servicios que dan soporte a un programa de Gobierno, ofrecen mecanismos
para: gestionar y mantener las políticas y para imponer unos checkpoints durante varias
fases del ciclo de vida de desarrollo de software (SDLC) verificando que los servicios, las
APIs y/o los proyectos cumplen con esas políticas. También proporciona mecanismos que
permiten la aprobación manual y automática y la gestión de excepciones de los procesos.
Todo esto permite al Gobierno SOA la integración con las herramientas del ciclo de vida
de desarrollo tradicional (SDLC) y de los sistemas de gestión y gobierno habituales de las
tecnologías de la información (TI).

Algunos componentes de la infraestructura de Gobierno SOA están dirigidos al gobierno
del tiempo de desarrollo, y otros componentes al gobierno están destinados al gobierno
a nivel de ejecución (runtime). Por ejemplo el componente “Service registry” permite un
puente entre los componentes desarrollo y los de ejecución.

Un objetivo clave para las iniciativas SOA es conseguir un portfolio de servicios que
exhiba una arquitectura clara. Los modelos de negocio técnicos e industriales verticales
son puntos de inicio útiles para el desarrollo de un catálogo de servicios único para una
organización. El diseño de servicios e interfaces son pequeñas piezas de un conjunto de
programas más grandes que deben ser gestionados para establecer una altamente efectiva
manera de entrega, colaboración y confiabilidad de los servicios TI.

Iniciando proyectos complementarios como la gestión de los procesos de negocio (BPM),
aplicaciones de racionalización o arquitecturas empresariales son excelentes mecanismos
para entender las dinámicas TI, descomponer los dominios de negocio, y determinar que
activos de software (¡y servicios!) pueden soportar los procesos de negocio.

El Gobierno API está fuertemente influenciado por los objetivos de negocio IT. Las
plataformas líderes en Gobierno API proporcionan analítica que permiten la evaluación de
los valor de negocio IT. La plataforma debe capturar información sobre las suscripciones en
la capa de servicio, recolectar estadísticas de uso, presentar métricas de productividad e
integrarse con sistemas de facturación y pago.

El Gobierno API engloba las suscripciones y la promoción de meta-data API. Las
actividades de gobierno en lo que se refieren a la promoción de los metadatos API incluyen
la racionalización de las etiquetas y keywords usadas para categorizar las APIs, y la gestión
de los contenidos de la documentación de desarrollo. Por otra banda los procesos de
gobiernos deben mejorar la revisión en tiempo de diseño antes de la publicación definitiva
de la API.

Las métricas de economía API incluyen la adopción de la tecnología y su uso, y es el
gobierno API el que establece cómo se realizan las políticas, las métricas y los procesos de
adopción (por versión, o por API) y el uso (por versión o por API). Entendiendo la adopción
y el uso de una API, los propietarios de negocio y los arquitectos pueden invertir de
manera más inteligente en futuros recursos de desarrollo, planificar convenientemente una
infraestructura API escalable y racionalizar el catálogo de las APIs.

Para la entrega eficiente y efectiva de soluciones IT, los equipos deben sincronizar las
actividades del Gobiernos API y del Gobierno SOA. La gestión de las API proporciona un
sencillo conjunto de estados en el ciclo de vida (por ejemplo, creado, publicado, obsoleto,
retirado, bloqueado) que pueden ser adaptados por el equipo de desarrollo.

Los registros facilitan la gestión de los metadatos del servicio y el gobierno en el diseño, la
implementación, el testeo y las operaciones en tiempo de ejecución.

Cuando desarrolladores consumen, incorporan, orquestan o componen APIs o servicios
entre organizaciones, las limitaciones, la documentación y los contratos que describen
cómo interactuar con la API o el servicio, lo que llamamos la adopción toma especial
relevancia. Los defensores de la tecnología API proponen evitar los contratos de interfaz
de servicios pesados y cambiarlos por documentación ligera y fácilmente inteligible por
las personas. Los paradigmas “RESTafari” en contra de los lenguajes descriptivos, los
esquemas y las políticas machine-readable clásicos comienzan a disminuir.

Las buenas prácticas REST, se están comenzado a ver influenciadas por el diseño y la
descripción, por lo que se construyan servicios SOA o RESTful APIs, los equipos deben de
considerar los siguientes puntos:

• No publicar endpoints que expongan modelos de dato rígidos y que requieran
  complicados patrones de interacción.
• Documentar cómo la sesión de contexto y el estado de la sesión influencia las
  interacciones.
• Documentar el modelo de mensaje.
• Describir las limitaciones de uso y las inquietudes de seguridad, es decir credenciales
  de autenticación aceptables, protocolos de autorización, etc...
• Las tácticas de ocultación los detalles internos de la interfaz exterior SOA y API
  deberían incluir frameworks de metadatos y de políticas que provean los cimientos
  requeridos para identificar, clasificar y describir los candidatos a consumir nuestros
  servicios o APIs. Las políticas se utilizan para asignar metadatos a cada caso y a los
  endpoints de los servicios desplegados. Los metadatos pueden abarcar los siguientes
  aspectos:
  • Visión general (nombre, descripción, …)
  • Atributos del ciclo de vida (versión, relaciones entre las versiones, estado en
    relación al ciclo de vida)
  • Clasificación (básico, compuesto, de infraestructura, de negocio, …)
  • Atributos del endpoint desplegado(protocolos, localización, especificaciones
    WS-*)
  • Modelo de datos (esquema JSON, RAML, esquema XML, WSDL, versión
    propiedades semánticas, validaciones)
  • Políticas y requisitos a nivel de Servicio (disponibilidad, capacidad, respuesta,
    seguridad, tasa de transacción)
  • Mediación (routing, queuing, caching, transformación, etc…)
  • Atributos de dependencia (para APIs, servicios, bases de datos, directorios,
    frameworks)
  • Instancias de dependencias físicas (por ejemplo, plataforma de la aplicación,
    seguridad, gestión)
  • Modelo de Proceso de Negocio o BPEL (Diagrama UML, clasificación de negocio,
    etc…)
  • Información del contrato (por ejemplo, consumidores, proveedores, usos)
  • Guías de uso (momento del día, disponibilidad, número de usuarios, rendimiento)
  • Opciones contables y de remuneración (pago por uso, suscripción, devoluciones,
    etc…)

Los Metadatos permiten una descripción formal de los endpoints y alientan el
descubrimiento y la reutilización por parte de otros equipos.

La mayoría de las organizaciones no comienzan con un esfuerzo completo de inventariar
los servicios o APIs, en su lugar simplifican el ámbito del proyecto. Las empresas trabajan
en describir cada candidato a servicio/API que es core de negocio para la empresa,
redefiniendo los metadatos de taxonomía, ganando de esta manera la aceptación por parte
de los equipos que ofrecen soluciones para la posible reutilización.

Conseguir un equilibrio productivo entre orientación útil y control asfixiante requiere
entender los impedimentos y la cultura propia del equipo involucrado. Las iniciativas SOA/
API se estancan principalmente por:

• Insuficiente educación, formación o mentoring.
• Falta de confianza o de colaboración entre departamentos u organizaciones.
• Incentivos o iniciativas contradictorias.
• Un pobre diseño del servicio o API.
• Falta de métricas.
• Falta de Gobierno.

Es necesaria una orientación, pero si los procesos de gobierno son molestos y caros, hará
que el resentimiento y la resistencia.

Cuando sea posible, los procesos deben ser transparentes y automáticos. Por ejemplo
las comprobaciones de conformidad pueden ser realizadas durante el alta o el registro al
servicio. Muchos sistemas de gestión de políticas proporcionan herramientas para verificar
el cumplimiento de las políticas de manera automática. Se deben buscar productos que se
integren perfectamente con las herramientas de desarrollo para que, de esta forma, sea lo
más sencillo posible para los desarrolladores la detección, la identificación y la solución de
incidencias relacionadas al cumplimiento de las políticas.

Los sistemas de gestión de contrato pueden ser muy valiosas como apoyo para la
gobernabilidad del proceso de aprovisionamiento de los consumidores, de la misma
manera que para la gestión del ciclo de vida del proceso, las peticiones de evolutivos y el
control de versiones de servicio.

Las iniciativas ya sean de mentalidad Big SOA, Small SOA, API-access o API-Centric
tienen éxito cuando se produce una adopción generalizada por todos los participantes, se
comparte, y se reúsa entre los distintos silos de proyecto, los dominios organizacionales y
las comunidades de desarrollo.

Las iniciativas de gobierno tienen éxito cuando implementan las siguientes iniciativas:

• Establecer una tabla de revisión del diseño.
• Se controlen los modelos de información, y clases.
• Se adopte un modelo de financiación compartida.
• Se implemente la monitorización del cumplimiento de las políticas (compliance).
• Crear definiciones comunes en el acuerdo de nivel de servicio.
• Crear un inventario de activos de aplicaciones y conexiones de integración.
• Implementar procesos de revisión del gobierno para gestionar cambios en el
  inventario.
• Extender el gobierno del ciclo de vida del desarrollo del software para que permita la
  orientación al servicio.

SOA puede ser una estrategia que alinee los recursos TI con las capacidades, los recursos
y los procesos de negocio. SOA se focaliza en compartir y en la reutilización que puede
optimizar el uso de los activos TI. Las iniciativas SOA se comprometen a reinventar las
interacciones B2B y permitir así, mejores relaciones con los partners y apoyo a redes de
proceso, lo que lo convierte inicialmente en desconcertante. Los servicios externos son
vistos como un mecanismo para extender el alcance económico de la empresa mediante
la reducción de costes de interacción, incorporando capacidades de trabajo externos,
permitiendo así especialización empresarial y la creación de soluciones de mayor valor que
extienden los procesos de negocio entre la red de socios empresariales.

El actual negocio de la API economy vincula la propuesta de valor de SOA, añade lecciones
aprendidas e incorpora tendencias populares en la industria, como son, REST, Internet of
everything, servicios en la nube y tecnología móvil.

Las APIs son un componente estratégico para ayudar en tu iniciativa SOA.
Superficialmente, las APIs RESTful son simplemente una versión especializada de Web
Services, y proporcionan unos beneficios técnicos similares. Ambos diseños REST API
y SOA pretenden exponer una funcionalidad clara mediante un interfaz bien definido.
Ambos modelos API y Servicios para que sean exitosos y escalables requieren endpoints
gestionados.

REST es un estilo de arquitectura de desarrollo de sistemas que imponen una serie de
restricciones en la interacción con los servicios. Todo junto, las restricciones permiten
propiedades beneficiosas para emerger, simplificar la nomenclatura, escalar, modificar,
afianzar, visibilizar, aumentar el rendimiento y la portabilidad. Los sistemas que satisfacen
estas restricciones son RESTful.

Mientras los beneficios de diseño RESTful ayudan a los objetivos SOA, el foco estratégico
del pragmatismo REST difiere en muchas de las iniciativas SOA. Los equipos que usan
diseños REST API Pragmáticos se centran en escenarios de adopción bottom-up(ver def.
3), protocolos y formatos accesibles (p.ej. HTTP, JSON, DNS), definiciones de interfaz
permisivas y simplificación de modelos de interacción (es decir, garantía de entrega y
reentrega).

Los equipos que “hacen REST” y “construyen APIs” normalmente se enfocan en superar las
barreras técnicas y en la adopción por parte de negocio mediante la creación de muchas
versiones que demuestren soluciones concretas a casos de uso del core de negocio sin
introducir complejidad tecnológica. Los equipos SOA comúnmente se centran en obtener
eficiencia en escalado, conseguir estandarizar la compañía, centralizar las decisiones y
satisfacer complejos requisitos no funcionales.

Las aproximaciones al enfoque pragmático SOA y al enfoque pragmático API se
superponen y un significado parecido. Los equipos que traten de seguir cualquiera de
los dos enfoques no fuerzan el uso de los estándares más comunes (y complicados), no
predican buenas prácticas difíciles, equilibran el gobierno de negocio con la autonomía
del proyecto y son conscientes de las deficiencias en habilidades y los obstáculos de
adopción. Una estrategia de adopción SOA efectiva require cambios fundamentales en el
diseño de la aplicación y en las técnicas de desarrollo y reducir los problemas de adopción
de las tecnologías (API o Service). El Gobierno SOA, el Gobierno API y el Gobierno de la
Aplicación pueden cruzarse y coexistir en una organización para avanzar en el objetivo de
conseguir una arquitectura racional.

Debido a que SOA representa la consecución de una arquitectura a largo plazo en la
mayoría de ocasiones entra en conflicto con tener una cartera de recursos TI de larga vida,
en resumidas cuentas SOA no ofrece soluciones rápidas, ni puede estar fundamentada
como iniciativa a corto plazo, sino que es un viaje arquitectónico con resultados futuros.
Debido a las APIs interconectan distintas capacidades empresariales hacia dentro y hacia
fuera de la organización, las API pueden proporcionar una plataforma para que los que las
estructuras comerciales patrocinen una renovación empresarial TI, así como una ejecución
desde el punto de vista de negocios pragmática.

Similar a las iniciativas Small SOA conducidas desde negocio, una aproximación a la
tecnología API con mentalidad API-access resulta en la compilación de casos de éxito,
los cuales animen futuras adopciones. Las APIs RESTful proporcionan una plataforma
tecnológica accesible para los equipos de integración TI y de negocios con el fin de
acercase a las aplicaciones móviles, aplicaciones Javascript basadas en navegadores o
scripts máquina-a-máquina (M2M).

Las organizaciones con mentalidad empresarial API-Centric llegan a más clientes y generan
mayor actividad de negocio.

Las APIs facilitan la interconexión con procesos de negocio entre una cadena de valor
extendida. Parnerts, proveedores, distribuidores, y clientes pueden acceder de manera
sencilla a una capacidad de negocio ofrecida por una API, y aumentar la interacción de
negocios a través del canal API. Las empresas con mentalidad API-Centric van más allá de
una solución de comercio electrónico como finalidad, sino que abrazan la descentralización,
la personalización, la contextualización y la gamification, así como los canales de
distribución dinámicos. Entre las tendencias tecnológicas actuales que abarcan estos
conceptos se incluyen los canales: móvil, machine-to-machine (M2M), person-to-person
(P2P), business-to-developer (B2D). En cada uno de estos casos las APIs son el pegamento
a través de los actores y los componentes de una solución distribuida.

• [1] The Only Sustainable Edge, John Hagel III & John Seely Brown, 2005
  
  https://www.johnseelybrown.com/readingTOSE.pdf
  
• [2] La economía API (The API Economy) Se puede definir como el intercambio comercial de recursos
  de información facilitado por: La exposición de la información de entidades “core” a un ecosistema
  de desarrolladores a través de una API basada en internet y por la combinación de recursos de
  información expuestos por otras entidades API para construir nuevos recursos de información.