UNIVERSIDAD DE LAS CIENCIAS INFORMÁTICAS FACULTAD 4
TRABAJO DE DIPLOMA PARA OPTAR POR EL TÍTULO DE INGENIEROS EN CIENCIAS INFORMÁTICAS
Ciudad de la Habana, Junio de 2009
“Año del 50 Aniversario del Triunfo de la Revolución”
Propuesta de modelo para la gestión de la gobernabilidad durante la fase de diseño en un proyecto BPM/SOA
AUTORES: Giselle Ortega Hernández Dariel Chirino Esquijarosa
TUTORES: Ing. Marbys Marante Valdivia
Ing. Leevan Abón Cepeda
TÍTULO:
I DECLARACIÓN DE AUTORÍA
DECLARACIÓN DE AUTORÍA
Declaramos ser autores del presente Trabajo de Diploma y reconocemos a la Universidad de las Ciencias Informáticas los derechos patrimoniales de la misma, con carácter exclusivo.
Para que así conste firmamos el presente documento a los _____ días del mes de ___________ del año _________.
____________________________
____________________________
____________________________
____________________________
Giselle Ortega Hernández Dariel Chirino Esquijarosa
Marbys Marante Valdivia Leevan Abón Cepeda
II DATOS DE CONTACTO
DATOS DE CONTACTO
Tutor: Ing. Marbys Marante Valdivia
Correo electrónico: [email protected]
Línea BPM/SOA, Centro de Consultoría Tecnológica e Integración de Sistemas, Infraestructura Productiva de la Universidad de las Ciencias Informáticas. Ministerio de la Informática y las Comunicaciones.
Ingeniero en Ciencias Informáticas, Universidad de las Ciencias Informáticas 2005.
Se ha desempeñado en el campo del Desarrollo de Software y la Gestión de Proyectos.
Categoría Científica: Ingeniero.
Categoría docente: Instructor.
Tutor: Ing. Leevan Abón Cepeda
Correo electrónico: [email protected]
Línea BPM/SOA, Centro de Consultoría Tecnológica e Integración de Sistemas, Infraestructura Productiva de la Universidad de las Ciencias Informáticas. Ministerio de la Informática y las Comunicaciones.
Ingeniero en Ciencias Informáticas, Universidad de las Ciencias Informáticas 2007.
Se ha desempeñado como Jefe de Módulo en proyectos de Desarrollo de Software.
Categoría Científica: Ingeniero.
Categoría docente: Adiestrado.
III
“Cuando se es joven, se crea. Cuando se es inteligente, se produce.
No se adapta, se innova: la medianía copia; la originalidad se atreve.”
José Martí
IV AGRADECIMIENTOS
AGRADECIMIENTOS De Giselle:
A mi mamita linda, mimita, este es el resultado de tantos años de trabajo que hemos pasado juntas, quiero darte las gracias por estar siempre a mi lado, por darme fuerzas en los momentos más difíciles, por confiar en mí y demostrarme que siempre se puede salir adelante, te regalo mi sueño hecho realidad, sin ti hubiera sido imposible lograrlo. Mimita: ¡Hoy tu niña es Ingeniera!
A mi hermanito, tatica eres el regalo más grande que la vida me ha dado, sin tu apoyo no hubiera podido estar aquí, eres mi vida, mi fuerza, el mejor hermanito del mundo, gracias por hacerme sentir importante, solo quiero que te sientas orgulloso de mi, te quiero mucho.
A Liusdel por dedicarme todo su tiempo, por guiarme, por enseñarme el camino, por todo su amor, cariño y comprensión, por ayudarme en todo cuanto me hiso falta, por ser mi amigo y mi novio, gracias por enseñarme tanto. Nene se me hace muy difícil escribir lo mucho que significas para mí. Te quiero mucho.
A mis abuelitos por todo el cariño que me han brindado, y por ser los mejores del mundo, gracias por estar ahí para mí.
A mi padrastro, a Raque, Sergio y a toda mi familia por el apoyo que me han brindado, por su preocupación y su confianza.
A Chiri, mi compañero de tesis, porque sin él no hubiera sido posible desarrollar este trabajo, te doy las gracias por tu dedicación, comprensión, por tu cariño y paciencia, por tus locuras y por animarme cuando pensaba que todo estaba perdido. Eres una persona muy especial para mí. ¡Gracias!
A mis amigas, a Mile, Yesi, Yane por estar siempre conmigo en las buenas y en las malas, por todo el cariño que me dan y por dejarme ser parte de esa pequeña familia que hemos formado, gracias por darme la fuerza que necesito para levantarme cada día y tratar que sea mejor.
A la negri Odaisy, a Lili y Alain, por transmitirme tanta energía, por ser ejemplos a seguir, por enseñarme que no se puede abandonar hasta que no logremos nuestras metas.
A la Revolución y a Fidel por darme la oportunidad de superarme y estudiar en esta universidad.
A todas las personas que nos apoyaron durante estos 5 años y en la realización de este trabajo.
V AGRADECIMIENTOS
De Chirino:
A la Revolución y Fidel por brindarme la posibilidad de estudiar en un lugar maravilloso como esta Universidad.
A mis padres que siempre me han dado motivos suficientes para estar orgulloso de ellos. A mi prima Dorys que ha sido mi otra madre y me ha apoyado en todo momento. A todos los miembros de mi familia, que siempre me han brindado su ayuda.
A los hermanos que la vida ha puesto en mi camino para siempre, mis amigos de la eternidad: Soliet, Alién, Olivier y Omar; sin ellos no sería el mismo. Con las cosas que he aprendido de ellos podría llenar varias páginas, pero no es necesario, pues el eterno agradecimiento a su apoyo va siempre conmigo y eso es lo más importante.
A Gise, mi compañera de tesis, por soportar mis arranques, por estar siempre para darme apoyo, pues aún cuando las ideas brillaban por su ausencia, seguía ahí para darme ánimos. Le agradezco por su sencillez y su gran corazón.
A Lilian, por acompañarme en todas mis locuras. Por ayudarme a soñar una Facultad llena de logros y estar siempre presente.
A los amigos que he conocido en la Universidad y han marcado mi vida para siempre. Decir nombres es bien difícil, pues todos han sido importantes, pero sería injusto no mencionar a mi equipo de la FEU que juntos hemos tenido la oportunidad de sufrir y disfrutar cada momento.
A todos aquellos que conocí y me auxiliaron hasta el último minuto. Los que me ayudaron en la revisión y preparación de la Tesis: Baby, Tahirí, Liannis, Karina, Alain, Alionuska, Haydée, Lizandra, Yesenia; a todos gracias por ese apoyo incondicional.
A todos los profesores que he conocido a lo largo de estos cinco años y que me han ayudado a ser mejor cada día; unos desde el aula y otros desde su enseñanza y ejemplo, todos han sido importantes en cada momento.
A la FEU, que sin ella mi paso por la Universidad no se hubiera convertido en los mejores cinco años de mi vida.
Al destino por ponerme en el lugar y el momento precisos.
VI DEDICATORIA
DEDICATORIA
A mi mamita, por construir conmigo este sueño y ser la luz de mi vida, te adoro.
A mi hermano, por ser mi mayor tesoro y mi vida.
A mi sobrino, por imponerme la meta de ser su ejemplo.
A mi padrastro, por ser como un padre para mí.
A Liusdel, a mi nene, por todo su amor.
A mis abuelitos y toda mi familia por todo su cariño.
A Fidel y a la Revolución por darme la oportunidad de realizar mi sueño.
Giselle
A mis padres, por enseñarme a enfrentar la vida.
Pensando en ellos he luchado por hacer realidad este sueño.
A mi hermano, por sus enseñanzas.
A mi prima Dorys por acogerme como su hijo durante estos cinco años.
Al Comandante en Jefe por ser el artífice principal de este sueño.
A toda mi familia, por ser mis inspiradores y siempre confiar en mí.
Chirino
VII RESUMEN
RESUMEN
El Gobierno BPM/SOA es el conjunto de directivas, funciones, responsabilidades y procesos que se utilizan para guiar, dirigir y controlar el uso de las tecnologías, manejar la toma de decisiones, formular estrategias y asegurar el logro de los objetivos de una empresa que haya decidido adoptar una Arquitectura Orientada a Servicios (SOA) en combinación con la Gestión de los Procesos de Negocio (BPM).
Debido al dominio que tienen las empresas privadas del sector de SOA, se hace difícil utilizar y aplicar de manera gratuita los modelos de Gobierno BPM/SOA que existen actualmente. Utilizando como base esta problemática, es que tiene lugar el desarrollo de la presente investigación, la cual tiene como objetivo proponer un modelo que garantice la gestión de la gobernabilidad durante la fase de diseño en un proyecto BPM/SOA.
El estudio de metodologías y buenas prácticas de gobierno desarrolladas por compañías de prestigio en el sector de SOA, sirvió como punto de partida para la definición del modelo. La propuesta unifica algunos aspectos de ambas secciones que fueron considerados como importantes para el logro de un buen gobierno.
Los elementos fundamentales de la propuesta son los artefactos, roles, herramientas, técnicas, procesos y actividades que componen el flujo de trabajo a seguir durante la aplicación del gobierno para la fase de diseño en un proyecto BPM/SOA. Para validar la propuesta fue utilizado el Método Delphi, a través del cual se utilizaron como elementos de certificación los criterios aportados por un conjunto de expertos en el tema.
PALABRAS CLAVE
Arquitectura Orientada a Servicios, BPM, Gestión de Procesos de Negocio, Gobierno, Gobierno BPM/SOA, SOA.
VIII
ÍNDICE DE CONTENIDOS
INTRODUCCIÓN ... 1
CAPÍTULO 1: FUNDAMENTACIÓN TEÓRICA ... 6
1.1. INTRODUCCIÓN ... 6
1.2. CONCEPTOS ASOCIADOS AL DOMINIO DEL PROBLEMA ... 6
1.2.1. Arquitectura Orientada a Servicios... 6
1.2.2. Gestión de los procesos de negocio ... 10
1.2.3. Integración de SOA y BPM ... 12
1.2.4. Gobierno ... 12
1.3. IMPORTANCIA DEL GOBIERNO BPM/SOA ... 17
1.4. ELEMENTOS DEL GOBIERNO BPM/SOA ... 18
1.5. METODOLOGÍAS DE GOBIERNO BPM/SOA DE REFERENCIA ... 19
1.5.1. IBM ... 19
1.5.2. Everware-CBDI ... 24
1.5.3. Software Associates ... 29
1.6. BUENAS PRÁCTICAS DE GOBIERNO BPM/SOA ... 33
1.6.1. Buenas prácticas de gobierno aportadas por Oracle ... 34
1.6.2. Buenas prácticas de gobierno aportadas por TIBCO ... 37
1.7. ANÁLISIS VALORATIVO DE LAS METODOLOGÍAS Y MARCOS DE REFERENCIA DE GOBIERNO CONSULTADOS ... 38
1.8. CONCLUSIONES PARCIALES ... 40
CAPÍTULO 2: DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA ... 41
2.1. INTRODUCCIÓN ... 41
2.2. ESTRUCTURA DEL MODELO ... 41
2.3. ALCANCE DEL MODELO... 41
2.4. PRINCIPIOS DEL MODELO ... 42
2.5. PREMISAS PARA LA APLICACIÓN DEL MODELO ... 43
2.6. ROLES PROPUESTOS POR EL MODELO ... 45
2.6.1. Gerente de Gobierno ... 45
2.6.2. Arquitecto de políticas... 45
2.6.3. Bibliotecario SOA ... 46
2.6.4. Gestor de métricas ... 46
2.6.5. Auditor de Gobierno ... 47
2.7. REPRESENTACIÓN DEL MODELO ... 47
2.8. DESCRIPCIÓN DEL MODELO ... 49
2.8.1. Organización del ámbito de Gobierno ... 50
2.8.2. Priorizar los objetivos de negocio ... 59
2.8.3. Preparar el escenario tecnológico de Gobierno ... 60
IX
2.8.4. Identificar y registrar los servicios de la empresa ... 61
2.8.5. Levantamiento y definición de normas ... 62
2.8.6. Definir parámetros de seguridad ... 78
2.8.7. Establecer el control de versiones ... 80
2.8.8. Definición del ciclo de vida de la arquitectura ... 81
2.8.9. Definición de métricas... 87
2.9. CONCLUSIONES PARCIALES ... 92
CAPÍTULO 3: VALIDACIÓN DE LA SOLUCIÓN PROPUESTA MEDIANTE EL CRITERIO DE ESPECIALISTAS ... 93
3.1. INTRODUCCIÓN ... 93
3.2. LOS MÉTODOS DE EXPERTOS ... 93
3.3. EL MÉTODO DELPHI ... 94
3.4. APLICACIÓN DEL MÉTODO ... 96
3.4.1. Elección de los expertos ... 96
3.4.2. Elaboración del cuestionario de validación de la propuesta ... 99
3.4.3. Establecimiento de la concordancia de los expertos mediante el coeficiente de Kendall .... 100
3.4.4. Desarrollo práctico y explotación de resultados ... 102
3.5. RESULTADOS DE LA VALIDACIÓN DEL MODELO ... 106
3.5.1. Resultados obtenidos de la encuesta de validación ... 108
3.6. CONCLUSIONES PARCIALES ... 114
CONCLUSIONES GENERALES ... 115
RECOMENDACIONES ... 116
BIBLIOGRAFÍA CITADA ... 117
BIBLIOGRAFÍA CONSULTADA ... 121
ANEXOS ... 127
GLOSARIO DE TÉRMINOS ... 178
X
ÍNDICE DE FIGURAS
Figura 1. Valor aportado por la Arquitectura Orientada a Servicios ... 10
Figura 2. Jerarquía y relación de las formas de Gobierno ... 13
Figura 3. Elementos del Gobierno BPM/SOA ... 19
Figura 4. Metodología de gobierno propuesta por CBDI ... 24
Figura 5. Estructura típica de las organizaciones para Gobernar las TI ... 30
Figura 6. Principios del modelo ... 43
Figura 7. Premisas del modelo ... 44
Figura 8. Representación general del Modelo ... 48
Figura 9. Flujo de actividades de la Organización del ámbito de Gobierno ... 53
Figura 10. Flujo de actividades del Levantamiento y definición de normas ... 65
Figura 11. Flujo de actividades de la Definición de normas ... 69
Figura 12. Flujo de actividades de la definición del ciclo de vida de la arquitectura ... 83
Figura 13. Flujo de actividades de la definición de métricas ... 88
Figura 14. Representatividad de los expertos por especialidad... 107
Figura 15. Coeficiente de Competencia de los expertos ... 107
Figura 16. Nivel de adecuación de las Preguntas 1, 4, 5, 7, 8, 9, 10, 11 y 12 ... 108
Figura 17. Nivel de adecuación de la Pregunta 2 ... 109
Figura 18. Nivel de adecuación de la Pregunta 3 ... 109
Figura 19. Nivel de adecuación de la pregunta 6 ... 110
Figura 20. Nivel de adecuación de las preguntas de la encuesta ... 110
XI
ÍNDICE DE TABLAS
Tabla 1. Grados de influencia en la determinación del coeficiente de argumentación ... 98
Tabla 2. Coeficiente de competencia de los expertos ... 99
Tabla 3. Frecuencias absolutas para cada pregunta de la encuesta ... 103
Tabla 4. Frecuencias absolutas acumuladas ... 104
Tabla 5. Frecuencias relativas acumuladas ... 104
Tabla 6. Puntos de corte ... 106
Tabla 7. Grados de adecuación ... 106
Tabla 8. Evaluación del objetivo 1 ... 111
Tabla 9. Evaluación del objetivo 2 ... 112
Tabla 10. Evaluación del objetivo 3 ... 112
Tabla 11. Evaluación del objetivo 4 ... 112
Tabla 12. Evaluación del objetivo 5 ... 113
Tabla 13. Evaluación del objetivo 6 ... 113
1 INTRODUCCIÓN
INTRODUCCIÓN
Con el transcurso de los años se han incrementado los volúmenes de información que se manipulan así como la velocidad con que avanzan los negocios y las actividades comerciales, haciéndose casi imposible su gestión sin la utilización de tecnologías de cómputo y aplicaciones destinadas para ello. Esto conlleva a que en la actualidad, sea vital para el éxito de cualquier negocio la agilidad a la hora de adaptarse a los constantes cambios del mercado o de los procesos de la propia empresa. Sin embargo, mientras perduren las arquitecturas tecnológicas tradicionales, esa rapidez para lograr la adaptación será difícil de alcanzar, pues realizar estas transformaciones se convierte en una tarea muy compleja que pocos se atreven a llevar a cabo, ya que cualquier cambio tiene asociadas muchas otras modificaciones; la realización manual de estas, supone costos elevados para la empresa tanto en tiempo como en dinero.
Tratando de buscar una solución viable a esta situación, en los últimos años del siglo XX, comenzó a aparecer a nivel mundial un nuevo estilo para desarrollar las arquitecturas empresariales: la Arquitectura Orientada a Servicios (conocida como SOA por sus siglas en inglés). Esta arquitectura define un camino para todas aquellas empresas que deseen alinear la estrategia de su negocio con las Tecnologías de la Información (TI), al mismo tiempo que ayuda a agilizar los procesos y maximizar el rendimiento de los recursos. La adopción de SOA, ofrece a las empresas la posibilidad de mantener una infraestructura tecnológica y unos sistemas de información que sean flexibles y adaptables al continuo cambio en los procesos de negocio, capaces de mantenerse acordes y paralelos a las nuevas exigencias del mercado, que puedan ser modificados y configurados rápidamente.
De igual manera, ha irrumpido en la escena mundial la Gestión de Procesos de Negocio (conocida como BPM por sus siglas en inglés) convirtiéndose en una de las disciplinas de gestión más utilizadas en los últimos tiempos. Con BPM se puede tener una mejor perspectiva general de todos los procesos de negocio de una empresa y sus interacciones, además de permitir una gestión, optimización y automatización eficiente de los mismos. La adopción de BPM mientras se implementa SOA, permite la reutilización de sus componentes, minimizando la complejidad de los procesos de negocio.
Pero, para poder adoptar SOA exitosamente, es necesario aplicar un conjunto de políticas, estándares y procedimientos que aseguren que el modelo o proyecto que se está realizando cumpla con las
2 INTRODUCCIÓN
expectativas del cliente. Además, son necesarios mecanismos que aseguren una estructura sólida de toma de decisiones y relaciones entre servicios. A este conjunto de políticas, estándares, procedimientos y actividades de control y gestión, se le llama gobierno.
Desde hace varios años, Cuba decidió enfrentar el desarrollo, consolidación y expansión de la industria del software, por el amplio espectro económico que posee este mercado. Así fue que surgió en el año 2002, la Universidad de las Ciencias Informáticas (UCI), como punto central de la formación integral de profesionales y la producción de software de alta calidad.
Por todas las ventajas que aporta SOA, es que la UCI decide dar sus primeros pasos para adentrarse en el sector de este tipo de arquitectura y surge así, en el año 2008, el Centro de Consultoría Tecnológica e Integración de Sistemas. Dentro de este centro, ocupa un papel principal la atención a proyectos de adopción de SOA y la asesoría en temas relacionados con este tipo de arquitectura, así como la superación del personal que lo integra, para poder dar respuesta a cualquier situación que le presenten.
Uno de los principales problemas que ha encontrado este centro, en su desempeño y preparación, ha sido la dificultad para acceder a información referente a SOA, pues las principales compañías que a nivel mundial dominan este sector son privativas y por tanto no socializan sus conocimientos y obstaculizan el acceso a esa información. Esta situación ha provocado que el Centro de Consultoría no posea todos los recursos necesarios para capacitar a sus miembros y que además no se encuentre completamente preparado para enfrentar proyectos BPM/SOA, lo que implica que tampoco posea un modelo de gobierno que pueda utilizar en el momento de desarrollar algún proyecto de este tipo, pues aunque existen modelos para la gestión de la gobernabilidad en un proyecto BPM/SOA, no es posible obtenerlos de manera gratuita; incluso, de aquellos que se posee algún tipo de información, no es suficiente como para permitir la total comprensión de las actividades y elementos que los componen. Además, estos modelos existentes no se ajustan a las necesidades de la UCI, pues proponen el uso de herramientas y tecnología también de origen propietario y en algunos casos no ofrecen la flexibilidad que se requiere para poder adaptarlos a cualquier iniciativa de adoptar una infraestructura SOA.
Lo anteriormente expuesto, hace que se distinga como situación problemática que existen modelos de gobierno, pero son desarrollados por compañías privadas y por tanto no es posible acceder a todos los detalles que los componen; además de que los mismos no están acordes con las necesidades de la UCI y ofrecen poca flexibilidad para ajustarse a las características de cualquier empresa en la que decida
3 INTRODUCCIÓN
implantar una infraestructura SOA. Por consiguiente, la UCI, que busca insertarse en el sector de SOA, no posee un modelo de gobierno que pueda aplicar durante la fase de diseño en un proyecto de adopción de SOA, que permita definir los mecanismos y políticas necesarios durante el desarrollo del ciclo de vida del proyecto, así como los roles y responsabilidades de quienes deben llevarlo a cabo y que además sea adaptable a cualquier iniciativa corporativa de adoptar una Arquitectura Orientada a Servicios.
Por lo que se traza como problema a resolver: ¿Cómo desarrollar la gestión del gobierno durante la fase de diseño de un proyecto BPM/SOA, que asegure la orientación y normalización de las actividades a realizar?
Por tanto, el objeto de estudio de esta investigación es el Proceso de gestión de gobierno durante la fase de diseño en un proyecto BPM/SOA.
De ello se deriva que el campo de acción sean los Modelos de referencia de gobierno para la fase de diseño en un proyecto BPM/SOA.
Se plantea como objetivo general desarrollar un modelo para la gestión de la gobernabilidad durante la fase de diseño en un proyecto BPM/SOA.
Como guía de la investigación se trazan los siguientes objetivos específicos:
Establecer un marco conceptual relativo a la gobernabilidad BPM/SOA.
Caracterizar la situación actual de las metodologías de Gobierno BPM/SOA.
Obtener la propuesta de modelo de gobierno.
Validar por el método de expertos la propuesta de modelo para la gestión de la gobernabilidad durante la fase de diseño en un proyecto BPM/SOA.
Para dar cumplimiento a estos objetivos fueron trazadas las siguientes tareas:
Caracterización de los aspectos esenciales de SOA y BPM.
Caracterización de la gobernabilidad BPM/SOA.
4 INTRODUCCIÓN
Caracterización del estado del arte de las diferentes metodologías y buenas prácticas existentes para la gestión de la gobernabilidad durante la fase de diseño en un proyecto BPM/SOA.
Realización de un análisis crítico y valorativo de las fortalezas y debilidades de las metodologías y buenas prácticas encontradas.
Definición de los subprocesos y actividades involucrados en el gobierno durante la fase de diseño de un proyecto BPM/SOA.
Elaboración de todos los artefactos involucrados en el gobierno durante la fase de diseño de un proyecto BPM/SOA.
Definición de todos los roles involucrados en el gobierno durante la fase de diseño de un proyecto BPM/SOA.
Selección de los expertos para participar en la validación del modelo propuesto.
Elaboración de los cuestionarios de validación.
Valoración de los resultados obtenidos de la validación.
De la presente investigación, se espera como resultados:
Modelo formal de gestión de gobierno para la fase de diseño en un proyecto BPM/SOA, que provea todos los artefactos, herramientas, técnicas, roles y sus responsabilidades, que garantice una guía clara sobre cómo aplicar el gobierno en el desarrollo de un proyecto BPM/SOA.
Actualización del estudio del arte asociado a las metodologías de gestión de Gobierno BPM/SOA.
El presente documento cuenta con un Resumen, una Tabla de Contenidos, Introducción, tres Capítulos, seguido de Conclusiones, Recomendaciones, Bibliografía, Glosario de Términos y Anexos.
El Capítulo 1 brinda un breve acercamiento a los principales conceptos asociados al dominio del problema y que son abordados a lo largo del trabajo, así como un estado del arte de las principales metodologías y buenas prácticas usadas en la actualidad para el gobierno BPM/SOA, que han servido de apoyo para la solución del problema planteado.
5 INTRODUCCIÓN
En el Capítulo 2 se define el modelo el cual es objetivo principal este trabajo, describiéndolo de manera gráfica y textual, de forma sencilla y explícita. Además, esta explicación de la solución que se propone, refleja los artefactos de entrada y salida, herramientas, técnicas, roles y sus responsabilidades que forman parte del modelo de solución.
En el Capítulo 3 se plantean las facilidades y potencialidades de los sistemas de expertos, realizando la validación de la propuesta con la aplicación del Método Delphi y la utilización del criterio de un grupo de expertos asociados a la Universidad.
6 CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA
CAPÍTULO 1: FUNDAMENTACIÓN TEÓRICA
1.1. INTRODUCCIÓN
Durante la realización de este capítulo se analizan los principales conceptos y definiciones asociados al dominio del problema que son necesarios para el desarrollo de la investigación. De acuerdo con esto, se ofrece un enfoque de los aspectos fundamentales relacionados con la Arquitectura Orientada a Servicios (SOA), la Gestión de los Procesos de Negocio (BPM) y el Gobierno BPM/SOA, como aspecto medular en el aseguramiento del éxito a la hora de adoptar una arquitectura BPM/SOA. Además, se realiza un estudio del estado del arte de las principales metodologías de gobierno que existen a nivel internacional realizando un análisis crítico y valorativo de cada una de ellas.
1.2. CONCEPTOS ASOCIADOS AL DOMINIO DEL PROBLEMA
En este epígrafe se muestran los conceptos más importantes relacionados con el problema, para de esta manera lograr un mejor entendimiento del modelo propuesto.
1.2.1. Arquitectura Orientada a Servicios 1.2.1.1. Antecedentes de SOA
Desde hace varias décadas, los departamentos encargados de las TI en las empresas, han sentido la necesidad de gestionar sus recursos y para ello han elaborado soluciones que soporten las operaciones de la organización y sus clientes, llegando a crear infraestructuras lo suficientemente potentes y eficientes como para lograr este objetivo (Parra, 2003). Como resultado de este proceso, se ha logrado la creación y mantenimiento de un número considerable de aplicaciones que funcionan en el interior de las empresas y que cada una tiene sus tareas propias dentro de la infraestructura, pero todas concebidas de manera independiente y que no permiten la interoperabilidad. A medida que van cambiando aceleradamente los mercados y los procesos de negocio, se hace necesario un mayor nivel de especialización, en el que las empresas tienen que introducir aplicaciones cada vez más complejas, con menos tiempo y presupuesto que antes. En muchos casos crear estas aplicaciones requiere de funcionalidades ya antes
7 CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA
implementadas como parte de otros sistemas. Al presentarse esta situación, los arquitectos de software tienen dos opciones para realizar su trabajo:
Tratar de reutilizar funcionalidades que ya estén implementadas en otros sistemas, lo cual no resulta tan sencillo, ya que estas aplicaciones no fueron diseñadas para integrarse, pues generalmente se encuentran implementadas sobre plataformas y/o tecnologías incompatibles.
Reimplementar la funcionalidad requerida, lo cual implica mayor tiempo de desarrollo.
Aunque no sea la más acertada, es la segunda variante la más usada por parecer fácil y segura; esto trae consigo varios resultados adversos: funcionalidades replicadas en varias aplicaciones; dificultad de migración de los sistemas internos, al haber múltiples conexiones desde sistemas que dependen de estos para su funcionamiento; aparición de fallas, al no existir una estrategia de integración de aplicaciones;
poca escalabilidad; pobre respuesta al cambio.
Todo esto trae aparejado, que las empresas busquen soluciones viables para estas dificultades, de manera que logren despojarse de las consecuencias provocadas por la baja interoperabilidad que traen consigo las arquitecturas tecnológicas tradicionales. De esta manera surge la perspectiva SOA, que implica un cambio significativo respecto al modelo tradicional de TI, pues en lugar de estructurar las aplicaciones a base de funciones, componentes y objetos, pasa a estructurarlas alrededor del concepto de servicios, que pueden ser expuestos mediante un conjunto de tecnologías estándares para su uso por otras aplicaciones. Así, las empresas han ido apuntando poco a poco hacia SOA, por las grandes ventajas que ha ido mostrando, especialmente desde el año 2000, que es cuando empieza a irrumpir con mayor fuerza en el mercado mundial, aunque las primeras definiciones de SOA fueron aportadas por Gartner1 en 1996.
1Gartner es la compañía líder a nivel internacional en el campo del asesoramiento en temas relacionados con las Tecnologías de la Información; tiene su sede en Standford. Las áreas de tecnología que la empresa incluye dentro de sus alcances las organiza de tres modos: de investigación por mercado, de investigación por asuntos y de investigación por industrias.
8 CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA
1.2.1.2. Definición de SOA
Actualmente, no existe una definición única de lo que es SOA, o dicho de otra manera, existen múltiples definiciones, que dependen del organismo de estandarización, empresa o consultora del sector de las TI que la emita.
A estos efectos, se pueden ver algunas definiciones de SOA realizadas por los principales organismos de estandarización:
Según la Organización para la Mejora de las Normas de Información Estructurada (conocida como OASIS2 por sus siglas en inglés), SOA es “un paradigma para organizar y utilizar capacidades distribuidas, funciones que pueden estar bajo el control de diferentes dominios, proporcionando un medio uniforme para ofrecer, descubrir y utilizar dichas capacidades para producir los efectos deseados para cubrir una necesidad” (OASIS, 2006). Tras esta formal definición, se esconde la intención de plasmar una definición de SOA en términos de necesidades y capacidades, de forma que una arquitectura SOA proporciona un mecanismo de armonizar las necesidades de consumidores de servicios con las capacidades ofrecidas por proveedores de servicios.
Para El Grupo Abierto (The Open Group3), una arquitectura SOA no es más que “un estilo arquitectural que soporta orientación a servicios” (Harding, 2006). Por estilo arquitectural se entienden los aspectos que definen o expresan un tipo específico de arquitectura, y por orientación a servicios el modo de pensar y enfocar el desarrollo basándose en la definición del concepto de servicio.
Para el Grupo de Gestión de Objetos (conocido como OMG4 por sus siglas en inglés), una arquitectura SOA es un “estilo arquitectural para una comunidad de consumidores y proveedores de servicios para alcanzar valor mutuo” (Harrison, 2007), de forma que:
2OASIS: Organization for the Advancement of Structured Information Standards; es un consorcio internacional sin fines de lucro que orienta el desarrollo, la convergencia y la adopción de estándares de comercio electrónico y servicios web.
3Open Group es un consorcio de la industria del software que provee estándares abiertos neutrales para la infraestructura de la informática. Es muy famoso por sus sistemas de certificación de la marca UNIX.
4 OMG: Object Management Group; es un consorcio dedicado al cuidado y el establecimiento de diversos estándares de tecnologías orientadas a objetos tales como UML, XMI y CORBA. El grupo está formado por compañías y organizaciones de software como son: Hewlett-Packard (HP), IBM, Sun Microsystems y Apple Computer.
9 CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA
Se permite a los participantes de la comunidad, el trabajo conjunto con mínima dependencia tecnológica.
Especifica los contratos a los que las organizaciones, personas y tecnologías deben adherirse para participar en la comunidad.
Garantiza que el valor y los procesos de negocio son aportados por la comunidad.
Permite el uso de una gran variedad de tecnologías para facilitar las interacciones dentro de la comunidad.
Por su parte, Gartner expresa que “SOA es una arquitectura de software que comienza con una definición de interface y construye toda la topología de la aplicación como una topología de interfaces, implementaciones y llamados a interfaces. Sería mejor llamada Arquitectura Orientada a Interfaces. SOA es una relación de servicios y consumidores de servicios, ambos suficientemente amplios para representar una función de negocios completa” (GARTNER, 2004).
SUN5 expresa que: “Una arquitectura orientada a servicios es una estrategia donde las aplicaciones se basan en servicios disponibles en una red. Siendo una manera de compartir funciones (típicamente de negocios) en una manera flexible y extendida” (SUN, 2006).
A pesar de todas estas definiciones, utilizando sencillamente la propia traducción del término SOA, se podría definir como un paradigma de arquitectura de software que cuenta con la orientación a servicios como su principio fundamental de diseño.
La Arquitectura Orientada a Servicios no se trata de software o de un lenguaje de programación, es un marco de trabajo conceptual que permite a las organizaciones unir los objetivos de negocio con la infraestructura de las TI integrando los datos y la lógica de negocio de sus sistemas separados.
5 Sun Microsystems es una empresa informática de Silicon Valley, fabricante de semiconductores y software. Las siglas SUN se derivan de Stanford University Network, proyecto que se había creado para interconectar en red las bibliotecas de la Universidad de Stanford.
10 CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA
Mediante SOA las empresas pueden alcanzar un alto rendimiento a través de tres factores fundamentales:
diferenciación en el mercado, simplificación interna en la operación, así como flexibilidad y rapidez de adaptación al cambio.
Figura 1. Valor aportado por la Arquitectura Orientada a Servicios 1.2.2. Gestión de los procesos de negocio
De forma reciente, un gran número de empresas han identificado acertadamente la Gestión de los Procesos de Negocio (conocida como BPM por sus siglas en inglés) como la forma más segura para mejorar su rendimiento, eficiencia y eficacia. El objetivo fundamental de BPM es perfeccionar y aumentar los resultados de la empresa a través de la administración y gestión sistemática de los procesos de negocio, que se deben modelar, automatizar, integrar, monitorizar y optimizar de forma continua.
Un proceso de negocio no es más que un conjunto de tareas o actividades relacionadas lógicamente que permiten crear valor transformando una entrada en una salida logrando así un resultado de negocio concreto (Martínez, 2008).
11 CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA
1.2.2.1. Definición de BPM
La Gestión de los Procesos de Negocios engloba todas las actividades que son parte del ciclo de vida de un proceso de negocio, tales como el descubrimiento, diseño, simulación, despliegue, ejecución, interacción, monitoreo, control, análisis y optimización del proceso de negocio (JBoss, 2005).
Por tanto, BPM en una empresa es el área o campo de conocimiento que resulta de la intersección entre la gestión de sus procesos y las TI, que abarca las técnicas, métodos y herramientas para diseñar, representar, controlar y analizar los procesos de negocio operacionales que involucran a personas, organizaciones, aplicaciones y documentos en el contexto de una empresa. Al hablar de procesos de negocio operacionales se hace referencia a los procesos que se realizan de forma repetitiva en el día a día de las organizaciones, en contraposición a procesos estratégicos de decisión que se realizan en los niveles directivos de las organizaciones.
1.2.2.2. Beneficios de BPM
Las empresas que han aplicado BPM, han reportado beneficios que se traducen en la mejora de sus capacidades de dirección, la reducción de obstáculos para reaccionar ante cambios del mercado, y la adquisición de una mayor capacidad de análisis sobre el desempeño de la empresa. Otras ventajas de BPM son:
Mayor visibilidad de los procesos de las empresas.
Mayor flexibilidad y agilidad para adaptación al cambio.
Posibilidad de integrar la información del negocio dispersa en diferentes sistemas.
Dirigir los esfuerzos de la empresa de una manera planificada y alineada con los objetivos estratégicos.
Adquirir la habilidad para diseñar, simular y monitorear procesos de manera automática y sin la participación de usuarios técnicos.
Reducir costos futuros de integración y mantenimiento al adquirir nueva tecnología.
12 CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA
Lograr estos beneficios es el resultado de la aplicación metódica de prácticas de gestión, de la implantación y adopción de formas de operar automatizadas y estratégicamente seleccionadas (Sánchez, 2004).
1.2.3. Integración de SOA y BPM
En la actualidad, todas las empresas buscan la satisfacción de las expectativas y las necesidades de sus clientes y usuarios de una manera práctica y sustentable. Pero para esto se necesita: coordinar esfuerzos, optimizar el uso de los recursos e integrar los activos y componentes actuales y futuros de las TI de manera que respondan a los procesos surgidos de la estrategia organizacional. La manera más viable para lograr esto es mediante la integración de SOA y BPM.
Estas dos visiones tienen el mismo objetivo, pero utilizan medios diferentes para conseguirlo. SOA y BPM son complementarios y permiten optimizar las aportaciones de cada uno gracias a sus propias virtudes (Desbouis, 2008). En efecto, SOA está dirigida a las TI, mientras que BPM se orienta hacia el negocio.
La unión de ellas permite entonces una mejor adecuación entre los objetivos de los servicios informáticos y los objetivos de negocio. Además, la comunicación entre las dos está basada en el objetivo común de mejorar el rendimiento.
Por tanto, puede decirse que BPM y SOA forman parte de la misma estrategia, ofreciendo una infraestructura abierta, permitiendo un cambio rápido de las aplicaciones o servicios y asegurando el cumplimiento de los objetivos del negocio (Desbouis, 2008).
1.2.4. Gobierno
En toda empresa es necesario tener un conjunto de directivas, funciones, responsabilidades y procesos para guiar, dirigir y controlar el uso de las tecnologías, manejar la toma de decisiones, formular estrategias y asegurar el logro de los objetivos que se hayan trazado (Microsoft Corporation, 2007). Las estructuras creadas para lograr esto, son las que en el marco de esta investigación están definidas como gobierno y para el caso específico de una empresa que decida adoptar una Arquitectura Orientada a Servicios, se define como Gobierno BPM/SOA.
13 CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA
1.2.4.1. Definiciones de Gobierno
La definición de Gobierno BPM/SOA debe ser vista necesariamente, en el contexto de sus relaciones con otras formas de gobierno que resultan relevantes para su definición y que se encuentran estrechamente relacionadas dentro de una misma empresa. En este sentido se pueden distinguir:
El gobierno empresarial o corporativo.
El gobierno de las Tecnologías de la Información.
1.2.4.1.1. Gobierno corporativo
Según Vepa Kamesam6, el “Gobierno Corporativo significa hacer todo de una forma más adecuada, con el objetivo de mejorar las relaciones entre la compañía y sus accionistas; mejorar la calidad de los miembros de la Junta Directiva; animar a la administración a pensar a largo plazo; asegurar que la información financiera es apropiada; asegurar que la gerencia es fiscalizada en el mejor interés de los accionistas”
(Kamesan, 2005).
Figura 2. Jerarquía y relación de las formas de Gobierno
De manera sencilla, el gobierno corporativo establece las políticas y las reglas a partir de las cuales la empresa dirige su negocio. Para ello, se tienen en cuenta la estrategia de la organización, el mercado al cual se orienta y las bases de su negocio. En otras palabras, el gobierno empresarial cubre, de alguna manera, todos los aspectos relacionados con el negocio.
6 Vepa Kamesam, Gerente del Instituto nacional de seguridad y gestión de riesgos de la India.
14 CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA
1.2.4.1.2. Gobierno de las TI
En la actualidad existen varios criterios relacionados con lo que significa gobierno de las Tecnologías de la Información.
Booby Woolf, arquitecto de la compañía Máquinas Internacionales de Negocios (conocida como IBM7 por sus siglas en inglés y coloquialmente llamada el Gigante Azul) define el gobierno de las TI como “la aplicación de gobierno a una organización de TI, sus personas, procesos e información para guiar la forma en la que esos activos apoyan las necesidades del negocio” (Woolf, 2006).
Analizando lo visto hasta este momento, se puede llegar a la conclusión de que el gobierno de las TI es parte integral del gobierno corporativo y es la estructura organizacional y el conjunto de procesos y procedimientos que gestionan y controlan las actividades de las TI para alcanzar los objetivos de negocio.
Determina el marco para la toma de decisiones y la responsabilidad para fomentar el comportamiento deseado en el uso de las TI.
Su objetivo es asegurar que las tecnologías aporten valor a la empresa y que el riesgo asociado a ellas esté bajo control.
1.2.4.2. Gobierno BPM/SOA
El Gobierno BPM/SOA, es un tema relativamente nuevo, por lo cual, existen varias definiciones asociadas al término:
Booby Woolf define el Gobierno BPM/SOA como “una especialización del gobierno de TI que pone las decisiones claves del gobierno de TI dentro del contexto del ciclo de vida de los componentes, servicios y procesos de negocio” (Woolf, 2006).
Gartner lo define como “asegurar y validar que los activos y artefactos dentro de la arquitectura están actuando como se espera y manteniendo un cierto nivel de calidad” (Windley, 2006).
7 IBM: International Business Machine; es una empresa que fabrica y comercializa hardware, software y servicios relacionados con la informática. Tiene su sede en Amonk (Estados Unidos) y está constituida como tal desde el 15 de junio de 1911, pero lleva operando desde 1888.
15 CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA
Anne Thomas Manes8 lo define como “los procesos que una empresa pone en funcionamiento para asegurarse que las cosas son hechas correctamente; esto es, en concordancia con las mejores prácticas, principios arquitectónicos, regulaciones de la industria, leyes y otros factores determinantes” (Thomas, 2005).
Ian Charlesworth, analista de OVUM9, da la siguiente definición: “el gobierno de SOA implementa el marco de referencia de las políticas, procesos y rendición de cuentas requeridos para asegurar una implantación y una administración exitosa de una SOA, en apoyo a las necesidades principales y objetivos del negocio” (Charlesworth, 2007).
Con la base de estas definiciones y el análisis de las formas de gobierno presentadas, se puede conceptualizar el Gobierno BPM/SOA como una especialización del gobierno de las TI, que ofrece la capacidad de crear, operar, controlar y hacer evolucionar cualquier iniciativa corporativa BPM/SOA para satisfacer los objetivos de la empresa, a través del establecimiento de los mecanismos y políticas necesarios para asegurar que los principios de la orientación a servicios y la arquitectura distribuida de la organización sean gestionados adecuadamente y que los servicios sean capaces de satisfacer los objetivos del negocio. O sea, que se enfoca en la gestión del ciclo de vida de los servicios con el fin de garantizar el valor de negocio de SOA.
Cuando se habla de Gobierno BPM/SOA, existe la tendencia de dividirlo en dos campos del ciclo de vida de una solución BPM/SOA: el gobierno en tiempo de diseño y el gobierno en tiempo de ejecución (Porras, 2008):
Gobierno en tiempo de diseño (o gobierno para la fase de diseño)
Es el encargado de gobernar las actividades definidas para la creación y evolución de los elementos del modelo de la arquitectura BPM/SOA (identificación, modelado, diseño, desarrollo y pruebas) (Software Associates, 2007).
8 Anne Thomas Manes es directora de Investigaciones del Grupo Burton, una firma consultora y de investigación. Anne es ampliamente reconocida como experto en la industria de los servicios web. Es autora de varios libros relacionados con el tema.
9 OVUM es una consultora líder en la prestación de servicios de asesoramiento sobre el impacto comercial de la tecnología y los cambios en el mercado de las telecomunicaciones, software y servicios de las TI.
16 CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA
El Gobierno en tiempo de diseño asegura que la implementación de SOA se haga de acuerdo con lo establecido. Por lo tanto, este gobierno debe elegir un enfoque de diseño que debe ser el más adecuado para la situación específica que presente la empresa.
La herramienta fundamental que se utiliza para el Gobierno BPM/SOA en tiempo de diseño es el Registro y Repositorio, el cual se encarga de la gestión, control, diseño, desarrollo y despliegue de los servicios.
Gobierno en tiempo de ejecución (o Gobierno para la fase de ejecución)
Es el encargado de operar los elementos del modelo una vez que estos han sido desplegados (ejecutarlos, controlar su ejecución, definir y enviar alarmas, monitorizar los acuerdos de nivel de servicio, hacer cumplir políticas de seguridad, etc.) (Software Associates, 2007).
Sin embargo ambas etapas están fuertemente interconectadas y las dos son importantes en el ciclo de vida de los procesos y servicios; las decisiones tomadas durante el gobierno en tiempo de diseño influyen en los resultados en tiempo de ejecución.
El gobierno en tiempo de diseño típicamente abarca las fases de planeación, diseño, implementación y prueba de los servicios. Los actores en tiempo de diseño son personas que pueden tomar muchas decisiones técnicas y de negocio, que aclaran y establecen interfaces, identifican servicios reusables y desarrollan y prueban las implementaciones de los servicios.
En cambio, durante el gobierno en tiempo de ejecución las personas sólo están involucradas como usuarios; los actores son a menudo servicios en producción. En esta etapa, los servicios o aplicaciones compuestas llaman a otros servicios utilizando parámetros reales y políticas.
El gobierno en tiempo de diseño, constituye la esencia de esta investigación y aunque cada empresa debe aplicar el modelo que más se ajuste a sus características, se pueden identificar algunas funcionalidades generales que debe cubrir este gobierno y con las cuales coinciden la mayoría de los expertos del tema:
Desarrollo de una estructura que agrupe los miembros del gobierno.
Definición y asignación de roles.
17 CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA
Identificación de servicios de la empresa.
Identificación de aspectos no funcionales y propuesta de mejoras asociadas.
Desarrollo de una herramienta para el registro de los servicios.
Definición de normas.
Gestión del ciclo de vida de los servicios.
Auditorías y registros.
1.3. IMPORTANCIA DEL GOBIERNO BPM/SOA
Como se ha visto hasta aquí SOA define un camino para todas aquellas organizaciones que desean alinear la estrategia de su negocio con las TI, al mismo tiempo que agiliza sus procesos y maximiza el rendimiento de sus recursos. A lo largo del tiempo, los servicios necesitarán adaptarse a nuevas funcionalidades requeridas e incluso variar su comportamiento según van cambiando las necesidades del negocio. Por este motivo, esta alineación entre negocio y tecnología implica adaptarse a los constantes cambios que surgen en la empresa con el fin de evitar la creación de servicios con funcionalidades similares o la existencia de múltiples versiones de un mismo servicio.
Debido al incremento de la flexibilidad y la amplia interacción organizacional de los servicios de negocios que proporciona SOA, el gobierno constituye uno de los aspectos más importantes a la hora de adoptar dicho modelo, ya que se hace necesario un marco para el desarrollo de la toma de decisiones, un seguimiento preciso, una mayor capacidad de servicio y una mejor comunicación. La buena gobernabilidad de SOA es el mecanismo para garantizar una sólida estructura de toma de decisiones, una evolución integrada de los procesos organizacionales y la tecnología, una apropiada gestión de los servicios y una garantía de cumplimiento de las normas que regulan el funcionamiento de una empresa.
Sólo una empresa que reconozca la importancia de una efectiva gobernabilidad y un enfoque sostenible podrá beneficiarse con la transición a SOA, de lo contrario corre el riesgo de perder el control de sus sistemas y por ende las ventajas de un buen gobierno (NEORIS, 2007).
18 CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA
Un informe realizado por IDC10 para InfoWorld11 (Bastida, 2008) sobre la adopción de SOA durante el año 2007 revela que la mayor causa (con una cuota del 50%) por la que las empresas no se deciden a adoptar una SOA es la falta de un modelo de Gobierno BPM/SOA. Sin embargo, es necesario resaltar que la importancia que se le está dando a definir un buen modelo de Gobierno BPM/SOA ha aumentado durante los últimos años, viéndose hoy en día como una necesidad para poder implantar con éxito cualquier infraestructura SOA.
1.4. ELEMENTOS DEL GOBIERNO BPM/SOA
Para adoptar e implantar SOA en una empresa, es necesario el gobierno de todos los elementos implicados en la nueva arquitectura, desde el proceso de diseño hasta la monitorización y control (Software Associates, 2007). Estos elementos son:
Organización: Se definen los grupos de trabajo y roles necesarios en la empresa para que se puedan identificar los problemas existentes, decidir sobre ellos, hacer cumplir esas decisiones, monitorizar su efectividad y eficiencia, revisarlas y optimizarlas.
Normas: Se establecen procesos, procedimientos y políticas como consecuencia de las decisiones tomadas, que permitan gobernar las actividades relevantes para SOA, tanto de actores humanos como automáticos, de forma tal que sirvan lo mejor posible a las necesidades de la empresa. Las mismas deben estar escritas en un formato adecuado para que los actores puedan identificarlas, además se hace necesario que dispongan de mecanismos que las impongan, así como de medios que controlen y monitoricen su efectividad y eficiencia.
Tecnología: Este elemento establece el uso de toda la tecnología necesaria para poder llevar a cabo una gobernabilidad de forma eficaz y eficiente, que permita: definir, desplegar y poner en efecto las políticas, tanto en tiempo de diseño como de ejecución; controlar, monitorizar y gestionar las operaciones de la infraestructura SOA.
10 IDC es un proveedor global de inteligencia de mercado, servicios de asesoría y eventos para los mercados de tecnologías de la información, telecomunicaciones y tecnología de consumo.
11 InfoWorld es un medio de comunicación en línea y negocio de eventos dedicado a las Tecnologías de la Información que forma parte de una división del Grupo Internacional de Datos (International Data Group, conocido como IDG por sus siglas en inglés).
19 CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA
Figura 3. Elementos del Gobierno BPM/SOA
1.5. METODOLOGÍAS DE GOBIERNO BPM/SOA DE REFERENCIA
Motivados por el creciente desarrollo de la rama de BPM/SOA, muchas compañías han creado marcos de trabajo y metodologías para la gestión de la gobernabilidad durante el desarrollo de proyectos de este tipo.
Pero, todos pertenecen a empresas privadas y exigen altas sumas de dinero para acceder a todos sus detalles, lo cual hace que para la presente investigación no se cuente con toda la información existente sobre estas metodologías, aunque con los documentos consultados se ha podido sentar las bases para la propuesta.
Las metodologías más importantes en materia de gestión de Gobierno BPM/SOA identificadas son las desarrolladas por IBM, Software Associates12 y CBDI13.
A continuación se describirán brevemente cada una de estas compañías y sus metodologías.
1.5.1. IBM
A lo largo de los últimos años, IBM ha puesto todo su empeño en mostrar las ventajas que traen aparejadas las Arquitecturas Orientadas a Servicios (IBM, 2007). Esta compañía cuenta con casi 3 000
12 Software Associates es una compañía que se encarga de ofrecer Consultoría Tecnológica Avanzada especializada en seguridad de servicios web, interoperabilidad y soluciones tecnológicas basadas en SOA.
13 CBDI: Component Based Development and Integration; es una empresa con amplia experiencia en la aplicación de conceptos de orientación a servicios, metodologías y establecimiento de buenas prácticas relacionadas con SOA.
20 CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA
clientes de SOA y más de 2 500 socios de negocio, lo que la convierte en una de las empresas líderes en el desarrollo y adopción de SOA. Su trabajo actualmente está centrado en cuatro áreas:
El uso de BPM para sacar provecho de las ventajas de una arquitectura SOA basada en estándares.
El gobierno como base del éxito de la arquitectura SOA.
La preparación de infraestructuras de las TI para SOA.
La creación de servicios SOA especializados por sectores industriales.
IBM desarrolló la Metodología de Administración y gobierno para SOA, que describe un modelo para el Gobierno BPM/SOA y da un enfoque de los recursos a través de los cuales se implementa esta forma de gobierno. Constituye una estructura de desglose del trabajo para la planificación de proyectos, que cuenta con recomendaciones y tareas detalladas para cada fase del ciclo de vida del Gobierno BPM/SOA.
1.5.1.1. Metodología de Administración y Gobierno BPM/SOA de IBM
Esta Metodología de Administración y Gobierno de SOA de IBM (IBM SOA Governance and Management Method, conocido como SGMM por sus siglas en inglés) es flexible y fácilmente adaptable, que permite cumplir metas específicas y entender mecanismos de gobierno existentes.
Define el gobierno y administración del ciclo de vida SOA a través de cuatro fases:
Planificar Definir Habilitar Medir
El SGMM es iterativo y proporciona oportunidades para permitir que la autoridad del gobierno se centre en determinadas áreas en una iteración inicial y luego en las siguientes áreas en las siguientes iteraciones.
21 CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA
Las actividades que se realizan en cada una de estas fases tributan a la gestión del ciclo de vida de los servicios, que se define en tres etapas: Desarrollo de servicios, Despliegue de servicios y Administración de servicios.
1.5.1.1.1. Planificar
La fase de planificación se centra en entender el alcance global de las oportunidades de negocio dentro de la empresa y la identificación de las áreas para la mejora. Las principales tareas que propone esta fase son:
Establecer la necesidad de un gobierno y determinar qué esfuerzos se necesitan priorizar para la próxima iteración de trabajo del gobierno.
Definir una estrategia para SOA que esté acorde con las metas globales de la empresa y la estrategia de las TI.
Determinar el nivel que tiene la empresa en cuanto a las TI.
Estructurar y refinar la visión y estrategia para SOA.
Estudiar el ambiente de gobierno existente para mantener los mecanismos efectivos de gobierno que existan.
Definir y refinar el alcance del modelo de gobierno SOA.
Comprobar la buena disposición de la empresa para aceptar y adoptar cambios requeridos.
La mayoría de estas actividades son centradas en las personas y para su realización requieren de la comunicación con ellas y por consiguiente de su colaboración.
1.5.1.1.2. Definir
Cuando se identifican las oportunidades para el perfeccionamiento del gobierno, puede realizarse un trabajo de conjunto entre los miembros del equipo de adopción de SOA y los responsables de las TI en la empresa, para definir y modificar las configuraciones y mecanismos del gobierno existentes en la
22 CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA
empresa. Esto trae aparejado que se adopten nuevas estrategias para crear políticas. Es decir, se deben tomar otras decisiones y mecanismos importantes en lo referido al gobierno:
Definir o refinar el negocio y los principios SOA, así como la visión acerca de las TI.
Definir y refinar políticas, estándares y todos los aspectos operacionales del ciclo de vida de los servicios.
Definir mecanismos de gobierno que abarquen todas las estructuras organizativas y procesos, roles y sus responsabilidades asociadas y todos los aspectos requeridos para soportar el modelo de gobierno.
Identificar capacidades adicionales requeridas, así como posibles versiones mejoradas para la infraestructura de las TI.
Identificar las competencias que requiere el personal, y los planes de entrenamiento y superación.
Establecer políticas para la gestión del ciclo de vida de los servicios que cumplan con los lineamientos del negocio.
Establecer mecanismos que garanticen el establecimiento de los niveles de servicio.
Definir la infraestructura necesaria para soportar SOA y el gobierno SOA.
Definir medidas y métricas que indiquen la efectividad del modelo de gobierno.
1.5.1.1.3. Habilitar
Durante esta fase se ponen en práctica las soluciones que fueron definidas para cubrir las necesidades del gobierno. Usando uno de los artefactos que se definen en la fase anterior (el Plan de transición), el SGMM implementa varios elementos definidos en el modelo de gobierno. Estas soluciones que se implementan pueden incluir nuevas o enriquecidas configuraciones para el gobierno.
Las principales tareas que propone esta fase son:
Posibilitar los cambios organizativos en el gobierno SOA.
23 CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA
Lograr la integración del gobierno SOA, los planes y el adiestramiento del personal de la empresa.
Desplegar la infraestructura tecnológica requerida para soportar el gobierno SOA y establecer el Plan de administración.
1.5.1.1.4. Medir
Durante esta fase, se monitorizan las configuraciones de gobierno y los mecanismos que fueron identificados en la segunda fase y desplegados en la tercera fase. Las actividades que ocurren en esta fase ayudan a asegurar que se está cumpliendo con los procedimientos, políticas y estándares que fueron definidos y que se está trabajando en función de lograr las metas establecidas para el nuevo marco de trabajo de gobierno; además identifica si hay oportunidades para que el negocio refine e incremente su efectividad de gobierno con el comienzo de un nuevo ciclo para enriquecer el marco de trabajo del gobierno SOA.
1.5.1.2. Valoración de la Metodología propuesta por IBM
La metodología propuesta por IBM es iterativa y organiza el gobierno en cuatro fases, brindando una idea clara de la manera en que debe realizarse cada paso si se utiliza su metodología. De cada una de estas fases ofrece las actividades que la conforman, las entradas, salidas y roles que intervienen.
Todas las actividades que se realizan en el marco de esta metodología están encaminadas a lograr que el negocio mejore su rendimiento y aumente su competitividad. Los mecanismos de gobierno que ofrece la metodología tienen en cuenta todas las áreas de la empresa y los aspectos fundamentales relacionados con las personas que deben desempeñar tareas vinculadas a la nueva forma de arquitectura. Describe con suficiente claridad todos los roles que deben intervenir en el gobierno y las responsabilidades y competencias que debe tener cada uno de estos. Esta metodología está orientada al desarrollo conjunto de SOA con BPM, pero no brinda los pasos o actividades necesarios para lograr esta integración de una manera eficiente. Por otro lado, define todos los artefactos que se generan a lo largo de la aplicación del gobierno, pero no ofrece una descripción de los mismos, de los elementos que deben contener y de sus objetivos. Aporta una gran cantidad de herramientas que pueden ser utilizadas para la aplicación del gobierno, pero todas las que propone son de carácter propietario.
24 CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA
1.5.2. Everware-CBDI
Figura 4. Metodología de gobierno propuesta por CBDI
Esta compañía es el resultado de la unión de Everware14 y CBDI Forum15. Plantea que una SOA necesita un marco de trabajo de gobierno que se ajuste a los resultados del negocio y de las TI de la empresa, y que sea compatible con los enfoques de gobierno para las TI y del negocio de las organizaciones actuales.
14 Everware: Empresa estadounidense especializada en Arquitecturas Empresariales y Arquitecturas Orientadas a Servicios (SOA).
15 CBDI Forum: Empresa británica enfocada a la difusión de las mejores prácticas en la adopción exitosa de una SOA, a través de consultores independientes, educación y una base de conocimientos global.
25 CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA
1.5.2.1. Metodología de gobierno de CBDI
La metodología de gobierno SOA propuesta por CBDI plantea que es importante que la gestión del gobierno se realice de una manera equilibrada y completa para que se pueda definir con claridad y desarrollar la organización, la madurez, la infraestructura, los procesos y las políticas (qué, quién, cómo y cuándo) (Everware-CBDI, 2008).
CBDI realiza la gestión del gobierno mediante cinco vistas:
Vista de políticas.
Vista organizacional.
Vista de madurez.
Vista de infraestructura.
Vista de procesos.
1.5.2.1.1. Vista de políticas
Esta metodología plantea que la gobernabilidad estará garantizada si se logra una correcta identificación y ajuste de políticas.
Para cada categoría de políticas:
Define las metas del negocio para las TI.
Describe cómo los objetivos del negocio son traducidos en objetivos de SOA.
Identifica los riesgos potenciales.
Define la jerarquía de políticas necesaria para garantizar los resultados esperados para cada categoría de gobierno desarrollada.
26 CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA
CBDI plantea que las políticas se deben establecer para todo el ciclo de vida de los servicios, donde se deben definir las políticas adecuadas y en correspondencia con esto establece cinco categorías de políticas asociadas a este ciclo de vida:
Planeación: organizar y controlar los servicios.
Arquitectura: garantizar la calidad arquitectónica y la integridad.
Abastecimiento: determinar y controlar los servicios de abastecimiento.
Uso: determinar y controlar los servicios de uso.
Operacional: controlar el tiempo de ejecución de los servicios.
Además se establecen tres categorías más asociadas a las políticas que representan las actividades que se ejecutan a través de este ciclo de vida: Buenas prácticas, Servicio de gestión de activos y Organización.
1.5.2.1.2. Vista de Procesos
Esta vista se centra en los componentes de los procesos: sus tareas y entregables. En muchas ocasiones aumenta la complejidad de los procesos de gobierno SOA al mezclar la gerencia con las inquietudes operacionales. Por lo tanto, en esta vista el gobierno SOA separa estos elementos para asegurar su éxito en el cumplimiento de sus objetivos.
El nivel administrativo, el cual debe controlarse centralmente, asegura el buen funcionamiento del marco de trabajo de gobierno en términos de políticas, organización, procesos y requerimientos de infraestructura.
En esta vista se establecen y supervisan políticas relacionadas con los procesos que deben seguirse para establecer el gobierno SOA.
27 CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA
1.5.2.1.3. Vista de Organización
En esta vista se estructura la organización de la empresa. Se definen los roles y las responsabilidades de cada uno. Estos roles se encuentran específicamente enfocados a las cuestiones del gobierno SOA; por ejemplo la junta directiva y los líderes de gobierno SOA.
En esta vista CBDI incorpora una nueva estructura: El Centro de Excelencia SOA, que contiene un grupo de roles que conforman esta nueva unidad organizacional de la empresa.
Para la asignación de los roles y responsabilidades utiliza un método llamado RAEW16. Es importante definir políticas que establecen cuáles roles son responsables de qué artefactos, en términos de la responsabilidad (R), autoridad (A), habilidad (E) y el trabajo (W).
Esto significa que la asignación de responsabilidades en el gobierno para una persona o equipo está dado por:
Tiene Responsabilidad para tomar decisiones y realizar acciones con el fin de garantizar que las tareas sean realizadas.
Tiene Autoridad para controlar o evaluar las acciones de los demás roles.
Tiene la Habilidad para contribuir.
Hace el Trabajo.
1.5.2.1.4. Vista de Infraestructura
La vista de infraestructura aporta las capacidades de infraestructura necesarias para el gobierno SOA. En esta vista hay una extensa variedad de tipos de implementación, tanto automatizados como manuales. El objetivo fundamental de esta vista es enfocar la atención en las capacidades de gobierno en términos de:
Administración de políticas.
Mecanismos de ejecución.
16 RAEW: Este método adquiere su nombre de las siglas anglosajonas provenientes de Responsibility (R), Authority (A), Expertise (E) y Work (W).