BPM Chile Day 2011 - Informe BPM&SOA

999 views

Published on

Informe sobre BPM&SOA elaborado para el BPM Chile Day 2011 (http://bit.ly/wDKlVy). Se responde a las siguientes preguntas:

1. ¿Por qué están relacionados BPM y SOA?
2. ¿Empezar por BPM o empezar por SOA?
3. ¿Cómo se deben representar/especificar los 'requerimientos' para los proyectos de BPM y SOA?

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
999
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

BPM Chile Day 2011 - Informe BPM&SOA

  1. 1. GRUPO DE ESTUDIO BPM – SOAElaborado por: Ángel Yaulilahua (angel.yaulilahua@gmail.com)ENFOQUE: Todas las respuestas a las preguntas están orientadas a lograr el objetivo de encaminar a una organización hacia la implementación de BPM y SOA. Si bien se puede implementar BPM sin usar herramientas especializadas (gestión de procesos únicamente desde la perspectiva de negocio) en este trabajo se abordará el enfoque de BPM que aborda tanto la perspectiva de negocio como la perspectiva de TI mediante el uso de tecnologías orientadas a procesos de negocio.DESARROLLO DE PREGUNTASPREGUNTA 01: ¿Por qué están relacionados BPM y SOA? Una forma de responder a esta pregunta es analizar las definiciones y/o descripciones tanto deBPM como de SOA, sin embargo para el presente estudio en lugar de estudiar la relación a partirde definiciones textuales se partirá de un modelo conceptual y el ciclo de vida de cada uno de lostemas en estudio para identificar los elementos comunes y los puntos en los que se vinculan, deesta forma se demostrará porqué ambos temas están relacionados.MODELO CONCEPTUAL Y CICLO DE VIDA DE BPM Para elaborar el modelo conceptual de BPM se partirá de algunas definiciones que presentangrupos de estudio y/o proveedores de soluciones BPM:Definición de ABPMP: BPM es un enfoque disciplinario para identificar, diseñar, ejecutar,documentar, monitorear, controlar y medir procesos de negocio automatizados o no, paraalcanzar resultados deseados y consistentes con las metas estratégicas del negocio. BPM involucrala definición, mejoras, innovación y manejo de forma deliberada, colaborativa e iterativa y con laayuda de la tecnología, de los procesos de negocio de extremo a extremo (end to end) queconduce los resultados de negocio, crea valor y habilita a la organización a alcanzar de forma ágilsus objetivos de negocio.Definición de IBM: Se puede definir a BPM como una disciplina o enfoque disciplinado orientado alos procesos de negocio, pero realizando un enfoque integral entre procesos, personas ytecnologías de la información. BPM busca identificar, diseñar, ejecutar, documentar, monitorear,controlar y medir los procesos de negocios que una organización implementa. El enfoquecontempla tanto procesos manuales como automatizados y no se orienta a una implementaciónde software. Algo importante a tener presente es que BPM no es una tecnología de software, perose apoya y hace uso de las mismas para su implementación efectiva. Dependiendo del uso delCopyright © 2011, Ángel A. Yaulilahua Maraví (angel.yaulilahua@gmail.com).Todos los derechos reservados. Prohibida su reproducción total o parcial o su uso comercial sin permiso expreso delautor.
  2. 2. enfoque y su aplicación, BPM puede verse como una metodología, como una herramientaestratégica o bien como conjunto de herramientas tecnológicas, no existe definición precisa, tododepende del prisma que utilicemos para ver la realidad.Definición de Intalio: BPM es un enfoque empresarial operativo basado en la coordinación de lasactividades y decisiones que todas las partes involucradas deben realizar durante un proceso denegocio con el objetivo de convertirse en una organización altamente eficiente, ágil, innovadora yadaptable.Definición Software AG: BPM es un conjunto de métodos, herramientas y tecnologías utilizadaspara diseñar, representar, analizar y controlar procesos de negocio operacionales. BPM es unenfoque centrado en los procesos para mejorar el rendimiento que combina las tecnologías de lainformación con metodologías de procesos y gobierno. BPM es una colaboración entre personasde negocio y tecnólogos para fomentar procesos de negocios efectivos, ágiles y transparentes.BPM abarca personas, sistemas, funciones, negocios, clientes, proveedores y socios. BPM combinamétodos ya probados y establecidos de gestión de procesos con una nueva clase de herramientasde software empresarial.Definición Club BPM: Un conjunto de herramientas, tecnologías, técnicas, métodos y disciplinasde gestión para la identificación, modelización, análisis, ejecución, control y mejora de losprocesos de negocio. Las mejoras incluyen tanto cambios de mejora continua como cambiosradicales. Resaltamos que no consiste en una solución tecnológica. BPM = Gestión por procesos + gestión de procesos + tecnología BPM En base a estas definiciones podemos sintetizar el tema de BPM (lo que implica hacer oimplementar BPM en una organización) con el siguiente modelo conceptual y ciclo de vida:Copyright © 2011, Ángel A. Yaulilahua Maraví (angel.yaulilahua@gmail.com).Todos los derechos reservados. Prohibida su reproducción total o parcial o su uso comercial sin permiso expreso delautor.
  3. 3. Modelo Conceptual Fuente: Elaboración propia ELEMENTO DESCRIPCIONProceso de negocio El concepto central dentro de BPM, la noción de procesos puede ser amplia dependiendo de la disciplina en estudio, en BPM se abarca los procesos operacionales y que son transversales a varias áreas de negocio o áreas funcionales.Tareas humanas Actividades de un proceso que son ejecutadas por personas. En implementaciones BPM es crítico/clave prestar atención a los siguientes aspectos: - Asegurar que las personas cuenten con toda la información necesaria para ejecutar sus tareas. - Medir el rendimiento e impacto de estas tareas en el proceso.Tareas de sistemas Actividades de un proceso que son ejecutadas en forma automatizada por algún componente software.Monitoreo de procesos No se puede gestionar lo que no se puede medir, en ese sentido en las iniciativas BPM para poder gestionar los procesos hay que definir indicadores para medir los procesos.Pasar del Modelado a la Ejecución Las tareas de automatización permiten pasar de unamediante Tareas de definición de procesos (modelado) ha incorporar dichaAutomatización definición a la operación de la organización (ejecución). LoCopyright © 2011, Ángel A. Yaulilahua Maraví (angel.yaulilahua@gmail.com).Todos los derechos reservados. Prohibida su reproducción total o parcial o su uso comercial sin permiso expreso delautor.
  4. 4. característico de BPM es poder pasar de manera relativamente rápida del modelado a la ejecución de los procesos.Ciclo de vida BPM Fuente: Elaboración propia ELEMENTO DESCRIPCIONIdentificación Definir un mapa de procesos para la organización y a partir de la estrategia de negocio identificar de procesos que entregan valor.Modelización Diseño o rediseño de los procesos identificados para una iniciativa o proyecto BPM.Implementación Automatizar los procesos para su ejecución, puede hacerse mediante un desarrollo a la medida (Ing. de software) o mediante tecnología orientada a procesos (BPMS y tecnologías complementarias).Ejecución Incorporar los procesos automatizadas a la operación de la organización.Monitorización Control de los procesos a partir de la información generada porCopyright © 2011, Ángel A. Yaulilahua Maraví (angel.yaulilahua@gmail.com).Todos los derechos reservados. Prohibida su reproducción total o parcial o su uso comercial sin permiso expreso delautor.
  5. 5. la ejecución.Optimización Análisis de la información y toma de decisiones para mejorar los procesos monitoreados.MODELO CONCEPTUAL Y CICLO DE VIDA DE SOA Para elaborar el modelo conceptual de SOA se partirá de algunas definiciones que presentangrupos de estudio y/o proveedores de soluciones SOA:Definición de SOA1: SOA es un estilo de arquitectura para construir sistemas basados sobreorquestación débilmente acoplada, de grano grueso y componentes autónomos denominadosservicios. Cada servicio expone procesos y comportamiento a través de contratos que estáncompuestos de mensajes para direcciones detectables denominadas endpoints. Elcomportamiento de un servicio se rige por políticas que son externas al propio servicio. SOA es unestilo de arquitectura, esto significa que SOA define componentes, relaciones y restriccionesacerca del uso e interacciones de cada componente. SOA define los siguientes componentes:servicios, endpoint, mensaje, contrato, política y consumidor de servicio. SOA también defineciertas interacciones que los componentes pueden tener.Definición DBACCESS: Estilo de arquitectura de solución, basado en la definición y construcción deservicios reutilizables que sustentan funciones del negocio. Los servicios encapsulan el acceso a lainformación y la lógica de negocio permitiendo que las aplicaciones se integren bajo una visiónorganizacional e independiente de las tecnologías utilizadas. El esquema de diseño e integraciónestá enmarcado por una serie de políticas que gobiernan su uso y evolución en el tiempo.Definición IBM: Una arquitectura de aplicación en la cual todas las funciones se definen comoservicios independientes con interfaces invocables bien definidas, que pueden ser llamadas ensecuencias definidas para formar procesos de negocio.Definición Software AG: SOA es una forma de mirar al mundo. Cuando se adopta una visiónorientada a servicios, todo cobra forma de servicio. Los servicios son los ladrillos con los que seconstruye una SOA. Son un medio para acceder a las capacidades que se repiten en un negocio.Los servicios SOA pueden acoplarse para construir otros nuevos, y ensamblarse en secuencias paraconstruir procesos.1 Tomado del libro SOA Patterns (http://www.manning.com/rotem/)Copyright © 2011, Ángel A. Yaulilahua Maraví (angel.yaulilahua@gmail.com).Todos los derechos reservados. Prohibida su reproducción total o parcial o su uso comercial sin permiso expreso delautor.
  6. 6. Modelo conceptual SOA Para el presente trabajo se tomará como referencia la siguiente representación2: Asimismo se considerará el siguiente modelo conceptual: Fuente: Elaboración propia2 Tomado del libro Open Source SOA (http://www.manning.com/davis/)Copyright © 2011, Ángel A. Yaulilahua Maraví (angel.yaulilahua@gmail.com).Todos los derechos reservados. Prohibida su reproducción total o parcial o su uso comercial sin permiso expreso delautor.
  7. 7. ELEMENTO DESCRIPCIONServicio Es el concepto central de SOA, no está asociado a ninguna implementación tecnológica específica sin embargo a menudo se implementa como servicios web. Las principales características de un servicio en SOA es que son de grano grueso (alto nivel), reutilizables y autosuficientes (sin estado). Típicamente los servicios SOA se identifican a partir de las aplicaciones existentes (bottom-up) o a partir de las necesidades de datos/información de los procesos de negocio (top-down)Consumidor de servicio Un servicio existe porque existen otros componentes (consumidor de servicios) que hacen uso del mismo. Los típicos consumidores de servicios son otros servicios, los procesos de negocio y las interfaces de usuario.Mensaje Es el elemento de comunicación en SOA. Servicios y consumidores de servicios intercambian mensajesCiclo de vida SOA Fuente: Elaboración propiaCopyright © 2011, Ángel A. Yaulilahua Maraví (angel.yaulilahua@gmail.com).Todos los derechos reservados. Prohibida su reproducción total o parcial o su uso comercial sin permiso expreso delautor.
  8. 8. ELEMENTO DESCRIPCIÓNIdentificar servicios Básicamente existen dos enfoques para identificar servicios SOA. El enfoque top-down parte del análisis de los procesos de negocio para identificar servicios reutilizables entre diferentes procesos. Por otro lado el enfoque bottom-up parte del análisis de las funciones de las aplicaciones existentes para identificar servicios a partir de funciones que se repiten en múltiples aplicaciones.Implementar servicios Un aspecto clave en SOA es definir una tipología de servicios, es decir clasificar los servicios identificados para poder elegir la tecnología apropiada para cada tipo de servicio.Registro de servicios Dado que los servicios son el concepto central de SOA, para poder tener gobierno sobre la arquitectura SOA es necesario tener un control centralizado lo cual se logra a partir de un repositorio de servicios.Consumir Servicios A partir del consumo de servicios, SOA permite dar soporte a los procesos de negocio y combinar los servicios para generar diferentes soluciones de negocio.Monitorizar servicios Siendo los servicios los ladrillos con los que se construyen soluciones en SOA, es importante monitorear el comportamiento de los servicios para validar que cumplen el contrato que implementan y dan soporte adecuado a la funciones de negocio que automatizan.Optimización A partir de la monitorización de los servicios y con el apoyo de la tecnología SOA se puede aplicar diferentes técnicas de optimización sobre los servicios de la SOA.Copyright © 2011, Ángel A. Yaulilahua Maraví (angel.yaulilahua@gmail.com).Todos los derechos reservados. Prohibida su reproducción total o parcial o su uso comercial sin permiso expreso delautor.
  9. 9. RELACION ENTRE BPM Y SOABPM y SOA desde una Perspectiva Organizacional Tanto BPM como SOA se encuentran en una ‘Zona Intermedia’ entre el mundo de los negocios y el mundo de TI (tecnologías de la información). Ambos necesitan de la colaboración entre el personal de negocio y el personal de TI para implementarse de manera exitosa. Tanto BPM como SOA son medios para lograr los objetivos de la organización a partir de que proporcionan elementos útiles para la ejecución de la estrategia de negocio En cierta forma BPM está cercano al mundo de los negocios ya que se centra en los procesos de negocio y el personal de negocio es el principal interesado de que dichos procesos estén adecuadamente gestionados para producir los resultados que espera la organización. Sin embargo BPM, para lograr mejores resultados, necesita de un alto componente tecnológico (tecnología orientada a procesos) por lo que no es raro que hayan proyectos BPM que surjan como iniciativa del personal de TI. En cierta forma SOA está más cercano al mundo de TI dado que se origina como una evolución de las arquitecturas distribuidas en la ingeniería de software. Sin embargo SOA tiene un fuerte vínculo con el negocio debido a que el análisis de los procesos de negocio constituye una buena fuente para definir servicios reutilizables y la composición de servicios responde a necesidades de negocio y no a necesidades técnicas.Copyright © 2011, Ángel A. Yaulilahua Maraví (angel.yaulilahua@gmail.com).Todos los derechos reservados. Prohibida su reproducción total o parcial o su uso comercial sin permiso expreso delautor.
  10. 10. Fundamentos de la relación entre BPM y SOA El vínculo o relación entre SOA y BPM se fundamenta en que sus modelos compartenelementos comunes que son los puntos de complemento en sus respectivos ciclos de vida. Elementos compartidos: ELEMENTO PERSPECTIVA BPM PERSPECTIVA SOAProcesos Elemento central Fuente de identificación de servicios reutilizables. Un proceso automatizado también se puede considerar como un servicio.Servicios Soporte para las tareas de Elemento Central sistemas. Fuente de datos para la interfaz de usuario en las tareas humanasInformación Hay que garantizar el flujo de Hay que implementar, combinar información a lo largo del proceso servicios para proporcionar la de negocio información que el negocio necesita. CICLO BPM CICLO SOA DESCRIPCION DE LA RELACIÓN/COMPLEMENTOModelado Identificar servicios A partir del modelado de procesos y el análisis delOptimización monitoreo de procesos de negocio se puede identificar tareas de sistemas y/o decidir automatizar algunas tareas humanas y servir de entrada para el ciclo de vida SOA mediante la identificación de nuevos servicios, la actualización o la composición de servicios existentes.Implementación Implementar servicios La automatización de procesos conlleva a la implementación de servicios (nuevos servicios o composición de servicios existentes) para el soporte de las actividades de sistemas en los procesos.Copyright © 2011, Ángel A. Yaulilahua Maraví (angel.yaulilahua@gmail.com).Todos los derechos reservados. Prohibida su reproducción total o parcial o su uso comercial sin permiso expreso delautor.
  11. 11. Asimismo el proceso automatizado, dependiendo de las tecnologías utilizadas, podría ser un nuevo servicio implementado.Ejecución Consumir servicios La ejecución de procesos conlleva al consumo de los Monitorizar servicios servicios utilizados en su diseño, asimismo genera Optimizar servicios información sobre el uso de los servicios para su monitoreo y su posible optimización.PREGUNTA 02: ¿Empezar por BPM o empezar por SOA? ¿Comenzamos por los servicios (bottom-up) o los procesos (top-down)? Para responder a esta pregunta hay que considerar que en el contexto de una organizaciónpodrían presentarse los siguientes escenarios: 1. La organización todavía no se encuentra ejecutando proyectos ni BPM ni SOA. 2. La organización se encuentra ejecutando un proyecto BPM. 3. La organización se encuentra ejecutando un proyecto SOA. La respuesta a esta pregunta se centra en el primer escenario con el objetivo de encaminar a laorganización hacia la implementación de BPM y SOA. En los otros escenarios (si ya hay proyectosBPM o SOA en ejecución) la orientación es complementar el proyecto en ejecución con el otrotema a partir de la relación entre ambos descrita en el desarrollo de la primera pregunta. Partiendo de que el alcance de BPM y SOA no se limitan a un proyecto o una parte de laorganización sino a toda la organización, tanto la bibliografía de BPM y la de SOA coinciden en quepara la adopción (a nivel organizacional) de este tipo de soluciones es recomendable un enfoqueincremental (proyecto a proyecto) en lugar de tratar de hacerlo mediante un único ‘megaproyecto’, en ese sentido y considerando la naturaleza complementaria descrita en el desarrollode la pregunta 01, no es necesario ‘terminar de implementar’ uno de ellos para recién empezarcon el otro, proyecto a proyecto ambos pueden ir implementándose de manera gradual. Lo importante en la adopción incremental, proyecto a proyecto, es no perder el foco en el valorde incremento en la adopción de BPM y SOA. La identificación de un proyecto que aporte en laadopción/implementación de BPM en la organización (proyecto BPM) es bastante natural ya quesiempre habrá por lo menos un proceso de negocio dentro del alcance del proyecto, lo importantees trabajar bajo el modelo conceptual de BPM y cubrir el ciclo BPM descritos en la pregunta 01para considerarlo un “Proyecto BPM”. En el caso de los proyectos que aporten en laadopción/implementación de SOA en la organización es un poco más complicado ya queprácticamente cualquier proyecto de TI o relacionado a TI (integración de aplicaciones,actualización de aplicaciones existentes, implantación de un BPMS, etc.) puede considerarse comoun “Proyecto SOA” siempre y cuando acerquen a la realización de una arquitectura global deservicios para la organización por ejemplo a través de la elección de los servicios adecuados, de locontrario el proyecto de SOA sólo tendrá el nombre. De lo anterior se puede deducir que la claveCopyright © 2011, Ángel A. Yaulilahua Maraví (angel.yaulilahua@gmail.com).Todos los derechos reservados. Prohibida su reproducción total o parcial o su uso comercial sin permiso expreso delautor.
  12. 12. está en identificar los proyectos que aporten a la adopción/implementación de BPM, SOA o ambosdentro de la organización. Dado el enfoque de adopción incremental y la pregunta de ¿empezar por BPM o empezar porSOA? Lo ideal sería empezar por ambos a la vez a través de proyectos que abarquen tantoaspectos de negocio como aspectos de TI de tal manera que puedan aportar, a la vez, a laadopción/implementación de SOA y BPM; sin embargo esto no siempre es posible, pese a lasbondades que ofrecen tanto BPM como SOA, debido a los costos de la tecnología BPM y latecnología SOA. Considerando que este trabajo está orientado a la adopción de SOA y BPM a lolargo de una organización, la pregunta inicial se puede redefinir como ¿Cuál debería ser la primerainversión, Invertir en tecnología BPM (Suite BPM) o invertir en tecnología SOA (suite SOA)?Lógicamente dependiendo en qué tipo de tecnología se invierta primero, los proyectos queejecute la organización bajo la adopción incremental aportarán mayor valor a la adopción delmismo tipo que la tecnología elegida, sin que ello signifique que el aporte a la adopción del otrotema sea nulo, así mientras se avance en la adopción incremental llegará un momento en que seinvierta en el otro tipo de tecnología para completar los beneficios de una adopción integral deBPM y SOA. Para poder discernir por cuál empezar hay que analizar lo que implicaría empezar por BPM oempezar por SOA:Empezar por BPM implicaría: Centrarse en los procesos de negocio. Capacitación y uso de los estándares de BPM. Tener presente el complemento con SOA con miras a una implementación de BPM y SOA en toda la organización.Empezar por SOA implicaría: Centrarse en los servicios necesarios para construir soluciones a las necesidades de la organización a través de la reutilización y combinación de dichos servicios. Capacitación y uso de los estándares SOA. Tener presente el complemento con BPM con miras a una implementación de SOA y BPM en toda la organización. Basado en estas implicancias podemos analizar los siguientes criterios para evaluar por dóndeempezar:Copyright © 2011, Ángel A. Yaulilahua Maraví (angel.yaulilahua@gmail.com).Todos los derechos reservados. Prohibida su reproducción total o parcial o su uso comercial sin permiso expreso delautor.
  13. 13. Criterios para decidir por dónde empezar Motivación y Justificación de los proyectos: Todas las iniciativas de gran alcance en una organización necesitan para su implementación exitosa el respaldo o apoyo de los responsables de las unidades de negocio o de la alta gerencia (el patrocinador o sponsor de los proyectos). Por lo general los potenciales patrocinadores están más cercanos a las áreas de negocio que las áreas de TI. Asimismo los “Proyectos BPM” y sus beneficios tienen un vínculo más directo con las áreas de negocio que los “Proyectos SOA” y sus beneficios. En ese sentido es más simple obtener la motivación y justificación para los “Proyectos BPM”. Facilitación del trabajo en equipo: Tanto los “Proyectos BPM” y los “Proyectos SOA” requieren de una fuerte la colaboración entre el personal de negocio y el personal de TI para su implementación exitosa. Dada la cercanía, vínculo o relación de SOA con la ingeniería de software, los “Proyectos SOA” tienen potencialmente los mismos riesgos de ´divorcio´ entre el personal de negocio y el personal de TI que en los proyectos de software siendo necesarios analistas de negocio y/o analistas técnicos para traducir los requerimientos de negocio en la implementación técnica. En los “Proyectos BPM” la situación es algo diferente ya que en estos proyectos se suele utilizar la notación BPMN (Business Process Modeling Notation) que fue creada con el objetivo de ser un lenguaje común entre el personal de negocios y el personal de TI de esta forma el análisis se centra en el modelado del proceso y el flujo de flujo de información a lo largo del proceso en lugar de diagramas de modelado de software. Los estándares SOA están más orientados a personal técnico mientras que en BPM existe un estándar (BPMN) que hace de lenguaje común entre todo el equipo y facilita el trabajo en equipo. Por lo tanto la colaboración entre negocio y TI es más fuerte en los “Proyectos BPM”. Aporte para la adopción/implementación conjunta: Cuando se ejecuta un “Proyecto SOA” no necesariamente se aporta a la adopción de BPM (por ejemplo proyectos de integración de aplicaciones) sin embargo cuando se ejecuta un “Proyecto BPM” siempre se analiza uno o más procesos de negocio, dicho análisis es una buena fuente para identificar “servicios SOA” considerando que en la bibliografía SOA comúnmente se menciona dos enfoques para la identificación de los servicios: 1° el enfoque bottom-up que consiste en identificar servicios a partir de funcionalidad repetida en múltiples aplicaciones. 2° el enfoque top-down que consiste en identificar servicios a partir del análisis de los procesos. Por lo tanto los “Proyectos BPM” indirectamente aportan en la adopción de SOA (identificación de servicios) mientras que un “Proyecto SOA” no siempre aporta en la adopción de BPM.Copyright © 2011, Ángel A. Yaulilahua Maraví (angel.yaulilahua@gmail.com).Todos los derechos reservados. Prohibida su reproducción total o parcial o su uso comercial sin permiso expreso delautor.
  14. 14. PREGUNTA 03: ¿Cómo se deben representar/especificar los requerimientos para los proyectosde BPM y SOA? Del desarrollo de las preguntas anteriores también podemos inferir que cuando hablamos deadoptarimplementar BPM no estamos hablando únicamente de crear diagramas de procesos,estamos hablando de la gestión de los procesos de negocio a lo largo de todo el “ciclo BPM” lo quegeneralmente implica la automatización de dichos procesos de negocio pero ¿Cómo hacemos laautomatización? Sin el uso de la “Tecnología BPM” dicha automatización se realiza mediante laconstrucción de una aplicaciónsoftware por lo que al final terminamos hablando de“Documentación de Procesos” y “Requerimientos de Software”, en ese sentido como punto departida para el desarrollo de esta pregunta es pertinente revisar la problemática en cuanto arequerimientos de la Ing. de software.Típico Proceso de Desarrollo – Ingeniería de Software Fuente: Business Rules and Information Systems, Tony Morgan De este proceso, para fines de este informe, se destaca las siguientes características: El dueño de negocio está alejado del proceso de desarrollo, una vez que se ha creado una descripción inicial de las necesidades del negocio, típicamente en la forma de una especificación de requerimientos, su participación está limitada a la interacción a través de especialistas (analistas funcionales) y en el visto bueno final.Copyright © 2011, Ángel A. Yaulilahua Maraví (angel.yaulilahua@gmail.com).Todos los derechos reservados. Prohibida su reproducción total o parcial o su uso comercial sin permiso expreso delautor.
  15. 15.  El proceso se basa en gran medida en material descriptivo que tiene que ser interpretado por personas con el tipo adecuado de habilidades para convertirlos en productos de desarrollo, formándose una cadena de interpretación. Típicamente los analistas interpretan los requerimientos de negocio para producir documentos de análisis, luego analistas técnicos o diseñadores traducen los documentos de análisis en documentos de diseño que los desarrolladores interpretan y traducen en código fuente para que los especialistas en pruebas de software los validen previo a la validación o aprobación del usuario de negocio. Esta secuencia introduce posibles puntos de malentendidos que pueden no detectarse sino hasta muy tarde en el proceso, algo que podría compararse con el efecto del “teléfono malogrado”. Cadena de interpretación – enfoque tradicional Fuente: Business Process Management with JBoss jBPM, Matt CumberlidgeTípico Proceso de Desarrollo Ágil - Ingeniería de Software Cadena de interpretación – enfoque ágil Fuente: Business Process Management with JBoss jBPM, Matt Cumberlidge De este proceso, para fines de este informe, se destaca las siguientes características:Copyright © 2011, Ángel A. Yaulilahua Maraví (angel.yaulilahua@gmail.com).Todos los derechos reservados. Prohibida su reproducción total o parcial o su uso comercial sin permiso expreso delautor.
  16. 16.  La cadena de interpretación se reduce a la interacción directa entre el usuario de negocio y el desarrollador. A diferencia del proceso tradicional para la comunicación entre el requerimiento de negocio y la implementación se utilizan prototipos en lugar de documentos descriptivos. Del análisis anterior se podría resumir dos puntos como los principales inconvenientes de laautomatización de procesos de negocio mediante el enfoque de la ingeniería de software:1. Una vez implementados los requerimientos, la implementación no coincide del todo con lanecesidad de negocio que se tradujo en requerimientos de software. Esto se debe principalmentea la cadena de interpretación y a los diferentes lenguajes utilizados por cada uno de los intérpretesde la cadena lo que resulta en la necesidad de utilizar documentos descriptivos como elemento detraducción.2. Los cambios en los requerimientos suelen ser trabajosos de implementar por lo que noresponden, adecuadamente, al ritmo de los cambios en el negocio. Este inconveniente es unaconsecuencia del anterior. Las actualizaciones o mantenimientos suelen demorar porque, bajo elenfoque de la Ing. de Software, siguen casi el mismo ciclo que la implementación inicial y porquetodos los requerimientos se tratan de la misma forma (implementación a nivel de código), elcambio no siempre lo hace la misma persona que lo implementó y nunca el mismo usuario denegocio puede ejecutar los cambios. Todos los requerimientos se especifican e implementansiguiendo el mismo patrón y siendo los casos de uso el elemento por defecto para representartodo tipo de requerimientos. Cuando trabajamos con BPM y SOA para automatizar los procesos de negocio disponemos deelementos, técnicas, estándares y tecnologías para abordar esta problemática mediante ellenguaje común que proporciona BPM a través de BPMN y mediante la agilidad que proporcionaSOA para construir rápidamente soluciones de negocio, sin embargo queda latente la interrogante¿cómo debería abordarse los requerimientos para evitar los inconvenientes del enfoque de laingeniería de software? Como aporte de este trabajo se sugiere tener en cuenta las siguientes directrices en lo querespecta a requerimientos al abordar proyectos BPM y SOA:1. Reducir tanto como sea posible la cadena de interpretación. Aquí es donde el enfoque de BPMtiene un valor muy importante ya que permite pasar del modelado de procesos a la ejecución delos mismos, se podría decir así que “el proceso es la aplicación”, aquí el elemento de comunicaciónentre el personal de negocio y el de TI ya no es el típico caso de uso de la Ing. de software sino esel proceso mismo que representa la realidad de la operación de la organización. El principalestándar BPM que permite reducir la “cadena de interpretación” es la Notación de Modelado deProcesos de Negocio (BPMN). BPMN mejora los esfuerzos organizacionales para alinear el trabajodel personal de negocio y el personal de TI, proporcionando un lenguaje gráfico común, facilitandola comunicación y mejorando la comprensión de los procesos de negocio.Copyright © 2011, Ángel A. Yaulilahua Maraví (angel.yaulilahua@gmail.com).Todos los derechos reservados. Prohibida su reproducción total o parcial o su uso comercial sin permiso expreso delautor.
  17. 17. La clave está en utilizar los diagramas de procesos en BPMN como elemento central decomunicación, hablar de “requerimientos del procesos” (¿Cómo es y/o debe ser el proceso denegocio?, ¿cuál es la responsabilidad de negocio y la responsabilidad de TI en el proceso denegocio?, etc) en lugar de “casos de uso del sistema” como elemento intermediario entre negocioy TI. Fuente: Elaboración propia2. Pasar de requerimientos de software a requerimientos de información: Esto implica ver laactividad del negocio como el flujo de información entre diferentes actores (humanos yaplicaciones). Del desarrollo de las preguntas anteriores se puede inferir que tanto BPM como SOAson, en alto nivel, “enfoques” de cómo gestionar la operación y la construcción de aplicaciones enuna organización, en ese sentido para comprender este punto voy a citar al conocido como “elpadre de la administración moderna” con respecto a los roles de los directores de negocio y TI enuna organización: “Los directores generales deben aceptar que si el ordenador es una herramienta, es tarea del usuario de esa herramienta decidir cómo usarla. Deben asumir la “responsabilidad de la información”. Y eso significa preguntar: ¿Qué información necesito para hacer mi trabajo? ¿De quién? ¿En qué forma? ¿Cuándo? Y también: ¿Qué información debo dar? ¿A quién? ¿En qué forma? ¿Cuándo? Por desgracia, la mayoría sigue esperando que el director del departamento de informática o algún otro técnico responda a esas cuestiones. Y eso no puede ser… El director de Informática es quien fabrica la herramienta, el director general quien la usa”Copyright © 2011, Ángel A. Yaulilahua Maraví (angel.yaulilahua@gmail.com).Todos los derechos reservados. Prohibida su reproducción total o parcial o su uso comercial sin permiso expreso delautor.
  18. 18. La empresa en la sociedad que viene. Peter Drucker De esta cita hay que resaltar dos aspectos: La información como recurso para la operatividad de la organización. La responsabilidad del personal de negocio (operación) sobre el “recurso información” para realizar su trabajo y colaborar con los demás. Un diagrama BPMN si bien sirve para la comunicación entre negocio y TI, queda incompleto sino se especifica el flujo de información a lo largo del proceso, la tarea de determinarespecificar elflujo de información en el proceso permite poner énfasis en la “responsabilidad de la información”de cada participante de negocio en el proceso (información que necesita e información queagrega) al analizar las tareas humanas, asimismo también se enfatiza la responsabilidad del áreade TI para la adecuada gestión del recurso información (obtención, visualización, procesamiento,persistencia, etc.) a lo largo del proceso resultando en una o más tareas de sistemas requeridaspara la ejecución del proceso. La clave está en analizar “los requerimientos de información” de los procesos de negocio,incorporar prácticas de “gestión de la información” y así, en forma gradual, ir definiendo un“Sistema de Información Organizacional”. Fuente: Elaboración propia3. Clasificar o tipificar los requerimientos según el formato o soporte especializado que existapara cada tipo de requerimiento: No tenemos que trabajar todos los requerimientos de la mismaforma, existen diversos tipos de requerimientos y cada tipo tiene sus propias características, porejemplo la frecuencia de cambio, que en la actualidad existen soluciones especializadas paraciertos tipos de requerimientos tales como:Copyright © 2011, Ángel A. Yaulilahua Maraví (angel.yaulilahua@gmail.com).Todos los derechos reservados. Prohibida su reproducción total o parcial o su uso comercial sin permiso expreso delautor.
  19. 19.  Las soluciones de ECM: para gestión de contenidos. Las soluciones de BRMS: para la gestión de reglas de negocio. Los mismos BPMS: para requerimientos de gestión de procesos de negocio. Por lo tanto no es necesario especificar todos los requerimientos como “casos de usos” y“Diagramas UML”, en su lugar se deberían utilizar los formatos propios de cada tipo derequerimientos (por ejemplo tablas de decisión para las reglas de negocio, BPMN para losprocesos, etc). Sin embargo no hay que perder de vista que los “Servicios SOA” son componentesde software y en dicho caso se debería usar los elementos que dispone la Ing. de Software. Quizá el ejemplo más representativo de este tercer grupo son los BRMS (Business RulesManagement System) que permiten la definición y modificación de las reglas de negocio por partedel mismo usuario de negocio, lo que permite que este tipo de requerimientos que sonfrecuentemente cambiantes puedan reflejar los cambios en forma automática y transparente. La clave está en comprender que no es necesario implementar todos los requerimientos desdecero (código fuente) y evaluar el uso de estas soluciones especializadas como parte de laautomatización de los procesos de negocio. Un punto a favor del uso de estas solucionesespecializadas es que por lo general exponen su funcionalidad como “web services” y ello facilitasu incorporación en un contexto BPM&SOA. A modo de ejemplo para procesos de negocio que sean intensivos en trámites o gestióndocumental podría usarse el siguiente proceso para la especificación de sus requerimientos:Copyright © 2011, Ángel A. Yaulilahua Maraví (angel.yaulilahua@gmail.com).Todos los derechos reservados. Prohibida su reproducción total o parcial o su uso comercial sin permiso expreso delautor.
  20. 20. Fuente: Elaboración propiaCopyright © 2011, Ángel A. Yaulilahua Maraví (angel.yaulilahua@gmail.com).Todos los derechos reservados. Prohibida su reproducción total o parcial o su uso comercial sin permiso expreso delautor.

×