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:arturo@uci.cu