Model Maintenance Based In COBIT For The cOLOMBIA

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
s.roa@javeriana.edu.co
Departamento de Ingeniería de Sistemas
Pontificia Universidad Javeriana
Bogotá, Colombia
ogiraldo@javeriana.edu.co
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