La sorprendentemente sencilla adopción de la inteligencia artificial

Recientemente he finalizado la lectura del libro 'Microsoft Copilot: Mastering the AI Revolution in Office 365, Strategies for Innovation, Knowledge and Lifelong Learning' de Bryan J. Silva, un libro bastante limitado, la verdad (quizá por el demasiado cercano lanzamiento de Copilot), y de donde he sacado poco en limpio pero donde, sin embargo, y bastante al final, he visto algo que me ha hecho pensar y que motiva este post.

Bastante avanzado el libro, como digo, se expone brevemente la viabilidad de integrar scripts o modelos desarrollados en Python con Copilot 365. En el fondo, no es nada demasiado sorprendente. Sin embargo, me hizo pensar en lo potente que es esta integración y, yendo algo más allá, lo fácil que resulta hoy en día la adopción de la inteligencia artificial, tanto para incluirla en otro tipo de sistemas como para su uso directamente por personas.

Reflexión previa: nuestra incapacidad para sorprendernos con la tecnología

Antes, me gustaría hacer una breve reflexión previa. Y es una reflexión sobre nuestra relativa incapacidad para asombrarnos con los avances de la tecnología, en este caso con la inteligencia artificial.

Parece como que, de alguna forma, nos hubiésemos acostumbrado a que la tecnología nos aporte cosas que, no tanto antes, hubiésemos considerado 'alucinantes' o, como diría Arthur Clarke, 'indistinguibles de la magia'. En cierto modo ocurrió con Internet, ocurrió también con las redes sociales (asombrosas no tanto por su funcionalidad como por su escalabilidad), ocurrió con el smartphone y el internet móvil y creo que ahora ocurre con la inteligencia artificial en sus múltiples facetas.

No sé si esta incapacidad para el asombro es buena o mala. Entiendo que es un buen síntoma porque, si nos acostumbramos, es porque empieza a ser 'normal' que la tecnología avance a toda velocidad. Y eso es bueno. 

Pero, síntoma aparte, no estoy seguro de si es bueno de que no seamos conscientes de esos cambios y de lo transformadores, y muchas veces maravillosos que resultan.

No estoy seguro, pero no sé si esa incapacidad para el asombro nos puede restar capacidad para su adecuada gestión de todo tipo: técnica, económica, social y ética. O si, incluso, puede ser síntoma de algo que sería negativo: una cierta pasividad e incluso hastío casi existencial, que pudiera conducir, incluso, a problemas psicológicos.

Pero dejo aquí, bastante abierto la verdad, este excurso para entrar en lo que realmente era el tema de este post: la facilidad de adopción de la inteligencia artificial.

Una doble facilidad de adopción

Planteo esa facilidad de adopción con una doble cara.

Por un lado, y desde un punto de vista más técnico, lo sencillo que resulta incorporar capacidades, algoritmos y modelos de inteligencia artificial en todo tipo de sistemas y soluciones, sean estos en modo de sistema empresariales (ERP, CRM, SCM, HCM, etc), soluciones de RPA, soluciones BPMS o incluso soluciones a medida.

Por otro, la facilidad de uso por los usuarios, por las personas.

Una valiosísima y crucial herencia

Lo cierto es que, comenzando por el lado técnico, la actual facilidad de adopción de la inteligencia artificial se apoya en otro tipo de soluciones y planteamientos, ajenos y previos en general al auge actual de la inteligencia artificial y que, en el fondo, también se podrían utilizar para ayudar en la adopción de muchas otras tecnologías.

Comenzaría por algo que lleva ya muchísimos años entre nosotros, como es el planteamiento SOA ('Service Oriented Architecture') que ya hace muchos años nos mostró el camino para organizar la lógica de nuestros sistemas y soluciones en modo de componentes y, sobre todo, de servicios de negocio, unos componentes autocontenidos y de bajo acoplamiento que, además, se exponen hacia el exterior mediante una serie de servicios bien delimitados.

Acompañando y concretando la propuesta SOA, el desarrollo, generalización e implantación del concepto de API ('Application Programing Interface'), con especial relevancia hoy en día en las interfaces tipo Web Service y, sobre todo, hoy en día, REST.

Aunque no es una tecnología en sí misma, pero sí un planteamiento, destacaría también el muy extendido uso del concepto de conector que, en forma nativa, disponibiliza esas APIs para soluciones fundamentalmente basadas en filosofía 'low-code', y que simplifican enormemente el desarrollo de las integraciones.

Y como 'guinda del pastel', la expansión de la filosofía cloud computing, no sólo para alojamiento o virtualizacion de servidores, sino, sobre todo, para el ofrecimiento de servicios precisamente basados en APIs. Todo ello potenciado por la existencia de los denominados hiperescaladores (Amazon, Microsoft, Google,...) que disponibilizan, de forma tremendamente escalable y ubicua, ese tipo de servicios.

Algunas de estas tecnologías y planteamientos, para el lector que no las conozca, merecerían una explicación, pero no voy a entrar en ella para no alargarme en exceso.

Y algunas de estas tecnologías y planteamiento pueden resultar alejadas del foco mediático actual (aunque lo estuvieron en su momento), quizá incluso parecer, erróneamente, algo 'viejunas' y pasadas de moda, pero, sin embargo, son absolutamente clave y de plena actualidad, si no mediática, sí tecnológica y práctica.

La sencillez de la integración de componentes de inteligencia artificial

La multiplicación de APIs y conectores, en este caso recubriendo servicios de inteligencia artificial y con frecuencia en la nube (especialmente la nube de los hiperescaladores o grandes actores de la inteligencia artificial), y la enorme facilidad para integrar, mediante conectores o uso directo de APIS, esos componentes y servicios en otras soluciones, unida a la proliferación de herramientas 'low-code' que apenas exigen conocimientos de programación para desarrollar soluciones incluyendo integraciones, hace tremendamente simple la inclusión de capacidades de inteligencia artificial en todo tipo de soluciones y es un factor que favorece enormemente su adopción en empresas y administraciones.

La facilidad de uso de la inteligencia artificial

Pensando ya no tanto en la inclusión de capacidades en nuevas soluciones y sistemas, sino en su adopción por las personas, en el trabajo y el ámbito privado, cabe destacar el enorme avance que supone el haber conseguido interfaces conversacionales basadas en voz y lenguaje natural muy eficaces en el tratamiento de esa voz y los 'significados' del lenguaje.

Esto hace que muchas aplicaciones, tanto de inteligencia artificial como de otro tipo, resulten absolutamente naturales en su utilización. eliminando curvas de aprendizaje que traen consigo otro tipo de interfaces (comandos, ventanas, etc) y facilitando la llegada masiva, como así está siendo, de la inteligencia artificial a las personas, a los profesionales y los ciudadanos en general.

Conclusiones

De alguna manera, la inteligencia artificial actual es heredera de los buenos planteamientos que se han venido haciendo desde hace años e incluso décadas en el ámbito de las tecnologías de la información e interfaces de usuario. Y la confluencia de los avances específicos en inteligencia artificial con esos planteamientos, no brinda una sorprendente facilidad de uso e integración de la inteligencia artificial, al menos desde el punto de vista técnico y operativo, y esto debería garantizar una masiva y exitosa adopción de la inteligencia artificial.

En parte lo estamos viendo, pero, en realidad, todavía nos queda, creo, mucho por ver.

Modelos de software en la nube y el impacto en sistemas cognitivos

A estas alturas, creo que es indudable el gran impacto, la gran transformación que a nivel de TI y de todo el mundo digital, ha tenido la nube, el cloud computing.

La evolución del cloud computing

Debo confesar que, cuando hace ya bastantes años oí hablar de este concepto por primera vez, no creí que llegara a ser tan revolucionario...pero sí que lo ha sido y lo va a seguir siendo.

En sus  primeras implementaciones prácticas, el cloud computing puso más énfasis, como heredero de los llamados hosting y housing, en todo lo relativo al hardware y la infraestructura, lo que posteriormente se ha reconvertido en los así llamados IaaS (Infrastructure as a Service) y PaaS (Platform as a Service).

Pero con todo y lo importante que desde un punto de vista de negocio y de operación TI es la externalización de la infraestructura y su paso del modelo de propiedad al de uso, creo que la transformación más profunda y su carácter impulsor de la transformación digital global viene dada por la prestación de capacidades de software desde la nube, una prestación que inicialmente se centraba en el modelo SaaS (Software as a Service), que viene a ser, por decirlo coloquialmente, como el alquiler de una aplicación completa pero que se extiende y completa posteriormente con la visión más orientada a servicios, derivada de la filosofía SOA (Service Oriented Architecture) y que con ingredientes adicionales ha dado lugar a las APIs web (típicamente REST), a los contenedores, a los microservicios y al concepto de Función como Servicio (FaaS, Functions as a Service), generando una panoplia de opciones caracterizadas todas ellas por su prestación desde la nube y en modo pago por uso y unas opciones que cada vez se orienta menos a la aplicación y más al servicio, la función y las APIs.

Modelos de software en la nube

Aunque no es el objetivo principal del libro, me ha gustado mucho, por lo compacto y clarificador, el esquema que al respecto de todas las opciones existentes, plantea Jaume Miralles en 'Proyectos de Inteligencia Artificial' y que, a su vez, se basa en el articulo '¿Qué modelo Cloud es el mejor para los desarrolladores?' escrito por Ana López Mancisidor y José Miguel Ordax en un blog de IBM.

El modelo es el que se muestra en la figura:

En ese modelo se observan 9 niveles de capacidades hardware y software que, de abajo a arriba son:

• Networking
• Almacenamiento
• Servidores
• Virtualización
• Sistema operativo
• Middleware
• Configuración del middleware
• Datos
• Aplicaciones

En esos niveles, se puede ver que los tres primeros (Networking, Almacenamiento y Servidores) se concentran más en los aspectos hardware; los siguientes se concentran el el software de plataforma (Virtualización, Sistema Operativo, Middleware y configuración del middleware) y los dos dos últimos (Datos y Aplicaciones) en las aplicaciones finales.

A su vez, el esquema muestra mediante un código de colores en quién recae la responsabilidad de cada uno de esos bloques (azul oscuro es el modelo tradicional, con responsabilidad por parte del cliente o usuario, y azul claro responsabilidad por parte de un proveedor de servicio).

Y con esas bases, los autores encajan seis modelos, que, en orden creciente de externalización y servitización (que no de orden cronológico de aparición en el mercado) son:

• Tradicional ('on premises'): el cliente usuario mantiene la propiedad y responsabilidad de todos los elementos y en sus propias instalaciones.


• IaaS (Infrastructure as a Service): El proveedor de servicio proporciona ya lo relativo al hardware (Networking, Almacenamiento y Servidores) y algo de virtualización.


• CaaS (Containers as a Service): Se introduce el concepto de contenedor y el proveedor del servicio se hace cargo ya del sistema operativo y el middleware.


• PaaS (Plataform as a Service): El proveedor de servicio se hace ya cargo de todo el software de plataforma, añadiendo al caso anterior la configuración del middleware.


• FaaS (Functions as a Service): En realidad no añade externalización ni servitización de ninguna capa, pero sí es cierto que la capa de aplicación y datos cambia y se convierte, de hecho, en lo que los autores denominan 'acciones y disparadores' puesto que, en el caso de FaaS, no existe una aplicación como tal, sino una serie de funciones autocontenidas.


• SaaS (Software as a Service): Supone la externalización y servitización completas donde toda la aplicación y los elementos inferiores necesarios es proporcionada por el proveedor de servicios.

En este esquema se indica que los modelos más a la izquierda proporcionan un mayor rendimiento y control por parte del cliente / usuario, mientras que los de la derecha tienen a proporcionar velocidades crecientes de desarrollo.

El impacto en sistemas cognitivos

¿Y por qué Jaume Miralles se detiene a hablar sobre cloud computing y los modelos de prestación de las capacidades software cuando su libro trata de inteligencia artificial y de proyectos de inteligencia artificial?

Pues porque el impacto de estos modelos en la nube es enorme en el caso de la implantación y popularización de la inteligencia artificial. Porque, como el autor también explica en su libro, con cierta frecuencia (aunque no siempre), cuando una empresa se plantea realizar un proyecto de inteligencia artificial no desarrolla las capacidades cognitivas por sí mismo sino que se apoya en capacidades ya existentes y disponibles normalmente en la nube bajo alguno de los esquemas mencionados o alguno similar, muy especialmente los esquemas en que el software no se ofrece como aplicación sino como servicios y APIs (como sucede, por ejemplo, en CaaS y FaaS). Esto es especialmente notorio cuando hablamos de capacidades tecnológicamente complejas y que precisan muchísimos datos de entrenamiento como pueden ser las relativas a procesamiento de lenguaje natural.

Cuando se buscan los motivos del éxito actual de la inteligencia artificial se apuntan a aspectos como el aumento de la capacidad de computación (y el uso de las GPUs), la aparición de nuevos algoritmos (sobre todo de deep learning) y la gran disponibilidad de datos. Todo ello es cierto, pero creo que no cabe menospreciar sino, bien al contrario, resaltar, la contribución que estos modelos de prestación de servicios cognitivos desde la nube están teniendo en la democratización de la Inteligencia Artificial poniendo capacidades muy avanzadas casi al alcance de cualquiera.

Cuatro razones para usar Screen Scraping en lugar de un API

Uno de los  mecanismos más característicos que incluyen todas o la mayor parte de las soluciones de Automatización Robótica de Procesos para interaccionar con aplicaciones existentes, ya sean éstas aplicaciones corporativas o aplicaciones de terceros, típicamente en la web, es el Screen Scraping, es decir, la obtención de datos a partir de las propias pantallas de las aplicaciones con las que se necesita interactuar.

Es éste un mecanismo en cierto sentido atípico en la disciplina de integración de sistemas. Estamos acostumbrados a la integración de aplicaciones a partir de API ('Application Programmatic Interface') ofrecidos como servicios. Y desde hace años se propone SOA ('Service Oriented Architecture') como la mejor forma de estructurar la integración entre sistemas. Y SOA, propone, precisamente, la creación de esos servicios y esas APIs.

¿Entonces? ¿Por qué usar Screen Scraping? ¿No es ese mecanismo una suerte de rodeo a las buenas prácticas de arquitecturas¿ ¿No es casi, casi, una 'chapucita'?

Bueno, si y no.

Hay que dejarlo claro: desde un punto de vista de arquitectura de sistemas es claramente preferible, muy preferible, la integración a través de APIs y, si es posible, con arquitectura SOA. Sin embargo, a nivel práctico, cuando añadimos consideraciones de naturaleza temporal, presupuestaria y otras, hay ocasiones en que puede tener sentido, lo tiene de hecho, usar un método más relajado como es screen scraping, una de cuyas virtudes, probablemente la principal, y que traslada como propuesta de valor a RPA, es que no necesita modificar en absoluto la aplicación con que se integra, no pide ningún desarrollo concreto... ni siquiera la existencia de un API.

He iniciado la lectura del libro 'Web Scraping with Python' de Ryan Mitchell y en él, tras reconocer que las APIs son el mecanismo preferente de integración, la autora aporta cuatro razones, o cuatro situaciones en que se justifica utilizar Screen Scraping (en su caso,Web Scraping, es decir, la variante del Screen Scraping que se centra en pantallas Web). Son estas:

• Cuando lo que se quiere es recopilar conjuntos finitos de datos de una larga serie de aplicaciones web sin que exista un API coherente en todas ellas.


• Cuando los datos que se quieren recoger son de poco volumen y no muy habituales, por lo que las aplicaciones no disponen de un API para ello (y, añado yo, no vale la pena desarrollarla)


• La fuente ni dispone, por alguna razón, de la infraestructura o capacidad técnica (o, añado yo, temporal o presupuestaria) para desarrollar un API.


• Los datos a los que queremos acceder son valiosos o están protegidos y no se prevé distribuirlos de forma amplia.

Creo que, quizá, se podría añadir alguna situación más, pero la idea básica es bastante clara: en general es preferible usar APIs, pero Screen Scraping puede ser una alternativa razonable cuando, por un lado, no existe ese API y, por otro, no vale la pena desarrollarlo.

Actualizándonos en SOA con Thomas Erl.

En 'Service Oriented Architecture: analysis and design for services and microservices' Thomas Erl realiza un repaso actualizado de su trabajo sobre orientación a servicios llevado a cabo en los últimos años y recogido en numerosos libros. Se trata de un libro que más que de la tecnología en sí, trata del análisis y diseño de servicios y soluciones orientadas a servicios y, en ese sentido, resulta con frecuencia algo abstracto y un poco alejado del software real.

El libro se estructura en diez capítulos y cuatro apéndices, agrupados en tres partes:

• 'Introduction:' que simplemente presenta el libro pero sin entrar en materia.


• 'Case Study Backgrounds:' cuanta los casos de estudio que se utilizarán a lo largo de todo el libro a modo de ilustración y ejemplo.


• 'PART I FUNDAMENTALS:'


• 'Understanding Service Orientation:' explica lo que son los servicios y la orientación a servivicios como paradigma, presenta los principios de la orientación a servicios e identifica los problemas que se resuelven con la orientación a servicios.


• 'Understanding SOA:' continúa con los conceptos básicos y en este caso explica lo que son las arquitecturas orientadas a servicios, las características que presentan y una tipología con los cuatro tipos más comunes de SOA presentados como cuatro capas: arquitectura de servicios, composición de servicios, inventario de servicios y empresa orientada a servicios. A continuación revisa los objetivos estratégicos y beneficios esperados y presenta un ciclo de vida y metodología para proyectos SOA.


• 'Understanding layers with services and microservices:' propone una estructuración de los servicios empresariales en cuatro capas: servicios de utilidad, servicios de entidad, microservicios y servicios de tarea y cuenta cómo llegar a esa estructuración.


• 'PART II SERVICE ORIENTED ANALYSIS AND DESIGN:'


• 'Analysis and modeling with web services and microservices:' presenta un proceso para el modelado de servicios web que detalla paso a paso basándose en los casos de estudio propuestos en el segundo capítulo.


• 'Analysis and modeling with REST services and microservices:' muy similar al anterior pero en este caso orientado a servicios REST y microservicios.


• 'Service API and contract design with web services:' entra en un nivel mayor de detalle exponiendo cómo diseñar los servicios, incluyendo incluso aspectos como el nombrado, las operaciones, los documentos WSDL, etc


• 'Service API and contract design with REST services and microservices:' de nuevo, muy parecido al anterior pero en este caso orientado a servicios REST y microservicios


• 'Service API and contract versioning with web services ans REST services:' aborda la problemática del versionado y la compatibilidad tanto hacia adelante como hacia atrás.


• 'PART III APENDICES:'


• 'Service-orientation principles reference:' censa los principios SOA que se han tocado a lo largo de todo el libro
.
• 'REST constraints reference:' es un censo de las diferentes restricciones en servicios REST abordadas en el libro, con una tabla perfil por cada una de ellas.


• 'SOA design patterns reference:' censo de los patrones de diseño SOA mencionados en el libro proporcionando una tabla descritpiva por cada uno de ellos.


• 'The annotated SOA manifesto:' versión comentada del manifiesto SOA.

A lo largo de todo el libro se nota que el autor pone énfasis en explicar los conceptos de una forma por un lado sencilla (con abundancia de ilustraciones y esquemas) pero también rigurosa y ordenada. A pesar de ello, en mi opinión, no consigue del todo comunicar con claridad las ideas, quizá por ese alto nivel de abstracción que, de todas formas, es preciso reconocer que el autor intenta paliar, con éxito solo parcial, mediante ejemplos y casos de uso. Por ejemplo, una de las ideas 'estrella' de este nuevo libro, los microservicios, apenas se entiende en qué consisten realmente. Por otro lado, es un libro que se hace algo largo y las explicaciones se hacen a veces inacabables. Es preciso de todas formas, reconocerle un tratamiento amplio, muy ordenado y sistematizado del campo de la orientación a servicios. Además, se trata de las pocas fuentes bibliográficas actualizadas disponibles hoy en día y esas tres cosas, amplitud, orden y actualidad son méritos a reconocerle.

Thomas Erl

(Fuente: Traducción y ligera elaboración propia de la página personal del autor)

Thomas Erl

Canadiense nacido en 1967, Thomas Erl es un escritor de éxito sobre IT y fundador de Arcitura Inc. Thomas ha sido el autor sobre tecnología de servicios más vendido durante más de siete años y es el editor de la Prentice Hall Service Technology Series (www.servicetechbooks.com), así como editor de la Service Technology Magazine (www.servicetechmag.com). Con más de 200.000 ejemplares vendidos, sun nueve libros publicados se han convertido en bestseller internacionales y han sido formalmente respaldados por miembros senior de las mayores compañías de IT como IBM, Microsoft, Oracle, Intel, Accenture, IEEE, HL7, MITRE, SAP, CISCO, HP y otras.

Cuatro de sus libros, 'Cloud Computing: Concepts, Technology & Architecture', 'SOA Design Patterns', 'SOA Principles of Service Design' y 'SOA Governance' fueron escritos en colaboración con la comunidad IT y han contribuido a la definición de los mecanismos tecnológicos del cloud computing el modelo arquitectural de la orientación a servicios y de la propia orientación a servicios como un paradigma con entidad propia. Thomas actualmente trabaja con más de veinte diferentes autores en varios libros dedicados a materias especializadas como cloud computing, Big Data, tecnologías de servicios modernas y orientación a servicios.

Como CEO de Arcitura Education Inc, en en colaboración con SOA School, Cloud School y Big Data Science School Thomas ha dirigido el desarrollo del plan de estudios para los internacionalmente reconocidos programas de acreditación SOA Certified Professional (SOACP), Cloud Certified Professional (CCP) y Big Data Science Certified Professional (BDSCP).

Thomas es miembro fundador del SOA Manifesto Working Group y autor del Annotated SOA Manifesto (www.soa-manifesto.com). Es miembro del Cloud Education & Credential Committee, SOA Education Committee, y además supervisa las iniciativas SOAPatterns.org, CloudPatterns.org y BigDataPatterns.org, dedicadas al desarrollo de catálogos de patrones maestros para arquitectura orientada a servicios, cloud computing y Big Data.

Thomas ha viajado a lo largo de más de veinte paises como conferenciante e instructor para eventos privados y públicos y participa regularmente en conferencias internacionales. Ha publicado más de 100 artículos y entrevistas en numerosos medios, incluyendo The Wall Street Journal y CIO Magazine

Puedes saber más del autor visitando su perfil en LinkedIn.

Ficha técnica:

TITULO: Service-Oriented Architecture: Analysis and Design for Services and Microservices

AUTOR: Thomas Erl.

EDITORIAL: Prentice Hall

AÑO: 2016

ISBN: 978-0-13-385858-7
PAGINAS: 416

Artículos de este blog relacionados

• Capas de servicios SOA
• Objetivos y beneficios de SOA

Preparando SOA y BPM para el cambio con Marc Fiamante

'Dynamic SOA and BPM' es un libro de carácter netamente técnico, que explora conjuntamente los campos del BPM (Business Process Management) y SOA (Service Oriented Architecture) pero no de una forma general sino, muy expecíficamente, analizando las mejores prácticas para que ambas técnicas/tecnologías sean capaces de adaptarse con agilidad al dinamismo que se produce en la vida y negocios reales.

Se trata. además, de un libro bastante avanzado que da por sentados importantes conocimientos del lector en estos campos y no se detiene mucho en explicaciones previas sino que ataca directamente la temática que se propone. En ese sentido, no resulta un libro demasiado fácil de leer ni de entender salvo para personas expertas o al menos buenas conocedoras de estas materias.

El libro se estructura en ocho capítulos:

• 'From simplified integration to dynamic processes': Comienza analizando errores comunes en la aplicación de BPM y SOA que limitan su valor. Luego propone una arquitectura empresarial con tres capas paralelas (infraestructura, aplicaciones y negocio) y otra transversal (información) y comenta su 'mapping' a algunos modelos de referencia como eTOM, PCF o SCOR y termina aportando unos principios para conseguir el dinamismo.


• 'Streamlining the enterprise architecture for dynamic BPM and SOA': Un capítulo complejo en que realiza varios planteamientos a nivel de arquitectura empresarial para prepararla para la variabilidad.


• 'Implementing dynamic enterprise information': explora técnicas que flexibilizan el tratamiento de información a diferentes niveles de detalle, desde algunos más arquitecturales, a otros en el nivel de diseño e incluso otros muy cercanos ya a la implementación de datos.


• 'Implementing variable services': enfoca ahora la variabilidad desde el punto de vista de los servicios de negocio SOA, analizando temas como patrones de diseño, los contratos de servicios en WDSL, las arquitecturas de componentes o los servicios REST.


• 'Implementing dynamic business processes': Se centra ahora en el nivel de procesos de negocio tratando técnicas de un modelado para la variabilidad, aspectos relacionados con reglas de negocio o eventos.


• 'Implementing the enterprise expansion joint': Habla de los aspectos más relacionados con el nivel de infraestructura como el Enterprise Service Bus y técnicas relacionadas con la mediación entre servicios.


• 'Tooling for dynamic SOA and BPM processes': Cambia ahora un poco la orientación analizando el tipo y casos concretos de herramientas que se pueden utilizar en las tareas vistas hasta el momento, incluyendo la gestión del ciclo de vida de la arquitectura empresarial y el modelado e implementación de sus diferentes capas como procesos, servicios e información.


• 'Managing and monitoring a dynamic BPM and SOA environment': Finaliza hablando de aspectos más de gestión, incluyendo la monitorización, la gestión del ciclo de vida de procesos y servicios y la gestión operativa

Un libro, en fin, interesante pero de un nivel avanzado y que precisa de una lectura muy cuidadosa y experta para sacarle todo el beneficio.

Marc Fiamante

(Fuente: Traducción y ligera elaboración propia de la ficha de autor en InformIT)

Marc Fiamante

Marc Fiammante es un Ingeniero Distinguido de IBM, elegido para la IBM Academy of Technology en 2003, con amplia experiencia en la arquitectura de grandes proyectos y en desarrollo de software en múltiples entornos. Es arquitecto jefe del equipo de Enterprise Integration Solutions en Europa, Medio Oeste, África y Asia-Pacífico. Marc tiene más de veinte años de experiencia en TI. Ha registrado varias patentes en el dominio del software y ha publicado varios artículos en relación con tecnología e-business. Dirige equipos de arquitectura en grandes proyectos industriales. Tiene 'expertise' técnico y arquitectural con la arquitectura orientada a servicios, web services, Enterprise Application Integration y tecnologías orientadas a objetos y e-business, incluyendo variedad de sistemas de middleware, lenguajes de programación y estándares.

Marc es titulado por la Ecole Centrale de Paris.

Puedes saber más del autor visitando su perfil en LinkedIn.

Ficha técnica:

TITULO: Dynamic SOA and BPM

AUTOR: Marc Fiamante.

EDITORIAL: IBM Press Books

AÑO: 2009

ISBN: 978-0137018918
PAGINAS: 216

Artículos de este blog relacionados

• Cuatro dominios para una arquitectura empresarial
• Recordando las funciones de un Enterprise Service Bus
• Esa 'cosa' llamada reglas de negocio

Capas de servicios SOA

La filosofía SOA tiene todo que ver con el orden y la estructura, con la articulación inteligente y práctica de los componentes software con que se teje el entramado de los sistemas corporativos. En ese afán por poner orden, también tiene cabida la estructuración de la propia naturaleza de los servicios. Y una forma de poner orden es estructurar en Capas de servicios SOA, el conjunto de esos servicios, conforme a su diferente naturaleza.

En su libro 'Service-Oriented Architecture: Analysis and Design for Services and Microservices' Thomas Erl propone una estructura de cuatro capas de servicios SOA.

Antes de pasar a verlas conviene comentar la clasificación que menciona el autor en cuanto a servicios agnósticos y no agnósticos, basándose la diferenciación en si el servicio tiene 'conocimiento' y dependencia de su contexto y muy en concreto de la tarea en que se enmarca la funcionalidad del servicio, o es ajeno a él. En el segundo caso hablaríamos de servicio agnóstico y tienen como beneficio el hecho de ser más ampliamente reutilizables. Si existe ese 'conocimiento' y dependencia nos encontraríamos ante un servicio no agnóstico.

Según eso, y siguiendo una dirección de abajo a arriba, el autor distingue estas cuatro capas:

Capas propuestas por Thomas Erl antes de la llegada de los microservicios

• Servicios de tarea: Un servicio no agnóstico y que en general se corresponde con una actividad o tarea de un proceso de negocio.


• Microservicios: una capa que no se encontraba en el primer planteamiento de Erl (por eso no aparece en la figura superior) y que consiste en un servicio no agnóstico con un alcance funcional reducido. No suelen ser reutilizables de forma general, pero sí dentro de la aplicación en que se enmarcan.


• Servicios de entidad: Un servicio agnóstico y que se relaciona con una o más entidades de negocio (por ejemplo, Cliente, Factura o Contrato). Tienen un contexto agnóstico. Por ejemplo, un servicio 'Orden de compra' tendría como contexto el procesamiento de cada orden de compra específica.


• Servicios de utilidad: Un tipo de servicio agnóstico y reutilizable y que ofrece una funcionalidad puntual que no deriva de unas especificaciones de proceso. Suele encapsular funciones técnicas de bajo nivel como, por ejemplo, temas de seguridad o trazado (logs).

Existen otros planteamientos de tipos o capas de servicios no totalmente coincidentes con las propuestas por Erl, aunque sí bastante próximas en sus ideas.

Al final, se trata de poner orden en un conjunto amplio de servicios y diseñar de forma que se respeten algunos de los principios y objetivos de SOA como son la alta cohesión interna y bajo acoplamiento externo de los servicios y la 'reutilizabilidad' de los mismos en el contexto más amplio posible.

Objetivos y beneficios de SOA

Aunque el tirón mediático de SOA (Service Oriented Architecture) ya hace tiempo que pasó, lo cierto es que los beneficios de SOA siguen muy vigentes y es, por tanto, un planteamiento que a nivel de arquitectura y diseño de sistemas es plenamente actual.

Cualquier organización con un mapa de sistemas suficientemente complejo debería tenerlo como un elemento rector de su arquitectura.

Incluso hoy en día con la cada vez mayor prevalencia de las soluciones cloud (PaasS y SaaS, en especial) adquiere quizá mayor sentido. Y eso tanto como arquitectura interna a usar por proveedores de cloud como en la forma de relacionarse las empresas con el software que le proporcionan esos mismos proveedores cloud.

Sabemos que la arquitectura SOA promueve la estructuración del software en forma de servicios reutilizables y con contratos bien definidos. Recoge así los tradicionales principios de la alta cohesión interna y bajo acoplamiento externo tan propios de la ingeniería software, pero llevados ahora, si cabe, a un mayor protagonismo. Aunque esa filosofía se puede implementar a nivel técnico de muchas formas, lo cierto es que lo que predomina hoy día son unos servicios que se exponen como web services ya sea con arreglo a los estándares SOAP (Simple Object Access Protocol) o REST (REpresentational State Transfer).

Pero ¿cuáles son esos beneficios que ofrece SOA y que la convierte en una arquitectura tan interesante?

En su libro 'Service-Oriented Architecture: Analysis and Design for Services and Microservices', Thomas Erl, concentra en siete los puntos a tener en cuenta, cuatro objetivos estratégicos y tres beneficios que se derivan

Los objetivos estratégicos de SOA

• Incremento intrínseco de interoperabilidad: En ese sentido cabe recordar que SOA persigue una interoperabilidad nativa de servicios sin necesidad de trabajos adicionales de integración. En esa dirección colaboran aspectos como la estandarización de los contratos de servicio, la predecibilidad del comportamiento, la escalabilidad y la fiabilidad.


• Incremento de la federación: recordando que por federación se entiende el que recursos y aplicaciones colaboren y se encuentren de alguna forma unidos pero manteniendo su autonomía y auto-gobierno.


• Incremento de las posibilidades de diversificación de proveedores: ya que al basarse en estándares y promover la interoperabilidad se eliminan dependencias innecesarias de los proveedores del software.


• Incremento del alineamiento entre negocio y tecnología: ya que SOA promueve un primer nivel de abstracción precisamente en el nivel negocio de forma que sus conceptos son naturales para ese negocio.

Los beneficios de SOA que se derivan

• Incremento de ROI: ya que las soluciones SOA son más sencillas tanto de mantener como de evolucionar que las soluciones más a medida.


• Incremento de la agilidad organizativa: es decir, la capacidad de las organizaciones de responder al cambio. Factores anteriores como el alineamiento con el negocio,o la reutilización facilitan mucho el evolucionar el software y por tanto responder con esa agilidad.


• Reducción de la carga para TI: ya que las aplicaciones son más sencillas de evolucionar, la complejidad total es menor y el gobierno también resulta más sencillo.

Ni que decir tiene que las implementaciones reales en grandes empresas son complejas y que ni SOA, ni ninguna otra arquitectura alternativa van a traer 'el mundo feliz' ni a la organización de TI ni al negocio. Pero aún así, desde luego SOA es un paso decisivo en la buena dirección y los beneficios de una arquitectura SOA bien diseñada y aplicada son innegables..

Cuatro dominios para una arquitectura empresarial

El concepto de arquitectura empresarial, algo borroso y no del todo extendido, nos lleva a un modelo  estructurado de los principales elementos de gestión de una empresa desde una perspectiva de negocio pero con mucha orientación hacia sus sistemas de información. Entre los dominios para una arquitectura empresarial que podemos encontrar en la literatura se encuentran aspectos como los procesos, los sistemas, la información, la organización, etc.

En su libro, 'Dynamic SOA and BPM', el arquitecto de IBM, Marc Fiammante nos habla de cuatro dominios para una arquitectura empresarial, cuatro dominios que, además, y a modo de regla nemotécnica de naturaleza gráfica, estructura en unas capas que conforman la letra 'E' de 'Enterprise architecture'.

Los cuatro dominios que se identifican son:

• Negocio
• Aplicaciones
• Infraestructura
• Información

y se ilustran en la siguiente figura procedente del libro:

Aunque Fiammante no realiza una definición detallada, sí podemos entrever los elementos de cada nivel.

Dominio de negocio

En este dominio, hablamos del negocio con independencia de la base técnica con que se pueda operar. Elementos que se encuentran en este nivel son la organización y la asignación de responsabilidades.

Pero también, y aunque no se menciona explícitamente, los procesos de negocio. De hecho, el gráfico se ilustra con el mapa de procesos PCF (Process Classification Framework) cross-sectorial de la APQC (American Productivity and Quality Center) y en su disertación Marc Fiammante nos habla también de otros modelos de procesos como eTOM (enhanced Telecom Operations Map), propio del mundo de las telecomunicaciones o SCOR (Supply Chain Operation Reference model) para cadenas de suministro.

Dominio de aplicaciones

En este dominio se sitúa por un lado, el censo de servicios de negocio (no olvidemos que el libro habla de SOA) y el mapa de sistemas o aplicaciones de la empresa y donde se mapean esos servicios de negocio.

Como ejemplo de un modelo de aplicaciones estandarizado, el autor nos refiere a TAM (Telecom Application Map) que acompaña a eTOM pero ahora con perspectiva de aplicaciones y no procesos de negocio.

Dominio de infraestructura

Este es el dominio más técnico donde se recogen elementos como el repositorio de servicios, el Enterprise Service Bus, los servicios de infraestructrura, etc. Se trata de un dominio donde apenas existen resultados de estandarización.

Dominio de información

En la figura se delinea como transversal a las otras capas. En este caso se trata estructurar la información que se maneja en la empresa, agrupándola en dominios de información, entidades y datos concretos.

El modelo de referencia más conocido en ese sentido es SID (Shared Information Data) que, junto con eTOM a nivel de procesos y TAM en lo relativo a aplicaciones, conforman una arquitectura casi completa para el sector de las telecomunicaciones.

***

El modelo de arquitectura empresarial que propone Fiamante identifica, creo que con bastante acierto cuatro capas relevantes de la arquitectura empresarial aunque, bien es cierto que la capa de infraestructura queda algo desdibujada al no existir ningún tipo de estándar, normativa o buena práctica que se apunte y en el nivel de negocio quizá convendría una explicitación más clara de dos aspectos: la organización y los procesos.

No es, de todas formas, el concepto de arquitectura empresarial un tema sencillo por lo que cualquier modelo que proporcione una visión más o menos estructurada y comprensible, como es el caso, es de agradecer.

Recordando las funciones de un Enterprise Service Bus

Parece que nos hubiéramos olvidado de SOA (Service Oriented Architecture) y de todo lo que supuso... y supone aún. Pero no nos debemos olvidar porque las necesidades de integración de sistemas y de arquitecturas que permitan estructurar el armazón funcional y de información siguen vivas, muy vivas. Un elemento arquitectónico muy importante a que dio lugar el desarrollo de SOA es el Enterprise Service Bus, una pieza de software, un middleware como se le dio en llamar, que se constituía en una especie de conector universal.

Definiciones académicas aparte, el Enterprise Service Bus es un software cuya misión, en esencia, es interconectar sistemas. No proporciona por sí mismo una funcionalidad para el usuario final, sino que hace más fáciles y racionales los intercambios de información y servicios entre diferentes sistemas para proporcionar funcionalidades más amplias o para, por ejemplo, implementar extremo a extremo un proceso de negocio.

El Enterprise Service Bus ofrece mecanismos tecnológicos (Web Services, colas de mensajes, conectores a aplicaciones populares, etc) para implementar servicios de interconexión pero, además, suele ofrecer funcionalidades adicionales como la traducción de datos o adaptación de formatos, la persistencia y transacionalidad de las interacciones o la implementación de pequeños workflows.

En su libro 'Dynamic SOA and BPM', Marc Fiammante agrupa en cuatro las responsabilidades de un Enterprise Service Bus:

• Enrutado de mensajes: Cuando utilizamos un ESB la aplicación que necesita un servicio de otra, no llama directamente a esa otra aplicación sino que lo hace a través del bus y es el bus quien sabe cómo hacer llegar esa invocación a la aplicación destino. Esto constituye un primer nivel de desacoplamiento o independización entre ambas aplicaciones


• Conversión de protocolos de transporte: Es decir, cada aplicación o servicio puede utilizar el protocolo que más le convenga y es el bus el que sabe utilizar en cada interacción el protocolo adecuado y realizar las conversiones oportunas cuando protocolo de peticionario y servidor no son iguales.


• Transformación de formatos de mensajes: El bus realiza, si es necesario, traducciones de formatos de argumentos y contenidos de mensajes con lo que, de nuevo, independiza a las aplicaciones que no tiene por qué usar los mismos formatos.


• Tratamiento de eventos de negocio dispares: con lo que, el mismo servicio ofrecido por una aplicación, puede ser invocado en diferentes contextos de negocio.

Como se puede ver, el Enterprise Service Bus viene a ser, dicho de forma muy sencilla, un facilitador de las interacciones entre aplicaciones, desacoplando sus lógicas, interfaces y liberando a éstas de la esclavitud e ineficiencia que suponen los acuerdos bilaterales de protocolos y formatos de mensajes en las interfaces tradicionales.

Se trata, pues, de una pieza de software injustamente olvidada, puesto que juega un papel esencial en la arquitectura de cualquier empresa con un mapa de sistemas complejo.

Espagueti de sistemas. Receta para la construcción y la deconstrucción

Espagueti de sistemas... No sé si suena apetitoso... pero en realidad no lo es, no lo es en absoluto. Es la pesadilla (y por desgracia, con frecuencia la realidad) de los departamentos de sistemas de las grandes corporaciones.

Una maraña inmensa de sistemas construidos con diferentes tecnologías, diferentes modelos de información, diferentes tecnologías de integración, diferentes semánticas de datos...pero interconectados entre sí, influyéndose entre sí, solapándose entre sí, limitándose entre sí.. y complicando la vida, a veces hasta extremos insospechados e insoportables, del departamento de sistemas y de los departamentos de negocio a que estos dan soporte.

Es una pesadilla...pero es real, muy real...

Leyendo 'Leading digital' de George Westerman, Didier Bonet y Andrew McAfee encuentro razonamientos y situaciones que me resultan tan familiares que no sé si consolarme con aquello del mal de muchos...

Así se describe en 'Leading digital' el espagueti:

why do so many large companies have poorly designed technology platforms?. Large companies operate in silos each with its own systems, data definitions and business processes. The systems are confusing, sometimes duplicative, and often tied together in complex (and sometimes unknown) ways. Generating a common view of customers or products can be very difficult.

¿Cómo se llega a estos espaguetis de sistemas? ¿Cuál es la desgraciada receta?

En general se produce en organizaciones grandes y con historia más o menos larga. En esa situación, los sistemas surgen (o surgieron en el pasado) para ir dando respuesta a necesidades puntuales de diferentes departamentos. Mientras los sistemas todavía eran una pieza relativamente secundaria, mientras existían pocos sistemas, mientras estos no eran críticos para el negocio, y mientras sólo existían islas de informatización no solapadas, esta situación, sin ser óptima, no era especialmente problemática.

Pero con esa dinámica, el número de sistemas crece. Poco a poco, además, se hacen más críticos para el negocio. Poco a poco toda la actividad  de la empresa se encuentra informatizada... Así que los sistemas ya son muchos, heterogéneos, solapados e interconectados. Es decir: primera aparición del espagueti en el menú... 

Todavía, empero, podría haber sido la situación en ese punto reconducible con un esfuerzo razonable de racionalización y ordenación de demandas. Pero entonces surgen las presiones del negocio, del 'time-to-market', de los resultados, y... la ortodoxia de la arquitectura y mapa de sistemas se rompe irremediablemente...

De nuevo, en 'Leading digital':

Every request for a nonstandard technology, every demand to do things your own way, every choice to go around corporate governance processes so you can move faster, and every integration meeting that your staff people miss will create more complexity. Sometimes that complexity is neccessary, but often it is not.

Como consecuencia de esa presiones de tiempo y de la falta de una adecuada racionalización arquitectural se adoptan presuntas soluciones, construyendo nuevos sistemas encima de los anteriores o de capas que presuntamente ocultan la complejidad de los anteriores...pero sin eliminar ningún sistema ni revisar el mapa de sistemas en su conjunto.

We don't retire systmes. We just add on top of them, which creates a tremendous amount of expense and complexity.

Más sistemas, más intereracciones, más complejidad...El espagueti en todo su esplendor...

¿Y qué hacemos ahora?

Pues ahora tenemos un gran problema y no queda otra que un profundo programa de transformación, de revisión, reordenación, reducción y simplificación del mapa de sistemas.

El trabajo es titánico...pero inevitable. La propia supervivencia de la empresa a medio plazo puede estar en juego si no se acomete.

El trabajo es ciertamente inmenso, pero hay tres ingredientes que nos pueden ayudar en esta deconstrucción, en esta transformación de sistemas.

En primer lugar, la arquitectura empresarial, una herramienta que nos permite ordenar los procesos, la información y las tecnologías con visión global de compañía. En esta arquitectura debe encajarse de manera limpia cualquier solución de futuro.

En segundo lugar, SOA, como tecnología de integración que permite ordenar los servicios de negocio y la información que intercambian esos servicios...servicios e información que, además, deben encajar perfectamente en la arquitectura empresarial.

Y la tercera, liderazgo, mucho liderazgo. Liderazgo intelectual para saber poner orden en el caos y mantener el rigor en la aplicación de la arquitectura empresarial y SOA. Y liderazgo transformador, para construir la visión, comunicarla y movilizar a la organización en pos de su consecución. En cierto modo, la falta de este liderazgo ha permitido en el pasado llegar al espagueti, y ahora ese liderazgo perdido se debe recuperar... 

Spaghetti happens only because leaders let it happen. And removing spaghetti requires strong leadership.

No, el espagueti de sistemas no es apetecible en absoluto. 

Una deconstrucción de sistemas, con guarnición de nuevo mapa de sistemas, cocinada conforme a la receta de la arquitectura empresarial y sazonada con SOA es mucho más apetecible y, para conseguirlo, más que buenos cocineros necesitamos líderes...

Que aproveche...

Entendiendo los fundamentos de SOA con Thomas Erl

'Next Generation SOA' es, como su subtítulo 'A concise introduction to service technology & service orientation' claramente explicita, una guía breve y compacta de los principales conceptos de SOA (Service Oriented Architecture) desde un punto de vista tanto tecnológico como de negocio.

La intención es claramente mantenerse en un nivel introductorio y sencillo sin apenas introducirse en los aspectos tecnológicos que sólo se esbozan en el capítulo cinco.

El libro se estructura en 7 capítulos y tres apéndices. Los capítulos que conforman el cuerpo principal de la obra son:

• 'Introduction': simplemente, introduce el tema, presenta la estructura del libro y aporta referencias a lecturas complementarias.


• 'An overview of SOA & Service Orientation': intenta clarificar los conceptos de servicio y orientación a servicios y proporciona aportaciones valiosas como los principios de la orientación a servicios, las características de SOA, los tipos más habituales y los objetivos de la aplicación de la orientación a servicios, así como algunas ideas básicas sobre el gobierno SOA.


• 'A look at how services are defined and composed': resume una serie de ideas sobre conceptos (lógica agnóstica, modelos y capas de servicios y capacidades) y la forma de determinar los servicios (descomposición funcional, encapsulación, abstracción, dominios e inventarios de servicios). Los planteamientos son muy interesantes aunque se perciben aún como abstractos.


• 'An exploration of service orientation with the SOA manifesto': Repasa los conceptos de SOA mediante una revisión comentada del texto del'SOA manifesto'.


• 'An overview of service technology': hace un rapidísimo repaso por las principales tecnologías y metodologías involucradas en SOA (y algunas que, personalmente, opino que no son SOA). Así, introduce temas como servicios basados en web, componentes, virtualización, cloud computing, gestión de API, diseño software orientado a modelos, web semántica, BPM, composición y orquestación, Master Data Management (MDM), motores de reglas, tecnologías de redes sociales, movilidad, arquitectura dirigida por agentes, arquitectura dirigida por eventos y procesado de eventos complejos, inteligencia de negocio, EII (Enterprise Information Integration), ETL (Extraction, Transformation and Load) y Big Data.


• 'A look at service-driven industry models': presenta una serie de modelos de relación anivel negocio que se ven impulsados por la existencia de SOA (enterprise service model, virtual enterprise model, capacity trader model, enhanced wholasaler model, price comparator model, content provider model, job market model, global trader model, industry watchdog y guarantors) en unas reflexiones interesantes pero que dejan la sensación de tratarse de algo muy teórico, filosófico y conceptual.


• 'A case study': reproduce, en un estilo narrativo, la aplicación de conceptos SOA en una compañía y situación específicas.

Los tres apéndices que cierran el libro son los siguientes:

• 'Aditional reading for aplying service-orientation': profundiza en los ocho principios de la orientación a servicios introducidos en el capítulo 2 y que ahora amplía mediante una ficha explicativa por cada principio. Igualmente, amplia la información sobre las cuatro características de SOA y presenta los patrones de diseño SOA describiendo nueve patrones (agnostic capability, agnostic context, capability composition, capability recomposition, domain inventory, enterprise inventory, functional decomposition, non-agnostic context y service encapsulation) mediante una ficha estructurada.


• 'Additional reading for planning & governing service-orientation': aporta algunas ideas adicionales sobre gobierno SOA y madurez SOA


• 'Additional reading for cloud computing': realiza un breve tratamiento sobre Cloud computing, sus beneficios, retos y riesgos, en un tratamiento muy correcto, pero quizá algo fuera de lugar.

'Next Generation SOA', en su intento por dar una visión de alto nivel y poco técnica de la orientación a servicios, acaba siendo un libro para mi gusto algo fallido, porque se queda en un nivel muy superficial y teórico, que creo no clarifica realmente a personas de negocio lo que SOA supone y, a cambio, tampoco aporta información técnica relevante (casi que ni siquiera como resumen). Igualmente, creo que mezcla con SOA conceptos que realmente constituyen otra disciplina (por ejemplo, Big Data) o que sólo indirectamente tiene que ver (como cloud computing) lo cual creo que puede crear confusión especialmente en los lectores de carácter poco técnico a los que, en principio, va dirigido el libro.

Igualmente, me resulta flojo el tratamiento tanto de la parte tecnológica como del gobierno SOA donde hubiera esperado más ideas y mayor organización.

A cambio, me parecen aportaciones interesantes las del capítulo 2 donde establece los principios, características, tipos y objetivos de SOA. Igualmente, me resulta un tema interesante y prometedor (pero que precisa investigación adicional) lo que tiene que ver con patrones de diseño SOA.

Un libro, en fin del que, a sabiendas que era introductorio y con una visión necesariamente a vista de pájaro, esperaba más información, más claridad y un enfoque algo más práctico y técnico.

Thomas Erl

(Fuente: Traducción y ligera elaboración propia de la página personal del autor)

Thomas Erl

Canadiense nacido en 1967, Thomas Erl es un escritor de éxito sobre IT y fundador de Arcitura Inc. Thomas ha sido el autor sobre tecnología de servicios más vendido durante más de siete años y es el editor de la Prentice Hall Service Technology Series (www.servicetechbooks.com), así como editor de la Service Technology Magazine (www.servicetechmag.com). Con más de 200.000 ejemplares vendidos, sun nueve libros publicados se han convertido en bestseller internacionales y han sido formalmente respaldados por miembros senior de las mayores compañías de IT como IBM, Microsoft, Oracle, Intel, Accenture, IEEE, HL7, MITRE, SAP, CISCO, HP y otras.

Cuatro de sus libros, 'Cloud Computing: Concepts, Technology & Architecture', 'SOA Design Patterns', 'SOA Principles of Service Design' y 'SOA Governance' fueron escritos en colaboración con la comunidad IT y han contribuido a la definición de los mecanismos tecnológicos del cloud computing el modelo arquitectural de la orientación a servicios y de la propia orientación a servicios como un paradigma con entidad propia. Thomas actualmente trabaja con más de veinte diferentes autores en varios libros dedicados a materias especializadas como cloud computing, Big Data, tecnologías de servicios modernas y orientación a servicios.

Como CEO de Arcitura Education Inc, en en colaboración con SOA School, Cloud School y Big Data Science School Thomas ha dirigido el desarrollo del plan de estudios para los internacionalmente reconocidos programas de acreditación SOA Certified Professional (SOACP), Cloud Certified Professional (CCP) y Big Data Science Certified Professional (BDSCP).

Thomas es miembro fundador del SOA Manifesto Working Group y autor del Annotated SOA Manifesto (www.soa-manifesto.com). Es miembro del Cloud Education & Credential Committee, SOA Education Committee, y además supervisa las iniciativas SOAPatterns.org, CloudPatterns.org y BigDataPatterns.org, dedicadas al desarrollo de catálogos de patrones maestros para arquitectura orientada a servicios, cloud computing y Big Data.

Thomas ha viajado a lo largo de más de veinte paises como conferenciante e instructor para eventos privados y públicos y participa regularmente en conferencias internacionales. Ha publicado más de 100 artículos y entrevistas en numerosos medios, incluyendo The Wall Street Journal y CIO Magazine

Ficha técnica:

TITULO: Next Generation SOA

AUTOR: Thomas Erl et al.

EDITORIAL: Prentice Hall

AÑO: 2014

ISBN: 978-0-13-385904-1
PAGINAS: 185

Artículos de este blog relacionados

• Una advertencia sobre los estándares y la interoperabilidad
• Los siete objetivos de SOA
• Cuatro características de SOA
• #macrotweet: la condición necesaria para una transformación empresarial
• Los 8 principios del diseño SOA
• #macrotweet: la definición originaria de SOA

Una advertencia sobre los estándares y la interoperabilidad

El empleo de estándares facilita la vida de sus usuarios. Puede complicar desde el punto de vista de la estrategia a los fabricantes pero, desde luego, favorece a los consumidores de esos estándares.

Sin embargo, no es oro todo lo que reluce.

Confiar en exceso en los estándares, especialmente cuando en lo que a interoperabilidad de sistemas software se refiere, puede ser una trampa.

En el libro 'Next Generation SOA' y hablando, evidentemente, de SOA, se afirma.

The use of industry standards alone does not guarantee that services will be intrinsically interoperable.

¿Por qué?

Puede haber muchos motivos. 

Uno de ellos, por ejemplo, que un fabricante afirme respetar un estándar... y no sea así. O podemos encontrarnos ante fabricantes usando dos versiones del estándar... no compatibles. O el fabricante puede tendernos una trampa y, aunque respete el estándar, también ofrezca 'extensiones' propietarias...que si la usamos nos apartan inmediatamente del estándar y dificultan la interoperabilidad.

Sin embargo, estos motivos comentados arriba son, en realidad, formas de no respetar estrictamente el estándar. Pero, incluso con el respeto más absoluto, la obra anterior nos advierte de los siguiente:

For two software programs to be fully compatible, additonal coventions  (such as data models and policies) need to be adhered to.

En mi opinión, el modelo de información de intercambio entre servicios/sistemas es fundamental. En la medida que manejemos un modelo común y que precise lo menos posible de transformaciones de los modelos nativos, más cerca estaremos de una verdadera y sencilla interoperabilidad.

En esa línea, una arquitectura empresarial que incluya modelos de información comunes (como puede ser el caso de SID dentro de Frameworx) es una gran ayuda y un paso firme hacia la interoperabilidad.

En cualquier caso, advertido queda el lector: los estándares son buenos y necesarios en lo que a interoperabilidad se refiere... pero, confianzas, las justas...

Los siete objetivos de SOA

Continuamos esta corta serie de artículos que caracterizan SOA (Service Oriented Architecture) basados en las aportaciones de Thomas Erl et. al en el libro 'Next Generation SOA' repasando los objetivos específicos de la orientación a servicio.

En concreto, y según la fuente citada, estos son los objetivos que persigue la orientación a servicios:

• Aumentar la interoperabilidad intrínseca: ya que los servicios se diseñan precisamente para poder ser ensamblados, reconfigurados y reutilizados en respuesta a necesidades de negocio.


• Aumentar la federación: estableciendo un contrato que oculta la disparidad subyacente.


• Aumentar las opciones de diversificación de proveedor: usando un modelo de arquitectura neutral y no ligado a plataformas propietarias.


• Aumentar el alineamiento entre negocio y tecnología: con servicios diseñados con un contexto orientado a negocio, lo que les permite evolucionar de forma paralela al mismo.


• Aumentar el retorno de la inversión (ROI): los servicios se convierten en activos TI que aportan valor de forma repetida superando el coste de despliegue y propiedad.


• Aumentar la agilidad organizativa: con mayor capacidad de respuesta en menores plazos a las necesidades de negocio, construyendo soluciones mediante ensamblado de piezas existentes y potenciando la reutilización e interoperabilidad.


• Reducir la carga de IT: toda la empresa se racionaliza como consecuencia de todo lo anterior permitiendo a la organización de TI dar un mejor soporte a la compañía y proporcionar mayor valor con menor coste.

No son objetivos modestos. desde luego. Algunos los aplicaríamos a otras arquitecturas o soluciones TI pero otros, como la federación, son muy propios de SOA.

Lo importante, una vez fijados los objetivos, es cumplir la promesa....

Artículos de este blog relacionados

• Cuatro características de SOA
• Los 8 principios del diseño SOA