Tarea: Análisis de activos existentes
Esta tarea identifica los elementos de diseño de una solución orientada a servicios desde el punto de vista de los servicios y las particiones, y documenta la especificación inicial de dichos servicios.
Objetivo
  • Identificar los elementos de diseño de una solución orientada a servicios desde el punto de vista de los servicios y las particiones.
  • Documentar la especificación inicial de servicios.
  • Determina las dependencias iniciales y la comunicación entre servicios.
Relaciones
RolesPrincipal: Adicional: Asistencia:
EntradasObligatoria: Opcional: Externa:
  • Ninguno
Salidas
Descripción principal
El análisis de activos existentes es el proceso de aprovechamiento de los activos existentes (por ejemplo, sistemas existentes como aplicaciones empaquetadas o personalizadas), así como de los estándares del sector, los modelos y los activos para conseguir la ejecución de los servicios. Con un enfoque de arriba a abajo, el análisis de activos existentes identifica y valida servicios candidatos, componentes y flujos. Las limitaciones técnicas relacionadas con los sistemas existentes deberían evaluarse tan pronto como sea posible, con el fin de gestionar los riesgos. Esto conduce a que la viabilidad técnica de las decisiones de realización de servicio se ejecute a menudo tan pronto como sea posible después o durante el análisis de activos existentes.
Pasos
Identificar servicios candidatos a partir de aplicaciones personalizadas

Para identificar la funcionalidad suministrada por las aplicaciones existentes se utilizan dos subpasos. El primer subpaso, la correlación sin detallar, correlaciona procesos empresariales con la cartera de aplicaciones existentes. El segundo subpaso, la correlación detallada, entraña la correlación de un servicio con una transacción o un proceso por lotes específicos dentro de la aplicación existente. La correlación detallada se realiza durante la especificación de servicio.

El objetivo de la correlación sin detallar es ofrecer la correlación preliminar, por ejemplo inicial, de las funciones empresariales con los servicios.

Para identificar servicios candidatos a partir de la funcionalidad en aplicaciones existentes, debe entenderse la relación entre aplicaciones de proceso empresarial y existentes. Esto se puede describir como correlación sin detallar. Esta correlación se produce entre las actividades o los procesos empresariales y las funciones empresariales de aplicaciones existentes, tal como se muestra a continuación.

Para capturar las relaciones entre procesos empresariales y aplicaciones existentes, realizamos los siguientes pasos de correlación sin detallar:

  1. Entender las funciones empresariales a las que da soporte cada aplicación.  Normalmente una función empresarial se puede correlacionar con una actividad de un proceso empresarial.
  2. Registrar atributos de aplicaciones existentes desde el punto de vista de las tecnologías utilizadas, los estilos de arquitectura, etc.
  3. Identificar aplicaciones que realizan servicios comunes.

Correlación sin detallar y análisis de la cartera de aplicaciones

Comprender el valor empresarial y la calidad técnica de las aplicaciones existentes ayuda en la creación de un plan transformativo que de prioridad a los servicios de valor más alto, y para valorar los riesgos técnicos y de ámbito de las calidades técnicas de la aplicación, por ejemplo, el grado de acoplamiento.

El análisis de la cartera de aplicaciones ofrece un ámbito y unos límites a la correlación sin detallar. Por ejemplo, las aplicaciones con mínimo valor empresarial o poco valor técnico que estén destinadas a caer en desuso probablemente no estén en el ámbito de la identificación de servicios candidatos.

El análisis de la cartera de aplicaciones, si se realiza, puede proporcionar información acerca de los servicios existentes para la correlación sin detallar. Los resultados de este análisis son los servicios candidatos que se muestran a continuación.

Identificar servicios candidatos a partir de aplicaciones empaquetadas

Los paquetes de proveedores de software independientes (ISV) se implementan normalmente para permitir subsistemas y/o componentes de servicio dentro de una organización. Por ejemplo, los paquetes ISV de planificación de recursos empresariales, caso de los ofrecidos por SAP, PeopleSoft y Oracle, a menudo se implementan como sistemas completos que incluyen varios subsistemas que dan total soporte a uno o más dominios de una organización. En esta sección se describen una serie de pasos que permitirán al especialista identificar funcionalidad y servicios candidatos de paquetes ISV existentes.Este análisis permitirá que se llenen la matriz función/sistema empresarial, el catálogo de reglas empresariales y productos de trabajo del modelo de servicio según las funciones de los paquetes de ISV existentes.

Nota: Como cada paquete de ISV es diferente, no se puede desarrollar un enfoque prescriptivo detallado para cada uno de ellos. Las siguientes actividades describen un enfoque genérico y un conjunto general de actividades que sirven para:

  • Identificar servicios candidatos dentro de paquetes de ISV.
  • Identificar las características de alto nivel de los paquetes de ISV que se tendrán en cuenta durante la realización de servicio.

Identificación de paquetes de ISV

De forma ideal, los paquetes de ISV de los dominios y componentes empresariales del ámbito deberían identificarse en la entrada Preformato de sistema CBM a componente empresarial (o equivalente). Esto produciría una lista de paquetes de ISV que permitirían la funcionalidad dentro de los componentes empresariales específicas en el ámbito de la solución prevista. Si falta esta entrada, los paquetes de ISV que den soporte a los componentes empresariales y dominios del ámbito deberán identificarse y correlacionarse con los componentes empresariales.

Tenga en cuenta que algunos paquetes de ISV, caso de SAP, PeopleSoft y Oracle se componen de un gran número de módulos centrales y opcionales. Por ejemplo, SAP tiene un módulo de fabricación , un módulo de recursos humanos y un módulo de gestión de relaciones con los clientes. En estos casos, es importante especificar qué módulos específicos de los paquetes de ISV se van a utilizar. Esto producirá un análisis más centrado que ahorrará tiempo y evitará la proliferación de servicios innecesarios.

Categorización de paquetes de ISV

La categorización de paquetes de ISV proporciona un conocimiento de alto nivel de las características importantes que deberán tenerse en cuenta durante la realización de servicio (esto se aplica a componentes funcionales y técnicos). Los ISV se pueden categorizar como ISV de nivel 1, 2 o 3 según características tales como sus competencias centrales, su tamaño y sus ingresos, tal como se resume en la tabla 10. Observe en particular los aspectos Impacto técnico e Impacto empresarial.

Categoría de ISV ISV de nivel 1 ISV de nivel 2 y 3
Descripción ISV grandes como proveedores de Planificación de recursos empresariales que proporcionan aplicaciones empaquetadas que ayudan a las empresas a gestionar sus recursos y operaciones centrales. ISV medianas y pequeñas que tienden a ofrecer soluciones empresariales verticales específicas del sector
Características
  • Aplicaciones de industria cruzada, varios módulos e integradas para planificación de productos, compra de componentes, mantenimiento de inventarios, interactuación con los proveedores, suministro de servicios de cliente y seguimiento de pedidos.
  • También pueden incluir módulos de aplicación para los aspectos de finanzas y recursos humanos de una empresa.
  • Normalmente incluyen varios componentes empresariales e incluso dominios dentro de una correlación CBM
  • A menudo están empaquetadas con sus propios componentes de middleware de propietario, seguridad y otros componentes técnicos
  • Permiten normalmente subsistemas verticales específicos del sector que dan soporte a una función específica dentro de una empresa.
  • Normalmente han documentado interfaces empresariales con uno o más ISV de nivel 1.
  • Normalmente están contenidas dentro de un dominio CBM y de un pequeño número de componentes empresariales.
  • Dependen normalmente de middleware de terceros externo y otros componentes técnicos.
  • Pueden tener sus propios componentes de seguridad.
Impacto técnico Dado su gran "espacio", estos ISV pueden tener una influencia importante en los estándares técnicos y la arquitectura utilizados dentro de una organización. En estos casos, estas influencias se identifican y se tienen en cuenta durante la realización de servicio.
El middleware y otros componentes técnicos, caso de la autenticación y el registro, deberán tenerse en cuenta durante la realización de servicio.
Estos ISV tienen normalmente menos influencia arquitectónica dentro de una gran organización, pero en una organización específica del sector más pequeña y altamente especializada, pueden tener también una influencia importante en la realización de servicio.
Estos paquetes normalmente no proporcionan sus componentes de middleware o componentes técnicos. Puede que dependan de componentes técnicos y middleware de terceros (o pueden depender de los proporcionados por un ISV de nivel 1). Algunos ISV más pequeños pueden no ofrecer interfaces a componentes técnicos. Puede que dependan de componentes técnicos y middleware de terceros (o pueden depender de los proporcionados por un ISV de nivel 1). Algunos ISV más pequeños pueden no ofrecer interfaces a componentes técnicos.
Impacto empresarial Las organizaciones que han invertido en ISV de nivel 1 tienen normalmente una predisposición a aprovechar al máximo estos paquetes de ISV. En estos casos, existirá una fuerte propensión a utilizar estos paquetes existentes para ejecutar servicios y también para permitir nuevos servicios. Como estos paquetes tienden a un ámbito de funcionalidad más estrecho, existe menos propensión y oportunidad de ampliar estos paquetes para realizar nuevos servicios.
Ejemplos SAP, Siebel, Peoplesoft, Oracle Financials Manugistics, Provia, Evoke/TD>

Como virtualmente se utilizan paquetes de ISV dentro de cada organización, la mayoría de las soluciones orientadas a servicios incorporarán servicios ejecutados a través de componentes de servicio basados en paquetes de ISV. La categorización de estos paquetes de ISV permitirá al especialista entender el rol y la importancia relativa de estos paquetes dentro de la solución de arquitectura orientada a servicios, así como identificar las características técnicas y funcionales que se deberán tener en cuenta durante la realización de servicio.

Con cada paquete de ISV, se obtiene un entendimiento de las siguientes áreas obtenidas a través del análisis realizado durante la categorización:

  1. Comprensión de la importancia e influencia de este paquete de ISV dentro de la empresa.
  2. Propensión a realizar nuevos servicios a través de este paquete de ISV.
  3. Los estándares de arquitectura y los componentes técnicos utilizados dentro del paquete de ISV y su rol dentro de la empresa.
  4. Comprensión del middleware y los componentes técnicos compatibles con el paquete de ISV.

Analizar opciones para el acceso a servicios dentro de paquetes de ISV

Este paso identifica los mecanismos a través de los cuales se puede acceder a las funciones de los paquetes de ISV (por ejemplo, aspectos técnicos del paquete directamente relacionados con la exposición y realización del servicio). Esta información se utiliza para identificar servicios candidatos dentro de los paquetes de ISV (en el siguiente paso) y también se utilizarán posteriormente para valorar la viabilidad técnica y la toma de decisiones de realización de servicio.

Para acceder a paquetes de ISV se pueden utilizar varios mecanismos. Durante este paso, cada paquete de ámbito se analiza para determinar y describir los mecanismos disponibles para cada paquete. En general, los paquetes de ISV darán soporte a uno o más de los siguientes mecanismos:

Mecanismo Descripción
Exposición directa como servicio El paquete expone directamente la funcionalidad utilizando servicios compatibles con la arquitectura orientada a servicios, que normalmente son servicios web. Estos servicios se pueden mostrar en un catálogo. Se valora la implementación específica para que cumpla con los estándares y la interoperabilidad.
Uso de API El paquete ofrece una o más API que se pueden utilizar para exponer servicios dentro del paquete. Estas API se pueden utilizar directamente para exponer la funcionalidad como servicio, o se pueden desarrollar derivadores de servicios web o una fachada para permitir el acceso a las funciones a través del API.
Acceso de datos directo En caso de que no haya API disponibles sino que se necesite un servicio que exponga los datos gestionados por el paquete de ISV, se desarrollará un servicio que directamente acceda a la base de datos utilizada por el paquete.
Nota: Aunque este enfoque pueda resultar técnicamente viable, pasar la lógica empresarial del paquete de ISV introduce un potencial riesgo de corrupción de los datos o de infracción de la integridad de los datos forzada del programa. Por este motivo, se recomienda limitar esta técnica a los servicios que realizan operaciones de "sólo lectura". Aun así, este enfoque sigue siendo arriesgado debido a cambios potenciales en el esquema de datos del ISV, y debe por tanto utilizarse con gran precaución.

Técnicas de identificación de servicio de paquetes de ISV

Durante este paso, se utilizan algunas técnicas para analizar los paquetes de ISV e identificar las funciones que se pueden exponer potencialmente como servicio. Las reglas empresariales asociadas con las funciones también se identifican. Cada técnica se utiliza para valorar los paquetes desde distintas perspectivas, permitiendo que los paquetes se analicen en profundidad en busca de servicios candidatos. Los resultados del análisis se capturan en los productos de trabajo Matriz de función/sistema empresarial y Catálogo de reglas empresariales. Como ocurre con las actividades de identificación de SOMA, los servicios candidatos se añaden a Cartera de servicios y Jerarquía de servicios.

  1. Revisar el catálogo de servicios predefinidos del paquete de ISV

    Algunos paquetes de ISV ofrecen un catálogo de servicios predefinidos. Si es el caso, los servicios candidatos para los dominios y componentes empresariales del ámbito se identifican a través del catálogo y se añaden a la Cartera de servicios. Si el ISV le da soporte, esta técnica representa la forma más fácil de identificar servicios candidatos utilizando los paquetes de ISV.

    Nota: Durante el paso Especificación de SOMA, el grado de granularidad de estos servicios será considerado parte de la toma de decisiones de exposición de servicios. Así que es importante capturar el grado de granularidad como característica de los servicios candidatos durante la identificación de SOMA. Puede que sea necesario agregar o descomponer los servicios expuestos en función del grado en el que se alinean con los servicios ejecutados dentro de los paquetes de ISV. Este análisis también ayuda a alinear los servicios candidatos dentro de la jerarquía de servicios.
  2. Revisar las API del paquete de ISV

    Los paquetes de ISV pueden ofrecer una o más API que se pueden utilizar para acceder a las funciones de los paquetes. Estas API se examinan para que los componentes empresariales y dominios del ámbito identifiquen servicios candidatos que añadir a la cartera de servicios. Como las funciones accesibles a través de estas API no se ofrecerán de forma nativa como servicio, se necesitará desarrollar un derivador de servicio o fachada para exponer estas llamadas de API como servicios. La flexibilidad de este enfoque permite la combinación de dos o más llamadas de API dentro de un sólo servicio, lo que puede permitir el desarrollo de los servicios dentro de los paquetes para alinearse con los servicios de la jerarquía de servicios. En este caso, el especialista identifica servicios dentro de la jerarquía de servicios y los correlaciona con las funciones soportadas y llamadas de API de los paquetes.
  3. Revisar correlaciones y flujo de trabajo de procesos empresariales de ISV

    El flujo de trabajo y los procesos empresariales permitidos por paquetes de ISV se pueden documentar en una copia impresa o en formato electrónico. Estos artefactos se examinan para identificar servicios candidatos adicionales que añadir a la cartera de servicios. En concreto, esta revisión debería obtener una visión de extremo a extremo de los procesos empresariales de los paquetes así como el contexto de flujo de trabajo en el que se ejecuta el proceso. Esto permite que se identifique cualquier servicio candidato relacionado y también identificar consideraciones de flujo de trabajo y proceso que deban tenerse en cuenta durante la realización de servicio.
  4. Identificar los límites de servicio de paquetes de ISV

    Un paquete de ISV se desarrollar para dar soporte a procesos empresariales y gestionar datos con un ámbito que se alinee con dominios y componentes empresariales (áreas funcionales). Estos componentes empresariales forman el "espacio" o "límite de servicio" para los paquetes de ISV. No obstante, dentro de una determinada empresa, el paquete de ISV puede ser implementado dentro de un subconjunto del límite de servicio global para dicho paquete. Mediante la identificación del límite de servicio global del paquete de ISV el especialista determina si deben añadirse a la cartera de servicios servicios adicionales dentro del límite de servicio del paquete. Y lo que es más importante, el especialista puede determinar si se pueden ejecutar nuevos servicios necesarios a través de paquetes de ISV

    Si se determina que son necesarios nuevos servicios para permitir la solución orientada a servicios, el especialista debería determinar si estos servicios entran dentro del límite de servicio del paquete ISV. Si lo hacen, los servicios dentro del paquete de ISV que den soporte a las funciones necesarias se identificarán y añadirán a la Cartera de servicios. Esto permitirá que la solución saque provecho de todas las funciones del paquete de ISV, y reducirá el riesgo de desarrollar duplicaciones dentro de los diversos sistemas que dan soporte al mismo componente empresarial.
  5. Analizar elementos de datos controlados en paquetes de ISV

    Los elementos de datos dentro del ámbito de la solución se valoran para determinar si están gestionados en los paquetes de ISV. Si los datos se gestionan dentro de los paquetes de ISV, otros procesos empresariales de los paquetes que leen o actualizan los mismos datos se analizarán para que los servicios candidatos se añadan a la cartera de servicios.

    Este análisis también revela procesos relacionados o externos e interfaces que pueden verse afectados por la solución y que deben tenerse en cuenta durante la realización de servicio. Éstos se documentan y valoran durante la realización de servicio.
  6. Analizar componentes de seguridad y otros componentes técnicos

    Muchos paquetes de ISV contienen sus propios componentes se seguridad para autenticación y autorización y pueden contener otros componentes técnicos que den soporte a funciones como el registro y la mensajería. En cada paquete, estos componentes se identifican y analizan para identificar servicios técnicos candidatos que se puedan añadir a la cartera de servicios.

    Además, durante este análisis, los problemas o restricciones que puedan ser introducidos por estos componentes se identificarán para su consideración durante la realización de servicio. Por ejemplo, la interacción necesaria con los componentes de seguridad del paquete para acceder a las funciones del paquete deberán entenderse y tenerse en cuenta durante la realización de servicio.

La aplicación de estas técnicas de análisis diversas permitirá identificar los servicios candidatos dentro de los paquetes de ISV del ámbito desde distintas perspectivas. También identificaremos problemas y restricciones introducidas por los componentes funcionales y técnicos de los paquetes de ISV que deberán tenerse en cuenta durante la realización de servicio.

Garantizar la documentación de los requisitos no funcionales de activos

Al documentar requisitos no funcionales para activos existentes se deben tener en cuenta los siguientes temas clave.

  • Manejo de excepciones: Debemos entender cómo funciona hoy en día el manejo de excepciones. En el proceso de lotes, cuando se produce una excepción, el programa finaliza anormalmente y produce un volcado del núcleo. El programador debe observar el volcado del núcleo y observar qué se debe hacer. Esto puede no ser aceptable. Uno debe averiguar lo que debe hacerse... por ejemplo, cómo realizar la integración con la infraestructura del manejo de excepciones.
  • Distribución de datos y procesos: Debemos examinar dónde se ejecutan los datos y procesos. La aplicación CICS que se ejecuta en una máquina puede enviar una solicitud a otra máquina (también conocida como función envío en CICS) o datos de llamada remotos en otra máquina. Quizás deseemos ir directamente (JDBC a DB) a la máquina remota en la que se ejecutan los datos o el proceso, en lugar de utilizar el conector que atraviesa de JDBC a DB.
  • Disponibilidad de datos: Si tenemos un archivo de cliente en VSAM que necesita, digamos, una ventana de mantenimiento de 4 horas, entonces no podremos dar soporte al servicio de cliente de 24 horas los 7 días de la semana. Deberíamos considerar la posibilidad de una nueva solución de almacenamiento.
  • Autorización/Autenticación: Muchas aplicaciones heredadas tienen mecanismos de autorización y autenticación en el código de aplicación. Esto requeriría la migración de la gestión de acceso de usuarios a un entorno gestionado de forma federada soportado por mejores prácticas.
  • Retardos de intermedio: Normalmente los programas de lotes se ejecutan una vez al día por la noche.Si los requisitos obligan a ejecutar el programa más frecuentemente, entonces tendremos que modificar el programa de planificación para cambiar la frecuencia.
Propiedades
Varias apariciones
Condicionado por sucesos
Continuo
Opcional
Planeado
Se puede repetir
Más información