Model Maintenance Based In COBIT For The Applications Architecture In TOGAF Enterprise Architectures -MOMCAESilvia Milena Roa Mantilla Olga Lucía Giraldo Departamento de Ingeniería de Sistemas Pontificia Universidad Javeriana Bogotá, Colombia [email protected] Departamento de Ingeniería de Sistemas Pontificia Universidad Javeriana Bogotá, Colombia [email protected] Abstract — This paper presents concepts related to enterprise architecture (EA) and the rationale for how their practice has been gaining importance in organizations because of its integrating character and purpose of aligning Information Technology (IT) in business [1], [2]. An exercise in AE using frameworks that provide guidelines that guide its implementation. In TOGAF phase change management architecture establishes guidelines for maintenance of AE [3], however, the level of abstraction is high, does not identify the conditions that trigger the maintenance, or define how that should make [3]. This raises the need to formulate a maintenance model to structure the various elements that make up the process, contributing to have traceability of the different changes arising during the life horizon AE, thereby controlling the maintenance process. Keywords: Programming, Software Engineering, Enterprise Architecture, TOGAF, Model Maintenance, ADM, COBIT, IT Governance, Enterprise Architecture Frameworks, ArchiMate, models. I. INTRODUCCION Una motivación fundamental para desarrollar un ejercicio de Arquitectura Empresarial (AE) es soportar de manera eficiente los objetivos de negocio de una organización a través de una plataforma tecnológica base, y aprovisionar procesos que permitan lograr una estrategia de TI 1 valiosa, propendiendo porque TI sea un activo capaz de responder a una estrategia de negocio exitosa. Debido a la evolución constante de las empresas, la dinámica de su entorno, y el rápido desarrollo de la tecnología, es necesario lograr que su infraestructura tecnológica soporte y facilite sus procesos de negocio, para hacerlos más eficaces, efectivos y eficientes[4]. Por lo anterior, la realización de un ejercicio de AE es una práctica fundamental para disminuir las inconsistencias entre el negocio y el área de tecnología de las organizaciones, permitiendo así, obtener una aproximación a su valor generado y garantizando control sobre las inversiones y el presupuesto asignado a TI. Abordar un ejercicio de AE requiere la utilización de un marco de trabajo que brinde prácticas, lineamientos y principios para facilitar su implementación. Y si bien, puede utilizarse un marco de trabajo específico como rector de la implementación, durante la fase de definición y planeación se pueden utilizar elementos de varios frameworks, e incluso de estándares no orientados específicamente a AE, que puedan aportar valor en alguna de las fases. TOGAF es un framework ampliamente aceptado en la industria, con una constante evolución desde su creación en el año 1995[4]; actualmente está en la versión 9.1 [3], consolidándose como un framework maduro y probado en el ejercicio de arquitecturas empresariales. Por otro lado, en 2012, ISACA2 lanzó la edición 5.0 del marco de gobierno empresarial, COBIT, el cual proporciona una visión del Gobierno de TI enfocada en la tecnología y la información como generador de valor para las empresas [5]. COBIT en la versión 5.0 se alinea con TOGAF, definiendo incluso un proceso para la Gestión de la Arquitectura Empresarial, de tal manera que permite incorporar elementos valiosos del Gobierno de TI a la práctica de AE, permitiendo enriquecer su práctica en una organización [5]. A lo largo de este artículo se presenta la articulación entre el mantenimiento de las arquitecturas empresariales basadas en TOGAF, en su dominio de arquitectura de aplicación o solución, y el gobierno de TI a través de la utilización de COBIT 5.0. Este artículo se ha estructurado de la siguiente manera: en la sección 2 se presentan conceptos relacionados con la Arquitectura Empresarial, algunos frameworks utilizados como marcos metodológicos para el desarrollo de las mismas, los dominios principales de AE, enfatizando en el método ADM formulado por TOGAF para el desarrollo de un ejercicio de arquitectura Empresarial. La sección 3 presenta el concepto de mantenimiento evolutivo, las técnicas y herramientas que provee TOGAF y que permiten apoyar el proceso de mantenimiento. En la sección 4, el énfasis está orientado a presentar la problemática del mantenimiento en las AE evidenciando la necesidad de formular un modelo de 978-1-4799-1056-4/13/$31.00 ©2013 IEEE 1 Tecnologías de Información. 2 Asociación de Auditoría y Control de Sistemas de Información mantenimiento evolutivo e identificando de manera preliminar los elementos y el lenguaje de representación del modelo a formular. A lo largo de la sección 5 se presenta la estrategia de gobernabilidad a través de la práctica de arquitectura empresarial, realizando la integración en aspectos de gobernabilidad entre COBIT 5.0 y TOGAF 9.1. Finalmente en la sección 6 se plantean las conclusiones y el trabajo futuro. II. APROXIMACIÓN A LA ARQUITECTURA EMPRESARIAL El concepto AE se refiere a una disciplina que provee una organización lógica de procesos de negocio e infraestructura de TI, que permite determinar las capacidades esperadas para satisfacer los requerimientos del modelo de negocio de una compañía [6], [7]. Lankhorst define AE como: [8] “… un conjunto coherente de principios, métodos y modelos que se utilizan en el diseño y la realización a nivel empresarial de la estructura organizacional, los procesos de negocio, los sistemas de información y la infraestructura”. Los orígenes del concepto de AE se remontan a 1987 con la publicación del artículo de John Zachman: [9], “Un marco para la arquitectura de sistemas de información” [10,11], donde se establece tanto el desafío como la visión de la arquitectura empresarial y su aplicación para administrar la creciente complejidad de los sistemas de información soportados en sistemas computacionales [12,13]. El ejercicio de la AE ha venido cobrando relevancia en las organizaciones durante la última década [5], debido a su carácter integrador y a su propósito de alinear las TI con el negocio [2, 29] favoreciendo así, la difusión de su práctica en las organizaciones [10]. En resumen, la AE es una disciplina que proporciona un mapa de entendimiento común de la organización, y se usa para alinear la estrategia y los requerimientos tácticos [15]. Toma como base elementos del negocio que comprenden: modelo operacional, misión, visión, problemática de la organización, motivadores de negocio y sus metas. Y define las principales relaciones entre las personas y los activos claves organizacionales que incluyen procesos, productos, servicios, aplicaciones, tecnología y documentos [11]. Relaciona estos elementos con los elementos de TI que los soportan, haciendo explícita la intención de evolución en un horizonte de tiempo, de 5 a 7 años. frameworks, se destacan: Gartner Enterprise Architectural framework (GEAF) [20], Purdue University Enterprise Reference Architecture (PERA), y el Computer Integrated Manufacturing Open Systems Architecture (CIMOSA)[21], E2AF (Extended Enterprise Architecture framework) [22], DoDAF (United States Department of Defense Architectural framework) y PEAF (Pragmatic Enterprise Architectural framework)[23]. La mayoría de los frameworks citados contienen cuatro dominios básicos: arquitectura de negocio, arquitectura de información, arquitectura de aplicación o de solución y arquitectura de tecnología o de infraestructura. B. Dominios de la Arquitectura Empresarial TOGAF TOGAF a través de sus 8 fases cubre los siguientes dominios de arquitectura: • Arquitectura de Negocio: Se definen la estrategia de negocio, la gobernabilidad, la estructura y los procesos clave de la organización. [6, 25]. • Arquitectura de Datos o Información: describe la estructura física y lógica de los datos, enfatiza en la administración y uso de los recursos de información y presenta el flujo y modelado de la información a nivel transversal [6,7]. • Arquitectura de Aplicaciones o de solución: provee un blueprint para cada uno de los sistemas de aplicación que se requiere implantar en la organización; además refleja las interacciones entre estos sistemas y los procesos de negocio Core de la organización [6,7]. • Arquitectura de Tecnología: la Arquitectura de tecnología busca describir la estructura de hardware, software y redes requerida para dar soporte a la implantación de las aplicaciones de misión crítica, de la organización [6,7]. Las prácticas de AE se fundamentan en marcos de trabajo, frameworks, especializados que proveen lineamientos, principios, guías, mejores prácticas y directrices, que facilitan su desarrollo e implementación en la organización [16,10]. A. Evolución de Frameworks de AE. Hacia 1984 hiciera su aparición el primer framework de arquitectura empresarial y hasta comienzos de 2000, la práctica de las metodologías planteadas en dichos frameworks [17,18] sólo se realizaba en entidades gubernamentales de los Estados Unidos [19]. A partir de 2003 aparecen versiones comerciales completamente desarrolladas de otros frameworks de AE que comienzan a ser adoptadas por diferentes industrias a nivel mundial debido a la necesidad de las empresas de adoptar estos modelos [17]. En este grupo de nuevos Figura 1 - Detalle de elementos del Modelo MOMCAE Los cuatro dominios se articulan por medio del ADM (Architecture Development Method) [26,38], un método confiable y probado, compuesto por ocho fases, Figura 1, que permiten desarrollar un ejercicio arquitectónico que satisfaga las necesidades del negocio. III. MANTENIMIENTO EVOLUTIVO El mantenimiento consiste en las modificaciones realizadas en un producto después de haber sido entregado al usuario. Estas modificaciones se realizan para mejorar el rendimiento, corregir defectos, adaptar el producto a un nuevo entorno, software o hardware, obedecer a imposiciones legales o a cambios en el entorno o de la estructura corporativa [6,27]. El mantenimiento evolutivo modifica algo para aumentar, disminuir o cambiar las funcionalidades del sistema, ya sea por las necesidades del usuario, cambios normativos, etc. [28,29]. De ahí que el control sobre el mantenimiento de una AE permitirá que TI evolucione a la par de la empresa y sus necesidades. Este mantenimiento incluye incorporación de nuevos procesos, mejoras o cambios en procesos existentes, formación y actualización de los niveles de software [32,34]. TOGAF incluye elementos que pueden considerarse como herramientas de apoyo al mantenimiento evolutivo a saber el continuum empresarial y el TOGAF Resource Base [30,31] explicados a continuación. A. Continuum Empresarial Consiste en el conjunto de recursos, guías y plantillas, provistos para ayudar al arquitecto empresarial a establecer una práctica arquitectónica dentro de una organización. Se basa en los modelos y arquitecturas existentes (patrones, modelos, descripciones arquitectónicas, etc.) dentro de la empresa o en la industria objeto del ejercicio [3,26]. El Continuum Empresarial involucra tanto al Continuum Arquitectónico como el Continuum de Soluciones. El primero define la estructura de los artefactos arquitectónicos reutilizables; incluye reglas, representaciones y relaciones de los sistemas de información disponibles en la organización. Incluye el Modelo de Referencia Técnico (TRM), que proporciona un modelo y una taxonomía de los servicios genéricos de la plataforma; y el TOGAF Información Base de las Normas (SIB) que es una base de datos de estándares abiertos que se pueden utilizar para definir los servicios particulares y otros componentes de una arquitectura específica [27,3]. El segundo describe la implementación del Continuum Arquitectónico mediante la definición de bloques constitutivos de solución. B. TOGAF Resource Base Es un conjunto de guías, formatos, listas de chequeo y otros artefactos que soportan el ADM. Agilizan y facilitan el proceso de la AE porque proporcionan lineamientos metodológicos para realizar cada una de las fases del método ADM [3,40]. Busca asegurar que diversas descripciones arquitectónicas de una empresa, hechas por uno o varios arquitectos o equipos de arquitectura, sean coherentes, comparables e integrables en los dominios de AE y en relación con los diferentes ámbitos de negocio. Para apoyar este objetivo TOGAF provee definiciones y arquitecturas de referencia, representadas como modelos de arquitectura, vistas arquitectónicas de los modelos, y otros artefactos. Después de finalizar un ejercicio de arquitectura, estos artefactos son recursos que deben ser gestionados y controlados, con el ánimo de evolucionar y reutilizar [3, 43]. IV. PROBLEMÁTICA DEL MANTENIMIENTO DE UNA AE El mantenimiento de las arquitecturas empresariales es un punto crítico y requiere de la definición y estandarización de un proceso que garantice su realización [2,44]. En esta sección se analiza cómo COBIT puede ser utilizado para contribuir en la solución del problema de mantenimiento. Uno de los factores que más inciden en el presupuesto de una organización son las inversiones tecnológicas que si bien responden a necesidades y problemáticas de negocio, son con frecuencia vistas como gastos. A esto se le suma la dificultad de detectar de manera proactiva y controlada el momento en que se requiere evolucionar los diferentes modelos y artefactos desarrollados durante la fase de arquitectura de solución [20, 26, 45]. Por tal razón surge la necesidad de formular un modelo para establecer el momento en que se requiera aplicar un proceso de mantenimiento a una arquitectura empresarial. A. La Necesidad de un Modelo de Mantenimiento de AE Uno de los aspectos más críticos en el ejercicio de una arquitectura empresarial es garantizar el mantenimiento de los modelos arquitectónicos que surgen durante su desarrollo [30], especialmente en lo referente a los artefactos del dominio de arquitectura de solución. Es allí donde se generan los modelos arquitectónicos y artefactos que constituyen la línea base de la arquitectura dimensionada [18]. La dificultad en el proceso de mantenimiento de los modelos se evidencia en la falta de trazabilidad de su evolución arquitectónica [30]. TOGAF en su fase de “Manejo de cambios de arquitectura” establece lineamientos para realizar el mantenimiento de arquitecturas empresariales [3]. No obstante el nivel de abstracción es tan alto que no identifica las condiciones que lo disparan, ni define la forma en que se debería realizar [3]. Así mismo existen algunas aproximaciones hacia la formulación de modelos, para arquitecturas empresariales desarrolladas bajo TOGAF [18] y propuestas de carácter general para AE [46]. Aunque en ellos no se hace énfasis en el mantenimiento de los artefactos y modelos arquitectónicos surgidos durante el desarrollo de una AE sino que se concentra en el proceso de mantenimiento general o evolución de una AE. Por consiguiente surge la necesidad de formular un modelo de mantenimiento que permita estructurar los diferentes elementos que componen el proceso de mantenimiento contribuyendo así al logro de la trazabilidad de los cambios surgidos durante el horizonte de vida de la AE. B. Ausencia de un Modelo de Mantenimiento en TOGAF. TOGAF no se orienta a temas de gobierno de TI; por consiguiente, no es riguroso en el establecimiento de lineamientos y aspectos que permitan gobernar de manera eficiente el mantenimiento de la arquitectura empresarial. Por tal razón resulta valioso incorporar lineamientos de un marco de trabajo orientado a temas de Gobierno de TI, como COBIT [36]. En 2012 ISACA lanzó la edición 5.0 de COBIT, el cual proporciona una visión empresarial del Gobierno de TI, enfocada en la tecnología y la información como generadores de valor [4], e incorpora un proceso específico para la gestión de la AE: el marco en general tiene una relación explicita con AE. De ahí que resulte valioso incorporarlo en la formulación del modelo de mantenimiento, introduciendo elementos que han sido significativos en un framework como COBIT [4]. conocido como DSL 3 -, permiten promover la integración e interoperabilidad de meta modelos y la definición de reglas claras para la construcción de modelos. Incorporar COBIT 5.0 obedece a las razones anteriores. Puesto que el problema de mantenimiento está ligado a la falta de gobernabilidad, usar un framework orientado al gobierno del que adolece TOGAF, busca potencializarlo con las fortalezas del primero. En la sección 5 se profundizará en la propuesta del modelo de mantenimiento a formular. C. Gobernabilidad de TI a través de AE Las organizaciones buscan asegurar que los nuevos proyectos tecnológicos y su modelo de gobierno soporten la estrategia de negocio de la empresa, consolidando su visión empresarial a través de alineación y vigilancia de recursos, políticas de estandarización y soporte de decisiones [2, 5]. Se decidió trabajar con COBIT para formular un modelo de mantenimiento, que permita gobernar los mantenimientos de los modelos y artefactos arquitectónicos de una arquitectura empresarial [5,36], debido a que un elemento crítico para el éxito de las organizaciones es la administración efectiva de la información y de las TI. Esta criticidad emerge de la creciente dependencia de la información y de los sistemas que proporcionan dicha información [47]. Figura 2 - Modelo MOMCAE El modelo propuesto se presenta en la Figura 2, donde se muestran sus principales elementos conceptuales. El modelo contempla 4 capas: • Primera capa- meta modelo: basado en el meta modelo que provee TOGAF: el TRM 4 [3,46] El meta modelo define un conjunto de entidades y conceptos arquitectónicos que pueden ser representados, y utilizados de tal manera que apoye la consistencia, integridad y trazabilidad del modelo[49]. • Segunda capa- Lenguaje de representación general: utiliza UML como lenguaje de referencia para la notación de los elementos genéricos del modelo [38]. También se utilizarán los elementos de notación propios de BPMN. Esta capa sirve para proveer la estructuración en cuanto a la representación de elementos generales del modelo. • Tercera capa –DSL: donde se utiliza Archimate como lenguaje de dominio específico para representar el modelo de mantenimiento; se escogió Archimate porque es un lenguaje abierto e independiente, promocionado por el “Open Group 5 ” que permite describir gráficamente las capas de negocio, procesos, aplicaciones, datos e infraestructura de una empresa [46,47]. • Cuarta capa - modelo de mantenimiento evolutivo MOMCAE, Figura 3: incluye los elementos del TRM y del SIB 6 , e involucra los activos definidos en el proceso APO 03; Administrar la Arquitectura Empresarial del dominio; Alinear, Planear y Organizar (APO) de COBIT 5.0. Aquí también se introducen elementos propios de ésta propuesta que corresponden a los Elementos Motivadores de control EMC7 y EC8. Los EMC son aquellos elementos que pueden originar El Gobierno de TI regula el día a día de la organización propendiendo por el desarrollo de la visión de la organización [6], y controlando la evolución y adaptación a los cambios del entorno. De ahí la importancia de incorporar los elementos de gobierno al modelo de mantenimiento evolutivo propuesto. V. MODELO PROPUESTO El término modelo fue introducido por Dijkstra [44, 46,48] en ciencias de la computación en los 70. Los modelos simplifican la complejidad de problemas específicos, entendiendo que su verdadero valor radica en representar una abstracción de la realidad que es útil para propósitos analíticos [26, 27, 48]. El objeto de este trabajo es desarrollar un modelo de mantenimiento para el dominio de aplicaciones en una AE que permita tener una representación de los procesos, entidades, bloques de arquitectura (building blocks), artefactos y sistemas que la conforman. El modelo propuesto representa varios niveles de abstracción en contextos diferentes; los niveles superiores representan la esencia del modelo y los niveles más bajos el detalle. Se presentará primero un meta-modelo; el Content Model de TOGAF para especificar las características del modelo, utiliza para su construcción y especificación una ontología, debido a que éstas permiten representar todos los posibles escenarios de un modelo. Así se obtienen artefactos más precisos y completos en las arquitecturas empresariales, y debido a que estas ontología utilizan un lenguaje estándar – 3 Lenguaje de Dominio Específico Modelo Técnico de referencia de TOGAF 5 Es un consorcio de la industria del software que provee estándares abiertos neutrales para la infraestructura de la informática 6 Standards Information Base de TOGAF 7 Elementos Motivadores de control, Definidos por los autores 8 Elementos de control, Definidos por los autores 4 una actualización o modificación en la arquitectura de aplicaciones definida, por ejemplo; elementos normativos, finalización u obsolescencia del ciclo de vida de la arquitectura, reacción ante cambios del mercado entre otros. Los EC, son aquellos elementos que sufren el proceso de mantenimiento, entre ellos: building Blocks, modelos y artefactos arquitectónicos. dominios del negocio reduciendo la ambigüedad. La desventaja que tiene es que su uso no está tan extendido como UML, y muchos arquitectos empresariales no están familiarizados con su notación y representación. REFERENCIAS 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Figura 3 - Representación de la capa del modelo MOMCAE VI. CONCLUSIONES El ejercicio de AE le permite a las organizaciones consolidar su estrategia corporativa apoyándose en TI. Por consiguiente es importante incorporar en los frameworks de AE elementos que le permitan subsanar los vacíos en términos de gobernabilidad. De ahí que resulte de utilidad la incorporación de COBIT en un framework como TOGAF específico para el desarrollo de AE. Uno de los aspectos más críticos en el ejercicio de AE es garantizar el mantenimiento de los modelos arquitectónicos que surgen durante su desarrollo, puesto que si no se tiene control y gobernabilidad sobre ellos se corre el riesgo de obsolescencia tecnológica y más grave aún de pérdida de alineación con el negocio. Por esto es necesario concentrar esfuerzos en el desarrollo de un modelo de mantenimiento evolutivo, para el dominio de aplicación de AE desarrolladas bajo las directrices de TOGAF, y considera los elementos de COBIT, para garantizar el control y la gobernabilidad de sus modelos y artefactos. En la definición del modelo de mantenimiento evolutivo propuesto se utiliza un DSL que se integra de manera “natural” con TOGAF. Por esto se escogió Archimate como framework de arquitectura en este proyecto, por ser un lenguaje para modelar AE, independiente del Framework que se utilice para su desarrollo. Su objetivo es apoyar la descripción, análisis y visualización de la arquitectura dentro y fuera de los 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. W. Engelsman, D. Quartel, H. Jonkers, y M. van Sinderen, «Extending enterprise architecture modelling with business goals and requirements», Enterprise Information Systems, vol. 5, no. 1, pp. 9–36, feb. 2011. Raghupathi W. “Corporate governance of IT: a framework for development”. Vol. 50, No. 8 communications of the ACM.Agosto 2007. Open Group. Documento en línea disponible en: http://www.opengroup.org/togaf/. Accedido 10 de Agosto de 2012. Roger. Sessions. “A Comparison of the Top Four Enterprise Architecture Methodologies”, 20 de febrero, 2008; en www.objectwatch.com. Accedido el 18 de Noviembre de 2012. ISACA. Documento en línea disponible en: http://www.isaca.org/COBIT/Pages/default.aspx. Accedido el 10 de Agosto de 2012. Ross, J.” Forget Strategy: Focus IT in your Operating Model.” CISR Research Briefings 2005, Volume V (3C). Enero, 2006. Ross, J., Weill, P., Robertson, D. “Enterprise Architecture as Strategy Creating a Foundation for Business Execution”. Harvard, Boston. Business School Press. 2006. M. Lankhorst.” Enterprise Architecture at Work –Modeling, Communication, and Analysis”. Berlin: Berlin Heidelberg, Springer– Verlag, 2005, 352 p. J. Zachman. "A framework for information systems architecture" IBM Systems Journal, 1987, Vol 26, No, 3. Accedido el 18 de Noviembre de 2012. Winter R. and R. Fischer. Essential Layers, Artifacts, and Dependencies of Enterprise Architecture. In IEEE Computer Society, editor, EDOC Workshop on Trends in Enterprise Architecture Research. IEEE Computer Society Press. 2006. J. Henderson, and Venkatraman, N. Strategic alignment: Leveraging information technology for transforming organizations. IBM Systems Journal 38, 2–3 (1999), 472–484. J. F. Sowa, J. A. Zachman. “Extending and formalizing the framework for information systems architecture”, IBM Systems Journal archive, 1992. Documento en línea disponible en: http://www.zachman.com/about-thezachman-framework. Accedido el 18 de Noviembre de 2012. U. S. D. o. Defense, “Technical Architecture framework for Information Management (TAFIM),” D. o. Defense, ed., 1994. Accedido el 19 de Noviembre de 2012. Bernus P., Nemes L, Schmidt G. “Handbook on enterprise architecture”. Springer, Berlin 2003. J. Schekkerman. “How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating or Choosing an Enterprise Architecture Framework”. Trafford Publishing, Victoria, British Columbia, 2 edition, 2004. Becker Christoph, Gonçalo Antunes, José Barateiro, Ricardo Vieira, José Borbinha. “Modeling digital preservation capabilities in enterprise architecture”. INESC-ID Information Systems Group, Lisboa, Portugal. Pages 84-93. ACM New York, NY, USA.2011. Leist Susanne, Greg Zellner. “Evaluation of current architecture frameworks”. Proceedings of the 2006 ACM symposium on Applied computing. 2006. Pages 1553- 1556. ACM, 2006. U. S. CONGRESS, “Clinger-Cohen Act of 1996,” Public Law. 1996. Gartner (2009), “Gartner’s Enterprise Architecture research”. Documento en línea disponible en http://www.gartner.com/id=486650. Accedido el 03 de Octubre de 2012. Feltus, C., Petit, M., Vernadat, F., “Enhancement of CIMOSA with Responsibility Concept to Conform to Principles of Corporate Governance of IT”, 13th IFAC Symposium on Information Control Problems in Manufacturing, 3-5/6/2009, Moscow, Russia. "FEA Consolidated Reference Model Document Version 2.1," December 2006, published by the Federal Enterprise Architecture Program Management Office, Office of Management of Budget, Documento en línea disponible en: http://www.whitehouse.gov/sites/default/files/omb/assets/fea_docs/FEA_ 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. Practice_Guidance_Nov_2007.pdf. Accedido el 19 de Noviembre de 2012. F. Goethals et al., “Managements and enterprise architecture click: The FADE framework,” Information Systems Frontiers, vol. 8, no. 2, pp. 6779, 2006. Tae-Young Kim, Sunjae Lee, Kwangsoo Kim, Cheol-Han Kim. “A modeling framework for agile and interoperable virtual enterprises”. Department of Industrial and Management Engineering, Pohang University of Science and Technology, Republic of Korea. Science Direct. 2005. R. Whittle, y C. Myrick, Enterprise Business Architecture: The Formal Link between Strategy and Results, Boca Ratón, USA: CRC Press LLC, 2004, 256 p. Gerber Aurona, Kotz´e Paula, van der Merwe Alta. “Towards The Formalisation of The TOGAF Content Metamodel Using Ontologies “. Meraka Institute of the CSIR, Pretoria.2009. T. Kamogawa, “Structural Models that Manage IT Portfolio Affecting Business Value of Enterprise Architecture”, IEICE Transactions on Information and Systems, vol. E93-D, no. 9, pp. 2566–2576, 2010. Saetang Sureerat, Haider Abrar. “Conceptual aspects of IT governance in enterprise environment”. Proceedings of the 49th SIGMIS annual conference on Computer personnel research. Pages 79-82. ACM, 2011. Dobson, J. and Martin, D., “Enterprise Modeling Based on Responsability”, TRUST IN Technology: A Socio Technical Perspective, Clarke, K., Hardstone, G., Rouncefield, M. and Sommerville, I., eds., Springer, 2006. Lankhorst Marc M. “Enterprise Architecture Modelling—The Issue Of Integration”. Advanced Engineering Informatics, Volume 18, Issue 4, October 2004, Pages 205-216. Janssen, M. and Hjort-Madsen, K. (2007). “Analyzing enterprise architecture in national governments: The cases of denmark and the netherlands”. In Proceedings of the 40th Hawaii International Conference on System Sciences, pages 1530–1605. Chaki Sagir, Diaz-Pace, Andrés, Garlan David. Ariel Gurfinkel, Ipek Ozkaya. “Towards engineered architecture evolution”.. IEEE Computer Society. 2009. T. Kamogawa, “Structural Models that Manage IT Portfolio Affecting Business Value of Enterprise Architecture”, IEICE Transactions on Information and Systems, vol. E93-D, no. 9, pp. 2566–2576, 2010. Lippitt, G. L. Visualizing Change: Model Building and the Change Process. University Associates, Inc.1973. Quartel D., M. W. A. Steen, y M. M. Lankhorst, “Application and project portfolio valuation using enterprise architecture and business requirements modeling”, Enterprise Information Systems, vol. 6, no. 2, pp. 189–213, may 2012. Feltus C., Petit M., Dubois E. “Strengthening Employee’s Responsibility to Enhance Governance of IT - COBIT RACI Chart Case Study”. Proceedings of the 1st ACM Workshop on Information Security Governance (ACM WISG 2009) (ACM CCS 2009), Chicago, 13.11.2009, ISBN 978-1-60558-787-5. 37. Ernst Alexander M. “Enterprise Architecture Management Patterns”. Proceedings of the 15th Conference on Pattern Languages of Programs. Technische Universitat Munchen, Germany. ACM, 2008. 38. Napoli Juan Pablo, Kaloyanova Kalinka. “An Integrated Approach for RUP, EA, SOA and BPM Implementation”. International Conference on Computer Systems and Technologies - CompSysTech’11. Pages 63-68. ACM 2011. 39. Dobson, J. and Martin, D., “Enterprise Modeling Based on Responsibility”, TRUST IN Technology: A Socio- Technical Perspective, Clarke, K., Hardstone, G., Rouncefield, M. and Sommerville, I., eds., Springer, 2006. 40. Ozkaya Ipek,Wallin Peter, Axelsson Jakob.” Architecture knowledge management during system evolution: observations from practitioners”. Proceedings of the 2010 ICSE Workshop on Sharing and Reusing Architectural Knowledge. Pages 25-59. ACM, 2010. 41. Winter Robert, Joachim Schelp “Enterprise Architecture Governance: The Need for a Business to IT Approach”. Proceedings of the 2008 ACM symposium on Applied computing. Pages 548-552. ACM 2008. 42. S. H. Kaisler et al., “Enterprise Architecting: Critical Problems” en Proceedings of the 38th Hawaii International Conference on System Sciences (HICSS'05), Hawaii, USA, 2005. 43. F. S. De Boer et al., “Change Impact Analysis of Enterprise Architectures” en Proceedings of the 2005 IEEE International Conference on Information Reuse and Integration (IRI–2005), Las Vegas, USA, 2005, pp. 15-17. 44. Velitchkov Ivaylo. “Integration of It Strategy And Enterprise Architecture Models”. Proceeding CompSysTech '08 Proceedings. En la International Conference on Computer Systems and Technologies and Workshop for PhD Students in Computing. Article No. 69. ACM New York, NY, USA ©2008. 45. A. Ishihara, H. Furuta, T. Yamaoka, K. Seo, y S. Nishida, “A modelbased method to design an application common platform for enterprise information systems”, Electrical Engineering in Japan, vol. 176, no. 3, pp. 37–51, ago. 2011. 46. C. Braun and R. Winter. “A Comprehensive Enterprise Architecture Metamodel and Its Implementation Using a Metamodeling Platform”. In J. Desel and U. Frank, editors, Enterprise Modelling and Information Systems Architectures – Proceedings of the Workshop in Klagenfurt. Bonn, Alemania. October 24-25, 2005, volume P-75, pages 64–79. 47. Buckl, S., Ernst, A., Lankes, J., Matthes, F., Schweda, C., and Wittenburg, A. “Generating visualizations of enterprise architectures using model transformation (extended version)”. Enterprise Modelling and Information Systems Architectures – An International Journal Vol. 2, 2 (2007). 48. Dijkstra, E. W. The end of computing science?. Communications of the ACM, 44(3):92. 2001. 49. http://www.togaf.info/togaf9/togafSlides9/TOGAF-V9-M7Metamodel.pdf