Mapa Mental Togaf9 Fundation

Aquí les dejo un “Mapa mental” de la guía de estudio Togaf 9 Fundation:

Si no lo pueden ver, me escriben y se los mando por correo.

Manejo de Excepciones Avanzadas en BPM Lombardi

En la automatización de procesos con Lombardi, cuando se requiere hacer implementaciones complejas  como llamados a sistemas externos, puede ocurrir que no se tenga disponibilidad de los servicios que se van a  invocar como: Servicios de datos, Web Services, invocación a sistemas de archivos, etc. Esto es común cuando se requiere consultar información que recide en otros sistemas o cuando se quiere compartir a los mismos, desde el proceso de negocio. Por esta razón en el modelado debe contemplarse que hacer, en caso de que se presente algún tipo de error.

Para actividades que son de tipo System Service, que van hacia sistemas externos como un llamado a un Web Service, se les debe agregar un Intermetiate Exception event y a este se le le asocia un flujo de secuencia, hacia una actividad de tipo Human service para que se pueda visualizar los errores y de esta manera reintentarlos manualmente (Esto dependerá del negocio). En caso de que los reintentos manuales se ejecuten exitosamente, el flujo continuará su curso.

 Como el error se presenta en un line diferente. Se debe asignar de la siguiente manera, a una variable del proceso:

Dentro el flujo interno del servicio: “Enviar información Financiera”, es importante se lanze la excepción con una figura Throw Exception, de esta manera el subproceso la maneja con el  Intermetiate Exception event. Cuando se presenta un error Lombardi lo representa como un XML y este puede ser complementado para envíar información adicional que se requiera, para que despues sea manejada por ejemplo en un  Human service.

 Flujo interno del manejo de la excepción:

Más información en el Infocenter: Manejando Excepciones

Invitacion a tomar el curso de Arquitectura Empresarial

Esta es una invitación para todos aquellos que quieran profundizar sus conocimientos en la Arquitectura Empresarial y el Framework TOGAF.

Arquitecturas Orientadas a Servicios

Para ampliar un poco el uso de los ESB utilizados en las arquitecturas SOA. A continuación Ilustrare un par de ejemplos, para que puedan apreciar su alcance:

Arquitectura SOA – Compartiendo archivos de forma segura:

El sistema “A” cada 2 horas deja un archivo con saldos en una unidad de red compartida, el archivo almacenado posee un formato XML y es nombrado con la fecha y hora del sistema. Se deben mover los archivos de saldos generados durante el día, de forma segura al path de red del sistema “B”.

• En el proceso que se desarrolle sobre el ESB se deberá configurar variables como: Servidor, puerto, path, usuario, password de los sistemas “A” y “B”.
• Se deberá configurar la máscara del archivo que se generará en el sistema “A”. Ej: SaldosDDMMYYHHMMSS.xml
• Se deberá configurar la frecuencia de ejecución
• El proceso deberá manejar un LOG de auditoría y manejo de excepciones para su seguimiento.

Arquitectura SOA – Servicios Seguros:

El sistema “A” debe consumir una catalogo de servicios que ofrece el sistema “B”. La información que se compartirá es de carácter sensible, razón por la cual debe protegerse. Cualquier otro sistema de la compañía podrá acceder a consumir los servicios que expone el sistema "B".

• En el proceso que se desarrolle sobre el ESB deberá ser una fachada de los servicios que expone el sistema “B”.
• Los ESB manejan un componente de seguridad el cual puede estar desplegado en el mismo servidor del ESB o en un servidor independiente. Este se deberá encargar de manejar autenticación de los servicios hacia el servidor LDAP. Si la autenticación es correcta le permitirá consultar al consumidor los servicios del sistema "B".
• El componente de seguridad deberá ofrecer los servicios con certificados digitales, para que la información viaje de forma segura.
• El proceso deberá manejar un LOG de auditoría y manejo de excepciones para su seguimiento.

En este link podrás encontrar el stencil de visio, utilizado en los libros de Thomas Erl para representar arquitecturas orientas a Servicios:

http://www.soabooks.com/SOA_Visio_Stencil.zip

Que es un metamodelo en el contexto de la Arquitectura Empresarial y del Framework TOGAF 9?

Vamos hacer una breve introducción a lo que es el metamodelo en el contexto de la Arquitectura Empresarial y como es interpretado y representado por el Framework Togaf.

En el POS de Automatización de Procesos y Siglas, hicimos una introducción a las 3 capas del modelado según la OMG: “M3: Meta – Meta Modelo”, “M2: Meta - Modelo” y “M1: Modelo”. Teniendo en cuenta lo anterior como punto de partida un metamodelo es una definición precisa de las construcciones y normas necesarias para la creación de modelos. El uso de modelos nos ayuda a entender y comprender los temas complejos de una organización. Temas como su funcionalidad, los procesos que apoyan el negocio, las aplicaciones que los soportan con el objetivo de abstraer, entender y poder satisfacer las necesidades de los stakeholders apoyándose también con la construcción de catálogos, matrices y diagramas.

Según TOGAF el metamodelo es usado para estructurar la información específica de una arquitectura, ellos lo estructuran dentro del core y el Extension Content.

Cuál es el objetivo y alcance del Core and Extension Content según TOGAF?

Su objetivo es apoyar varios escenarios del metamodelo por lo cual lo dividieron en core y extension content.

• El núcleo/core proporciona un conjunto mínimo de contenido arquitectónico que soporta la trazabilidad a través de artefactos.
• El contenido de extensión es más específico y profundiza en el modelamiento.

Veamos un ejemplo de un metamodelo que construí apoyándome en un diagrama de clases representado con UML.

La figura anterior nos ayuda a aterrizar las diferentes capas que podríamos modelar en una organización. Dependiendo el tipo de industria existirán nuevas capas a modelar y estas serán más específicas, como por ejemplo para el sector salud o para el sector financiero. Para concluir el anterior modelo está un poco orientado a la capa de datos, también podría complementarse o orientarse con una capa de Estrategia, de Negocio, de seguridad, etc.

Que es Case Management?

Es la administración de casos donde las actividades no tienen un flujo de secuencia predefinido, por el contrario el flujo va ocurriendo de acuerdo a ciertas variables de quienes se ven involucrados en el proceso, el flujo de secuencia se va adaptando a los cambios del entorno.

Un caso de negocio candidato a “Case Management” es por ejemplo la atención de un tratamiento de un paciente en un hospital, éste puede requerir atención e ciertos especialistas (Urólogo, Gastroenterólogo, Neurólogo, proctólogo, etc.) a sus vez requerir de ciertos exámenes de laboratorio o ayudas diagnósticas (Rayos X), cirugías, etc.

En conclusión este tipo de procesos es un poco complejo diseñarlos a priori, para lo cual su gestión debe hacerse de manera más inteligente y más flexible, según la consultora Forester ya existen empresas que están trabajando en la automatización de este tipo de escenarios.

Para quien quiera profundizar este tema les recomiendo:

http://www.pega.com/resources/the-forrester-wave-dynamic-case-management-q1-2011

http://www-01.ibm.com/software/data/advanced-case-management/

Estados de madurez de la Arquitectura Empresarial

En el pos de la relevancia del MO, aprendimos que el punto de partida de una Arquitectura Empresarial es el modelo operativo, el cual nos indica cómo operamos actualmente y cómo deseamos hacerlo en el futuro.

Otro de los pasos dentro de una Arquitectura Empresarial, es evaluar los estados de madurez de la AE, para poder hacerlo existen muchas propuestas en el mercado, aquí les dejo una que proponen en el libro: “Enterprise Architecture as Strategy” de Jeanne W. Ross, Peter Weill, David C. Robertson:

1. Business Silos Architecture

Se hace evidente la presencia sistemas legados y otros que no manejan comunicación entre sí. La integración y estandarización de los procesos de negocio es casi nula. El rol de TI es automatizar lo procesos de negocio, los administradores de negocio diseñan los procesos de negocio y especifican los requerimientos funcionales a TI. Ti desarrolla o compra aplicaciones para cumplir con los requerimientos del negocio.

El estudio que hace el MIT a varias empresas arroja que el 12% se encuentran en este nivel.

Una organización que se encuentre en un nivel de madurez mayor, puede recaer en este cuando su negocio crece rápidamente o cuando se hacen fusiones con otras empresas, es aquí donde la organización debe hacer un gran esfuerzo para volver a cambiar de nivel Business silos.

2. Standardized technology Architecture (Estandarización)

Su principal objetivo es la reducción de costos, lo que significa que si se reducen o simplifican plataformas se disminuye la administración de las mismas.

Con la administración y apoyo de “estándares tecnológicos”, se obtiene:

• Reducción del riesgo
• Reducción del costo al compartir servicios como: Soporte, mantenimiento, compras, confiabilidad, seguridad, desarrollo y entrega a tiempo.
• Reducción del número de software que produce funcionalidad similar
• Se incrementa un acceso compartido a los datos, se introducen bodegas de datos, las transacciones siguen siendo individualmente en cada una de las aplicaciones.
• Se comparte infraestructura y servicios

3. Optimized Core Architecture (Optimización del Nucleo)

Las compañías se mueven de una vista local de datos a una vista empresarial, su principal objetivo estandarizar los datos y los procesos de negocio, más dependiente del modelo operativo, el ROLE de TI es asegurar la reusabilidad de los datos y de la plataforma que soporta los procesos de negocio generalmente en un enfoque y esfuerzo TOP-DOWN. Se analizan requerimientos y capacidades de TI, para estar alineado con el modelo operativo de la organización es aquí donde se evidencian oportunidades y apalancamientos.

4. Business Modularity Architecture (Modularización)

Habilita la agilidad estratégica través de la personalización y reúso de módulos (escancia del negocio). El principal objetivo crear nuevos módulos o re-usarlos para compartirlos transversalmente a las unidades del negocio. Estos servicios deben contar con interfaces estándar para acceder a módulos relacionados con datos, recursos internos y externos. El ROL de TI es proveer vínculos entre los procesos de negocio y las interfaces estándar. También en este nivel se identifican desarrollar y mejorar módulos que extiendan el core del negocio, para poder responder al cambio de condiciones del mercado para ello se usa el reúso de la experiencia en procesos, datos y estandarización tecnológica.