ARTÍCULO ORIGINAL

 

Bases para crear un modelo de madurez para Arquitecturas Orientadas a Servicios

 

Bases for creating a maturity model for Service Oriented Architectures

 

 

Arturo César Arias-Orizondo, Vivian Estrada-Senti

Universidad de las Ciencias Informáticas (UCI). La Habana, Cuba.

 

 

---

RESUMEN

La adopción por las organizaciones de Arquitecturas Orientadas a Servicios (SOA, por sus siglas en inglés), muestra altas tasas de fracaso. Las principales causas apuntan al modo en que es adoptado este paradigma. La complejidad de este proceso debe ser abordada empleando el enfoque evolutivo que ofrecen los modelos de madurez de SOA; sin embargo, la diversidad de estos dificulta la selección y aplicación de alguno. Por lo anterior, el objetivo de este trabajo consistió en realizar un análisis comparativo entre los modelos de madurez más representativos y determinar si son suficientes para evaluar y planificar con efectividad la adopción de SOA. Las insuficiencias detectadas, valoradas integralmente, limitan las capacidades de evaluación y planificación que ofrecen los modelos. Con el propósito de superarlas y empleando la experiencia internacional acumulada en esta materia, fueron definidos los constructos (principios, elementos y estructura) que sustentan un modelo de madurez más integral.

Palabras clave: arquitectura orientada a servicios (SOA), adopción de SOA, modelo de madurez.

---

ABSTRACT

The adoption of Service Oriented Architectures (SOA) by the companies shows high failure rates, mainly because of the way this paradigm is adopted. Thus, the complexity of this process should be addressed by using the evolutionary approach that maturity models offer. However, the diversity of maturity models makes difficult the selection and implementation of most of them. Taking this into account, the objective of this paper is to carry out a comparative analysis between the most representative maturity models and to determine whether they are sufficient in order to evaluating and planning the adoption of SOA with effectiveness. The inadequacies detected after a comprehensive assessment, restrict the evaluation and planning capacities that these models offer. In order to overcome them and using the international experience gained in this field, it were defined the constructs (principles, elements and structure) that support a more integral maturity model.

Key words: services oriented architecture (SOA), SOA adoption, maturity model.

---

 

 

INTRODUCCIÓN

La Arquitectura Orientada a Servicios (SOA, por sus siglas en inglés) es un estilo arquitectónico sustentado en la orientación a servicios, paradigma en el que los recursos son particionados y representados como servicios. SOA permite exponer capacidades de las Tecnologías de la Información (TI) y del negocio para ser empleadas en contextos diferentes, recombinar dichas capacidades y crear aplicaciones compuestas más complejas con independencia de la tecnología subyacente. La generación de nuevas soluciones que respondan a las necesidades de la organización mediante la reutilización de activos existentes, le confiere a las TI mayor eficiencia, flexibilidad e interoperabilidad, lo que facilita su alineación con el negocio.

Adoptar SOA requiere partir de un proyecto empresarial integral, concebido como un proceso continuo bajo un pensamiento estratégico y una implementación táctica. La misma parte de una visión estratégica global, evoluciona en el tiempo y afecta a toda la organización. Además, se desarrolla a través de un programa para completar objetivos de negocio mediante proyectos.

En la práctica la adopción de SOA ha resultado compleja y no siempre se han obtenido los beneficios esperados, razón por la que buena parte de las iniciativas ha fracasado. En el sector empresarial el fracaso se ubica en el rango del 50 % al 70 %. Un estudio hecho a 20 compañías por el Burton Group en 2008, mostró que el fracaso fue del 50 % y del resto, un 30 % no se consideró fracasada la iniciativa pero tampoco exitosa [1].

El éxito depende del modo en que SOA es adoptada. En este empeño por lo general no falla la tecnología. Su implementación y uso más que un reto técnico es un asunto organizacional [2]. En consecuencia, las buenas prácticas para adoptar este paradigma aún deben madurar. La adopción de SOA es un evento contemporáneo para el cual no se ha establecido una teoría científica sustancial. El tema ha sido insuficientemente tratado en la academia a diferencia de los aspectos técnicos. Por ello, la forma en que se adopta SOA para generar los beneficios esperados a un costo razonable, sigue siendo objeto de examen [3].

Los profesionales de TI deben contar con las herramientas que les permitan enfocarse y asegurar los aspectos claves para crear sistemas de información más eficientes usando SOA. Los modelos de madurez son de utilidad en esta tarea. El enfoque evolutivo que ofrecen permite manejar la complejidad inherente a la adopción de SOA [4]. Con ellos es posible planificar una hoja de ruta a partir de una evaluación del estado actual de la adopción de SOA y la definición de un estado deseado. Sin embargo, la mayoría de los modelos de madurez para SOA, están basados en prácticas o factores de éxito derivados de la experiencia en proyectos pero carentes de una teoría de base [5].

La ausencia de un sustento metodológico demuestra que esta es un área aún por madurar. Por lo anterior, fueron planteados como objetivos de este trabajo, identificar y valorar insuficiencias de modelos de madurez de SOA, así como determinar si los mismos son suficientes para evaluar y planificar con efectividad la adopción de este paradigma en las organizaciones. Con el propósito de superar las insuficiencias detectadas, fueron definidos los constructos (principios, elementos y estructura) que sustentan un modelo de madurez más integral, en interés de lograr una evaluación y planificación más efectiva del proceso de adopción de SOA.

 

MÉTODOS

El desarrollo de un modelo de madurez se enmarca dentro de las Ciencias del Diseño, donde la investigación se ejecuta a través del proceso de construcción y evaluación de artefactos [6]. Van Steenbergen (2010), propone una metodología para el desarrollo de modelos de madurez aplicada con éxito al campo de la Arquitectura Empresarial (AE) [7]. Esta sugiere realizar un análisis comparativo entre modelos de madurez existentes, para identificar el problema y los objetivos de la solución.

En esta investigación se adoptó este enfoque para detectar y valorar insuficiencias de los modelos de madurez de SOA. Mediante el análisis de la literatura especializada, tanto académica como empresarial, se identificaron modelos de madurez representativos de SOA. Se empleó además el método analítico-sintético para elaborar los principios que sustentan el diseño de un modelo de madurez que supera las insuficiencias detectadas y para arribar a conclusiones.

Para este estudio fueron definidos un conjunto de atributos identificados a partir del análisis documental y el criterio de expertos. Estos cubren aspectos relevantes a considerar durante la adopción de SOA:

• A1: Si el modelo evalúa las capacidades arquitectónicas creadas con respecto a una arquitectura SOA de referencia [8].
• A2: Si el modelo concibe la adopción de SOA como parte del desarrollo de la Arquitectura Empresarial de una organización [9; 10].
• A3: Si el modelo evalúa la madurez de la adopción de SOA en función de los beneficios que esta genera [11].
• A4: Si el modelo refleja la existencia de relaciones de dependencia entre las capacidades que se crean durante el proceso de adopción de SOA [7].
• A5: Si existe acceso libre y completo a la información del modelo (disponibilidad del modelo) [5].

Los atributos fueron analizados en los siguientes modelos de madurez, reconocidos por la literatura especializada e incluidos en un estudio previo realizado por los autores [12]:

• M1: Domain Model for SOA. BEA System, Inc. (empresa adquirida por Oracle).
• M2: The New SOA Maturity Model. Sonic Software.
• M3: Oracle SOA Maturity Model.
• M4: Service Oriented Architecture Maturity Model. Microsoft.
• M5: HP SOA Maturity Model. Hewlett-Packard.
• M6: The SOA Maturity Model. CBDI Inc.
• M7: SOA Maturity Model. Infosys.
• M8: iSOAMM. Independent SOA Maturity Model. Research Center for IT (FZI), Germany.
• M9: The Service Integration Maturity Model (OSIMM v2). The Open Group.
• M10: Service Oriented Architecture Maturity. Propuesto por los académicos Welke, Hirschheim & Schwarz (2011).

 

RESULTADOS

Los resultados de la evaluación de cada uno de los atributos anteriormente definidos en los modelos de madurez para SOA identificados, se muestran en la tabla 1. Los resultados se expresan en: Sí, cuando se verificó la existencia de evidencia explícita que el atributo evaluado es considerado por el modelo; parcialmente (P), cuando, aunque no existe evidencia explícita se aprecia que el atributo es considerado por el modelo; pobremente (P-), cuando no se evidencia que el atributo evaluado es incorporado intencionalmente en el modelo aunque se aprecia que no lo desconoce del todo y No, cuando definitivamente el modelo no considera el atributo. La tabla 1 incluye información adicional sobre la cantidad de dominios y niveles de madurez de los modelos, así como el año de creación de los mismos.

El estudio arrojó que existen casi tantos modelos de madurez para SOA como compañías de consultoría informática o fabricantes de tecnología. Ello evidencia que aún no existe un estándar establecido para esta disciplina, lo que dificulta la elección y aplicación de alguno de los modelos.

En la figura 1 se aprecia, a partir de una cuantificación de los resultados, que ninguno de los modelos consideró completamente la totalidad de los atributos. Los atributos mejor valorados fueron A1 (evaluar la madurez con respecto a una arquitectura de referencia) y A2 (coherencia con la Arquitectura Empresarial). Los peor valorados fueron A4 (relaciones de dependencia entre las capacidades) y A3 (madurez en función de beneficios). Los resultados demuestran la necesidad de profundizar en la integración de estos elementos en un modelo de madurez para SOA.

Por lo general no se apreció una asociación clara entre modelos de madurez y una arquitectura de referencia estándar para SOA, de modo que no son evaluados todos los aspectos relevantes de la arquitectura bajo un patrón uniforme. Dentro de las excepciones se aprecia el modelo OSIMM v2 que declara emplear como arquitectura de referencia a: “The OASIS Reference Architecture for SOA Foundation” y “The Open Group SOA Reference Architecture”.

La coherencia que debe existir entre un programa de adopción de SOA y el desarrollo de la Arquitectura Empresarial de la organización ha sido un aspecto ampliamente abordado por la literatura [9]. Ambas arquitecturas comparten metas comunes, constituyen estrategias de cambio en las organizaciones que buscan optimizar sus recursos de TI, cubren los mismos dominios arquitectónicos y se obtienen mejores resultados si se ejecutan como parte de un mismo programa. El modelo de madurez de Oracle y el OSIMM v2 declaran que están basados en “The Open Group Architecture Framework” (TOGAF) como marco de trabajo de Arquitectura Empresarial; en cambio, en el resto de los modelos de madurez no es explícita la relación con alguno de los marcos de trabajo de AE existentes. En relación a los dominios arquitectónicos que describen la AE, en los modelos analizados el dominio información/datos es tratado con menor profundidad, excepto en los modelos de Oracle, CBDI y OSIMM v2. De igual modo se apreció que los modelos de madurez para SOA profundizan menos en los aspectos de gestión de la arquitectura, considerados con mayor fuerza en los marcos de trabajo de Arquitectura Empresarial y sus respectivos modelos de madurez.

Todos los modelos analizados representan la madurez mediante un número fijo de niveles. Sin embargo, mostraron diferentes criterios sobre cómo evaluarla, al emplear enfoques distintos para caracterizar los niveles de madurez.

En cuanto a los beneficios, estos se enuncian en varios de los modelos, pero no se explica cómo medirlos para justificar un nivel de madurez. Solo el modelo de HP ofrece una herramienta adicional para evaluar los activos, las capacidades creadas y la agilidad que logra la organización.

No siempre son evidentes las relaciones de dependencia que deben existir entre las capacidades que se crean durante la adopción de SOA. El marco de referencia SOA de CBDI reconoce que las capacidades deben desarrollarse siguiendo un orden, por lo que establece relaciones de dependencia entre ellas. Sin embargo, en la mayoría de los modelos de madurez, las capacidades dentro de un dominio evolucionan de manera independiente, sin considerar la existencia de relaciones con capacidades de otros dominios (relaciones interdominios).

Como resultado del análisis de los atributos definidos, se apreció además que todas las dimensiones/dominios y las respectivas capacidades sobre las que se evalúa la madurez de la arquitectura, tienen el mismo peso en el desarrollo de la iniciativa SOA. Esto dificulta trazar un plan de mejora como resultado de la evaluación y abordar aquellas capacidades que no han sido desarrolladas siguiendo un orden de importancia, tal como lo propone el “Organizational Project Management Maturity Model” (OPM3) [13].

A las insuficiencias anteriormente mencionadas se suma la escasa información disponible de los modelos desarrollados por las principales compañías internacionales de la industria del software, a los que solo es posible acceder libremente a información general, pues el instrumento de evaluación forma parte del “know how” de dichas instituciones y es protegido como patrimonio intelectual. En cambio, los modelos desarrollados por organizaciones internacionales, grupos académicos o instituciones gubernamentales, brindan mayor información, aunque algunos modelos a la fecha del estudio no estaban terminados (el modelo 10).

En síntesis, de las áreas menos valoradas es posible destacar que los modelos de madurez mostraron insuficiencias que atentan contra el proceso de evaluación y planificación de la adopción de SOA debido a que:

• Todos los modelos revisados representan la madurez mediante un número fijo de niveles. Esto constituye una simplificación excesiva cuando se valoran fenómenos complejos [7]. Para favorecer análisis locales más profundos, dimensiones diferentes deben tener distintos niveles de madurez. Distinguir un mayor número de niveles permite definir pasos más pequeños para avanzar entre ellos, lo que ofrece una guía más detallada para el desarrollo de las capacidades.
• Las relaciones de dependencia entre capacidades que pertenecen a diferentes dominios de madurez no son evidentes. Esto no favorece sugerir un orden para desarrollar las capacidades considerando dichas relaciones. A juicio de los autores, algunas áreas necesitan lograr cierto grado de madurez para garantizar el avance de otras.
• Todas las capacidades se muestran con el mismo nivel de importancia relativa, lo que no contribuye a establecer un orden de prioridad para su desarrollo.
• Los modelos no están orientados a evaluar el resultado en sí (los beneficios de la adopción de SOA), pues no exigen datos objetivos para determinar un nivel de madurez (son modelos informativos). Además, si bien los beneficios son enunciados en la mayoría de los modelos, no queda establecida una relación explícita entre ellos y las capacidades que los generan. Esto limita la identificación y desarrollo de las capacidades que contribuyen directamente a lograr los resultados esperados
• Por defecto la adopción de SOA es a nivel de la organización. Sin embargo, pueden existir otras consideraciones que influencien la decisión del alcance de la iniciativa. En los modelos de madurez no es posible distinguir aquellas capacidades que se requieren para distintos alcances. Excepto el de Oracle, el resto de los modelos no se adapta a alcances específicos.
• Los modelos son menos precisos para abordar los aspectos organizacionales que influyen en la adopción de SOA. Este proceso, que por lo general fracasa debido a razones no técnicas, requiere que sean desarrolladas aquellas capacidades que garantizan una adecuada gestión de la arquitectura. Los modelos que mejor abordan la gestión de la arquitectura desde la perspectiva de la organización, mediante la aplicación de buenas prácticas de Arquitectura Empresarial (los modelos de Oracle, HP y CBDI), no brindan libremente toda la información necesaria para su aplicación. Sin embargo, es posible encontrar para este aspecto una alternativa en los modelos de madurez de AE, siendo estos más explícitos que los primeros en relación a las capacidades que debe crear la organización para gestionar la arquitectura.

La figura 2 muestra la relación entre la integralidad de los modelos y la disponibilidad de los mismos. Teniendo en cuenta que los modelos no mostraron contradicciones y sí aspectos en los que se complementan, es posible emplear los mejor valorados como puntos de partida para obtener un modelo más integral que supere las insuficiencias detectadas.

Principios para diseñar el modelo de madurez

Con el propósito de superar las insuficiencias detectadas y contribuir a mejorar la capacidad de los modelos de madurez para evaluar y planificar la adopción de SOA, fueron definidos un conjunto de principios que consideran aspectos relevantes de este proceso e integran las mejores prácticas, fruto de la experiencia internacional acumulada en esta materia:

1. Garantizar la coherencia (alineación) entre la Arquitectura Empresarial y SOA. Para ello el modelo debe considerar aspectos que evalúan los modelos de madurez de AE. Ambas iniciativas comparten dominios arquitectónicos y persiguen metas comunes, por lo que seguir rutas distintas complejizaría su gobernanza [9]. No contar con un modelo integrado SOA/AE, dificulta diseñar un programa de adopción de SOA efectivo y alineado con el desarrollo de la Arquitectura Empresarial de la organización.

2. Evaluar las capacidades arquitectónicas creadas con respecto a una arquitectura de referencia definida para SOA. El objetivo es identificar los elementos que faltan o que requieren ser adaptados en la arquitectura sobre una base estándar, para generar prioridades a ser resueltas en el tiempo [8].

3. Considerar las capacidades que paulatinamente debe desarrollar la organización para sustentar la adopción de SOA, teniendo en cuenta que las principales causas de fracaso de estas iniciativas no son técnicas, sino organizacionales [14; 2]. Para enriquecer el modelo en este aspecto, resultan referencias válidas la experiencia acumulada sobre factores de éxito y fracaso de iniciativas SOA ejecutadas y los modelos de madurez de Arquitectura Empresarial.

4. Evaluar el avance de la adopción de SOA en función de los beneficios que esta genera a la organización, razón que justifica cualquier inversión en TI. Para ello, el modelo debe clarificar la forma en que SOA genera los beneficios que promete, mediante la definición de relaciones causa-efecto que conectan a las capacidades con los beneficios que generan (experiencia tomada del Organizational Project Management Maturity Model OPM3, desarrollado por el Project Management Institute) [13].

5. Sugerir un orden para desarrollar las capacidades. Para lograrlo, estas se posicionan en el modelo atendiendo a las relaciones de dependencia que entre ellas existan (experiencia tomada de los modelos de madurez orientados a áreas focales) [7].

6. Favorecer la realización de análisis locales más profundos, al no forzar que los dominios de madurez tengan el mismo número de niveles (experiencia tomada de los modelos de madurez orientados a áreas focales) [7].

7. Establecer un nivel de prioridad para desarrollar las capacidades, al definir la importancia relativa de unas con respecto a otras (experiencia tomada del Organizational Project Management Maturity Model OPM3, desarrollado por el Project Management Institute) [13].

8. Acompañar al modelo de madurez de un mecanismo que permita su adaptación a la organización donde se aplique. Para ello este debe soportarse sobre una estructura flexible que permita adaptarse a alcances específicos y distinguir las capacidades que son necesarias de acuerdo al alcance de la adopción de SOA (experiencia tomada del modelo de madurez SOA de Oracle [15]). Además, debe ofrecer facilidades para ajustar el instrumento de evaluación.

9. Concebir el modelo de madurez como una base de conocimientos que refleje la experiencia de expertos en la adopción de SOA. Mediante un mecanismo de retroalimentación controlada, el modelo deberá actualizarse cada vez que se identifiquen nuevos factores que influyen en este proceso. Para facilitar su empleo y retroalimentación, el modelo debe estar disponible en línea para practicantes y académicos.

Elementos esenciales que conforman el modelo de madurez y sus relaciones

Para garantizar que se obtenga un modelo de madurez efectivo y coherente con los principios anteriormente definidos, fueron establecidos los elementos esenciales que lo conforman y sus relaciones. Los mismos son ilustrados en la figura 3 y descritos a continuación:

• Beneficios o metas de adopción: La adopción de SOA tiene como propósito la obtención de beneficios para la organización. Estos pueden ser cuantificados mediante indicadores, los que permitirían evaluar cuantitativamente la adopción de SOA en función de los resultados que se obtengan. A su vez, los beneficios conectados con las capacidades que los habilitan siguiendo la lógica causa-efecto, clarifican la forma en que SOA genera los beneficios que promete, permitiendo además establecer que las capacidades estarán ratificadas si generan beneficios.

Adoptar esta filosofía para estructurar el modelo, mejora la forma en que se evalúa la adopción de SOA. La mayoría de los modelos de madurez son informativos (no cuentan con un modelo de evaluación asociado que exija datos objetivos y de calidad para determinar un nivel de madurez) y se enfocan a evaluar el desempeño de los procesos. En cambio, los procesos son solo habilitadores del resultado, no el resultado en sí y la contribución de los procesos como habilitadores es relativamente modesta [16].

Teniendo en cuenta que durante la adopción de SOA las metas se alcanzan de manera paulatina y su consecución marca la evolución exitosa de la iniciativa [17], una evaluación más objetiva de este proceso debe apoyarse en la determinación de los beneficios que se generan y asociarlos a los distintos niveles de madurez. Entonces, las capacidades ubicadas por niveles de madurez solo estarían logradas si generan beneficios.

• Capacidades técnicas y organizacionales: La adopción de SOA debe ser cuidadosamente analizada desde la perspectiva técnica y organizacional [18]. Para ello el modelo distingue capacidades técnicas y organizacionales, diferenciando así aspectos propios del desarrollo de la arquitectura y los de su gestión. Adicionalmente, a las capacidades se les asigna un nivel de importancia relativa, lo que facilita la priorización durante la planificación.
• Modelo de referencia: Para identificar las capacidades de acuerdo a un patrón uniforme es necesario contar con un modelo de referencia. En principio, las arquitecturas SOA de referencia (ejemplo: The OASIS Reference Architecture for SOA Foundation” y “The Open Group SOA Reference Architecture”) pueden emplearse para este fin; sin embargo, aspectos particulares de la adopción de SOA (ejemplo: gobierno SOA, arquitectura de datos, métodos y otros) pueden requerir referencias adicionales para profundizar y completar lo que proponen las arquitecturas de referencia.
• Organización de las capacidades: Las capacidades se ubican en áreas focales, las que a su vez se agrupan en dimensiones (dominios de madurez). En las áreas focales los niveles de madurez de cada una dependen del análisis particular al que esté orientada la función de madurez que se aplique, buscando maximizar beneficios, mayor formalidad y sistematicidad de los procesos, mayor robustez de las herramientas y de la infraestructura, etc. Esto posibilita distinguir distintos niveles de madurez entre las áreas focales y realizar análisis locales más profundos.
• Alcance del programa SOA: Para evaluar la madurez de SOA en una organización es necesario considerar su alcance. SOA puede iniciarse como un proyecto piloto. Luego ejecutarse como iniciativa de un departamento (áreas funcionales o unidades de negocio). Si el proyecto es validado, puede establecerse como iniciativa donde los servicios se convierten en activos empresariales compartidos para toda la organización, hasta crear un ecosistema SOA como parte intrínseca del negocio y las TI. No existe una relación uno a uno entre el alcance y la madurez (relacionada con los beneficios que se obtienen como se expresó anteriormente). Es posible generar beneficios crecientes dentro de un mismo alcance y por tanto, lograr mayor nivel de madurez [19]. Obviamente, estos beneficios tendrán mayor impacto en alcances mayores.

Por lo anterior, definir el alcance del programa SOA es esencial, pues en este ámbito para alcanzar beneficios se requieren crear capacidades técnicas y organizacionales. Luego, con la expansión progresiva de la iniciativa, aumenta el alcance, se incrementa el número de involucrados y beneficiarios, se complejiza el programa de adopción y se imponen nuevos requisitos técnicos y organizacionales para alcanzar mayores beneficios y mantener los ya obtenidos.

De los modelos de madurez analizados, el de Oracle asume esta filosofía de trabajo, al plantear que se adapta a alcances específicos. Considerando estos elementos, el modelo de madurez será más preciso si se definen instancias de este para alcances bien establecidos, para los que se determinan las capacidades que son necesarias.

Representación de la madurez

Los modelos de madurez orientados a áreas focales descritos por Van Steenbergen (2010) [7], son apropiados para representar la madurez teniendo en cuenta los principios anteriormente establecidos. A diferencia de los modelos tradicionales, que tienen un número fijo de niveles, en este tipo de modelo cada área focal tiene sus propios niveles de madurez.

Las áreas focales que se definen responden a aspectos que deben ser implementados hasta cierto nivel para que sean efectivos dentro de un dominio funcional. Las áreas focales deben cubrir los dominios relevantes para la adopción de SOA. Para cada área focal se asocian un número de capacidades específicas. Una capacidad es definida como una habilidad requerida para alcanzar una meta predefinida asociada a un determinado nivel de madurez. Las capacidades se posicionan en una matriz de madurez de tal modo que reflejen relaciones de dependencia intraprocesos e interprocesos.

En la figura 4 se ejemplifica cómo en la matriz de madurez es posible distinguir las relaciones de dependencias entre capacidades de áreas focales distintas. De esta forma el modelo muestra el orden en que las capacidades deben ser desarrolladas mediante pasos progresivos.

Funcionamiento del modelo

Definidos los principios, los elementos que conforman el modelo y sus relaciones, así como la estructura para organizar las capacidades y representar la madurez, a continuación se describe el funcionamiento del modelo, articulando armónicamente los constructos anteriormente establecidos.

Con la aplicación del modelo se persiguen dos objetivos fundamentales: evaluar el estado actual de la adopción de SOA y planificar los próximos pasos. Primero el modelo debe ajustarse a las características de la iniciativa en curso en la organización. Para ello se determina el alcance en que se adopta SOA para identificar las capacidades que se requieren en ese escenario, de modo que se obvien durante la evaluación aquellas capacidades propias de otros alcances. Posteriormente se aplica el instrumento de evaluación, consistente en un cuestionario asociado a las capacidades. Con las respuestas obtenidas es posible determinar las capacidades logradas y con ello el nivel de madurez alcanzado en cada área focal. En este punto se verifica si se evidencian los beneficios asociados a dichas capacidades y en algunos casos será posible su cuantificación. Entonces quedarán ratificadas las capacidades para las que se confirmen los beneficios que prometen.

Una vez obtenido el nivel de madurez por cada área focal, se identifican las capacidades ubicadas en el próximo nivel de madurez de cada una. Estas serán las siguientes a desarrollar. Las capacidades primero se ordenan de acuerdo a las relaciones de dependencia que entre ellas exista, de modo que se desarrollen primero aquellas que se requieren para el completamiento de otras. Posteriormente se ordenan de acuerdo al nivel de importancia relativa asignado a cada una. De esta forma las de mayor importancia relativa tienen prioridad.

La figura 5 ilustra los pasos para completar los procesos de evaluación y planificación anteriormente descritos.

 

DISCUSIÓN

Los principales aportes de esta investigación consisten en la identificación de insuficiencias que afectan la capacidad de los modelos de madurez de SOA para evaluar y planificar la adopción de este paradigma en las organizaciones. Además, en la integración de experiencias positivas en materia de modelos de madurez para definir los constructos (principios, elementos y estructura) que sustentan un modelo de madurez más integral, contribuyendo a superar las insuficiencias detectadas.

Seleccionar la estructura que proponen los modelos de madurez orientados a áreas focales, facilita la planeación de la mejora, respetando el orden en que las capacidades deben ser desarrolladas al definir un camino incremental y balanceado que toma en cuenta las capacidades de todas las áreas focales. Además permite la realización de análisis locales más profundos, al distinguir un mayor número de niveles de madurez que resultan en pasos más pequeños entre los niveles, ofreciendo una guía más detallada para establecer prioridades en el desarrollo de las capacidades. Estas características los hacen más apropiados para expresar combinaciones complejas de diferentes factores que determinan la efectividad de un área funcional.

Por otro lado, relacionar en un mismo modelo los beneficios con las capacidades que los generan, contribuye a evaluar con mayor efectividad la madurez de la adopción de SOA y a planificar el proceso de adopción en función de resultados, identificando y desarrollando las capacidades que contribuyen a lograrlos. No obstante, esta tarea plantea un reto, pues en la literatura no se aprecia una definición estándar de los beneficios y la forma de cuantificarlos. Si bien varios autores coinciden en identificar los beneficios más notables que debe generar la adopción de SOA [20], [4], [17] (reúso de aplicaciones y datos, flexibilidad de TI, interoperabilidad, incremento de la agilidad organizacional, reducción de costos de TI, entre otros), aún no existe uniformidad en su categorización, en la forma en que se conectan los beneficios de TI con los de negocio y en la definición del momento en que estos se alcanzan durante la adopción de SOA. Esto se debe a que los impactos de SOA en la organización ha sido el área menos investigada [21], debido a la relativa “infancia” en que se encuentra la adopción de este paradigma [22]. Tampoco existe un estudio empírico que evalúe el valor de SOA al negocio desde una perspectiva integral [23].

Ante esta situación, resulta imprescindible sintetizar los diferentes enfoques con que se abordan los beneficios SOA y sus relaciones por la literatura especializada. Para lograrlo es factible aplicar la idea de Afshar (2008), jefe de arquitectos SOA de Oracle, relativa a la creación de un mapa de beneficios [24]. Con ello es posible conectar a los habilitadores SOA (las capacidades) con los beneficios que estos generan a las TI y al negocio. De tal forma quedarían conectados al modelo de madurez capacidades y beneficios, siguiendo la lógica “causa-efecto”.

Un modelo desarrollado sobre estos constructos, puede emplearse además para diagnosticar las capacidades iniciales de las organizaciones que pretenden adoptar SOA y evaluar sus posibilidades reales de ejecutar la iniciativa. Adicionalmente, permitirá detectar en función de los resultados que se estén obteniendo, si la adopción de SOA no está resultando exitosa, de no constatarse los beneficios esperados.

 

CONCLUSIONES

1. Como resultado del análisis comparativo entre modelos de madurez representativos de SOA, se detectaron insuficiencias que limitan la capacidad de estos modelos para evaluar y planificar la adopción de Arquitecturas Orientadas a Servicios en las organizaciones.

2. Mediante la integración de experiencias positivas en materia de modelos de madurez, fueron definidos los constructos (principios, elementos y estructura) que sustentan un modelo de madurez más integral. Estos permiten superar las insuficiencias detectadas y contribuyen a mejorar la capacidad de un modelo de madurez para evaluar y planificar la adopción de SOA.

 

REFERENCIAS

1. ORIZONDO, A., ¿Es suficiente la tecnología para garantizar el éxito de iniciativas SOA? , La Habana, Actas del Taller de Impacto Social de las TIC. IV Conferencia Científica de la Universidad de las Ciencias Informáticas. UCIENCIA 2012, 2012, ISBN 978-959-286-019-3.

2. MACLENNAN, E., BELLE, J., «Factors affecting the organizational adoption of service-oriented architecture (SOA)» Information Systems and e-Business Management, 2013, vol. 11, no. 1, pp. 1-30, ISSN 1617-9846.

3. CIGANEK, A., HAINES, M., HASEMAN, W., «Service Oriented Architecture Adoption: Key Factors and Approaches» Journal of Information Technology Management, 2009, vol. XX, no. 3, pp. 42-54, ISSN 1042-1319.

4. WELKE, R., HIRSCHHEIM, R., SCHWARZ, A., «Service Oriented Architecture Maturity» Computer, 2011, vol. 44, no. 2, pp. 61-67, ISSN 0018-9162.

5. METTLER, T., «A Design Science Research Perspective on Maturity Models in Information Systems», en University of St.Gallen - Institute of Information Management, 2009, [consulta: 2012-04-12]. Disponible en: <https://www.alexandria.unisg.ch/export/DL/214532.pdf>

6. HEVNER, A., MARCH, S., «Design Science in Information Systems Research» MIS Quarterly, 2004, vol. 28, no. 1, pp. 75–105, ISSN 0276-7783.

7. STEENBERGEN, M., BOS, R., «The design of focus area maturity models», en 5th International Conference on Design Science Research in Information Systems and Technology Berlin, Springer Berlin Heidelberg, 2010, vol. 6105, pp. 317-332. [consulta: 2013-02-13]. ISBN 978-3-642-13334-3. Disponible en: <http://link.springer.com/chapter/10.1007%2F978-3-642-13335-0_22>

8. ZIMMERMANN, A. ZIMMERMANN, G., «ESARC - Enterprise Services Architecture Reference Cube for Capability Assessments of Service-oriented Systems», en Third International Conferences on Advanced Service Computing Roma, SERVICE COMPUTATION 2011, 2011, [consulta: 2013-01-24]. ISBN 978-1-61208-152-6. Disponible en: <http://toc.proceedings.com/14356webtoc.pdf>

9. KISTASAMY, C., A. VAN DER, M., DE LA HARPE, A., «The Relationship between Service Oriented Architecture and Enterprise Architecture», en 14th IEEE International Enterprise Distributed Object Computing Conference Workshops Vitoria, IEEE Computer Society, 2010, pp. 129-137. [consulta: 2012-10-23]. ISBN 978-0-7695-4164-8. Disponible en: <http://dl.acm.org/citation.cfm?id=1909661>

10. POSTINA, M., TREFKE, J., STEFFENS, U., «An EA-Approach to Develop SOA Viewpoints», en IEEE Computer Society, 14th IEEE International Enterprise Distributed Object Computing Conference Vitoria, 2010, pp. 37-46. [consulta: 2012-10-23]. ISBN 978-0-7695-4163-1. Disponible en: <http://dl.acm.org/citation.cfm?id=1909770>

11. O’SULLIVAN, R., BUTLER, T., O’REILLY, P., «Realizing the Business Value of Service-Oriented Architecture: The Construction of a Theoretical Framework», en 6th European Conference on Information Management and Evaluation, Cork, Ireland, 2012, pp. 258-266. [consulta: 2013-01-24]. ISBN 978-1-908272-66-9. Disponible en: <http://connection.ebscohost.com/c/articles/82397577/realizing-business-value-service-oriented-architecture-construction-theoretical-framework>

12. ORIZONDO, A., ESTRADA SENTÍ, V., «Abordando la adopción de SOA desde un enfoque evolutivo más integral», en XV Convención y Feria Internacional Informática 2013. III Taller Internacional Las TIC en la Gestión de las Organizaciones La Habana, 2013, ISBN 978-959-7213-02-4.

13. PROJECT MANAGEMENT INSTITUTE, Organizational Project Management Maturity Model (OPM3), 1st. ed., Pennsylvania, Project Management Institute, 2003, ISBN 978-1-930699-08-3, pp. 179.

14. GERIC, S., VRCEK, N., «Prerequisites for successful implementation of Service-Oriented Architecture», en 31st International Conference on Information Technology Interfaces Dubrovnik, 2009, pp. 175-180. [consulta: 2012-10-03]. ISBN 978-953-7138-15-8. Disponible en: <http://old.foi.hr/CMS_home/znan_strucni_rad/konferencije/IIS/2007/papers/T04_08.pdf>

15. HENSLE, B., DEB, M., «SOA Maturity Model - Guiding and Accelerating SOA Success», en Oracle Corporation 2008, [consulta: 2012-04-14]. Disponible en: <http://www.oracle.com/technetwork/topics/entarch/oracle-wp-soa-maturity-model-176717.pdf>

16. WALKER, A. J., «Enterprise Maturity Models: Have We Lost the Plot?» Computer, 2008, vol. 41, no. 11, pp. 96-98, ISSN 0018-9162.

17. MULIK, S., AJGAONKAR, S., SHARMA, K., «Where do you want to go in your SOA Adoption Journey?» IT Professional, 2008, vol. 10, no. 3, pp. 36-39, ISSN 1520-9202.

18. BASTIDA, L., BERRETEAGA, A., CAÑADAS, I., Adopting Service Oriented Architectures Made Simple, in Enterprise Interoperability III. New Challenges and Industrial Approaches, Londres, Springer London, 2008, ISBN 978-1-84800-220-3, pp. 221-232.

19. INAGANTI, S., ARAVAMUDAN, S., «SOA Maturity Model», [en línea], 2007, [consulta: 2011-05-05]. Disponible en: <http://www.bptrends.com/publicationfiles/04-07-ART-The%20SOA%20MaturityModel-Inagantifinal.pdf>

20. ERL, T., SOA Principles of Service Design, 1st. ed., Boston, Prentice Hall, 2007, ISBN 0-13-234482-3, pp. 608.

21. VIERING, G., LEGNER, C., AHLEMANN, F., «The (Lacking) Business Perspective on Soa – Critical Themes in Soa Research», en 9th Internationale Tagung Wirtschaftsinformatik Wien (Austria), 2009, pp. 45-54. [consulta: 2012-10-14]. ISBN 978-3-85403-246-5. Disponible en: <http://aisel.aisnet.org/wi2009/5/>

22. LUTHRIA, H., RABHI, F., «Service Oriented Computing in Practice - An Agenda for Research into the Factors Influencing the Organizational Adoption of Service Oriented Architectures» Journal of Theoretical and Applied Electronic Commerce Research, 2009, vol. 4, no. 1, pp. 39-56, ISSN 0718–1876.

23. JOACHIM, N., BEIMBORN, D., WEITZEL, T., «Eine empirische Untersuchung des Wertbeitrages von serviceorientierten Architekturen (SOA)», en 10th International Conference on Business Informatics Zurich, 2011, vol. 2, pp. 861-870. [consulta: 2013-01-22]. ISBN 978-1-4467-9236-0. Disponible en: <http://www.zora.uzh.ch/60516/1/20120227114121_merlin-id_2354.pdf>

24. AFSHAR, M., PALVANKAR, P., SCHNEIDER, R., «Going Beyond Project-Driven SOA», [en línea], 2008, [consulta: 2012-05-04], Disponible en: <http://mohamadafshar.sys-con.com/node/698981>

 

 

Recibido: 22/06/2012
Aprobado: 21/06/2013

 

 

Arturo César Arias-Orizondo. Universidad de las Ciencias Informáticas (UCI). La Habana, Cuba.
E-mail:[e-mail]