Evaluación de empresas para determinar su capacidad para desarrollar servicios de negocios compuestos

Este artículo describe cómo se puede evaluar una empresa para que adopte arquitecturas que soporten Composite Business Services (CBS) y aplicaciones compuestas para solucionar problemas de negocios empresariales. Nos concentraremos en las cuatro dimensiones en las que se puede evaluar una empresa: el soporte existente para la arquitectura de negocios, la arquitectura de aplicación, la arquitectura de integración y la arquitectura tecnológica.

Introducción

En este artículo, discutimos los pasos que debe dar una empresa para planificar y desarrollar una estrategia de activación de CBS para realizar la transición desde las arquitecturas empresariales convencionales hacia las arquitecturas de referencia que soportan CBS. Además, también discutimos los métodos para analizar y evaluar la alineación de una arquitectura empresarial con las diferentes dimensiones de negocios, aplicación, integración y tecnología y sus parámetros clave relacionados. Esto nos ayudará a comprender a las empresas según su capacidad para construir soluciones con Composite Business Services (CBS) y para detectar las brechas existentes y cumplir con todos los requisitos de cada dimensión en la que se encuentra rezagada.

La mayoría de las organizaciones han estado automatizando cada vez más sus requisitos de procesos de negocios mediante su división en casos de uso de aplicación y la implementación de la funcionalidad como aplicaciones de TI según lo necesario y dentro de las limitaciones presupuestarias existentes. La mayoría de estas aplicaciones suelen crecer fortuitamente dentro de la empresa y, en algún punto, para intentar cumplir con los nuevos requisitos de procesos de negocios, estas aplicaciones requieren la integración con otras aplicaciones. Estas aplicaciones pueden ser tanto internas como aplicaciones asociadas. Esto ha creado una creciente demanda de tecnologías y productos de integración. Por lo tanto, muchos proveedores se están concentrando en este espacio y están realizando grandes esfuerzos para ser líderes de mercado en el dominio de Enterprise Application Integration (EAI). Por otra parte, otros diseños arquitectónicos empresariales diferentes como Zachman, TOGAF, TeA e IAF (por favor, vea la sección Recursos para mayor información) también están intentando eliminar la brecha existente entre las demandas de negocios y las soluciones de TI implementadas. Muchos de estos métodos arquitectónicos empresariales buscan implementar requisitos de procesos de negocios a través de la integración de estas aplicaciones. Esto nos lleva a una mayor concentración en los esfuerzos de integración y fracasa al momento de ofrecer un panorama claro de los procesos de negocios a nivel empresarial. La integración pasa a ser algo desafiante cuando estas aplicaciones sufren transformaciones para poder cumplir con los nuevos requisitos de negocios. Existen también demandas adicionales para que los proyectos ofrezcan soluciones con menores costos de desarrollo y un menor tiempo de entrega. El desarrollo impulsado por los negocios con SOA le ofrece una solución viable para este problema en la forma de una aplicación compuesta o de servicios de negocios compuestos. Un Composite Business Service (Servicio de negocios compuesto) es una colección de servicios de negocios que funcionan en conjunto, junto con las aplicaciones existentes del cliente, con el objetivo de ofrecer una solución de negocios específica. CBS hace que sea posible que un modelo de activos basado en la composición de activos distribuidos y de acoplamiento holgado pueda ofrecer soluciones reutilizables y flexibles. CBS también puede incluir aplicaciones legadas, paquetes de aplicaciones y servicios entregados a través de la red. La metodología de desarrollo, el diseño y la arquitectura de la solución Composite Business Services nos ayudan a crear servicios de negocios reutilizables que se encuentran a un nivel funcional superior y pueden cumplir con la promesa de las funciones del desarrollo impulsado por los negocios sin ninguna de codificación.

Para las empresas que ya adoptaron SOA, el paso hacia el desarrollo de aplicaciones compuestas mediante la adopción de modelos de contenidos industriales probados resulta muy fácil y rápido. Los modelos de contenidos industriales le ofrecen definiciones de servicios, modelos de datos probados y servicios comunes basados en estándares industriales y mejores prácticas. El único esfuerzo extra requerido consiste en realinear la arquitectura de negocios usando estos modelos reutilizables, reevaluar los servicios de negocios para el nivel adecuado de descomposición y granularidad y mejorar o modificar las características funcionales diferentes basándose en el rol o en el canal por medio del que se las invoca.

Si una empresa todavía no adoptó el desarrollo impulsado por los negocios y SOA y desea desarrollar aplicaciones compuestas, debe estudiar y evaluar las arquitecturas empresariales de la organización en su estado actual en la práctica para directamente migrar hacia las arquitecturas de referencia de CBS. La aplicación y las arquitecturas de datos junto con sus métodos de integración no resultan suficientes a raíz de la madurez de SOA de la empresa que suele estar seguida por los Modelos de Madurez de Integración de Servicios (SIMM). Además, también se debe considerar la evaluación del soporte empresarial para las funcionalidades de negocios y de las arquitecturas tecnológicas.


Métodos de evaluación de la arquitectura empresarial

Existen métodos cualitativos y cuantitativos probados para evaluar si las arquitecturas empresariales existen o no en la práctica. Los métodos cualitativos tratan de ayudarlo a determinar de qué forma la arquitectura empresarial se ocupará de los requisitos solicitados mediante el examen de las decisiones arquitectónicas tomadas durante el ciclo de diseño. Los resultados de esta clase de evaluación producen conclusiones cualitativas sobre los objetivos evaluados. Los métodos cuantitativos son enfoques más retrospectivos y se basan en mediciones cuantitativas que se llevan a cabo durante la fase de implementación. Los describimos a continuación:

Métodos cualitativos

La arquitectura de una solución se evalúa cualitativamente examinando el sistema con la ayuda de técnicas basadas en cuestionarios y listas de verificación. Estos métodos son más adecuados en una etapa temprana del ciclo de desarrollo de software (SDLC) antes de que se construyan los prototipos. Al método de evaluación cualitativa de la arquitectura también se lo puede denominar como métodos de evaluación predictiva. Luego de esto, intente anticipar la forma en la que la arquitectura se ocupará de los requisitos solicitados mediante el examen del diseño arquitectónico (decisiones) adoptado durante la primera etapa del SDLC. Los resultados de esta clase de evaluación producen conclusiones cualitativas sobre los objetivos evaluados. Métodos similares también se pueden aplicar sobre las arquitecturas de software empresarial en su estado actual mediante el análisis de enfoques basados en cuestionarios y listas de verificación sin ninguna medición cuantitativa.

Método basado en cuestionarios: Si los objetivos del sistema de software son fáciles de identificar y caracterizar, es posible definir una lista de preguntas que se pueden aplicar a la arquitectura general del sistema de software. Estas preguntas constituyen el cuestionario para evaluar la arquitectura y se pueden ocupar de aspectos diferentes de la definición de la arquitectura.

Métodos basados en listas de verificación: Este método es similar al que se basa en cuestionarios pero, generalmente, se concentra en calidades específicas de las que se debe ocupar la arquitectura. El método basado en listas de verificación requiere una práctica de evaluación más madura si lo comparamos con el método anterior.

Métodos cuantitativos

La arquitectura de una solución se evalúa cuantitativamente realizando algunos experimentos sobre el sistema existente. Estos métodos son enfoques más retrospectivos y se basan en mediciones cuantitativas que se realizan durante la fase de implementación. Los prototipos se crean en una etapa temprana del SDLC y se aplican mediciones cuantitativas sobre estos modelos. Luego, a partir de los resultados que se obtienen, se evalúa la arquitectura de manera cuantitativa.

Métodos basados en métricas: Este método es un análisis cuantitativo que se basa en la medición de los componentes de la arquitectura. El propósito de esta medición consiste en descubrir los lugares en los que existen problemas en la arquitectura general con el objetivo de realizar modificaciones para mejorar el diseño.

Métodos basados en pruebas de concepto (PoC): Éste es el caso cuando los prototipos que se usan para los experimentos y las simulaciones son artefactos que resultan del proceso de desarrollo. En este método, probamos una implementación considerando un caso de uso de aplicación compleja que representa un modelo de la arquitectura. Los resultados de este prototipo se usan para responder a algunas preguntas críticas relativas a la arquitectura antes de realizar el diseño y el desarrollo en una gran cantidad de casos de uso.

Podemos usar un enfoque cualitativo o un enfoque cualitativo y cuantitativo combinado para la evaluación de la arquitectura empresarial y de su adecuación para desarrollar aplicaciones compuestas basadas en la disponibilidad de tiempo y en el soporte que ofrece la organización para la evaluación. La figura 1 le muestra un enfoque de evaluación combinado claramente definido.

Figura 1. Enfoque del proceso de evaluación
Enfoque del proceso de evaluación

Disciplinas para CBS

Se diseña un proceso de evaluación para evaluar las arquitecturas empresariales con propósitos de alineación con las arquitecturas de referencia que son la base de CBS de IBM. Existen cuatro dimensiones que se detallan a continuación:

Arquitectura de negocios

Esta disciplina se ocupa de las preocupaciones de los usuarios, los planificadores y los gerentes de negocios y se concentra en los aspectos funcionales del sistema desde la perspectiva de los usuarios. Principalmente, se ocupa del rendimiento de negocios, la funcionalidad y la usabilidad. Cuenta con las siguientes subvistas (por favor, haga clic en el vínculo correspondiente de la sección Recursos para tener acceso a un vínculo hacia Open Group, desde donde se toma lo siguiente):

  • La vista People (Personas) se concentra en los aspectos de los recursos humanos del sistema. Además, también examina los actores humanos involucrados en el sistema.
  • La vista Business Process (Proceso de negocios) se ocupa de los procesos de los usuarios involucrados en el sistema.
  • La vista Business Function (Función de negocios) se ocupa de las funciones requeridas para soportar los procesos.
  • La vista Business Information (Información de negocios) se ocupa de la información requerida para permitir que fluya el soporte de los procesos.
  • La vista Usability (Usabilidad) considera los aspectos de usabilidad del sistema y su entorno.
  • La vista Business Performance (Rendimiento de negocios) considera los aspectos de rendimiento del sistema y su entorno.

Arquitectura de aplicación y de datos:

Esta disciplina describe las arquitecturas que abarcan tanto los datos como los dominios del sistema de la aplicación. Además, incluye inventarios, diagramas e interfaces del software de aplicación entre las aplicaciones (lo que incluye eventos, mensajes y flujos de datos). La arquitectura de datos incluye modelos de datos conceptuales, lógicos y físicos y sus modelos de metadatos.

Arquitectura de integración:

La arquitectura de integración describe varios aspectos de la integración en una empresa, entre los que podemos incluir la integración de personas, sistemas y bases de datos de manera interna y externa. Se toman en consideración diversos aspectos de la integración para el desarrollo de servicios de negocios compuestos eficientes y flexibles. Entre estas subvistas de integración, podemos incluir las siguientes:

  • La vista Access / presentation integration (Integración de presentación / acceso) se ocupa de las diversas formas de acceder a las funciones del sistema y del soporte de varios tipos de clientes (portal, móvil, intranet y dispositivos como los teléfonos, el correo electrónico, los PDA, etc.). Además, se ocupa de todo esto mediante llamadas a servicios web, portlets remotos de servicios web y llamadas a APIs de interacción creadas de manera personalizada.
  • La vista Application integration (Integración de aplicaciones) se ocupa de la integración de aplicaciones dentro de la organización, o con socios de negocios por medio de aplicaciones empresariales. Esto hace que las aplicaciones se puedan conectar entre sí con el objetivo de compartir y usar información para lograr un mejor uso a nivel empresarial.
  • La vista Information (data) integration (Integración de información [datos]) se ocupa de las diferentes formas de información de negocios que se pueden integrar en toda la empresa. La integración favorece la búsqueda, el acceso, la replicación, la transformación y el análisis coherente mediante una vista unificada de activos de información para así poder satisfacer todas las necesidades de negocios.
  • La vista process integration (Integración de procesos) se ocupa de los cambios en los negocios, cómo opera el negocio a través del modelado, la automatización y el monitoreo de procesos entre personas y sistema heterogéneos, tanto dentro como fuera de la empresa.

Arquitectura tecnológica

La arquitectura tecnológica es esencialmente la infraestructura que incluye los componentes de hardware y software. Esta arquitectura incluye los servidores de la empresa, los servidores de datos, los firewalls, la infraestructura de la aplicación, la seguridad, el monitoreo y el middleware. Además, también se describen los lenguajes de programación y los sistemas operativos que se usan en la empresa. Esta disciplina también evalúa cómo los componentes de software desarrollados han potenciado estándares técnicos abiertos.


¿Cómo evaluar la adecuación de la arquitectura empresarial para CBS?

El primer paso para evaluar la arquitectura empresarial consiste en completar una Solicitud de Información (RFI) que incluya las cuatro disciplinas que se mencionan con anterioridad. Se debería enviar esta solicitud al cliente. Luego de obtener la respuesta de la organización, se prepara una plantilla basada en una lista de verificación. Las respuestas se verifican usando esta plantilla. Los resultados finales de la plantilla evalúan cualitativamente la arquitectura existente en relación con la arquitectura de referencia de CBS y el desarrollo de los servicios de CBS. Si una organización se encuentra cualitativamente calificada para las cuatro disciplinas que se están evaluando, como un segundo paso para la evaluación cuantitativa, se le solicita a la organización que prepare una descripción para desarrollar un prototipo basado en varios escenarios. La descripción de cómo se debe diseñar el prototipo y cómo se lo debe desarrollar basándose en el escenario y en las mediciones a evaluar figura en la sección "Evaluación PoC basada en el escenario". La Figura 2 le muestra los enfoques cualitativos y cuantitativos con respecto a su alineación con CBS.

Figura 2. Iteración cualitativa y cuantitativa
Iteración cualitativa y cuantitativa

Alineación de la arquitectura de negocios

Una evaluación cualitativa puede comenzar desde el siguiente cuestionario. A las organizaciones se las evalúa basándose en el dominio de negocios o el área funcional en la que brinda soluciones. En primer lugar, los aspectos infraestructurales de una organización se analizan para soportar sus necesidades de negocios. A continuación, mencionamos algunos de los puntos importantes a tener en cuenta (por favor, lea el artículo titulado "Exploración de los sistemas de gestión de procesos de negocios y el impacto de BPM sobre los desarrolladores", que figura en la sección Recursos):

  • ¿Cuenta la organización con un Sistema de Gestión de Procesos de Negocios (BPMS) bien definido como para poder definir, actualizar, medir, analizar y mejorar de manera continua sus procesos de negocios?
  • ¿Cuenta la empresa con herramientas (como, por ejemplo, un modelador de procesos de negocios, un modelador de procesos ejecutables, un motor de ejecución de procesos, monitores de actividad de negocios, un portal de administración de procesos, etc.) que soporten la gestión del ciclo de vida completo del BPMS?
  • ¿Cuenta la organización con un Centro de Excelencia de BPM (BPM-COE) organizado para que se pongan en práctica los marcos, las herramientas y las metodologías necesarias para transformar de manera eficiente los requisitos de negocios en un sistema de TI?
  • ¿Cuenta la organización con gobernabilidad de procesos, lo que la ayuda a garantizar que las órdenes corporativas se cumplan a nivel operacional?

La sección de requisitos de negocios en una RFI debe incluir las sub-funcionalidades de negocios predefinidas en el dominio de negocios en el que opera la empresa. Tomemos como ejemplo un portal de autoservicio bancario. Entre sus sub-funcionalidades, podemos incluir las siguientes: la apertura de cuentas, la visualización de cuentas, las solicitudes de servicio para PIN duplicado de cajero automático o chequera, el pago de facturas, la transferencia de fondos y los servicios de tarjetas de crédito. La organización debe presentar sus soluciones de negocios en relación con estas sub-funcionalidades. A partir de la respuesta a la RFI que se obtuvo de la empresa, se consideran los siguientes puntos para la alineación de negocios de la organización:

  • ¿Cuántas sub-funcionalidades de negocios soporta la organización hoy en día?
  • ¿Cuántas sub-funcionalidades de negocios se deben modificar basándose en las funcionalidades predefinidas?
  • ¿Cuántas sub-funcionalidades de negocios se deben desarrollar desde cero?
  • ¿Cuántas de las sub-funcionalidades de negocios que existen hoy en día no cuentan con el soporte requerido, pero existe un mapa de ruta claro para que se soporten dichos servicios en un margen de tiempo estipulado?

La sección de evaluación de la arquitectura de negocios también incluye un cuestionario sobre el cumplimiento de las sub-funcionalidades de negocios con los modelos de procesos de negocios y los servicios de negocios. Considere los siguientes puntos al evaluar el cumplimiento de los servicios de negocios.

  • ¿La organización adopta algún modelo de proceso de negocios específico a la industria?
  • ¿La organización usa sus propios modelos personalizados? De ser así, ¿qué tan flexibles son estos modelos personalizados al momento de absorber los cambios en los requisitos de negocios?
  • ¿Los servicios de negocios de la organización soportan los modelos de datos específicos a la industria (como, por ejemplo, ACCORD, HiPAA y SWIFT) para intercambiar datos entre otros servicios?
  • ¿La organización usa algún método o técnica estándar para identificar los servicios de negocios (como, por ejemplo, RUP para SOA, SOMA, etc.)?
  • ¿Los servicios de negocios que se usan ofrecen un comportamiento flexible y adaptable basado en la política de negocios y en el contexto del usuario?
  • ¿Los servicios de negocios se materializan a través de múltiples canales de comunicación?
  • ¿El servicio de negocios se materializa desde sistemas de TI dispares? De ser así, ¿es desde un formato Silo, es integrado o es a través de la integración de un proceso componentizado?

Todas las respuestas del cuestionario anterior se estudian y analizan según su alineación con el desarrollo de servicios CBS y, finalmente, se prepara un cuadro de evaluación cualitativa para compararlo con esta sección.


Alineación de la arquitectura de datos y aplicación

En esta sección, analizaremos cómo se evalúan las arquitecturas de datos y aplicación de una organización para descubrir su alineación con las arquitecturas de referencia de CBS. La madurez arquitectónica general de la aplicación se puede evaluar desde diversos puntos de vista (como, por ejemplo, su cercanía a las arquitecturas de referencia de CBS, los socios de negocios electrónicos de IBM, los patrones arquitectónicos de la aplicación empresarial y el desarrollo con herramientas de arquitecturas impulsadas por modelos). Esta sección evalúa estrictamente los principios arquitectónicos, como el acoplamiento holgado entre niveles, los patrones MVC que se usan, los conceptos en niveles que se practican y las capacidades de escalación de la aplicación. Los niveles arquitectónicos clave desde sus arquitecturas de aplicación y los puntos de evaluación clave (por favor, haga clic en el vínculo que lo llevará hacia el artículo titulado "Evaluación de la Arquitectura Orientada a Servicios" en la sección Recursos) incluyen lo siguiente:

  • Nivel de presentación y canales
  • Nivel de coreografía y procesos de negocios
  • Servicios o funciones expuestas
  • Reglas de negocios
  • Nivel de registro de servicios
  • Datos y nivel de acceso a datos

Las siguientes secciones le ofrecen detalles sobre cada uno de estos temas.

Nivel de presentación y canales:

La arquitectura de la aplicación o el sistema se evalúa según cómo se relaciona con los niveles de presentación y canales. La aplicación compuesta debe atender a varios clientes desde un entorno de hosting común y compartido. El nivel de presentación y canales se evalúa desde los siguientes puntos:

  • El nivel de presentación debería soportar marcos de estándares abiertos (como, por ejemplo, STRUTS, JSF y Dot Net UI) y debe ser fácil de extender o modificar con el objetivo de crear marcos personalizados del nivel de presentación.
  • El nivel de presentación también debería ser lo suficientemente flexible como para que se puedan agregar canales nuevos (como, por ejemplo, clientes PDA, formularios y correo electrónico, etc.).
  • Si la organización está usando algún tipo de marco exclusivo, se debería evaluar su asociación con los marcos de código abierto.
  • Verifique la existencia de invocaciones sin encabezado de funciones del sistema a través de interfaces de servicios web.
  • Verifique si el nivel de presentación está acoplado holgadamente con el sistema / la aplicación actual o no.
  • ¿Cuáles son todos los tipos diferentes de dispositivos físicos / canales que soporta el sistema? ¿Qué tan flexible es el sistema existente al momento de agregar un dispositivo físico nuevo?

Nivel de coreografía y procesos de negocios:

La arquitectura de la aplicación se evalúa con respecto a la función de coreografía y procesos de negocios. Se debería analizar la organización y determinar si adopta algún nivel de procesos de negocios y motor de tiempo de ejecución para la orquestación de sus funciones de aplicación / servicios de negocios. Los siguientes puntos evalúan este nivel arquitectónico:

  • Si se usa algún nivel exclusivo de flujo de trabajo o flujo de procesos, verifique si cumple con los estándares BPEL realizando la migración hacia motores de tiempo de ejecución y herramientas de diseño BPEL externas. Identifique los pasos y los procedimientos que se deben implementar para ejecutar estos flujos de trabajo exclusivos en motores de tiempo de ejecución de estándares abiertos.
  • ¿La organización tiene alguna herramienta de modelado de procesos de negocios que genera código de tiempo de ejecución automáticamente para su implementación?
  • Verifique cómo se implementa el motor de tiempo de ejecución que cumple con BPEL como un producto completo y escalable con compensación, manipulación de excepciones técnicas y de negocios y métricas de negocios y funciones de monitoreo de volúmenes de transacción.
  • Verifique si los flujos de proceso actuales soportan la invocación de tareas humanas, selectores, reglas de negocios y ESB.
  • Observe cómo se implementan la interacción del servicio y los flujos de proceso BPEL. ¿Están acoplados holgada o estrechamente y se puede exponer el proceso BPEL en sí mismo como un servicio con estándares abiertos?

Servicios o funciones expuestas:

Aquí, aprenderemos a evaluar la arquitectura del sistema / la aplicación a medida que se relaciona con servicios o funciones expuestas como interfaces y APIs. El nivel de madurez de los servicios se determina a partir de los siguientes puntos:

  • ¿Cómo se puede acceder a los servicios? ¿Se accede por medio de estándares técnicos abiertos como servicios web o interfaces SCA?
  • ¿Cómo se implementan los servicios con sistemas subyacentes? ¿Están holgada o estrechamente acoplados?
  • ¿Los servicios iniciales de la organización cumplen con todos los estándares industriales aplicables (como, por ejemplo, ACCORD e HiPAA) para acceder a los datos empresariales y compartirlos?
  • ¿Los servicios se implementan con el nivel adecuado de descomposición y granularidad?
  • ¿Los servicios soportan la invocación tanto sincrónica como asíncrona?
  • ¿Los servicios soportan la administración de excepciones y la recuperación ante fallas?
  • ¿Los servicios soportan la autenticación y la autorización?
  • ¿Los servicios pueden realizar publicaciones en registros tanto en el tiempoo de diseño como en el tiempo de ejecución?
  • ¿El control de versiones del servicio se soporta tanto en el tiempo de diseño como en el tiempo de ejecución?
  • ¿Cómo están organizados los servicios técnicos y cómo los servicios de aplicación o los servicios de negocios interactúan a lo largo de estos servicios técnicos al momento de materializar las transacciones de negocios?

Reglas de negocios:

Esta sección evalúa la arquitectura de una aplicación a medida que se relaciona con las reglas de negocios. ¿Cómo se implementan las reglas de negocios? ¿Están estrechamente acopladas al sistema y no se pueden externalizar? Aunque algunas implementaciones están holgadamente acopladas, tampoco se las puede externalizar y es necesario realizar modificaciones a nivel del código para cambiar la regla. Algunas implementaciones están holgadamente acopladas y usted las podrá externalizar, pero siempre use un motor de reglas exclusivo o un marco de programación exclusivo. Algunas reglas de negocios están holgadamente acopladas y se las puede externalizar. Su modelo de programación cumple con estándares al estilo de JSR94 y las reglas se pueden modificar fácilmente con requisitos de negocios. Los siguientes puntos evalúan la tenacidad de las reglas de negocios adoptadas en la arquitectura de la solución:

  • ¿Cómo está construido el motor de reglas (EJBs o clases Java planas)? ¿Se lo implementa como un producto completo y escalable con capacidad de edición online y soporte de gestión del ciclo de vida completo?
  • ¿El motor de reglas existente permite que un motor de reglas de un tercero se conecte para agregar reglas nuevas o transferir las reglas existentes al motor del tercero?
  • Verifique si se puede exponer este componente de regla como un servicio web o un servicio SCA, ya sea para orquestar desde flujos de proceso BPEL externos o para realizar llamadas desde los clientes de terceros.

Nivel de registro de servicios:

Un registro de servicios le ofrece la capacidad de registrar servicios, gestionar metadatos y automatizar servicios. Este nivel se evalúa basándose en las respuestas obtenidas del siguiente cuestionario:

  • ¿Se está usando un registro? Si no se está usando ninguno, ¿cómo hacen todas las partes que usan servicios compartidos para conocer la disponibilidad y la capacidad de los servicios? ¿Cómo se actualiza la información del servicio para evitar la duplicación innecesaria?
  • ¿Qué políticas se implementaron para garantizar el uso adecuado de los registros?
  • ¿Cómo se definen y gestionan los metadatos del servicio tanto dentro como fuera del registro? ¿Las consideraciones a largo plazo en relación con las posibles necesidades se incluyen en el cálculo que se usa para realizar el diseño?
  • ¿Para qué fases del ciclo de vida de la aplicación SOA (inicio a través del retiro de servicio) se está usando el registro?
  • ¿Cómo se controlan los controles de acceso al servicio y las políticas de gestión de cambios? ¿Se implementaron controles adecuados para equilibrar la seguridad, la capacidad de modificación y el cumplimiento con la TI y otros estándares?
  • ¿Se está usando el registro para el ruteo dinámico de las llamadas de servicio (por ejemplo, para el particionamiento de aplicaciones, el balanceo de carga y la conmutación por error)? En caso afirmativo, ¿la instalación del registro es donde se presenta la falla? ¿Se cumple con todos los requisitos de rendimiento y tiempo de conmutación por error?
  • ¿El registro es público o privado? ¿La implementación del registro administra de manera adecuada la diferenciación de los servicios internos y los servicios externos?

Datos y nivel de acceso a datos:

Esta sección le explica la arquitectura de la aplicación a medida que se relaciona con los datos y el acceso a los datos. Los siguientes puntos se toman en consideración al momento de evaluar esta sección:

  • ¿Qué tan robusto y flexible es el modelo de datos? ¿Se cumple con estándares industriales maduros? ¿Es posible agregar elementos de datos nuevos fácilmente?
  • ¿Con qué se implementa el nivel de acceso a datos? ¿Está acoplado estrechamente y usa marcos exclusivos? ¿Está acoplado holgadamente y cumple con todos los marcos maduros aplicables (como, por ejemplo, los objetos de datos de servicio de código abierto)?
  • ¿La organización potencia el uso de herramientas de mapeo de la relación con el objeto (como, por ejemplo, toplink, hibernate o iBatis)?
  • Si un repositorio de datos se distribuye en toda la empresa, ¿qué tipo de mecanismo se usa para acceder a la aplicación?
  • Para soportar "Information As a Service" (Información como un servicio), ¿qué tipos de herramientas o productos la organización debe potenciar?
  • ¿Cómo la arquitectura de datos empresariales nos ayuda a procesar la transformación de datos transaccionales en datos analíticos con una menor latencia de datos?
  • ¿Cómo la arquitectura de datos empresariales nos ayuda con el procesamiento analítico de datos para brindar información a los usuarios de negocios en el momento que lo soliciten?

Alineación de la arquitectura de integración

Esta sección evalúa la arquitectura de aplicación a medida que se relaciona con la integración de las aplicaciones, los componentes y los servicios (incluyendo a los terceros y a los sistemas legados). Los siguientes puntos se toman en consideración al momento de evaluar la madurez del nivel de integración.

Las preguntas de evaluación de muestra que se deben formular sobre el nivel de integración son las siguientes:

  • ¿Qué tan robusto es el nivel de integración? ¿Se lo está implementando como un producto completo y escalable? ¿Se lo está implementando con una API de código abierto o con conectores y adaptadores según lo que sea necesario?
  • ¿Cuáles son los patrones arquitectónicos de integración soportados? ¿Se usará ESB, el sistema radial de integración o el protocolo punto a punto?
  • ¿Cuáles son las funcionalidades que soporta el nivel de integración (como, por ejemplo, el ruteo de mensajes, la transformación de formatos de datos y la puerta de enlace de seguridad centralizada para todos los servicios)? ¿Se soportará la agregación de mensajes y el modelo de mensaje de publicación y subscripción?
  • ¿Qué tan estrecha u holgadamente está acoplado el nivel de integración desde el resto del sistema o la aplicación?
  • ¿Cuáles son los tipos diferentes de especificaciones / estándares / marcos de integración que la organización soporta en la actualidad? Por ejemplo, ¿soporta RPC, RMI, SOAP/JMS, SOAP/HTTP?
  • ¿El nivel de integración soporta funcionalidades auxiliares (como, por ejemplo, la administración de excepciones, la gestión de eventos, la auditoría y el registro y el soporte para el control de acceso)?
  • ¿La arquitectura de aplicación que se usa en la actualidad le ofrece la capacidad de introducir este nivel de integración entre niveles que tengan soluciones maduras con arquitecturas de integración?

Nosotros capturamos información de manera exclusiva sobre cómo la integración de la aplicación legada se lleva a cabo en la organización mediante la obtención de más información sobre los siguientes puntos:

  • ¿Qué mecanismos se adoptaron para la integración de los sistemas nuevos y legados? Los que nosotros buscamos incluyen pantalla-raspadores, llamadas a servicios web, ESB con adaptadores por una plataforma legada, sistemas de mensajería, llamadas directas a la API de software legado y puertas de enlace y puentes específicos a la tecnología.
  • ¿Cómo se comparó el mecanismo seleccionado en términos de complejidad y costos de implementación?
  • ¿El mecanismo seleccionado cumplió con el rendimiento del sistema en lo que se refiere a la cantidad de llamadas esperadas y los tiempos de respuesta deseados?
  • ¿Se cumplieron todos los requisitos de seguridad (como, por ejemplo, el control de acceso y la privacidad de los datos) tanto en los sistemas legados como en los demás sistemas ya existentes?

Alineamiento de la arquitectura tecnológica

Analicemos la infraestructura de software y cómo piensa brindar soporte para la implementación de aplicaciones centrales y críticas para la misión. Esta categoría incluye a los servidores empresariales, los servidores de aplicación, los servidores de proceso, los servidores de base de datos, los servidores de seguridad, los servidores de notificación y sus configuraciones de implementación. La evaluación de la arquitectura tecnológica abarca los siguientes temas.

  • Servicios de infraestructura
  • Arquitectura de seguridad
  • Servicios de soporte y gestión de sistema
  • Estándares técnicos abiertos
  • Modelo operacional o arquitectura de implementación
  • Rendimiento
  • Otros NFRs (disponibilidad y confiabilidad)
  • ¿La arquitectura de aplicación que se usa en la actualidad le ofrece una forma de introducir este nivel de integración entre niveles que tengan soluciones maduras con arquitecturas de integración?

De manera exclusiva, nosotros capturamos información sobre cómo se está llevando a cabo la integración de la aplicación legacy en la organización mediante la obtención de más información sobre todo lo siguiente:

  • ¿Qué mecanismos se adoptaron para la integración de los sistemas nuevos y legados? Los que nosotros buscamos incluyen pantalla-raspadores, llamadas a servicios web, ESB con adaptadores por una plataforma legada, sistemas de mensajería, llamadas directas a la API de software legado y puertas de enlace y puentes específicos a la tecnología.
  • ¿Cómo se comparó el mecanismo seleccionado en términos de complejidad y costos de implementación?
  • ¿El mecanismo seleccionado cumplió con el rendimiento del sistema en lo que se refiere a la cantidad de llamadas esperadas y los tiempos de respuesta deseados?
  • ¿Se cumplieron todos los requisitos de seguridad (como, por ejemplo, el control de acceso y la privacidad de los datos) tanto en los sistemas legados como en los demás sistemas ya existentes?

Servicios de infraestructura:

En esta sección, analizamos varios componentes infraestructurales (por favor, haga clic en el vínculo que lo direccionará hacia el artículo titulado "Guía para practicantes de SOA - Parte 2: Arquitectura de referencia de SOA" en la sección Recursos) requeridos para la reutilización para el desarrollo de aplicaciones o para la reutilización a nivel empresarial. Si se pueden volver a usar estos servicios en todos los niveles de la empresa, esto demuestra que la organización es consistente y cuenta con un enfoque uniforme para la creación de soluciones con servicios probados. Resulta fácil decidir si la organización es o no capaz de cumplir con los acuerdos de nivel de servicio con los datos históricos disponibles con las soluciones que se crearon con anterioridad con dichos servicios. La evaluación se realiza basándose en los diversos servicios disponibles en la organización. Para determinar cuál es la mejor forma de configurar los servicios de infraestructura, tomamos todo lo siguiente en consideración:

  • ¿Cuáles son los servicios / componentes comunes disponibles en la organización para desarrollar aplicaciones personalizadas / aplicaciones empaquetadas? Estos servicios pueden incluir servicios de datos, servicios de registro, servicios de administración de fallas y servicios de gestión de sesión, auditoría, búsqueda y notificación.
  • ¿Cuáles son los diferentes tipos de servicios de portal disponibles para permitir la reutilización y dar una impresión consistente? Estos servicios incluyen los de personalización, información, localización y monitoreo del tráfico Web.
  • ¿Cuáles son los diferentes tipos de servicios infraestructurales empresariales disponibles? En este caso, nos interesarían cosas como LDAP, el correo electrónico y la colaboración (chat / IM / pizarra virtual) y la gestión de contenidos.
  • ¿Cuáles son todos los diferentes tipos de servicios de gestión de datos maestros disponibles? En esta categoría, podemos incluir los servicios de integración de datos del cliente y el maestro de productos.

Arquitectura de seguridad:

Es muy importante comprender el modelo de seguridad actual, los roles de los usuarios, los permisos y las capacidades de la aplicación. Los siguientes puntos lo ayudarán a evaluar la madurez de la arquitectura de seguridad:

  • ¿Cuáles son los diferentes servicios de seguridad de TI implementados en la organización?
  • Identifique si la seguridad de TI se puede implementar o no en todos los niveles de la aplicación.
  • ¿Qué tan fácil resulta modificar y actualizar la arquitectura de seguridad?
  • Descubra si la arquitectura de seguridad se implementó con posicionamiento de firewall de protocolo, firewall de dominio y firewall empresarial.
  • ¿La aplicación soporta el inicio de sesión único (SSO)? ¿El SSO se usa tanto a nivel de la aplicación como a nivel de los servicios web?
  • ¿La organización implementó marcos de gestión de políticas de seguridad?

Servicios de soporte y gestión de sistema:

En esta sección, evaluaremos la arquitectura de la aplicación a medida que se relaciona con los servicios de soporte y gestión de sistema. Algunas arquitecturas de aplicación no soportan ningún servicio de gestión de sistema. Algunas aplicaciones tienen una buena arquitectura y fueron diseñadas con gestión de aplicación / soporte del servicio de ciclo de vida completo (como en el caso de la gobernabilidad, el acceso, la autorización y el monitoreo).

  • Verifique si se implementaron los servicios de gestión y monitoreo del sistema con estándares abiertos y APIs (como, por ejemplo, JMX y APIs SNMP abiertas).
  • Verifique si todos estos servicios de gestión o productos de estándares abiertos usados cumplen con los requisitos de monitorear los indicadores clave de rendimiento de TI y de negocios?
  • Descubra si el monitoreo de datos está ayudando al arquitecto de gestión a poner a punto la infraestructura y al analista de negocios a redefinir los procesos de negocios optimizados.

Arquitectura de implementación:

En esta sección, analizamos varios servidores de middleware involucrados en brindar soporte a las soluciones implementadas con las arquitecturas de aplicación especificadas. Generalmente, la organización presenta un modelo de implementación detallado de la solución.

  • Verifique si se usó algún patrón arquitectónico de implementación de negocios electrónicos estándar para congelar su arquitectura topológica.
  • Realice la verificación en el modelo operacional o en la arquitectura topológica del sistema que muestra nodos de hardware y versiones de componentes de software que se ejecutarían en los nodos en un entorno de producción típico. Verifique si el modelo está completo, es claro y le ofrece información detallada sobre las zonas, el hardware, el software y las especificaciones o los detalles de conexión.
  • Observe los demás aspectos (como, por ejemplo, si la solución está virtualizada o no) y, si la cuadrícula de la solución le permite sacar provecho del clustering y del balanceo de carga de trabajo.

Rendimiento:

Evalúe el rendimiento de la aplicación observando los resultados de las métricas de rendimiento provistas por la organización para los casos de uso simples, medios y complejos. Obtenga la información relativa a la escalabilidad del sistema (es decir, la cantidad de usuarios y la cantidad de transacciones con configuraciones de hardware soportadas). La mayoría de las organizaciones no tienen el grado de madurez necesario como para ofrecer los estándares de comparación de rendimiento a nivel del servicio. Insista sobre las métricas de rendimiento de nivel de servicio que lo ayudan a predecir los tiempos de respuesta de extremo a extremo y la planificación de la capacidad de los servidores cuando se crea la aplicación compuesta. Tenga en cuenta todos los demás aspectos:

  • ¿La organización cuenta con algún componente o producto de marco de software que mejore el rendimiento de la solución en lo que se refiere al tiempo de respuesta transaccional y a la capacidad de procesamiento?
  • ¿Cuenta la organización con herramientas de modelado de rendimiento y planificación de capacidad? ¿La solución actual toma en consideración un plan de crecimiento de carga de trabajo de usuario para los próximos 2-3 años?
  • Durante el proceso del Ciclo de vida de desarrollo de software de la etapa de la solución, ¿deseamos ver si se aplicaron o implementaron herramientas / metodologías de ciclo de vida de ingeniería de rendimiento?

Otros requisitos no funcionales (disponibilidad y confiabilidad):

Verifique la disponibilidad del sistema en condiciones críticas como las siguientes:

  • Cuando se hackea el sistema con mensajes no autorizados y sin formato.
  • Cuando el sistema está sobrecargado.
  • Durante los períodos de mantenimiento.
  • Durante los cambios de la versión de software.

Verifique la confiabilidad del sistema en casos de fallas y recuperaciones para:

  • Conocer el estado del proceso transaccional.
  • Conservar los mismos datos luego de la recuperación.

El cuestionario que figura con anterioridad en cada disciplina lo ayuda a evaluar la arquitectura empresarial con atributos cualitativos (como, por ejemplo, para determinar si el alineamiento con las arquitecturas de referencia IBM CBS es bajo, medio o alto).

Para lograr una mejor comprensión de los conceptos de una evaluación cuantitativa para el alineamiento de las arquitecturas CBS, una evaluación PoC basada en un escenario de muestra en la disciplina de arquitectura de aplicación se discute a continuación.


Método de evaluación PoC basada en un escenario

Deberíamos evaluar las disciplinas arquitectónicas que se mencionaron con anterioridad de manera cuantitativa mediante la creación de PoCs basadas en un escenario. La arquitectura de negocios se evalúa generando casos de prueba funcionales según las funcionalidades definidas por la empresa. Estos casos de prueba se ejecutan en la solución implementada y se los verifica con las características funcionales comprometidas. La evaluación cuantitativa se realiza basándose en la cantidad de casos de prueba usados durante la prueba funcional. Se usan evaluaciones cuantitativas similares para las secciones arquitectónicas de información, integración y tecnología basándose en un escenario de evaluación. Por ejemplo, consideramos un escenario típico desde una disciplina de arquitectura de aplicación en la que se evalúa una organización durante la fase de transformación arquitectónica en arquitecturas de referencia de CBS.

Escenario:
¿Los componentes y los servicios de aplicación existentes pueden consumirse directamente para el desarrollo de una aplicación compuesta?

La evaluación cuantitativa se realiza basándose en el siguiente conjunto de puntos predefinidos. Cada aseveración se define de forma tal que cuenta con un nivel discreto de distinción de su alineamiento ideal. Observe los puntos de datos que figuran en orden descendente y que se desvían del alineamiento con el servicio de CBS y, por lo tanto, el puntaje de la evaluación en comparación con cada punto se reduce gradualmente.

  1. La organización tiene servicios / componentes que se exponen directamente como servicios web y que se consumen desde el proceso BPEL. Estos servicios se publican en UDDI o en algún otro registro equivalente (puntaje: 100%).
  2. La organización tiene servicios / componentes que se exponen directamente como servicios web y que se consumen desde el proceso BPEL. Pero estos servicios no se publican en UDDI o en algún otro registro equivalente (puntaje: 75%).
  3. La organización tiene servicios / componentes que se exponen indirectamente como servicios web a través de un componente de marco arquitectónico (servicio de puerta de enlace) pero que se pueden consumir por medio del proceso BPEL (puntaje: 50%).
  4. La organización tiene servicios / componentes que se exponen como servicios web pero no pueden realizar llamadas desde clientes externos debido a que falta una especificación URL de enlace de dirección SOAP a causa del no cumplimiento con WSDL (puntaje: 25%).
  5. La organización tiene un servicio / componente que se implementó y expuso como una interfaz EJB (puntaje: 0%).

De acuerdo con este escenario, se crea una PoC pequeña con WebSphere Integration Developer importando un servicio web en su entorno de montaje y se lo invoca a través de un proceso BPEL construido con búsqueda directa e indirecta de URL de punto final (por medio de UDDI) para un servicio web. Si el servicio web es del tipo especificado en la condición 4, no se podrá permitir que este tipo de WSDL realice una importación en el WID. Basándose en estas observaciones y ejecuciones de la PoC, se realiza la evaluación cuantitativa para este escenario. También se crean modelos de PoC similares basándose en escenarios en las disciplinas de arquitectura tecnológica y de integración y sus arquitecturas se evalúan cuantitativamente en su estado original.


Conclusión

En este artículo, analizamos la arquitectura empresarial a través de la respuesta RFI que obtuvimos de una organización. Se realizan evaluaciones cualitativas preliminares sobre sus negocios, aplicación y datos, alineamientos de la arquitectura tecnológica y de integración con respecto a las arquitecturas de referencia de la solución CBS basándose en los puntos que se presentaron en las secciones anteriores. Como las evaluaciones se realizan en base a información provista por la empresa, se la evalúa cuantitativamente mediante la realización de una PoC en el lugar y, por lo tanto, usted será capaz de determinar el estado de la empresa en lo que hace a su capacidad para potenciar los activos existentes que se puedan relacionar con los servicios de negocios compuestos. El informe de evaluación PoC final explica las brechas que la organización debe eliminar y prosigue con la creación de los servicios de negocios compuestos. Si una organización no está suficientemente alineada con los requisitos de las soluciones CBS, es necesario preparar una estrategia de activación y entregársela a la organización.

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

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=SOA y servicios web
ArticleID=486924
ArticleTitle=Evaluación de empresas para determinar su capacidad para desarrollar servicios de negocios compuestos
publish-date=08082011