Diseñar un ecosistema de SoE para admitir experiencias de usuario enriquecidas

Sistemas de contratación: la nueva era de la nube

Los sistemas de contratación están tomando un rol cada vez más importante en la vida diaria tanto del consumidor como de la empresa. Los usuarios buscan una experiencia enriquecida que recolecte y analice información desde orígenes múltiples y distintos con y sin estructura para ayudarles a tomar decisiones rápidas e informadas. Un entorno operativo en la nube es la plataforma que admite sistemas de contratación. Este artículo presenta un enfoque para diseñar un ecosistema de sistema de contrataciones.

Fabio Castiglioni, Client Technical Advisor, IBM

Fabio Castiglioni photoFabio Castiglioni is an Executive IT Architect with IBM Sales and Distribution in Italy. He has 13 years of experience in a development lab, where he held technical and management positions on international projects. In 1995, he was appointed Technical Director for a research project on object-oriented technologies. In 1998, he was an IGS Senior IT Architect working on major government projects. Fabio is one of the teachers of Component Modeling classes for IBM architects and has published several articles on the subject of nonfunctional requirements.


Nivel de autor contribuyente en developerWorks

Michele Crudele , 소프트웨어 아키텍트, IBM China

Michele Crudele는 로마에 있는 IBM Software Group의 Tivoli Lab에서 근무하는 소프트웨어 아키텍트로서 20년의 IT 업계 경력을 보유하고 있고, 주로 시스템 관리 제품 및 솔루션 개발에 집중해왔다. Michele은 변경 구성 관리, 모니터링 및 가용성 관리, IBM 자율 컴퓨팅 기술 및 출판 산업 부문용 디지털 자산 관리와 같은 다양한 분야에서 근무한 경험을 바탕으로 폭넓은 기술적 스펙트럼을 보유하고 있다. 현재 Michele은 클라우드 컴퓨팅 솔루션에 집중하고 있으며, TSAM 확장 기능의 책임 아키텍트이다



22-10-2013

Cada vez más, los consumidores en línea requieren una experiencia enriquecida que aproveche la información proveniente de orígenes distintos con y sin estructura, de canales sociales y de otros consumidores conocidos. El valor contenido en esta información puede extraerse rápidamente para alcanzar los objetivos de una persona y permitir las decisiones informadas. Actualmente la norma en el espacio del consumidor ya es este tipo de experiencia, que se está volviendo una expectativa general también para las aplicaciones empresariales. Un sistema de contratación (SoE) permite esta experiencia enriquecida mediante la extracción del valor a partir de información que proviene de múltiples canales y que permite nuevos modelos empresariales digitalizados. Un entorno operativo en la nube (CloudOE) es la plataforma que admite las cargas de trabajo de SoE. El CloudOE proporciona la agilidad y la velocidad que un SoE necesita, ya que provee un ecosistema para desarrollar, desplegar y operar aplicaciones de SoE.

El diseño de un ecosistema de SoE es una nueva forma de hacer las cosas, y los métodos de análisis tradicionales, tales como los casos de uso, son muy limitados para representar las decisiones que son la base de un modelo de SoE. Este artículo presenta un enfoque alternativo y describe su impacto en el proceso de diseño. Mediante un ejemplo en el campo del turismo, explica los conceptos de diseño relevantes y el flujo de desarrollo.

Procesos y sistemas basados en la contratación

Los procesos basados en la contratación ya son la tendencia principal para muchas industrias y se están volviendo cada vez más importantes para otras. Los ejemplos incluyen:

  • Planificación de las vacaciones: la planificación de las vacaciones que utiliza internet es el mercado basado en la contratación en línea más desarrollado. Acceder a motores de comparación de precios; consultar sistemas de reputación, tales como TripAdvisor; ver datos contextuales (tales como imágenes en Google Maps e información del clima en el canal del clima) y encontrar e intercambiar información con grupos expertos en redes sociales es un comportamiento común para el viajero nativo digital.
  • Consultoría financiera: desde hace tiempo, los bancos han dejado de ser simplemente un mostrador en el que se realizan operaciones financieras y empezaron a ser un consejero de salud financiera a través de una relación continua, estable y personal con sus clientes. Dicha relación requiere de un conocimiento continuo, actualizado y de confianza entre el consejero y el cliente.
  • Nuevos planes de asistencia social individual: con presupuestos reducidos y bajo una presión económica cada vez mayor, algunos gobiernos están cambiando el enfoque de evitar disturbios sociales a través de subsidios para obtener resultados sociales a través de programas personalizados para volver a incluir al ciudadano en el círculo de producción. Este enfoque requiere de colaboración en todas las agencias, integración de los datos de los ciudadanos de orígenes públicos y privados, y correlación de información con y sin estructura para identificar el plan que tiene más posibilidades de éxito para cada situación individual.
  • Investigación de fraudes y abusos: en un mercado electrónico global, los fraudes y abusos han tomado nuevas formas y alcanzado nuevas complejidades. Investigarlos requiere el análisis y la comparación de enormes cantidades de datos con y sin estructura a partir de orígenes distintos y frecuentemente no relacionados en apariencia. El momento y la ubicación geográfica de esos datos, así como la colaboración entre múltiples organizaciones, son habilitadores clave para este escenario.
  • Compras basadas en el contexto con base en la conciencia de la ubicación: la conciencia de la ubicación que se basa en la ubicación geográfica de los dispositivos móviles personales permite un nuevo escenario para el comercio minorista, y extiende así una experiencia que ya es común en internet con publicidad "contextual" de motor de búsqueda que está basada en el historial de navegación de los consumidores.

El soporte para SoE abre nuevas posibilidades para muchas industrias. Los usuarios pueden tener una experiencia enriquecida con el sistema — el tipo de experiencia que en el pasado era posible solo a través de la interacción personal. Las contrataciones están, de hecho, centradas en el humano por naturaleza. Al contrario de un sistema de registros (SoR) — cuyos procesos centrados en registros realizan el seguimiento del progreso de los usuarios a través de una secuencia de registros de datos, — la meta de un SoE es alcanzar los objetivos que sean significativos para el usuario.


El ecosistema de SoE

En un documento informativo de 2011, el consultor Geoffrey Moore introdujo el término sistemas de contratación para describir sistemas que se enfocan en "dar poder a la parte media de la empresa para comunicar y colaborar en todas las fronteras de la empresa, en todas las zonas horarias globales y en todos los idiomas y las barreras culturales, mediante aplicaciones de TI de última generación e infraestructura adaptada a partir del espacio del consumidor".

En esencia, los SoE aplican analítica predictiva para datos móviles, sociales, de servicios públicos en la nube y de sistemas de TI tradicionales (SoR) para entregar aplicaciones y productos inteligentes directamente en el contexto de la vida diaria de los clientes, socios y empleados.

La Figura 1 ilustra un ecosistema de SoE:

Figura 1. Un ecosistema de SoE
Illustration of an SoE ecosystem. The SoE uses data that comes from mobile devices and sensors, social channels, public services, and systems of records. It performs predictive analytics on the data and delivers recommendations to the user.

Un SoE:

  • Permite la colaboración: los SoE son para humanos, y asumen que los humanos colaborarán entre ellos. Por el contrario, la principal preocupación de los SoR es la interacción entre el usuario (humano) y el sistema (máquina) con respecto a procesos específicos. En una contratación, las interacciones humano con humano y humano con máquina se dan sobre la misma base y son parte de una colaboración general.
  • Explota datos enriquecidos a partir de múltiples orígenes: los SoE son imposibles sin los datos grandes. El análisis de orígenes de datos distintos para extraer información significativa y accionable se encuentra en el centro del razonamiento humano y también en el centro de los SoE.
  • Se adapta a identidades y preferencias: cuando actúa como un profesional de TI, tiene distintos comportamientos y preferencias que cuando lo hace como el padre de su hijo en la escuela (aunque las dos identidades se influencian entre ellas en algunas formas). Sin embargo, para algunos SoR todos sus roles utilizan el mismo ID, dirección, número de ID gubernamental, etc. Este no es el caso para un SoE. Los SoE deben tener en cuenta su trabajo, sus preferencias y su historial (en pocas palabras, su contexto) para brindar la experiencia enriquecida esperada. En términos prácticos, los SoE deben utilizar bastante analítica de datos sobre la marcha o un sistema de gestión de datos maestros (MDM) en donde la información compleja sobre los usuarios se mantiene y enriquece constantemente.
  • Está consciente del tiempo y la ubicación: una experiencia de usuario enriquecida debe tener en cuenta el hecho de que vivimos en el tiempo y nos movemos en el espacio. Recibir una imagen de una playa soleada para sus vacaciones de la siguiente semana cuando se espera una tormenta tropical en su destino esa misma semana no es un buen servicio para su contratación. (Es el nivel de servicio que proporciona la mayoría de los SoR de reservaciones). Los dispositivos móviles abren oportunidades para interacciones aún más enriquecidas a medida que se mueve durante una contratación.
  • Admite múltiples formas de interactuar: los dispositivos móviles suelen proporcionar la experiencia de cliente más enriquecida, ya que pueden incluir la ubicación del usuario en la lógica de contratación. Pero ciertas contrataciones no requieren de la conciencia de ubicación, por lo que pueden ser efectivas al utilizarse en una PC regular. Otros tipos de dispositivos, tales como kioscos o incluso cajeros automáticos, pueden jugar un rol en otros tipos de contrataciones
  • Mantiene seguridad y privacidad apropiadas: ya que un SoE conoce tanto sobre usted, debe mantener esta información segura. El usuario debe poder controlar quién obtiene qué información. Pero mientras menos datos se expongan, el servicio que se recibe será menor — ya que la personalización de la información y los servicios a los intereses personales de los usuarios son la principal función del sistema. (En este aspecto, un SoR es mucho menos demandante, ya que normalmente puede reducir diferencias en el comportamiento con clases de usuario o perfiles).

Entorno operativo en la nube: la tecnología detrás de los SoE

A diferencia de los SoR, los SoE deben diseñarse para trabajar con requisitos de recursos erráticos y necesidades de capacidad no planificadas e imprevisibles. Más aún — para diferenciarse en el mercado e incrementar los ingresos — deben permitir que los clientes obtengan un mayor conocimiento más rápidamente a partir de los datos disponibles. Por estas razones, los SoE necesitan una plataforma que facilite desplegar, gestionar y escalar aplicaciones. Los desarrolladores pueden entonces enfocarse en el desarrollo y las operaciones de la aplicación misma y no en la infraestructura necesaria para alojar la aplicación.

Las nubes de infraestructura como un servicio (IaaS) dan a los desarrolladores centros de datos de tamaño virtualmente ilimitado sin que necesiten invertir en compras de hardware por adelantado. Sin embargo, los desarrolladores aún necesitan configurar las máquinas virtuales, instalar el software de middleware, conectar componentes del sistema y mantener sistemas, — lo cual quita tiempo del verdadero trabajo de innovación. Aún cuando los desarrolladores implementan DevOps en IaaS, necesitan invertir tiempo en compilar y gestionar operaciones.

DevOps

DevOps es una metodología de software que pretende mejorar la comunicación, colaboración e integración entre desarrolladores y equipos de operaciones, con la meta de acelerar el proceso de entrega del software. Una práctica de DevOps es describir tareas de configuración-gestión repetitivas como plantillas (llamadas recetas o libros de cocina) y compilar sistemas (mediante herramientas tales como Chef) que ejecutan las plantillas para automatizar la gestión y el mantenimiento de la infraestructura.

La nube es capaz de hacer más que solo proporcionar IaaS. Un CloudOE puede encargarse de desplegar, configurar y conectar las máquinas virtuales, lo cual permite a los desarrolladores concentrarse en la aplicación. Un CloudOE puede automatizar procedimientos de DevOps, lo que se traduce en NoOps para los desarrolladores. La clave del éxito de un CloudOE es qué tan bien y qué tan rápido permite a los desarrolladores de primera línea compilar sus aplicaciones.

Categorías de servicio

Los casos de estudio han mostrado que una plataforma de CloudOE debe admitir cuatro categorías de servicios, las cuales son necesarias para compilar y operar aplicaciones centradas en la nube (o nativas de la nube), tales como SoE:

  • Servicios de desarrollo
  • Servicios de aplicación
  • Servicios de infraestructura
  • Servicios operacionales

Una plataforma de CloudOE debe brindar una variedad de estos servicios y debe hacerlos fácilmente utilizables a través de una API de cliente cohesiva y simple. El soporte de un solo lenguaje de programación y un solo contenedor web es insuficiente. En su lugar, el CloudOE debe acomodar diversas infraestructuras de desarrollo web adecuadas para el propósito (tales como Grails, Play Framework, Ruby on Rails y Django), lenguajes (tales como Java®, Ruby, Python y Node.js) y modelos de programación.

Entre los principales servicios de aplicación, la plataforma debe proporcionar, como mínimo:

  • Servicios de base de datos relacional
  • Servicios de base de datos (NoSQL) basados en documentos (como MongoDB)
  • Servicios de mensajería
  • Servicios de almacenamiento (como OpenStack Object Storage)

La Figura 2 resume los servicios clave que la plataforma de CloudOE debe exhibir para admitir cargas de trabajo de SoE:

Figura 2. Servicios clave para admitir cargas de trabajo de SoE
Illustration of key services (development, applicatoin, infrastrucure and operational) that suport SOE applications and workloads

Lo más importante es que todo debe fluir alrededor de una experiencia de desarrollador elegante y sin complicaciones que pueda verse así:

  1. Génesis:
    • Yo creo mi cuenta desde el portal de CloudOE.
    • Yo descargo la herramienta de línea de comandos (como desarrollador, me gusta la línea de comandos) para gestionar aplicaciones y servicios.
    • Yo descargo la API del cliente de CloudOE en el lenguaje que prefiero.
    • También puedo descargar el plug-in de CloudOE para mi IDE preferido.
  2. Ahora puedo comenzar a desarrollar mi siguiente aplicación de SoE. Necesito una base de datos relacional para metadatos y un servicio de almacenamiento de objetos para salvar los blobs que deseo gestionar (como fotografías, gráficos y artículos). Después necesito el soporte del tiempo de ejecución para la infraestructura de desarrollo web que deseo utilizar.
    • Observo la documentación y descubro que CloudOE me brinda todo esto.
    • Utilizo la línea de comandos o el plug-in de IDE para solicitar un servicio de base de datos y un servicio de almacenamiento de objetos. El CloudOE despliega estos servicios para mí automáticamente en su infraestructura.
    • Grabo mi aplicación, mediante una interfaz para los servicios con la API del cliente de CloudOE.
    • Despliego la aplicación con el plug-in de IDE o la línea de comandos. El CloudOE suministra automáticamente el entorno del tiempo de ejecución para la aplicación, crea las conexiones con los servicios que necesita y me da un URL para acceder a la aplicación.
    • Pruebo la aplicación.

Portabilidad

Los clientes no quieren estar atrapados en un proveedor de nube. Deben poder adaptar sus cargas de trabajo fácilmente para que se ejecuten en un CloudOE distinto. Idealmente, una aplicación de CloudOE es desplegable en el propio hardware y software de middleware del cliente con cambios únicamente en la configuración, no en el código.

Con un CloudOE, los desarrolladores pueden hacer en horas lo que requeriría días en un entorno tradicional. No necesitan desplegar el servidor de aplicaciones web para alojar las aplicaciones y no necesitan desplegar la base de datos y reservar el almacenamiento.

La infraestructura y los servicios operacionales de la plataforma de un CloudOE hacen que el valor de la plataforma sea más evidente. Estos servicios son importantes principalmente cuando las aplicaciones se mueven del entorno de desarrollo al entorno de verificación y, finalmente, al entorno de producción. El CloudOE debe brindar la habilidad de configurar múltiples entornos segregados para alojar las aplicaciones y las herramientas que simplifiquen la tarea de la entrega continua y la integración.

El dispositivo destacado de los servicios de infraestructura es el escalamiento horizontal de las aplicaciones: añadir más instancias cuando la demanda se incrementa y liberar instancias cuando la demanda disminuye. Los servicios operacionales conceden acceso a la gestión de la aplicación como un servicio, sin la necesidad de desplegar y mantener un conjunto de productos de gestión en premisas. Idealmente, un equipo de operaciones puede activar copias de seguridad regulares de una aplicación (y sus servicios) con unos cuantos clics del ratón en el portal de ClouldOE. Los desarrolladores pueden tomar instantáneas de los datos de los servicios, de forma que puedan restaurarlos en un entorno distinto para analizar un problema.

CloudOE del mundo real

Los CloudOE descritos en este artículo no son ciencia ficción; se están volviendo realidad rápidamente. Muchos proveedores de Plataforma como Servicio (PaaS) de la nube están acercándose rápidamente a CloudOE. Entre ellos están Cloud Foundry de Pivotal, Heroku y OpenShift de Red Hat.

IBM ha anunciado BlueMix, la plataforma de nube de última generación basada en la arquitectura de IBM Open Cloud y la PaaS de código abierto Cloud Foundry. IBM BlueMix crecerá con el tiempo y brindará servicios y tiempos de ejecución basados en el extenso portfolio de software de IBM. Permitirá el acceso a servicios de alto nivel, de forma que los desarrolladores puedan fácilmente consumir información de dispositivos móviles, canales sociales y datos disponibles públicamente.

La primera contribución a la comunidad de código abierto de Cloud Foundry es el IBM WebSphere Liberty Buildpack, el cual está disponible para vista previa para los consumidores que se involucrarán en el proyecto de BlueMix.

Conectividad y sistemas externos

A menos que los clientes puedan conectar sus SoR a la plataforma de CloudOE y hacerlos utilizables como un servicio para sus organizaciones de desarrollo, verán que el CloudOE (público o privado) es inútil. Una plataforma atractiva de CloudOE debe hacer posible conectar nuevos servicios y aprovechar sistemas externos como un servicio.

Por ejemplo, Cloud Foundry introdujo instancias de servicio proporcionadas por el usuario como la forma más rápida de brindar a los desarrolladores servicios que residan fuera de la plataforma, tales como un SoR existente. Con esa función, un cliente puede utilizar CloudOE público y:

  • Un SoR en las instalaciones — una base de datos de registros de clientes, por ejemplo, — puede conectarse a través de un servicio de VPN ofrecido por el proveedor de la nube.
  • Una instancia de servicio proporcionada por el usuario se crea para la base de datos de registros de clientes. (El propietario del SoR suministra el URL y las credenciales de usuario en esta fase, así como cualquier otro atributo que las aplicaciones necesiten para funcionar con la base de datos de registros de clientes).
  • Los desarrolladores pueden utilizar bibliotecas de clientes existentes de la base de datos de registros de clientes al desarrollar aplicaciones. El URL y las credenciales para conectarse a la base de datos son suministrados por Cloud Foundry en el entorno de la aplicación

Actores y arquitectura de SoE

Un SoE es un ecosistema que está diseñado para extensión. A diferencia de un SoR, no es una entidad completamente terminada. Un SoR es la implementación directa de uno o más procesos empresariales que tienen un inicio, un conjunto de acciones, posiblemente algunos puntos de decisión bien definidos, y un final. Un SoE admite colaboraciones entre actores empresariales. Las colaboraciones son mucho más difíciles de definir que los procesos empresariales. Y las colaboraciones normalmente evolucionan con el tiempo, como cualquier experiencia humana. Un SoE debe estar listo para evolucionar; debe compilarse como una plataforma empresarial que está diseñada para evolución y para el soporte de colaboración entre múltiples actores.

Utilizaremos la terminología que Rashik Parmar (Presidente de IBM Academy of Technology e Ingeniero Distinguido de IBM) utiliza (en un documento interno no publicado titulado "Introduction to Disruptive Businesses Platforms") para definir los actores de una plataforma empresarial (énfasis añadido):

En el centro de la plataforma está el propietario de la plataforma y el proveedor. Aunque estos dos pueden ser el mismo, la distinción es importante en plataformas de industrias múltiples y empresariales de industrias cruzadas. Los complementadores existen para añadir valor a la plataforma y tomar una parte en la captura de valores de los consumidores. Los proveedores son distintos de los complementadores, ya que ellos no mejoran ni brindan servicios directamente a los consumidores. En su lugar proporcionan herramientas, tecnologías y recursos para el proveedor de la plataforma, para permitir que el proveedor descargue sus responsabilidades. Los consumidores son atraídos para que compren los servicios de la plataforma empresarial debido a la diversidad, los niveles de servicio o el bajo costo. El uso novedoso también es motivado a través de la plataforma empresarial, de forma que, por ejemplo, los consumidores puedan realizar transacciones entre ellos.

La Figura 3 muestra los actores en una plataforma empresarial y cómo se relacionan entre sí:

Figura 3. Actores de un ecosistema de plataforma
Illustration of the actors that interact in a business platform ecosystem: end users, platform owner, platform provider, complementers, and suppliers.

Como un ejemplo, tome la plataforma de Apple iPhone/iTunes. Apple es el propietario y el proveedor de la plataforma. FoxConn, fabricante del iPhone, es un proveedor de Apple, el cual vende los teléfonos a los consumidores. En la plataforma, diversos complementadores (otras compañías) venden música y aplicaciones directamente a los consumidores, mejorando así el valor de la plataforma.

Las plataformas empresariales exitosas comparten estas características:

  • El ecosistema de complementadores y el proveedor de la plataforma pueden solucionar un problema en común para un amplio espectro de consumidores, haciendo así la plataforma viable financieramente.
  • Las interfaces que habilitan a los complementadores para mejorar la plataforma son abiertas y se basan en estándares para generar confianza en el ecosistema.
  • La plataforma puede ser fácilmente expandida, y permite la evolución sin interrupciones.
  • Se motiva la innovación y el uso novedoso por parte de complementadores y consumidores.
  • Los complementadores pueden añadir valor y valor de captura a través de la interfaz.
  • El servicio exclusivo brindado en el centro de la plataforma es difícil de sustituir.
  • El ecosistema es estable.

En esencia, una plataforma empresarial es una combinación de un proveedor de plataforma empresarial y un ecosistema de complementadores que se soportan uno a otro para brindar servicios para un mercado de consumidores.

Principios de arquitectura

Ahora podemos definir los principios de arquitectura de una plataforma de SoE:

  • Un SoE proporciona una experiencia enriquecida que requiere servicios de calidad superior, — especialmente rendimiento, escalabilidad y confiabilidad. Los SoE son entornos especialmente desafiantes para que los arquitectos de aplicaciones diseñen, ya que deben garantizar la satisfacción de requisitos no funcionales mientras que tienen un control limitado de la infraestructura subyacente. (Vea Resources para obtener libros y artículos que discuten cómo los requisitos no funcionales pueden integrarse en la descripción de arquitectura de sistemas complejos e intensivos en software).
  • Un SoE es una plataforma empresarial. Cualquier función disponible debe exponer API y ser capaz de extenderse o duplicarse por otra implementación de la competencia. Esas implementaciones y extensiones necesitan publicarse en un catálogo abierto. Los complementadores deben poder acceder al conjunto completo de herramientas necesarias para añadir posibilidades a la plataforma en cualquier nivel.
  • La nube es la tecnología básica detrás de un SoE. Además, un SoE necesita otras tecnologías subyacentes:
    • Un servicio de mensajería altamente escalable y de alto rendimiento.
    • Un adaptador para SoR externos que esté incorporado en el servicio de mensajería. (SoR siempre serán los mecanismos de acceso de los resultados de la contratación, así como orígenes de datos estructurados críticos). Dicho adaptador puede necesitar conectores para sistemas de legado y para el catálogo de eventos externos que sean significativos para la contratación y que puedan desencadenar la contratación.
  • Dado el aspecto confidencial de los datos de SoE, la seguridad aplicable en la nube es necesaria para la identificación, autorización y privacidad.
  • Los datos grandes y las posibilidades de analítica (incluidos datos y analítica sobre las operaciones de la plataforma misma, tales como sus indicadores clave de rendimiento [KPI]) deben estar presentes en la plataforma (tal vez con más de una implementación). Los datos grandes llegarán desde múltiples orígenes que necesitan hacerse interoperables, así que algún tipo de metadatos públicos y motor semántico deberá también estar presente.
  • Móvil es un aspecto clave en un SoE. El acceso en todo lugar y en todo momento, y la conciencia de ubicación, pueden mejorar el valor de una contratación.
  • Un SoE está lleno de normas que van desde preferencias personales en la toma de decisiones hasta la contabilidad de normas para el servicio de un complementador. Un sistema de gestión de normas empresariales es necesario, como un motor de tiempo de ejecución y como un repositorio de normas públicas
  • Ya que SoE se trata de contrataciones humanas, el acceso de usuario (el portal) y las herramientas sociales (públicas o específicas de la plataforma) son componentes esenciales de la solución.

Requisitos adicionales

Algunos otros requisitos se aplican a la tecnología que admite un SoE:

  • Orientación de servicio en el centro: Igual que los ecosistemas digitales y las plataformas empresariales, los SoE tienen servicios en su núcleo. Esos servicios son ligeros y se basan en la arquitectura de Transferencia de Estado Representacional (REST). Los SoE ni siquiera serían posibles sin una arquitectura orientada a servicios como su base.
  • Con base en estándares de la industria: Los SoE son plataformas de actores múltiples y compiladas para el crecimiento. No pueden prosperar sin estándares comunes sólidos.
  • Aprovechar y extender las tecnologías de código abierto: Ya que los estándares garantizan la interoperabilidad real solo después de una larga curva de aprendizaje — SOAP, por ejemplo, requiere de muchos años para alcanzar una interoperabilidad completa con perfiles de WS-I — el consenso en la industria de TI es que las tecnologías de código abierto puedan garantizar una ruta más rápida y sencilla hacia soluciones robustas e interoperables.
  • Integridad del proceso a escala de internet: al compilar un SoE no puede asumir la proximidad de los datos, la respuesta garantizada o las tasas de solicitud diferentes de aquellas que puede conseguir en internet — a menos que pueda aplicarlas explícitamente desde el tablero de dibujo.
  • Integración con posibilidades empresariales y sistemas de backend: Los SoR llegaron para quedarse, ya que hacen bien aquello para lo que están diseñados (registrar o aplicar un proceso). Un SoE probablemente necesitará integrarse con uno o más (probablemente más) SoR así como con las posibilidades de la empresa con las que harán interfaz los SoR.
  • Provisión de la plataforma para un ecosistema en crecimiento: está en la naturaleza de la misión de los SoE que evolucionen. Su arquitectura consiste en las posibilidades expuestas de subsistemas de propósito general más que de interacciones conectadas entre componentes de propósito especial. Su diseño busca riqueza y apertura más que elegancia y eficiencia.

Diseño de un SoE

El diseño de una solución de SoE, igual que como con cualquier tipo de solución, la primera tarea es definir los requisitos de la experiencia de usuario que se desea. Los usuarios esperan que los SoE aprovechen la convergencia del acceso móvil, la conciencia de ubicación, la colaboración y la explotación de datos grandes para ayudar al actor humano a tomar la mejor decisión posible con base en una evaluación informada de las opciones posibles.

El diseño de una experiencia de usuario que admita efectivamente las decisiones humanas es un aspecto crítico de un SoE. Esta experiencia no puede ser preceptiva y no puede utilizar un flujo o proceso fijo. Debe permitir la correlación de información distinta, que va desde correlación visual simple hasta analítica compleja. La experiencia es restringida por las pantallas pequeñas de los dispositivos móviles y debe incluir soporte para tecnologías de audio y video, incluido el reconocimiento de voz.

Las discusiones que van más allá del diseño de la experiencia están fuera del ámbito de este artículo. Continuaremos enfocándonos en los aspectos más cercanos a la arquitectura de un SoE.

Como hemos establecido, un SoE típico interactúa con un número de SoR que son los mecanismos de acceso del proceso de decisión y de la decisión misma. Si considera el espacio de requisito típico de un SoR (asumamos que es un sistema de soporte de viajes), esto se traduce en un modelo de caso de uso tal como el ejemplo en la Figura 4:

Figura 4. Un ejemplo de modelo de caso de uso para un SoR de soporte de viajes
Use cases diagram for a travel-support system of records

El modelo de caso de uso en la Figura 4 da un buen indicativo del proceso empresarial general para un SoR de soporte de viajes:

  1. Identifíquese usted mismo.
  2. Obtenga boletos o utilice su pase gratuito.
  3. Haga reservaciones y, si es necesario, modifíquelas.

Los casos de uso pueden descomponerse para conseguir una granularidad lo suficientemente detallada para identificar las principales funciones de la solución que se pretende. Y los casos de uso pueden agruparse en agregaciones que representan una muestra de los componentes del sistema futuro.

Ahora considere el otro aspecto del compromiso: cómo el viajero elige qué hacer en sus vacaciones y cómo organizarlas. La Figura 5 muestra los factores que pueden influenciar esa decisión:

Figura 5. Un ejemplo de los factores en una decisión vacacional
Illustration showing the types of multiple criteria that can influence a the decision of which vacation to take

Aquí, los casos de uso no aportan pistas para el proceso de toma de decisión. Puede ser un proceso largo de prueba y error que requiera días o una decisión de un segundo tal como "debo ir a este lugar que vi en una película".

En este caso, otras cosas son más relevantes como requisitos para la solución que el proceso mismo:

  • Información que debe considerarse (orígenes de datos y sus relaciones)
  • Criterio de decisión, incluidas las preferencias personales
  • Factores de influencia (humanos y no humanos)
  • Contexto, incluidos tiempo y lugar
  • Colaboración entre las partes involucradas

En resumen, lo que es relevante es lo que algunas infraestructuras de modelado (incluido TOGAF/ArchiMate) llaman el modelo de motivación detrás de la contratación.

Después de que los requisitos de motivación estén claros, la forma de la contratación puede ser establecida en términos de:

  • Funciones empresariales que deben proporcionarse sobre objetos de información que afectan la decisión
  • Colaboraciones entre actores
  • Entidades del proceso que describen la parte de la solución de los SoR

La Figura 6 muestra el metamodelo de TOGAF/ArchiMate de un SoE:

Figura 6. Metamodelo de TOGAF/ArchiMate de SoE
Enterprise architecture metamodel of the SoE

Como muestra la Figura 6:

  • La infraestructura técnica para un SoE es un CloudOE y uno o más SoR.
  • El CloudOE es la plataforma que ejecuta cargas de trabajo de SoE.
  • Los servicios se realizan físicamente a través de interfaces y las aplicaciones, a través de componentes.
  • Los componentes implementan un proceso empresarial o una actividad empresarial, y pueden utilizar otros componentes a través de sus interfaces o funciones técnicas a través de interfaces técnicas. Las funciones técnicas, en su mayoría, ofrecen posibilidades comúnmente proporcionadas por productos de middleware (por ejemplo, una base de datos de NoSQL).

Ejemplo: Un SoE de "Turismo en el Valle"

Como un ejemplo de la metodología que hemos señalado, utilizaremos el caso de una plataforma para apoyar y promover el turismo en un valle alpino. Seguiremos este ejemplo desde el modelo de motivación de las partes interesadas hasta la identificación de los servicios de middleware de CloudOE necesarios para admitir el SoE.

La Figura 7 muestra el modelo TOGAF/Archimate de la motivación de las partes interesadas:

Figura 7. Motivación de "Turismo en el Valle"
Architectural model of the stakeholders' motivation

Haga clic para ampliar la imagen

Figura 7. Motivación de "Turismo en el Valle"

Architectural model of the stakeholders' motivation

El modelo incluye el punto de vista de la parte interesada principal (el turista) y los objetivos de las otras partes interesadas del dominio: proveedores de servicios tales como hoteles, restaurantes, transporte y eventos (los proveedores); la oficina de turismo del valle (el dueño de la plataforma); y proveedores de aplicaciones de valor añadido y generadores de opinión externos (los complementadores).

Para simplificar la explicación, dividimos el modelo en dos partes: impulsado por el turista e impulsado por otras partes interesadas. También omitimos la discusión de KPI y medidas (incluidos los requisitos no funcionales), lo cual podría ser el tema entero de un artículo separado.

El turista es influenciado en la toma de decisión por una serie de impulsores que incluyen sus intereses personales y preferencias, el pronóstico del clima y recompensas de fidelidad obtenidas.

La oficina turística está a cargo de promover el valle como un destino vacacional. Esta oficina actúa a través de anuncios, iniciativas y apoyo de eventos locales que sean capaces de atraer a clientes a los servicios del valle. Los principales requisitos de la oficina turística son conocer los resultados de estas acciones para recolectar la información que necesita para mejorar el sistema empresarial del valle — como los patrones típicos de visitas (quizá por segmento de mercado) y el atractivo de los puntos naturales.

Los proveedores de servicios (hoteles, restaurantes, etc.) desean que la calidad y el precio de sus servicios se comparen favorablemente con la competencia. También desean igualar sus ofertas con las necesidades y preferencias del cliente — un requisito que es compartido por proveedores de aplicaciones de valor añadido (quienes, además, deben proteger su capital intelectual del uso no autorizado).

Una parte del modelo

Para ayudar a explicar el ejemplo, nos enfocaremos en la "parte" del modelo que incluye la selección de los servicios que conformarán un plan vacacional. No consideraremos todos los temas relacionados con el transporte y la reservación de servicios (que son las áreas que están más ligadas a los SoR tradicionales) y rastrearemos el modelado de los siguientes requisitos:

  • La necesidad de un catálogo de servicios que contenga información de servicios (disponibilidad, precio, planificaciones, etc.), eventos locales, noticias sobre incentivos y otros tipos de promociones.
  • La necesidad de comparar servicios con base en múltiples criterios (como el precio, la reputación y las opiniones confiables) y de seleccionar la mejor opción.
  • La necesidad de poder seleccionar servicios por su ubicación, por la proximidad con otra ubicación de interés o por el hecho de que pueden estar enlazados a un evento único específico que está ocurriendo en la ubicación.
  • La necesidad de considerar la información contextual, principalmente el clima. (El tráfico puede ser otro ejemplo).
  • La necesidad de gestionar las preferencias de usuario en la contratación (datos maestros turísticos).

Estos requisitos se muestran en el modelo en la Figura 8:

Figura 8. Requisitos del turista de "Turismo en el Valle"
Tourist requirements for the Tourism in the Valley example

Haga clic para ampliar la imagen

Figura 8. Requisitos del turista de "Turismo en el Valle"

Tourist requirements for the Tourism in the Valley example

Los requisitos se reflejan en funciones empresariales correspondientes:

  • Gestión del catálogo de servicios empresariales por parte del proveedor de la plataforma y los proveedores de servicios para mantener información actualizada sobre hoteles, restaurantes, eventos, transporte y otros servicios. Como mínimo, la información de servicio debe incluir cuándo está disponible el servicio, cuál es su planificación y cuál es su precio. Mientras mejor sea la información que proporciona un proveedor de servicios, mayor será la probabilidad de que coincida con las preferencias del cliente. (Por ejemplo, anunciar que el hotel es adecuado para los niños probablemente será atractivo para familias que viajan con niños pequeños).
  • Una búsqueda de criterios múltiples y una posibilidad de clasificación que utilice la información en el catálogo, más información de terceros, como la reputación del servicio, las opiniones en redes sociales, los programas de incentivos y las recompensas que posee el cliente. La decisión del cliente de comparar las ofertas puede originarse de ver un aviso externo, como un anuncio.
  • La habilidad del cliente para visualizar servicios y puntos naturales de interés en un mapa en línea de forma que las decisiones puedan basarse en ubicación y distancia y complementar la imagen con información contextual tal como el clima y el tráfico.
  • La posibilidad de alimentar y gestionar el registro de las necesidades e intereses del cliente (un gestor de datos maestros personal) que incluya no solo compras pasadas e historial de viajes, sino también orígenes confiables de opiniones y otros detalles personales. (Este tipo de información altamente sensible puede recolectarse y utilizarse solo con el conocimiento y la aprobación del cliente y debe ser consumida solo por él. El beneficio que esta información le da al turista es sustancial y los mecanismos de anonimato pueden garantizar que la información completa no sea accesible para otros).

La Figura 9 muestra la porción del modelo empresarial del SoE de Turismo en el Valle para satisfacer los requisitos del turista:

Figura 9. Modelo empresarial turístico de "Turismo en el Valle"
Tourist business model for the Tourism in the Valley example

Las posibilidades empresariales deben ser admitidas por servicios reales en el entorno de nube del SoE. A su vez, estos servicios deben ser implementados por componentes de aplicación reales que son proporcionados por el proveedor de la plataforma o por un complementador. Por ejemplo, un complementador puede desarrollar una aplicación "Encontrar buenas ofertas para los niños" con las API del catálogo de la plataforma.

Los servicios y las aplicaciones trabajan juntos

Ahora utilizaremos una posible experiencia de usuario para mostrar cómo los servicios y la aplicación trabajan juntos. Una aplicación de gestor de visualización para el SoE de Turismo en el Valle es una aplicación web en el CloudOE y puede ser descargada por el turista desde una tienda de aplicaciones móviles. El gestor de visualización interactúa con otros componentes de aplicación para proporcionar la experiencia de SoE completa:

  1. Yo decido tomar unas vacaciones y pienso que quiero visitar el valle alpino.
  2. Encuentro una aplicación en la tienda de aplicaciones que promete simplificarme toda la experiencia, desde la reservación del hotel hasta el transporte y recomendaciones sobre cosas que se pueden hacer en el valle. La instalaré.
  3. Pero tengo que registrarme: una cuenta más, una contraseña más. ¡No!
  4. Pero, espera, — la aplicación del "valle alpino" me permite iniciar sesión a través de Facebook o Twitter. Tengo una cuenta de Facebook, así que haré eso.
    • La aplicación utiliza el servicio de CloudOE del gestor de acceso y de identidad para delegar la autenticación a Facebook y obtener un token de usuario.
  5. Inserto mis credenciales de Facebook y ahora estoy "en" el valle.
  6. La aplicación utiliza el servicio de mapa para mostrar una vista del valle con los puntos de interés relevantes: villas y montañas correlacionadas con fotografías y resúmenes breves.
  7. Decido que deseo ir ahí, así que ingreso la fecha de inicio y la duración de mi estadía y dejo que la aplicación decida por mí algunas alternativas.
  8. La aplicación utiliza varios servicios para organizar el viaje:
    • Consulta el servicio del clima para obtener información sobre el clima durante la estadía.
    • Consulta el servicio de transporte para descubrir los mejores trenes y autobuses.
    • Consulta el servicio de hoteles para descubrir los mejores hoteles (un buen compromiso entre precio y calidad).
    • Consulta el servicio de eventos del valle para organizar mi agenda durante mi estadía.
  9. Recibo tres propuestas. Puedo elegir una tal como está o puedo elegir una y cambiarla ligeramente.
  10. ¡Increíble! La propuesta principal es un poco más costosa, pero incluye un hotel que ofrece clases de cocina con un chef famoso. Mi esposa, que es aficionada a la buena cocina (lo cual fue descubierto por la analítica del SoE a partir de su perfil de Facebook), estará emocionada. Selecciono esta opción e ingreso mi información de pago.
  11. La aplicación utiliza el servicio de pago para finalizar el pedido y utiliza el servicio de BPM para iniciar el flujo de trabajo de la reservación. Ese flujo de trabajo interactúa de nuevo con los servicios de hoteles, transporte y eventos del valle para finalizar la reservación.
  12. Recibo un email de confirmación. Puedo realizar un seguimiento del estado de mi solicitud mediante la misma aplicación.
  13. La aplicación utiliza el servicio de MDM para salvar mis elecciones. Utilizará esta información en contrataciones futuras para mejorar mi experiencia (y la de otros), — por ejemplo, para refinar las tres principales propuestas o para notificarme solo sobre eventos en los que pueda estar interesado.

La Figura 10 muestra los componentes de la aplicación:

Figura 10. Aplicación del SoE de "Turismo en el Valle"
Diagram of the components of the SoE visualization manager application

Algunos de los componentes de la aplicación requieren de servicios de middleware que proporcionan proveedores de tecnología.

La Figura 11 muestra el modelo del CloudOE central inicial para el ejemplo:

Figura 11. CloudOE de "Turismo en el Valle"
Diagram of the initial Cloud operating environment for the Tourism in the Valley example
  • El Catálogo de Servicios contiene información sobre servicios, eventos e incentivos que serán descubiertos por búsquedas. Este servicio se basará finalmente en una base de datos de NoSQL con posibilidades de búsqueda de texto que es ofrecida por el CloudOE.
  • Debido a que las funciones de búsqueda de servicios, comparación y análisis de contexto están basadas en el análisis de grandes volúmenes de datos con y sin estructura, aprovechan la posibilidad de analítica de CloudOE.
  • El componente Person MDM para almacenar las preferencias de usuario necesita una función de MDM correspondiente en el CloudOE. También necesita interfaces para SoR de seguimiento de ventas y para un servicio de seguimiento de ubicación que utiliza la interfaz de GPS del teléfono inteligente del turista — para entender las tendencias generales en el movimiento turístico y las preferencias específicas por persona.
  • La gestión de identidad, la gestión de acceso y el inicio de sesión único (SSO) se utilizan para autenticar el usuario y proteger el acceso a datos de usuario confidenciales. Esta es una función de CloudOE que puede utilizar el Person MDM como un repositorio de ID.
  • La visualización inteligente de la analítica, — incluida la visualización geográfica mediante una aplicación como Google Maps, — necesita un servidor de aplicaciones de dispositivos múltiples para admitir la experiencia enriquecida del usuario en plataformas móviles y web.
  • Un motor de gestor de procesos empresariales es necesario para actuar como un gestor de transacciones empresariales y compensación para coordinar los SoR de reservaciones de transporte y de pagos que están involucrados.
  • Una posibilidad de gestión de normas empresariales se encuentra en el centro del motor de comparación de criterios múltiples. El uso de normas empresariales proporciona flexibilidad, lo que a su vez genera la flexibilidad en el análisis de los datos del contexto y de la contratación que son necesarios para soportar una experiencia enriquecida del cliente.
  • Un servidor de mensajería capaz de sostener mensajería de grado de internet que incluya dispositivos web y móviles es necesario para soportar el flujo de mensajes que es interno para el SoE y que ocurre entre el SoE y los SoR.

Algunos de estos servicios serán ofrecidos en algún lugar en el CloudOE por proveedores de tecnología que puedan proporcionar plataformas altamente escalables y altamente resistentes, y soluciones de middleware, y los servicios serán accesibles de forma remota a través de sus API. Además, el CloudOE es la interfaz para SoR externos (públicos, en internet o que residen en redes privadas a las que se debe acceder a través de recursos de VPN). Estos SoR (como el componente del motor de transporte) registran decisiones de usuario sobre el viaje e inician los procesos empresariales apropiados (como la facturación). La aplicación puede combinar la información en el catálogo de servicios y en el Person MDM con la ubicación del GPS. Después, por ejemplo, en la hora de la comida puede enviar al teléfono inteligente del usuario el menú de un restaurante cercano que sirva los platillos favoritos del usuario.


Conclusión

Con SoE, la tecnología de TI se está abriendo a una clase completamente nueva de posibilidades para empresas basadas en lo digital. Estas posibilidades encuentran una pareja natural en la infraestructura de nube, pero requieren de conceptos de nube para conseguir el nivel de implementación de CloudOE que exceda los servicios de IaaS a los que estamos acostumbrados actualmente.

Modelar implementaciones de SoE y CloudOE requiere de procesos completos que inician con las motivaciones de la contratación y llegan a la identificación de la infraestructura de PaaS que es necesaria para admitir la aplicación de SoE.

Reconocimientos

Gracias a Michael Bradley, Martin Gale, Moti Nisenson y Thalia Hooker por muchas de las ideas incluidas en este artículo. Gracias a Fabio Benedetti, SmartCloud Orchestrator Lead Architect, y a Donald Cronin, Cloud and Smarter Infrastructure CTO en IBM, por el valioso tiempo que invirtieron en la revisión y por las sugerencias que brindaron.

Recursos

Aprender

Comentar

  • Participe en la comunidad de developerWorks. Conéctese con otros usuarios de developerWorks mientras explora los blogs, foros, grupos y wikis destinados a desarrolladores.

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Cloud computing
ArticleID=960810
ArticleTitle=Diseñar un ecosistema de SoE para admitir experiencias de usuario enriquecidas
publish-date=10222013