Tema 2

Tema 2
Planificación Estratégica mediante Arquitectura

Empresarial
Tema 2. Marcos de
Referencia de Arquitectura
Empresarial
Índice
Esquema
Ideas clave
2.1. Introducción y objetivos
2.2. Definición y contenido de un Marco de Referencia

de Arquitectura Empresarial
2.3. Análisis de los diferentes Marcos de Referencia y

estándares de AE
2.4. Selección de un Marco de Arquitectura Empresarial
2.5. Fases principales en el ciclo de creación y utilización

de la Arquitectura Empresarial
2.6. Referencias bibliográficas
A fondo
Innovación, Transformación y Arquitectura Empresarial
Marco de Arquitectura Zachman
Marcos de Arquitectura Empresarial
Modelo de Madurez de AE
Iniciativa de adopción de AE en la empresa
Arquitectura Empresarial y Gestión de Procesos
Test
Esquema
Planificación Estratégica mediante Arquitectura Empresarial 3

Tema 2. Esquema
© Universidad Internacional de La Rioja (UNIR)
Ideas clave
2.1. Introducción y objetivos
El propósito de este tema, una vez realizada la introducción a la Arquitectura
Empresarial del tema «Fundamentos de Arquitectura Empresarial», es profundizar en
el entendimiento del concepto y utilidad de un Marco de Referencia de Arquitectura
Empresarial (y por qué es relevante añadir «de Referencia» a la nomenclatura
aplicada hasta ahora, ya sea de manera explícita o implícita), considerando sus
componentes o piezas básicas, la taxonomía de Marcos y los principales Marcos
existentes, y terminando con la ubicación de este elemento clave de la Arquitectura
Empresarial en el proceso de adopción o implantación de la Arquitectura Empresarial
en una compañía u organización.
Teniendo en cuenta lo anterior, este tema tiene por objeto:
▸ Ampliar la definición de Marco de Referencia de Arquitectura Empresarial junto con
su propósito.
▸ Introducir los componentes de un Marco de Referencia de Arquitectura Empresarial.
▸ Conocer una taxonomía de marcos en cuanto a criterios de aplicación.
▸ Proporcionar una visión introductoria de los principales marcos existentes.
▸ Presentar un proceso o secuencia de actividades requeridas para la adopción de la
Arquitectura Empresarial en una organización y en qué punto posicionar el Marco de

Referencia de Arquitectura Empresarial.

Tema 2. Ideas clave
Ideas clave
2.2. Definición y contenido de un Marco de

Referencia de Arquitectura Empresarial
Hablar de Arquitectura Empresarial significa considerar la organización completa
junto con todos los elementos que la conforman, existiendo, en consecuencia, un
consenso generalizado en que esto implica hablar del alineamiento pleno de la
organización, en todas sus facetas, con los objetivos corporativos.
Bajo esta premisa, como ocurre en el ámbito de la Arquitectura TI, se podría asumir
que igualmente existe un entendimiento común acerca de los elementos básicos que
la componen y sobre la estructuración de los mismos; pero esto, en el caso de la

Arquitectura Empresarial, no ocurre. Si en el Tema «Fundamentos de Arquitectura
Empresarial» utilizábamos la analogía de la Arquitectura Empresarial con la
arquitectura de un edificio (para ilustrar la relación con otra disciplina clave en la
Planificación Estratégica como es BPM), ahora debemos refinar esa analogía para
aproximarla más a la realidad. Dado que la Arquitectura Empresarial tiene en
consideración toda la empresa, debe tener en cuenta igualmente su contexto, es
decir, la ciudad y, consecuentemente debe entenderse más como la planificación
urbanística donde se planifica un área completa y no solo un edificio.
A la luz del refinamiento conceptual anterior, queda patente, no solo la dificultad de
alcanzar un consenso acerca de la estructuración y composición de una Arquitectura
Empresarial, sino igualmente la necesidad de disponer de una herramienta que
posibilite crear y usar las arquitecturas empresariales. Esta herramienta es un Marco
de Referencia de Arquitectura Empresarial, o si preferimos la aproximación
terminológica de John A. Zachman, una Ontología Empresarial.

Tema 2. Ideas clave
Ideas clave
Más allá de lo expuesto hasta ahora, realmente, ¿por qué se necesita un marco?
▸ Porque necesitamos un mecanismo para definir y documentar una Arquitectura
Empresarial de manera transparente, que considere las complejidades y las

dependencias entre sus bloques básicos (bloques constructivos).
▸ Porque necesitamos un elemento de referencia de comunicación entre las partes
interesadas (negocio, comunidad TI, contexto, etc.) y entre diferentes perfiles dentro
de esas partes.
▸ Porque necesitamos una guía, adaptable y no necesariamente completa, que nos
permita planificar no solo la arquitectura empresarial, y nuestra estrategia, actual
sino su evolución y desarrollo para adoptar nuevos modelos de negocio acordes al

mercado en cada momento, considerando siempre unos estándares corporativos.
Componentes de un Marco de Arquitectura Empresarial
Un Marco de Arquitectura Empresarial define como crear y utilizar una arquitectura
empresarial, incorporando un conjunto de principios y prácticas para el uso de esa
descripción arquitectónica (bloques constructivos y características de integración
entre los mismos) y proporcionando igualmente una vertebración de la descripción en
un conjunto de dominios complementarios, también denominadas «vistas», junto con
herramientas y aproximaciones (modelos, matrices, diagramas, aproximaciones de
decisión, etc.) que ayudan a la optimización dentro de los mismos asegurando la
integración transversal a la empresa y el respaldo a la estrategia y objetivos
empresariales.
Si bien existen diferentes Marcos de Arquitectura Empresarial y, consecuentemente,
diferentes composiciones, como mínimo, deberemos observar los siguientes
elementos como constituyentes de un Marco de Arquitectura Empresarial:
▸ Vistas (descripción de la arquitectura). Mecanismos para comunicar la información
sobre los componentes y las relaciones que son importantes en una arquitectura.

Tema 2. Ideas clave
Ideas clave
Cada Vista proporciona una descripción de la arquitectura desde una perspectiva
diferente pero complementaria con el resto y, como se ha indicado, incluye las
entidades y relaciones que direccionan un aspecto de interés para una parte
interesada.
Una Vista puede ser documentada utilizando listas, tablas, diagramas o cualquier
composición de estos u otros instrumentos.
▸ Métodos [para describir la arquitectura]. Conjunto de Procesos utilizados por los
arquitectos para recoger y organizar los datos empresariales y construir las Vistas de
manera que se asegure su integridad, exactitud y completitud.
Estos Procesos se agrupan en un Supraproceso definido por sus objetivos, entradas,
fases (pasos o actividades) y salidas; y su descripción pura puede estar soportada
por propuestas de aproximación, técnicas, herramientas, principios, reglas y
prácticas específicas de la empresa, del sector industrial o globales.
▸ Experiencia (organización/práctica de arquitectura). Directrices en la estructuración
del equipo de Arquitectura Empresarial, así como con relación al Modelo de
Gobierno de AE, incluyendo las capacitaciones y experiencia de los miembros del

equipo para apoyar la aplicación de los Métodos (y la utilización de herramientas)
junto con las necesidades de formación.
Adicionalmente, para que un Marco de Arquitectura Empresarial cumpla realmente
su papel, debe incluir:
▸ Métricas de medición del Valor de Negocio (cuan eficiente es la AE), calidad de los
procesos, traducción de expectativas en objetivos, iniciativas de mejora, etc.
▸ Modelo de Madurez de la AE.

Tema 2. Ideas clave
Ideas clave
▸ Modelo de Gobierno de la AE junto con directrices prescriptivas sobre procesos,
contenido de la arquitectura y hojas de ruta para su evolución.
▸ Modelo de comunicación de la AE, con un vocabulario, modelos y taxonomía
comunes a todos los interesados.
▸ Modelo de soporte a estándares (criterios, directrices y mejores prácticas o métodos
de cumplimiento de una función) y modelos de referencia, tanto verticales (industria),

como horizontales (generalistas).
▸ Catálogo de entregables y artefactos de Arquitectura Empresarial.
▸ Contenido del metamodelo de la Arquitectura.
▸ Recomendaciones sobre herramientas y capacidades (modelado, usabilidad,
integración, administración y flexibilidad) para capturar, almacenar, estructurar y

analizar la información de la Arquitectura Empresarial.
Vistas de Arquitectura Empresarial
En general y con ligeras variaciones según el Marco de Arquitectura Empresarial que
se considere, la Arquitectura Empresarial se vertebra en los siguientes dominios,
que se aceptan comúnmente como vistas o perspectivas que se plantean sobre una
arquitectura empresarial global, y todos ellos dirigidos por la estrategia y objetivos de
la compañía.
▸ La Arquitectura de Negocio: alinea la estrategia, los drivers de negocio, la
organización y los procesos y servicios empresariales clave, así como los objetivos
que la compañía necesita para evolucionar como empresa y mantenerse en el
mercado.

Tema 2. Ideas clave
Ideas clave
▸ La Arquitectura de la Información: describe la estructura de los recursos de datos
lógicos y físicos de una organización y los recursos para su gestión. Esta

arquitectura resulta clave, ya que la información se consume en los componentes
que conforman los otros dominios. Comprender qué funciones y procesos
comerciales utilizan información, qué aplicaciones sirven como registro maestro,
dónde se crea y destruye la información y qué componentes tecnológicos almacenan
y manipulan la información es fundamental para lograr los objetivos de la
organización.
▸ La Arquitectura de Aplicaciones: define un modelo para las aplicaciones
individuales que se implementarán, sus interacciones y sus relaciones con los

procesos clave de la organización, para transformar, transmitir y almacenar
información.
▸ La Arquitectura Tecnológica: apuntala a las otras arquitecturas y proporciona una
descripción de la infraestructura lógica, física y virtual que se requiere para soportar

la implementación y ejecución de servicios de negocio, datos y aplicaciones. Debido
a que la empresa debe colaborar en todas las disciplinas, depende en gran medida
de la tecnología: almacenar y recopilar datos, vender e implementar bienes,
productos o servicios, brindar un servicio excelente al cliente, etc.

Tema 2. Ideas clave
Ideas clave
2.3. Análisis de los diferentes Marcos de

Referencia y estándares de AE
En la exposición del tema «Fundamentos de Arquitectura Empresarial» indicábamos
como punto de arranque de la Arquitectura empresarial la publicación en 1987 por
parte de John A. Zachman del artículo A framework for information systems
architecture (Zachman, 1987; Zachman y Spewak, 2008), pero en realidad esta
práctica hunde sus raíces en la década de 1960 con la metodología Business
Systems Planning (BPS) de IBM (Langefors y Sundgren, 1975) que proporciona los
fundamentos para las metodologías y Marcos de Arquitectura Empresarial y el Marco
PRISM (1986).
Desde entonces, y como se puede observar en la siguiente figura, la proliferación de
marcos y la retroalimentación entre los mismos ha sido una tónica constante.
Figura 1. Historia resumida de los Marcos de Arquitectura Empresarial (y lenguajes de modelización).

Tema 2. Ideas clave
Ideas clave
Si bien de manera cronológica se suelen clasificar los Marcos de Arquitectura
Empresarial en:
▸ Pre-AE (previo a la década de 1980). Fundamentados principalmente en BSP, como
las metodologías BSP de IBM y Method/1 de Arthur Andersen.
▸ AE Temprana (década de 1980 y comienzos de la década de 1990). Donde surgen
los primeros Marcos de AE auténticos, como PRISM, Zachman, NIST e incluso EAP;
y la Arquitectura Empresarial empieza a ser usada consistentemente.
▸ AE Moderna (desde el comienzo de la década de 1990). Donde se introducen los
Marcos de AE actuales como FEAF e IAF (generados a partir de EAP), DoDAF,

MODAF, NAF y TOGAF® (como evoluciones de TAFIM), conviviendo con las
evoluciones de Zachman (reconversión de «marco» a «ontología», si bien no vamos

a entrar a analizar la coexistencia y diferenciación entre ambos conceptos).
A efectos prácticos, vamos a clasificar los marcos según su naturaleza, o tipo de
empresa a la que están dirigidos:
▸ Privados o propietarios (parcial o totalmente): IFW (IBM Information Framework),
SAP EA Framework, EA Oracle Framework, Zachman EA Framework, EA3 Cube,

IAF (Integrated Architecture Framework, CapGemini).
▸ De consorcio: TOGAF® (The Open Group Architecture Framework), GERAM
(Generalised Enterprise Reference Architecture and Methodology, generado entre

IFAC e IFIP).
▸ Abiertos: TRAK (originario de London Undergorund Ltd. Y fundamentado en
MODAF) y EST (Enterprise System Topology) que se usa como fundamento de la

metodología Praxeme.

Tema 2. Ideas clave
Ideas clave
▸ Gubernamentales (Defensa): DoDAF (United States Department of Defense
Architectural Framework), MoDAF (United Kingdom Ministry of Defence Architectural

Framework), AGATE (French Délégation Générale pour l'Armement Atelier de
Gestion de l'ArchiTEcture des systèmes d'information et de communication), NAF

(NATO Architecture Framework).
▸ Gubernamentales (Generalistas): FEAF (United States Office of Management and
Budget Federal Enterprise Architecture Framework), NIST EA Model (National

Institute of Standards and Technology Enterprise Architeture Model), MRAE (Marco
de Referencia de Arquitectura Empresarial. Colombia).
▸ Modelización: Service-Oriented Modeling Framework (SOMF) (Methodologies
Corporation Enterprise Modeling Framework, propuesto por Michael Bell), OBASHI®

(The OBASHI Business & IT methodology and framework, inventado por Fergus
Cloughley and Paul Wallis of Stroma Software Ltd).
A continuación examinaremos más detalladamente algunos de los marcos anteriores.
DoDAF (Department of Defense Architecture Framework)
El Marco de Arquitectura del Departamento de Defensa de los Estados Unidos de
Norteamérica (DoDAF) es un marco global y modelo conceptual para el desarrollo de

arquitecturas que permitan a los gestores, en todos los niveles, del Departamento de
Defensa, la toma eficiente de decisiones mediante la compartición organizada de
información. De la misma forma, proporciona numerosas directrices para el
desarrollo de arquitecturas que soporten la adopción y ejecución de servicios dentro
del Departamento de Defensa.
Como es entendible, el uso de este Marco de Arquitectura Empresarial por el
Departamento de Defensa supuso su imposición al sector contratista, de manera que
actualmente es utilizado, tanto en el sector público, como en el privado.

Tema 2. Ideas clave
Ideas clave
Es importante destacar que la última versión de DoDAF (v2.0 a fecha de elaboración
de este documento) se centra en los Datos Arquitecturales en lugar de en el
desarrollo de «productos», como ocurre en versiones previas. Por este motivo, se
incluyen directrices (Método de Captura de Datos o DCM por sus siglas en inglés)
por grupo de datos para que los arquitectos recojan y organicen los datos
arquitecturales necesarios (pero sin prescribir ningún modelo físico de datos).
Este cambio de orientación implica una visualización de los datos arquitecturales
mediante Modelos («productos» en las versiones anteriores), que pueden ser
cualquier tipo de documento, hoja de cálculo, cuadro de mando o representación
gráfica que sirva como plantilla para la organización y presentación de los datos en
un formato entendible. Cuando la plantilla (Modelo) está rellena, se denomina Vista
(que a su vez puede ser utilizada como plantilla o ejemplo para su uso en otros
casos), y una colección organizada de Vistas (p. ej., procesos, sistemas, servicios,
etc.) conforman una Perspectiva (Viewpoint) que, junto con las definiciones
adecuadas, conforman una Descripción de Arquitectura (que explica el estado
actual y futuro del proceso o actividad considerado).
Otro elemento a destacar es que DoDAF (v2), frente a otros marcos, no requiere una
metodología particular para el desarrollo de una Arquitectura (ni de diseño gráfico de
Vistas). Solo proporciona directrices y sugerencias sobre cómo asegurar que otros
métodos se adecúen a las necesidades de los requisitos del Departamento de
Defensa con relación a la recogida y almacenamiento de datos.

Tema 2. Ideas clave
Ideas clave
Como se ha indicado, el foco se pone en los datos arquitecturales como elemento
clave para la eficiencia de los procesos implicados en la toma de decisiones a todos
los niveles del Departamento de Defensa. Si bien, las diferentes organizaciones del
Departamento de Defensa pueden establecer procesos propios utilizando DoDAF,
están obligadas a cumplir con los procesos de soporte a la decisión obligatorios en el
Departamento (susceptibles de ser complementados por esos procesos propios

mencionados).
Por este motivo, DoDAF (v2) soporta los siguientes procesos clave:
▸ Joint Capability Integration and Development System (JCIDS). Proceso
colaborativo para asegurar la recepción de las capacidades requeridas para la

ejecución exitosa de una misión asignada. Para ello se utilizan las descripciones
arquitecturales de manera integrada con el objeto de identificar diferenciales de
capacidad y aproximaciones para eliminarlos.
▸ Defense Acquisition System (DAS). Proceso encargado de la gestión de
inversiones en tecnología, programas y productos necesarios para respaldar la

estrategia de seguridad nacional. Se apoya en el proceso anterior (JCIDS).
▸ Systems Engineering (SE). Aproximación que busca un balance entre el
rendimiento global de los sistemas y el coste total de los mismos con el objeto de
asegurar que cualquier programa responde a un documento de capacidades o
requisitos, con independencia de la categoría de adquisición considerada. Estos
procesos establecen líneas base de desarrollo (con documentos de diseño y
decisiones de desarrollo soportados por la arquitectura) que se utilizan con los

sistemas, subsistemas y componentes de los mismos, así como con los sistemas de
apoyo utilizados en la producción, operación, capacitación, soporte y retirada del
sistema objeto del programa.

Tema 2. Ideas clave
Ideas clave
▸ Planning, Programming, Budgeting, and Execution (PPBE). Proceso sistemático
que identifica necesidades, planifica programas, estima recursos y los asigna,

además de establecer un marco y procesos de decisión en programas futuros.
DoDAF identifica los puntos de contacto entre este proceso y la arquitectura de
forma que se identifiquen los datos que deben recogerse en la Descripción

Arquitectural. Se apoya en el proceso JCIDS.
▸ Portfolio Management (PfM). Proceso para gestionar las inversiones TI como
portafolios respaldando la misión y objetivos del Departamento. Para ello se apoya

en el uso de planes de arquitectura y objetivos de capacidad (a partir de la
Descripción Arquitectural).
▸ Operations. Conjunto de plantillas, checklists y otros artefactos utilizados de manera
general para soportar la actividad. DoDAF incluye este tipo de procesos como parte
de la arquitectura debido al carácter repetitivo o rutinario de esta actividad del
negocio (las Operaciones [Militares]).
Hemos indicado que la Descripción de la Arquitectura en DoDAF se divide en
Perspectivas (Viewpoint) que están compuestas por datos que han sido organizados
para facilitar su entendimiento en Vistas/Modelos.
La organización de los Modelos de DoDAF se lleva a cabo en las siguientes
Perspectivas (Viewpoint) y se puede observar, a continuación, en la Figura 2:
▸ All Viewpoint (AV). Describe de forma genérica los aspectos del contexto de la
arquitectura relativos a todas las Perspectivas.
▸ Capability Viewpoint (CV). Articula los requerimientos y el alcance del proyecto, los
tiempos de entrega y la capacidad de puesta en marcha del proyecto.

Tema 2. Ideas clave
Ideas clave
▸ Data and Information Viewpoint (DIV). Articula las relaciones de los datos y las
estructuras de la arquitectura con la capacidad y los requerimientos operacionales,

procesos de sistema y servicios.
▸ Operational Viewpoint (OV). Incluye los escenarios posibles, actividades y los
requerimientos operacionales.
▸ Project Viewpoint (PV). Describe las relaciones entre los requerimientos
operacionales y la capacidad operacional También detalla dependencias entre la
capacidad operacional y los requisitos, diseño de los sistemas y diseño de servicios

dentro de los procesos de Adquisición del Departamento de Defensa (DAS en la lista
de procesos clave anterior).
▸ Services Viewpoint (SvcV). Presenta el diseño para la solución que involucre a los
intérpretes, y la forma que se relacionan con los servicios y con las operaciones,
soportando toda la carga operacional y toda la funcionalidad requerida.
▸ Standards Viewpoint (StdV). Articula las políticas de la industria, técnicas, de
negocio y operacionales, junto con estándares, directrices, restricciones y

previsiones que apliquen a los requisitos operacionales, de capacidad, del proceso
de Ingeniería de Sistemas (SE en la lista de procesos clave anterior), de sistemas y

de servicios.
▸ Systems Viewpoint (SV). Incluida por motivos de soporte de elementos legacy. Se
centra en diseño de soluciones articulando los sistemas, su composición,

interconexiones y contexto para dar apoyo a las funciones operacionales y de
capacidad.

Tema 2. Ideas clave
Ideas clave
Figura 2. Perspectivas (Viewpoint) consideradas en DoDAF v2.0. Fuente:

https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_viewpoints/
MoDAF (UK Ministry of Defence Architectural Framework )
MoDAF es un Marco de Arquitectura Empresarial desarrollado por el Ministerio de
Defensa del Reino Unido para respaldar las actividades de planificación y gestión de
cambios de la Defensa. Para ello, posibilita la captura y presentación de la
información de manera rigurosa, coherente y completa que ayuda en la comprensión
de un asunto complejo.
MODAF fue inicialmente desarrollado a partir del Marco de AE DoDAF, ajustándolo a
los requisitos del Ministerio de Defensa mediante dos iniciativas paralelas:
▸ Un programa de investigación sufragado por el Ministerio de Defensa y liderado por
QinetiQ (antigua agencia de Investigación y Evaluación de Defensa) para el

desarrollo de un Metamodelo.

Tema 2. Ideas clave
Ideas clave
▸ Un desarrollo de Vistas llevado a cabo por un consorcio asociado al Ministerio de
Defensa (Cornwell Management Consulting y PA Consulting Group con Model

Futures proporcionando datos técnicos, y extendido a otros proveedores como
Logica y Vega).
Al igual que en el caso de DoDAF, la utilización de MoDAF por el Ministerio de

Defensa del Reino Unido ha impulsado el uso de MoDAF por organizaciones
externas en mayor o menor medida relacionadas con la actividad del Ministerio; entre
otras organizaciones encontramos a BAE Systems, Thales, Lockheed Martin, Boeing
y Serco (antigua Cornwell Management Consulting participante en el desarrollo de
MoDAF).
También es relevante destacar que el uso de este Marco de AE no se limita al ámbito
británico, sino que MoDAF ha sido también adoptado por las Fuerzas Armadas de
Suecia, que lo han extendido dotándolo de un mecanismo ontológico de intercambio
de datos que se postula como elemento clave del Marco Unificado de Arquitectura
(convergencia de DoDAF, MoDAF, NAF y el marco canadiense que sustituye al
DNDAF – Department of National Defence/Canadian Armed Forces Architecture
Framework).
MoDAF proporciona un conjunto de reglas y plantillas que se llaman Vistas que, una
vez cumplimentadas, muestran una visualización, textual y gráfica, del área de
negocio considerada.

Tema 2. Ideas clave
Ideas clave
Al igual que en el caso de DoDAF, para facilitar la estructuración de una Arquitectura
Empresarial en diferentes dominios, cada uno de ellos centrado en un aspecto del
funcionamiento de la empresa, MoDAF incorpora el concepto de Perspectiva
(Viewpoint) como una agrupación de Vistas y proporciona un conjunto estándar de
Perspectivas sobre el modelo arquitectónico:
▸ Perspectiva Estratégica.
▸ Perspectiva Operacional.
▸ Perspectiva de Servicios.
▸ Perspectiva de Sistemas.
▸ Perspectiva de Adquisición.
▸ Perspectiva Técnica.
La siguiente figura proporciona un ejemplo del mecanismo (Principio de
Estratificación) mediante el cual se pueden establecer y analizar las diferentes
relaciones (expresadas mediante el paradigma “what-who-why-how-when-where”)
que puedan existir o establecerse entre Perspectivas o incluso entre Arquitecturas.
Figura 3. Ejemplo de relación entre Perspectivas de MoDAF. Fuente:
https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/38694/2
0090219_MODAF_Layers_and_Viewpoint_Linkages_U.pdf

Tema 2. Ideas clave
Ideas clave
Cada Vista ofrece diferentes percepciones sobre el negocio para dar soporte a
diferentes grupos de interés (ver la siguiente figura). Siguiendo la estructura indicada
de Perspectivas, encontramos:
▸ Vistas Estratégicas (StVs). Definen lo que quiere hacer el negocio y las
capacidades que se necesitan para lograrlo.
▸ Vistas Operacionales (OVs). Definen (en abstracto más que en real) los procesos,
información y entidades que necesitan rellenar los requerimientos.
▸ Vistas Orientadas al Servicio (SOVs). Describen los servicios requeridos para
soportar los procesos descritos en las vistas operacionales.
▸ Vistas de Sistemas (SVs). Describen las implementaciones físicas de las vistas
operacionales y las orientadas al servicio y definen la solución.
▸ Vistas de Adquisición (AcVs). Describen la dependencia y secuencia de proyectos
que llevarán a la solución.
▸ Vistas Técnicas (TVs). Definen los estándares que hay que aplicar a la solución.
▸ Todas las vistas (AVs). Proporcionan una descripción y glosario de contenidos de
la arquitectura.

Tema 2. Ideas clave
Ideas clave
Figura 4. Agrupación de Vistas en MoDAF. Fuente:

https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/38696/Vi
ewsHomeDownloadable.pdf
Para asegurar la coherencia entre las Vistas, existe un modelo que define las
relaciones entre todos los datos de todas las Vistas. Este modelo constituye el
metamodelo de MoDAF «M3» que proporciona un estándar técnico para permitir el
intercambio de datos entre arquitecturas desarrolladas en diferentes aplicaciones de
modelado arquitectónico.
TOGAF (The Open Group Architecture Framework )
TOGAF es el Marco para Arquitecturas Empresariales desarrollado por The Open
Group y es el más utilizado en la actualidad (es un marco que puede ser consultado
sin necesitar licencia y utilizado gratuitamente para la generación de una
Arquitectura, si bien la reproducción de su contenido sí está sujeta a licencia). La
primera versión de TOGAF fue desarrollada en 1995, basada en TAFIM ( Technical
Architecture Framework for Information Management, del Departamento de Defensa
de los Estados Unidos). La última versión es TOGAF 9.2 publicada en 2018.

Tema 2. Ideas clave
Ideas clave
Es igualmente importante comentar que, si bien, la documentación de TOGAF está
generada para conformar un todo utilizable de manera integral, permite que las
organizaciones que toman TOGAF como su Marco de Referencia puedan utilizar
solamente aquellas partes del marco que les resulten interesantes (Desfray y Gilbert,
2014).
Principales componentes de TOGAF
La estructura, y contenido, de TOGAF no sigue la aproximación clásica de un Marco
de Arquitectura Empresarial, como hemos visto hasta ahora, tanto en la introducción,

como en los marcos revisados anteriormente, sino que refleja los componentes
fundamentales para una práctica de Arquitectura Empresarial dentro de una
empresa, como recoge la siguiente figura:
Figura 5. Estructura y contenido de TOGAF. Fuente: https://pubs.opengroup.org/architecture/togaf9-

doc/arch/Figures/01_structure.png (Parte I, Sección 1).

Tema 2. Ideas clave
Ideas clave
Así, TOGAF y su documentación queda estructurada en torno a las siguientes partes:
▸ Parte I. Introducción. Esta parte proporciona una introducción a alto nivel de los
conceptos clave de Arquitectura Empresarial en general y, en particular, sobre la
aproximación seguida en TOGAF. Contiene las definiciones terminológicas que se

utilizarán a lo largo de todo el marco, proporcionando consecuentemente, un
vocabulario común a todos los interlocutores.
▸ Parte II. Método de Desarrollo de Arquitecturas (ADM). Es el elemento central del
Marco TOGAF ya que describe la aproximación propuesta, en modo paso a paso,

para el desarrollo de una Arquitectura Empresarial.
La aproximación propuesta consiste en un número de fases de desarrollo que
conforman un ciclo al efecto de reflejar el sentido de mejora continua de la AE. Cada
fase consta de una narrativa que la describe en términos de objetivos, enfoque,
actividades, entradas y salidas (entregables que conforman parte del contenido del
marco).
▸ Parte III. Guías y Técnicas del ADM . Actúa como complemento a la parte anterior
(ADM), proporcionando una colección de guías o directrices y técnicas (p. ej.,

principios, escenarios de negocios, análisis de brechas, planeación de la migración,
gestión de riesgos, etc.) para la aplicación de la aproximación TOGAF y de su ADM.
Esta colección viene complementada por otras guías y técnicas que, si bien no
forman parte del marco como tal, están disponibles en la Biblioteca TOGAF
(englobada en la Parte V de TOGAF).
Estas guías y técnicas pueden adaptarse a diferentes escenarios y a arquitecturas
específicas según lo necesite el usuario del marco.
▸ Parte IV. Marco de Contenido de la Arquitectura . Esta parte describe el marco de
Contenido de TOGAF. Para ello se proporciona un metamodelo para artefactos de
arquitectura, la reutilización de componentes (Bloques Constructivos de

Arquitectura) y un resumen de entregables de Arquitectura típicos.

Tema 2. Ideas clave
Ideas clave
▸ Parte V. Herramientas y Enterprise Continuum. Parte de TOGAF donde se
analizan las herramientas y taxonomías adecuadas para categorizar y almacenar el

resultado de la actividad de Arquitectura en una empresa u organización.
TOGAF incorpora, y gestiona, el concepto de Enterprise Continuum (conformado por
e l Architecture Continuum y el Solutions Continuum) de TOGAF para proporcionar
una visión del Repositorio de Arquitectura de forma que las arquitecturas
relacionadas se muestran ordenadas desde genéricas a específicas, abstractas a
concretas y desde lógicas a físicas.
▸ Parte VI. Marco para la Competencia de Arquitectura . Dedicada a los procesos,
habilidades, roles y responsabilidades requeridos para establecer y operar una

función (o competencia) de Arquitectura dentro de una empresa.
Como se ha indicado en la Parte II, dentro de la Parte V se incluye la Biblioteca
TOGAF. Esta biblioteca está conformada por materiales de referencia (directrices,
plantillas, patrones, etc.) que pueden ser utilizados para respaldar o acelerar la
aplicación de la aproximación TOGAF para desarrollar arquitecturas en una
organización. Aunque no forma parte como tal del estándar, se mantiene bajo el
control del Foro de Arquitectura de The Open Group y sus recursos están
estructurados en las siguientes secciones:
▸ Fundamentos.
▸ Directrices y técnicas genéricas.
▸ Directrices y técnicas específicas de una industria.
▸ Directrices y técnicas específicas de una organización.

Tema 2. Ideas clave
Ideas clave
Ciclo de Desarrollo de la Arquitectura (ADM)
Como se ha indicado, ADM es el elemento central de TOGAF en tanto que propone
una aproximación por pasos o fases para el desarrollo de una Arquitectura siguiendo
una secuencia cíclica, como recoge la siguiente figura:
Figura 6. Estructura del ciclo ADM de TOGAF. Fuente: https://pubs.opengroup.org/architecture/togaf8-

doc/arch/chap03.html

Tema 2. Ideas clave
Ideas clave
Las fases del ciclo ADM de TOGAF, de manera resumida son las siguientes:
▸ Fase Preliminar. Esta fase tiene por objeto las actividades de preparación e
iniciación requeridas para que una Arquitectura Empresarial cumpla con las
directivas de negocio. Incluye la definición de un marco de arquitectura específico de
la organización y la definición de los Principios.
▸ Fase A. Visión de Arquitectura. Esta es la fase inicial del ADM y establece cual es
el alcance de la Arquitectura junto con las partes interesadas, creando la Visión de la

Arquitectura y obteniendo las aprobaciones requeridas para su desarrollo.
▸ Fase B. Arquitectura de Negocio. Desarrollo de la Arquitectura de Negocio
(objetivo) de respaldo a la Visión de la Arquitectura, es decir, que describe cómo

tiene que actuar la empresa para alcanzar sus objetivos.
▸ Fase C. Arquitecturas de Sistemas de Información. Desarrollo de las
Arquitecturas (objetivo) de Datos y de Aplicaciones que posibilitarán la Arquitectura

de Negocio y, por consiguiente, la Visión de la Arquitectura.
▸ Fase D. Arquitectura Tecnológica. Desarrollo de la Arquitectura Tecnológica
(objetivo) conformada por componentes y servicios tecnológicos que posibilitan la

entrega de los bloques constructivos de Aplicaciones y Datos.
▸ Fase E. Oportunidades y Soluciones. Fase dedicada al proceso de identificación
de los proyectos, programas o portafolios de actuación requeridos para la entrega

efectiva de la Arquitectura Objetivo definida en las fases anteriores.
▸ Fase F. Plan de Migración. Fase donde se direcciona la planificación detallada de
la migración desde la Arquitectura o situación inicial (línea base) hasta la

Arquitectura Objetivo.
▸ Fase G. Implementación del Gobierno. Dedicada a la supervisión de la
implementación de la Arquitectura objetivo.

Tema 2. Ideas clave
Ideas clave
▸ Fase H. Gestión de Cambios a la Arquitectura. Establece los procedimientos para
gestionar los cambios que se quieran aplicar a la nueva Arquitectura para asegurar
que se mantiene vigente y responde a las necesidades de la empresa.
▸ Gestión de Requerimientos. No es una fase como tal ya que su presencia es
constante durante todo el ciclo ADM. Es el conjunto de actividades necesarias para

la adecuada gestión de requisitos a lo largo de todo el ciclo de desarrollo de una
Arquitectura Empresarial.
Zachman Architecture Framework (Zachman Framework®)
Zachman es el Marco para Arquitecturas Empresariales desarrollado por John A.
Zachman en 1984 y publicado por primera vez en IBM Systems Journal en 1987. Es
uno de los marcos de trabajo más antiguos y de mayor difusión en la actualidad junto
con TOGAF.
Este marco de AE Zachman, o de manera simplificada el Marco Zachman, es una
estructura que:
▸ Permite organizar y clasificar la representación detallada de una empresa mediante
la visualización de las relaciones entes los roles y los procesos.
▸ Se utiliza como herramienta de planificación al proporcionar información de contexto
de negocio y alternativas de actuación al proceso de toma de decisiones

empresariales.
▸ No se centra en la estrategia como tal ni en los mecanismos de Gobierno.
Proporciona una visión estática de los componentes de la arquitectura sin definir
procesos ni organizaciones para evolucionar desde la situación actual a la situación

objetivo.

Tema 2. Ideas clave
Ideas clave
El marco como tal es un conjunto de representaciones descriptivas que se
materializa mediante una matriz donde se cruzan los dos conceptos básicos de
clasificación/representación:
▸ Perspectiva. Puntos de vista particulares a cada tipo de participante sobre el objeto
considerado. El Marco Zachman establece cada «tipo de participante» a partir de los

pasos que sigue una idea abstracta para su instanciación, es decir: Identificación,
Definición, Representación, Especificación, Configuración e Instalación. Donde cada
uno de estos pasos lo enlaza con un «tipo de participante».
▸ Abstracción. Diferentes categorías o propósitos mediante los cuales se puede
describir un objeto. De manera concreta, el Marco Zachman utiliza como elementos

de descripción de un objeto el conjunto de preguntas primitivas dentro de la
comunicación humana: ¿qué?, ¿cómo?, ¿cuándo?, ¿quién?, ¿dónde? y ¿por qué?
De esta manera, si nos movemos por la matriz en sentido horizontal (fila) veremos
las diferentes descripciones de un sistema (empresa) desde el punto de vista de un
único participante, mientras que si nos movemos de manera vertical (columnas),
estaremos contrastando la percepción que todos los participantes tienen sobre un
mismo aspecto del sistema (empresa). Esto supone que cualquier elemento del
Marco de AE es el cruce explícito entre una visión o perspectiva subjetiva y una
descripción objetiva.
Es por lo anterior que existe una cierta controversia entre los partidarios de que el
Marco Zachman no es realmente un «Marco» sino una «Ontología» y aquellos que
consideran que no es una Ontología. Dado que a efectos prácticos de la introducción
del marco/ontología y de su uso, esta controversia es irrelevante, no vamos a
profundizar aquí en la distinción entre ambos conceptos y mantendremos la
nomenclatura de «marco».

Tema 2. Ideas clave
Ideas clave
Por el contrario, sí resulta necesario resaltar que el Marco Zachman no es una
metodología para la creación de la implementación (o instanciación) del objeto en

cuestión. Como hemos indicado, no describe ningún proceso como tal, sino que
simplemente proporciona la descripción del objeto. El Marco Zachman describe un
modelo integral de la infraestructura de la información de la empresa desde seis
Perspectivas (Tipos de Participantes):
▸ Planificador.
▸ Propietario.
▸ Diseñador.
▸ Constructor.
▸ Subcontratistas.
▸ Sistema de trabajo.
No hay ninguna orientación sobre la secuencia, proceso o aplicación del marco, sino
que el foco se pone en garantizar que todos los aspectos de una empresa estén bien
organizados y se muestren las relaciones claras que garanticen un sistema completo,

independientemente del orden en el que están establecidos.
Los principios fundamentales que guían la aplicación del Marco Zachman incluyen
los siguientes aspectos:
▸ Un sistema completo puede ser modelado por representación de las respuestas a las
siguientes preguntas (Abstracciones): ¿por qué?, ¿quién?, ¿qué?, ¿cómo?, ¿dónde?

y ¿cuándo? Sin imponerse ningún orden específico en cuanto a la realización de
estas preguntas.
▸ Las Perspectivas, siendo únicas, capturan todos los modelos críticos para el
desarrollo del sistema.

Tema 2. Ideas clave
Ideas clave
▸ Las restricciones para cada Perspectiva son aditivas; las de una fila inferior se
suman a las de las filas superiores (respaldo de la estructuración de responsabilidad

organizativa) para ofrecer un número creciente de restricciones.
▸ Cada celda resultante del cruce de una Perspectiva con una Abstracción es única.
Con todo lo anterior, el Marco Zachman está conformado, en su forma más genérica,
como recoge la siguiente figura:
Figura 7. Marco Zachman como estructura de clasificación (forma más genérica. Zachman.com). Fuente:
https://www.zachman.com/resources/ea-articles-reference/327-the-framework-for-enterprise-architecture-
background-description-and-utility-by-john-a-zachman

Tema 2. Ideas clave
Ideas clave
La descripción de las filas es la siguiente:
▸ Objetivo (Planificador): corresponde a un resumen ejecutivo de un planificador que
quiere una estimación del tamaño, costo y la funcionalidad del sistema. Además, el
planificador se ocupa del contexto de la empresa, de su entorno competitivo, de las
fuerzas internas y externas que influyen en su competitividad, del posicionamiento
de sus productos y servicios, que lo obligan a especificar sus alcances a largo plazo;
esta perspectiva cubre los componentes del nivel estratégico
▸ El modelo de negocio (Dueño): muestra todas las entidades y procesos de negocio,
y cómo interactúan. Aquí se relaciona el Dueño, este se interesa en la operación del

negocio, para lo cual requiere del modelado de la empresa mediante modelos de
procesos, de flujos de trabajo, de logística empresarial, de modelos semánticos y de
planes de negocio que le permitan controlar la operación de la empresa; esta
perspectiva se centra en el proceso de negocio, por lo que constituye en buena
medida el nivel de procesos.
▸ El modelo del sistema (Diseñador): es usado por un analista de sistemas que
deben determinar los elementos de datos y funciones de software que representan el

modelo de negocio. Tiene que ver con la especificación de los planos conceptuales
de los sistemas de información que se requieren para soportar la operación de los
procesos.
▸ Modelo tecnológico (Constructor): considera las limitaciones de las herramientas, la
tecnología y los materiales. El Constructor se encarga del ensamblado y fabricación
de los diversos componentes de los sistemas de información de acuerdo con las

restricciones de la tecnología utilizada-

Tema 2. Ideas clave
Ideas clave
▸ Componentes o representaciones detalladas (Programador): Representación
individual de los módulos independientes que pueden ser asignados a los

contratistas para la ejecución de tareas. El programador trabaja en la fabricación de
los componentes de acuerdo con las especificaciones del constructor. Las

perspectivas del diseñador, constructor y programador se ubican claramente en el
nivel de sistemas de información.
▸ Sistema de trabajo: muestra el sistema operativo.
Y de igual manera, la descripción de las Columnas es la siguiente:
▸ Personas (¿quién?): representa las relaciones de las personas dentro de la
empresa. El diseño de la organización empresarial tiene que ver con la asignación

de trabajo y la estructura de autoridad y responsabilidad. La dimensión vertical
representa la delegación de autoridad, y la horizontal representa la asignación de la
responsabilidad.
▸ Tiempo (¿cuándo?): representa el tiempo, o el caso de las relaciones que
establecen los criterios de rendimiento y los niveles cuantitativos de los recursos de

la empresa. Esto es útil para diseñar el programa maestro, la arquitectura de
procesamiento, arquitectura de control, y dispositivos de sincronización.
▸ Motivación (¿por qué?): describe las motivaciones de la empresa. Esto pone de
manifiesto los objetivos de la empresa y los objetivos estratégicos, plan de negocios,

la arquitectura del conocimiento y el diseño de los conocimientos.
▸ Data (¿qué?): describe las entidades involucradas en cada punto de vista de la
empresa. Los ejemplos incluyen los objetos de negocio, datos del sistema, las tablas
relacionales y las definiciones de campo.
▸ Función (¿cómo?): muestra las funciones dentro de cada perspectiva. Incluyen
procesos de negocio, la función de la aplicación de software, la función del hardware
del equipo y el lazo de control del lenguaje.

Tema 2. Ideas clave
Ideas clave
▸ Red (¿dónde?): muestra las localizaciones y las interconexiones dentro de la
empresa. Esto incluye lugares geográficos empresariales importantes, secciones

separadas dentro de una red logística, la asignación de los nodos del sistema, o
incluso las direcciones de memoria dentro del sistema.
Una versión plenamente cumplimentada del Marco Zachman, en su última versión
(v3.0) sería la siguiente figura:
Figura 8. Marco Zachman V3.0 plenamente cumplimentado (Zachman.com). Fuente:

https://www.zachman.com/images/ZI_PIcs/ZF3.0.jpg
Cuando indicamos «plenamente cumplimentado» hacemos referencia a un escenario
donde:
▸ Cada artefacto arquitectural está en una única celda de la matriz.
▸ Todos los artefactos arquitecturales están en una celda (están definidos).
▸ Todas las celdas de la matriz deben estar rellenas (artefactos arquitecturales) para
que la arquitectura sea completa.

Tema 2. Ideas clave
Ideas clave
▸ Una celda se considera rellena cuando contiene artefactos que determinan el
sistema (empresa) para un participante determinado y para un aspecto específico.
▸ Todas las celdas de una columna están relacionadas entre sí, por tanto, los
artefactos arquitecturales de esas celdas deben estar también relacionados entre

ellos (mantenimiento de consistencia y coherencia).
SOMF (Service Oriented Modeling Framework)
Es una metodología para desarrollo de software que emplea disciplinas y lenguajes
de modelado para proveer soluciones estratégicas y tácticas a problemas
empresariales, se caracteriza por identificar a las entidades de software como activos
llamados «servicios». Se centra en el uso de mejores prácticas para el diseño de
software bajo un enfoque de arquitectura empresarial, se basa en los principios
definidos en SOA, de hecho complementa a SOA mediante la incorporación del
modelado de procesos de negocio (Grigoriu, 2011).
Características
Las principales características del Marco SOMF son las siguientes:
▸ Permite realizar modelado de procesos de negocio estandarizando procedimientos y
empleando las mejores prácticas de modelado.
▸ Emplea terminología universal, vocabulario simple y sintaxis intuitiva.
▸ Promueve la reutilización y consolidación de software
▸ Alinea las TI a los procesos y estrategias de negocio.
▸ Consolidación de aplicaciones.

Tema 2. Ideas clave
Ideas clave
▸ Un usuario puede modelar cualquier tecnología, lenguaje de programación,
plataforma de arquitectura, infraestructura, software.
▸ Cada etapa de desarrollo requiere diagramas distintos.
▸ Se pueden utilizar patrones de diseño para agilizar la elaboración de un diagrama.
▸ Acelera el tiempo de entrega.
SOMF introduce un modelo de transparencia al permitir tres grandes marcos de
modelado en el tiempo, a menudo llamados generaciones de modelos:
▸ Used-To-Be: es un esquema de diseño de componentes de software y entornos
relacionados que fueron desplegados, configurados y utilizados en el pasado.
▸ As-Is: diseño de componentes de software y entornos correspondientes que se
están utilizando actualmente.
▸ To-Be: diseño de componentes de software y entornos que se implementarán,
configurarán y utilizarán en el futuro.
Conceptualización
Mediante sus modelos, SOMF ofrece una vista de 360° del ciclo de vida de cualquier
desarrollo de software, comenzando con la conceptualización, el diseño de la
arquitectura y el uso de las mejores prácticas en el modelado orientado a la
operación de los servicios en el ambiente de producción.

Tema 2. Ideas clave
Ideas clave
A fin de lograr los hitos propuestos se basa en las siguientes disciplinas
fundamentales (recogidas en la siguiente figura):
▸ Modelo de concepción orientado a servicios.
▸ Análisis de modelo y descubrimiento orientados a servicios.
▸ Integración de negocio orientada a servicios.
▸ Modelo lógico orientado a servicios.
▸ Modelo de arquitectura de software orientada a servicios.
▸ Herramientas de modelo de Cloud Computing.
Figura 9. Estructura de SOMF v2.0. Fuente: https://en.wikipedia.org/wiki/Service-
oriented_modeling#/media/File:SOMF_V_2.0.jpg

Tema 2. Ideas clave
Ideas clave
Una de las últimas incorporaciones a SOMF es el Cloud Computing Modeling
Notation (CCMN). Este modelo identifica una nube como una entidad estructural y
contextual que puede ser modelada como cualquier otro servicio. La nube como
concepto de servicios en SOMF es impulsado por el término “Everything as a
Service”. Por otra parte, los servicios que ofrece una nube encajan bajo muchas
categorías, las principales clasificaciones son de software como servicio (SaaS),
infraestructura como un servicio (IaaS) y plataforma como un servicio (PaaS). Esta
visión holística de modelado permite crear un entorno de Cloud Computing y facilitar
su adopción.
El marco ofrece una variedad de diagramas diseñados para comunicar la
arquitectura de negocio, diseño y desarrollo, estos se organizan en grupos en donde
cada uno representa un modelo de SOMF, aunque cada diagrama es construido
durante su fase correspondiente, en el ciclo de vida de desarrollo se permite la
combinación de estos para personalizar y representar el diagrama necesario para el
proyecto. Adicionalmente se pueden utilizar notaciones especificadas en dos o más

proyectos para construir un nuevo diagrama que no necesariamente es definido en
SOMF.

Tema 2. Ideas clave
Ideas clave
OBASHI® (Owner Business process Application System Hardware

Infrastructure)
El Marco OBASHI fue generado por Fergus Cloughley y Paul Wallis de Stroma
Software Ltd. a finales del 2001 como parte de su participación en un proyecto de
British Petroleum. Su colaboración se centró en ayudar a los responsables de las
plantas de BP a visualizar y comprender cómo y por qué los activos TI respaldaban
los servicios de negocio (y por extensión los objetivos de negocio) de BP;

consecuentemente, la fuente de inspiración de OBASHI son los modelos de control y
simulación operacional utilizados en procesos industriales.
Posteriormente, el Marco OBASHI, ha sido complementado con una metodología que
permitiera extender la aplicación de los métodos utilizados para determinar el coste y
el valor de los procesos productivos a cualquier otro tipo de sector industrial.
Marco OBASHI
OBASHI documenta y modeliza como las personas, los procesos y la tecnología
interactúan en una empresa u organización y presenta la información de manera que
sea entendible, tanto por personal técnico, como no técnico.
La metodología se apoya en el Marco OBASHI que consiste en un conjunto de seis
capas (las dos superiores dedicadas a las personas y procesos de negocio y las
cuatro restantes a los activos TI) en las que se recogen los datos relativos a las
personas, procesos y tecnologías, junto con las relaciones existentes entre ellos, de
la empresa para crear un Diagrama Negocio/TI (B&IT diagram).

Tema 2. Ideas clave
Ideas clave
La siguiente figura proporciona un ejemplo de Diagrama Negocio/TI utilizando el
Marco OBASHI:
Figura 10. Ejemplo de Diagrama Negocio/TI (B&IT diagram) utilizando el Marco OBASHI. Fuente:
https://commons.wikimedia.org/wiki/File:OBASHI_Business_and_IT_Diagram.jpg

Tema 2. Ideas clave
Ideas clave
Las capas mencionadas como conformantes del Marco OBASHI, y que figuran en el
ejemplo anterior, son las siguientes:
▸ Ownership. Esta capa contiene los elementos que representan a las personas o
grupos que son los propietarios o responsables de los procesos de negocio
representados en la capa Business Process. La disposición de los elementos

indicados (personas o grupos) no está limitada a un único nivel, sino que permite
reflejar jerarquías de propietarios si se necesita (en la figura anterior vemos este tipo
de jerarquías en las capas Application e Infrastructure).
▸ Business Process. Capa que contiene los elementos que representan los
procesos de negocio o funciones utilizadas por los elementos de la capa

Ownership. Estos elementos se situarán en el diagrama inmediatamente debajo de
su Propietario.
▸ Application. Esta capa contiene elementos que representan las Aplicaciones
software de la empresaque respaldan los procesos de negocio y,

consecuentemente, se ubican en el diagrama debajo de estos.
▸ System. Capa que contiene los elementos que representan los Sistemas
Operativos sobre los que se ejecutan las aplicaciones de la capa Application y,

como en todos los casos, se ubicarán debajo de los elementos correspondientes de
la capa superior.
▸ Hardware. Esta capa contiene los elementos que representan la plataforma de
computación (no de comunicaciones) para los Sistemas Operativos reflejados

en la capa System y se ubican justo debajo de estos.

Tema 2. Ideas clave
Ideas clave
▸ Infrastructure. Capa que contiene los elementos que representan la
infraestructura de la red (comunicaciones) utilizada para acceder a la plataforma

de computación o para comunicar elementos de la capa Hardware entre sí. Al
igual que en el resto de las capas, los elementos de esta capa se ubican debajo de
los elementos correspondientes de la capa superior (en este caso capa Hardware) y
se permite el establecimiento de jerarquías entre ellos.
Adicionalmente a lo indicado con respecto de la representación de relaciones dentro
de un diagrama, es necesario aclarar que el Marco OBASHI también establece un
conjunto de reglas que gobiernan la tipología y representación de las relaciones,
tanto implícitas, como explícitas, entre los diferentes elementos del diagrama.
Metodología OBASHI
Como hemos introducido, el Marco OBASHI surge en un sector industrial y,

consecuentemente, viene marcado en origen por sus características inherentes. De
manera simplificada se puede decir que las empresas de los sectores industriales
controlan sus procesos productivos mediante los Sistemas de Control (DCS –
Distributed Control Systems) donde los flujos de datos actúan como elementos calve
de control productivo (a una entrada concreta le corresponde una salida
determinada). Por tanto, el entendimiento y control de los flujos de datos resultan
clave para describir la operativa de una empresa.
La Metodología OBASHI surge posteriormente al Marco OBASHI, como propuesta
para extender la aplicación de los métodos utilizados para determinar el coste y el
valor de los procesos productivos, en sectores industriales, a cualquier otro tipo de
sector económico.

Tema 2. Ideas clave
Ideas clave
La Metodología OBASHI, por tanto, permite crear diagramas utilizando el Marco
OBASHI que describen los componentes empresariales y sus flujos de datos para
entender el funcionamiento del negocio. Los flujos de datos se representarán en las
denominadas Vistas de Análisis de Flujos de Datos (Dataflow Analysis View)
que, de manera rápida, se pueden entender como una superposición a los
Diagramas Negocio/TI para representar una secuencia de elementos requeridos para
dar soporte a un Servicio de Negocio.
Las DAV pueden ser, tanto representaciones gráficas, como estadísticas de los
recursos de Negocio y TI junto con sus atributos financieros, que representan las
interacciones entre ellos en la operativa diaria.
Un ejemplo de DAV gráfico está recogido en la figura 11:
Figura 11. Ejemplo de Diagrama de Análisis de Flujo de Datos (DAV). Fuente:

https://upload.wikimedia.org/wikipedia/commons/5/5f/OBASHI_Dataflow_Analysis_View.jpg
Campos de utilización o aplicación
Debido a sus orígenes, esta metodología está siendo utilizada para complementar la
implementación de ITIL®, OBASHITM puede apoyar la implementación a través del
ciclo de vida de los servicios de la siguiente manera (utilizando la estructuración de
ITIL v3):

Tema 2. Ideas clave
Ideas clave
▸ Service Strategy: ayuda a las organizaciones a crear y administrar su portafolio de
servicios, OBASHI ayuda a alinear los servicios a los procesos de negocio.
▸ Service Design: es el responsable de diseñar y actualizar los servicios, es necesario
conocer los requerimientos de negocio, OBASHI puede ayudar a identificar

oportunidades, identificar stakeholders y mostrar como las TI apoyan a los procesos
de negocio.
▸ Service Transition: es responsable de publicar los cambios y /o nuevos servicios,
OBASHI ayuda a identificar el impacto que pueden ocasionar dichos cambios

mediante la administración del conocimiento, provee además un mapa de la relación
que existe entre las TI y los procesos.
▸ Service Operation: garantizar la continuidad de los servicios, OBASHI ayuda a
determinar el impacto por caídas de los servicios, es decir puede mostrar que
pasaría si no se garantiza la continuidad y cómo afectaría a los procesos de
negocio.

Tema 2. Ideas clave
Ideas clave
2.4. Selección de un Marco de Arquitectura

Empresarial
Todos los Marcos de Arquitectura Empresarial, tanto los aquí presentados, como
cualquier otro que podamos considerar, poseen sus características particulares que
deberán ser analizadas y evaluadas como puntos fuertes o debilidades desde el
punto de vista de la adecuación a las características intrínsecas a la empresa u
organización a la que se quieran aplicar.
A la hora de determinar el Marco de Arquitectura Empresarial que mejor se adecúa a

una organización, podemos utilizar diferentes modelos de comparación disponibles
en el mercado (como por ejemplo: Urbaczewski y Mrdalj, 2006; Sessions y
deVadoss, 2014; Hernández-Julio, Nieto Bernal y Palm, 2017), pero siempre
debemos recordar que estas comparativas no reflejan necesariamente las
características de la organización considerada, ni tienen igualmente por qué
ajustarse a la aproximación u objetivo planteado para la aplicación de ese marco.
Como hemos podido comprobar en la sección anterior, los diferentes Marcos de
Arquitectura Empresarial disponibles en el mercado (los enumerados anteriormente y
otros), presentan variaciones sustanciales entre ellos, como que, por ejemplo,
mientras unos proporcionan más estructura en torno a la taxonomía o la clasificación
u organización de una empresa, otros enfatizan el propio proceso de generación de
la arquitectura. Esto tiene como consecuencia que el funcionamiento de un Marco de
Arquitectura Empresarial en una organización no tiene por qué significar de manera
automática que vaya a funcionar en otra de la misma manera: la eficiencia de un
Marco de Arquitectura Empresarial no depende de las características del marco

Tema 2. Ideas clave
Ideas clave
en sí mismo, sino de cómo y a qué organización se aplique. Por este motivo, es
conveniente que la empresa proceda a examinar cuidadosamente los marcos
disponibles a la luz de sus propias características y, en la medida de lo posible, haga
uso combinado con otras disciplinas complementarias, como puedan ser los Marcos
de Gobierno y Gestión TI (p. ej., COBIT e ITIL, entre otros).
Es por este motivo que, como hemos indicado al comienzo del presente tema,
añadimos el término «Referencia» para denominar los Marcos de Arquitectura
Empresarial: los Marcos de Arquitectura Empresarial deben ser tomados por las
empresas como puntos de Referencia para la creación y uso de sus propias y
particulares Arquitecturas Empresariales (como veremos también más adelante
cuando hablemos de las iniciativas de adopción de AE) y, en el caso de empresas
con un nivel de madurez de Arquitectura Empresarial elevado, poder incluso generar
su propio Marco de Referencia de Arquitectura Empresarial.
Llevar a cabo el contraste de selección del Marco de Referencia de Arquitectura
Empresarial significa aplicar una serie de criterios, tanto cuantitativos, como
cualitativos, de consideración y valoración de Marcos de Arquitectura Empresarial.
La siguiente es una lista no prescriptiva, exhaustiva o limitante de criterios que se

pueden aplicar para la comparativa y selección de un Marco de Arquitectura
Empresarial:
▸ Completitud de la Taxonomía. Hace referencia al nivel de adecuación
metodológica aportado por el marco para la clasificación de los artefactos

arquitectónicos.
▸ Completitud del Proceso. Hace referencia a si dispone, y en qué medida, de una
metodología que establezca un proceso paso a paso para la generación de una


Tema 2. Ideas clave
Ideas clave
▸ Modelo de Referencia. Medida del nivel en el que la metodología proporcionada
ayuda en la creación de modelos de referencia relevantes y soportados por un único

lenguaje común estandarizado.
▸ Prácticas. Grado en el que la metodología propuesta ayuda a la organización en el
cambio de mentalidad y el establecimiento de una nueva cultura en la que la
Arquitectura Empresarial es valorada y utilizada (Gestión del Cambio

Organizacional).
▸ Modelo de Madurez. Grado de concreción metodológica para la evaluación de la
eficiencia y madurez alcanzada por la organización en la utilización de la

▸ Foco en el Negocio. Indicativo del nivel de foco existente en el uso de la tecnología
como generador de valor de negocio, donde este puede estar definido

específicamente como reducción de gastos e incremento de ingresos.
▸ Directrices de Gobierno. En qué medida la metodología o el marco en sí posibilitan
la creación de un Modelo de Gobierno de la Arquitectura Empresarial y su

incorporación como parte del Gobierno TI, o Gobierno Corporativo de las TIC, en la
organización.
▸ Directrices de Simplificación. Hacen referencia al nivel en el que la metodología
del marco guía en el proceso de simplificación de la complejidad empresarial

mediante una división eficaz en elementos o dominios autónomos.
▸ Catálogo de Artefactos. Grado de definición metodológica para el establecimiento
de un catálogo prescriptivo de activos de arquitectura que puedan ser reutilizados en

actividades futuras.
▸ Neutralidad de fabricante. Verosimilitud de independencia de empresas
consultoras, asesoras o fabricantes a la hora de proceder a la adopción de un Marco

de Arquitectura Empresarial.

Tema 2. Ideas clave
Ideas clave
▸ Disponibilidad de Información. Volumen y calidad de información gratuita o de
bajo coste relativa al Marco de Arquitectura Empresarial, que puede ser utilizada
para asegurar o acelerar la adopción de dicho marco.
▸ Time to Value. Plazo estándar requerido por una organización (según diferentes
características) para la adopción del marco y comienzo de utilización para la

generación de valor de negocio (Hasselmann, 2011).
▸ Interoperabilidad Organizacional. Hace referencia al grado de armonización que
proporciona el Marco de Arquitectura Empresarial entre los Procesos de Negocio y

las Tecnologías de Información, considerando, tanto el ámbito interno de la empresa,
como la empresa extendida.
▸ Interoperabilidad Informacional. Hace referencia al modo en el que en el marco
considerado se asegura el valor representado por el intercambio de información y

datos, tanto dentro de la organización o empresa, como con otros elementos
externos.
▸ Mantenibilidad. Grado de esfuerzo requerido para el mantenimiento de la
Arquitectura Empresarial, derivado por las características del Marco de AE y no por

el tamaño o complejidad de la empresa como tal.

Tema 2. Ideas clave
Ideas clave
2.5. Fases principales en el ciclo de creación y

utilización de la Arquitectura Empresarial
Ya hemos visto que, tanto en sectores privados, como en el sector público, las
organizaciones adoptan las Arquitecturas Empresariales por diferentes motivos,
como puedan ser la mejora del alineamiento e integración entre Negocio y TI, la
planificación estratégica, la simplificación de complejidades empresariales o la
mejora en los procesos de toma de decisiones; pero, en cualquier caso, siempre en
la línea del cambio organizacional para la mejora de resultados.
A la hora de analizar el proceso de adopción de la Arquitectura Empresarial, es

importante tener en cuenta que, este concepto de adopción de AE, se entiende, de
manera general, bajo dos perspectivas complementarias:
▸ El modo en que las organizaciones utilizan o adoptan, en sentido literal, una
▸ La manera en la que la Arquitectura Empresarial funciona dentro de la empresa.
Como indicamos, ambas perspectivas no son excluyentes, si bien, aquí nos vamos a
centrar en la primera de ellas, es decir, el modo en el que las organizaciones
desarrollan y utilizan una Arquitectura Empresarial.
Este proceso de adopción, como cualquier otro proceso de cambio organizacional,
sobre el papel tiene una representación sencilla, como refleja la figura 12.

Tema 2. Ideas clave
Ideas clave
Figura 12. Flujo simple de Adopción de Arquitectura Empresarial.
Pero esto no debe llevarnos a una falsa confianza ya que la adopción de una
Arquitectura Empresarial está sujeta a múltiples factores, como son los siguientes:
▸ Factores organizacionales. Factores relacionados con las competencias, cultura o
estructura de la organización:
• La Estructura Organizacional.
• Existencia o no de una Competencia de Gestión del Cambio.
• La necesidad del Cambio en la Cultura organizacional.
• La capacidad de la Organización para adoptar cambios.
• El modelo de Gestión del portafolio TI.
• Grado en que los cambios están marcados por la estrategia.
• La estructuración de los procesos de toma de decisiones.
• El nivel de conformidad exigido a los cambios.
• La carencia de foco en la perspectiva social de los Marcos de Arquitectura

Empresarial.
• La capacidad de gestión de choques culturales que puedan surgir.
• Relevancia de la perspectiva social.

Tema 2. Ideas clave
Ideas clave
• Consideración de las personas y la tecnología en la organización.
• El nivel de resistencia al cambio en la organización.
• Nivel y modelo de liderazgo en la empresa.
• El grado de compromiso de la dirección.
• Ubicación organizativa de la Función de Arquitectura empresarial.
• Estructuras y mecanismos de comunicación organizativa.
• Grado de definición de los objetivos de la adopción de la Arquitectura Empresarial

por parte de la organización.
▸ Factores propios de la Arquitectura Empresarial. Factores pertenecientes a la
profesión o disciplina de la Arquitectura Empresarial:
• Selección del Marco de Arquitectura Empresarial.
• Concreción de la definición de Arquitectura Empresarial en la organización.
• Formalización en la utilización de Principios.
• Experiencia y capacitación del personal en Arquitectura Empresarial.
▸ Factores medioambientales. Factores relacionados con el contexto en el que opera
la organización, tales como legislaciones y regulaciones:
• El iniciador de la Arquitectura Empresarial.
• Aspectos de interoperabilidad de Arquitecturas relacionadas.
• Poder de dirección e influencia de terceras partes.
Tener presentes los factores anteriores durante todo el proceso de adopción de la AE
resultará clave para el éxito o fracaso de la iniciativa.

Tema 2. Ideas clave
Ideas clave
Ya hemos indicado con relación a los Marcos de AE que deben seleccionarse y
aplicarse considerando las características propias de cada organización, este
comportamiento se ve reforzado al recoger los factores anteriores según las
diferencias culturales e individuales existentes entre las organizaciones, lo que
implica que cada una siga un proceso o aproximación más o menos próximo al de la
figura anterior (ver Figura 12), si bien, siempre similar (Evernden y Evernden, 2015).
De esta forma, y sin complicar en exceso la secuencia de adopción de una

Arquitectura Empresarial, se puede considerar el siguiente flujo como un proceso
estándar para dicha adopción:
Figura 13. Flujo estándar de Adopción de Arquitectura Empresarial.
De manera resumida, los pasos a seguir son:
1.Explicaciónde los beneficios que, tanto a nivel empresarial, como a nivel particular,
presenta la adopción de una Arquitectura Empresarial. Esta explicación está dirigida
al personal directivo y decisor en cualquier iniciativa estratégica como pueda ser
esta. El propósito no es únicamente posibilitar el consenso y aprobación de la
iniciativa sino comenzar la ejecución de la iniciativa obligatoria de Gestión del

Cambio Organizacional y obtener la esponsorización y compromiso de la dirección
con la adopción de la AE.

Tema 2. Ideas clave
Ideas clave
2.Obtencióndel Mandatode adopción de la Arquitectura Empresarial. Debe

plantearse de manera formal cual es la misión, objetivos y alcance de la iniciativa y,
en la medida de lo posible, una aproximación de actuación e implicaciones que
permitan una toma de decisión más informada por parte de la directiva o el
refinamiento de la propuesta en función de las indicaciones recibidas.

- Uno de los principales inhibidores de progreso a una iniciativa de adopción
de una Arquitectura empresarial es la falta de visión común, y compromiso, en la alta
dirección acerca de la aplicación de una Arquitectura Empresarial.
3.En caso de alcanzarse un consenso para la adopción de una Arquitectura

Empresarial, y continuando con la iniciativa de Gestión del Cambio Organizacional,
se procede a:
- Capacitar a la organización según las diferentes necesidades para su

participación eficiente no solo en el proceso de generación y adopción de la
Arquitectura empresarial, sino también para su uso y mantenimiento posterior.
- Establecer una estructura organizativa responsable del proyecto de
adopción de la Arquitectura Empresarial considerando, igualmente, las actividades
funcionales posteriores a la adopción de la Arquitectura Empresarial.
- Asimismo, establecer un órgano de Gobierno y Gestión de la Arquitectura

que asegure en todo momento la coordinación y dirección al nivel competencial
requerido de las iniciativas y actuaciones requeridas para el establecimiento de la
Arquitectura empresarial.
4.Actuando como punto de retroalimentación a la capacitación de la organización, se

procederá a seleccionar el Marco de Referencia de Arquitectura Empresarial que
mejor se adecúe a las características propias de la organización y a la misión,
objetivos y alcance considerados. Se indica el carácter de retroalimentación en tanto

que la Capacitación comenzará con los elementos comunes de Arquitectura
Empresarial y, cuando se haya determinado el Marco de AE, se podrá finalizar la
Capacitación con los elementos específicos de este factor de referencia.
- Si bien la Arquitectura Empresarial objeto de definición y adopción es agnóstica
en cuanto a la tecnología subyacente empleada como respaldo, es conveniente en

Tema 2. Ideas clave
Ideas clave
este paso proceder igualmente a la selección de una herramienta de Arquitectura

Empresarial de forma que todos los datos e información estén recogidos y
gestionados de manera integral y consistente desde el arranque de la iniciativa, con

independencia de que se puedan utilizar de manera complementaria otras
herramientas de apoyo, como puedan ser aquellas específicas de la gestión de
programas y proyectos.
5.En caso de que el Marco de Referencia de Arquitectura Empresarial, como parte de

su metodología aporte una aproximación propia para su adopción, lo lógico es seguir
esta aproximación de adopción, siempre teniendo presentes los factores anteriores y
la consideración de las particularidades de la organización para asegurar la

idoneidad de la Arquitectura Empresarial resultante.
En cualquier caso, el proceso de adopción continúa de manera general con la
recogida de los datos e información actual de la organización para el alcance
considerado, de forma que, no solo quede recogida en la herramienta seleccionada,
sino que sirva como línea base de referencia o foto As-Is de la organización
(nuevamente, para el ámbito considerado).
6.A continuación se debe determinar el estado objetivo de la organización (foto To-

Be) de acuerdo con las directrices de descripción de Arquitectura establecidas en el
Marco de AE seleccionado. En este momento, como es lógico, solo podrán estar
definidas a alto nivel determinados componentes de la arquitectura, de forma que el
desarrollo y definición en detalle de la Arquitectura Empresarial se realizará en la
fase siguiente.
7.Finalmente, antes de entrar en la fase de uso y mantenimiento de la Arquitectura
Empresarial, se procederá a ejecutar el Cambio.

- Utilizando las herramientas y directrices del Marco de Referencia de
Arquitectura empresarial se procede a la definición en detalle de todos los
elementos, componentes y artefactos de arquitectura requeridos para la descripción
plena de la Arquitectura To-Be. La descripción de la Arquitectura no debe considerar
únicamente los Principios arquitectónicos técnicos, sino que debe incluir igualmente

Tema 2. Ideas clave
Ideas clave
los Principios arquitectónicos de negocio, y la relación de consistencia y coherencia

entre todos.
- Siguiendo la metodología del marco seleccionado, o bien empleando otra si
este no incorpora ninguna, se determinará el conjunto de iniciativas de
transformación requeridas para transicionar desde el estado As-Is (línea base) al
estado To-Be (objetivo), así como la estrategia de transición y transformación (p. ej.,
necesidad de establecimiento de Arquitecturas intermedias o de transición).

- Continuará sin interrupción la iniciativa ya lanzada de Gestión del Cambio
Organizacional.
8.Una vez finalizado el desarrollo de la Arquitectura, se entra en la fase de utilización

plena y mantenimiento de la Arquitectura. La Arquitectura Empresarial es un
elemento vivo, es decir, no solamente sirve de elemento de apoyo en la operativa
empresarial o para la toma de decisiones informadas, o para la planificación
estratégica de una empresa, sino que, en la medida en la que la propia organización,

en cualquiera de sus componentes (incluida la cultura empresarial), evoluciona, la
Arquitectura debe ser adecuada, por lo que continuará plenamente vigente la
actividad de los órganos de Gobierno y Gestión de la Arquitectura Empresarial que
se pusieron en marcha al comienzo de la iniciativa para, entre otras cosas:
- Generar Blueprints de la organización, que permitan entender su estructura,

operaciones e información.
- Analizar y Optimizar la Arquitectura, para ello se identificarán y crearán
mejoras continuamente de toda la Arquitectura (no solo de los procesos).
- Estudiar los retos de la organización, identificando los impactos de los
cambios, así como los riesgos, y controlando la gestión del cambio en la
organización.
- Compartir Resultados, mediante la creación de un repositorio común de
información que sirva para la toma de decisiones y la estandarización.

Tema 2. Ideas clave
Ideas clave
2.6. Referencias bibliográficas
Desfray P. y Raymond, G. (2014). Modeling Enterprise Architecture with TOGAF: A
Practical Guide Using UML and BPMN. The MK/OMG Press.
Evernden R. y Evernden, E. (2015). Enterprise Architecture - the Eight Fundamental
Factors: A practical guide to the factors that are common to all EA approaches and
frameworks. 2nd Edition. Createspace.
Grigoriu. A. (2011). An Enterprise Architecture Development Framework, 4th edition.
Amazon.
Hasselmann, C. (2011). Value Driven Enterprise Architecture. Createspace.
Hernández-Julio, Y. F., Nieto Bernal W. y Palm, M. (2017). A Comparative Analysis of
Emerging Enterprise Architecture Frameworks. Journal of Advanced Management
Science. Vol. 5, No. 6.
Langefors, B. y Sundgren, B. (1975). Information Systems Architecture.
Mason/Charte.
Sessions, S. y deVadoss, J. (2014). A comparison of the Top Four Enterprise
Architecture approaches in 2014. Microsoft Corporation.
Urbaczewski, L. y Mrdalj, S. (2006) A comparison of Enterprise Architecture

Frameworks. Issues in Information Systems, Volume VII, No. 2.
Zachman, J. A. (1987). A framework for information systems architecture. IBM
Systems Journal, vol. 26, no. 3, pp. 276-292.
Zachman, J. A y Spewak, S. H. (2008) Enterprise Architecture Planning: Developing
a Blueprint for Data, Applications, and Technology. Wiley-QED Publishing Group.

Tema 2. Ideas clave
Ideas clave
Información sobre Marcos de Arquitectura Empresarial:
AGATE:
http://www.sandness.com/AgatePartners/AgateIII/agateFrameworkWeb.html
http://www.ixarm.com/AGATE-framework
DoDAF:
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/
FEAF:
https://obamawhitehouse.archives.gov/omb/e-gov/FEA
MoDAF:
https://www.gov.uk/guidance/mod-architecture-framework
OBASHI:
https://obashi.co.uk/
SOMF:
https://enterprisemodelingsolutions.com/enacting-the-service-oriented-modeling-
framework-somf-using-enterprise-architect/
TOGAF:
https://www.opengroup.org/togaf/
ZACHMAN:
http://www.zachman.com/

Tema 2. Ideas clave
A fondo
Innovación, Transformación y Arquitectura

Empresarial
Robledo, P. (2017). La Arquitectura Empresarial necesaria para no ir a ciegas en
cualquier Innovación y Transformación empresarial . https://albatian.com/es/blog/la-

arquitectura-empresarial-necesaria-para-no-ir-a-ciegas-en-cualquier-innovacion-y-
transformacion-empresarial/
En este documento se explica el papel clave de la Arquitectura Empresarial en la
necesaria Transformación Digital en las Organizaciones.

Tema 2. A fondo
A fondo
Marco de Arquitectura Zachman
Sparks. G., Constable, B. y Ugavina, N. (Eds.). (2008). MDG Technology for
Zachman Framework User Guide. Sparx Systems.
https://www.sparxsystems.com.au/downloads/pdf/ZFUserGuide.pdf
En este documento se explica el uso del Marco de Arquitectura Empresarial
Zachman.

Tema 2. A fondo
A fondo
Survey of Architecture Frameworks. (20 de marzo de 2020). iso-architecture.org.

http://www.iso-architecture.org/ieee-1471/afs/frameworks-table.html
En esta web se recopilan en una tabla los principales marcos de Arquitectura
Empresarial junto con una breve descripción de su propósito, alcance y
características de clasificación (junto con enlaces a sitios web relevantes).

Tema 2. A fondo
A fondo
Modelo de Madurez de AE
Schekkerman. J. (2006). Extended Enterprise Architecture Maturity Model Support
G u i d e . Institute for Enterprise Architecture developments.
https://es.slideshare.net/Aamir97/extended-enterprise-architecture-maturity-model-
guide-v2
En esta guía se explica el modelo de madurez de la arquitectura empresarial,
asistiendo paso a paso en la definición, mantenimiento e implantación de la AE bajo
una metodología rigurosa para la gestión del ciclo de vida de AE.

Tema 2. A fondo
A fondo
Iniciativa de adopción de AE en la empresa
Schekkerman, J. (2004). Another view at Extended Enterprise Architecture viewpoints
Institute for Enterprise Architecture developments.
https://st2.ning.com/topology/rest/1.0/file/get/1696977827?profile=original
Este artículo trata de explicar el importante papel de la Arquitectura Empresarial en
las organizaciones y cómo incentivar en la Dirección este tipo de iniciativas.

Tema 2. A fondo
A fondo
Arquitectura Empresarial y Gestión de Procesos
Orensanz, D. (n. d.). Arquitectura Empresarial. [Archivo de vídeo].
En esta lección magistral se explica lo que aporta un Framework de AE para la
gestión de procesos de una empresa. Vídeo por David Orensanz, Managing Director
de BOC Ibérica (BOC Business Objetives Consulting Ibérica S.L.U.).
Accede al vídeo:
https://unir.cloud.panopto.eu/Panopto/Pages/Embed.aspx?id=8bcc3bc6-c993-
4fb1-861e-b12a00935898

Tema 2. A fondo
Test
1. Indica el Marco de Arquitectura Empresarial que es abierto:
A. IFW.
B. Zachman EA Framework.
C. OBASHI.
D. TOGAF.
E. DoDAF.
F. SOMF.
2. Indica los Marcos de Arquitectura Empresarial que son privados:
A. IFW.
B. Zachman EA Framework.
C. MoDAF.
D. SAP EA Framework.
E. EA Oracle Framework.
F. SOMF.
3. Indica los Marcos de Arquitectura Empresarial que son de organizaciones
estatales:
A. IFW.
B. FEAF.
- C. MoDAF.
D. Zachman EA Framework.
E. AGATE.
F. SOMF.

Tema 2. Test
Test
4. SOMF permite tres grandes marcos de modelado en el tiempo, denominados
normalmente como «generaciones de modelos». ¿Qué es el marco Used-To-Be?
A. Es el esquema de componentes de software y entornos relacionados que
fueron desplegados, configurados y utilizados en el pasado.
B. Es el diseño de componentes de software y entornos correspondientes que
se están utilizando actualmente.
C. Es el diseño de componentes de software y entornos que se
implementarán, configurarán y utilizarán en el futuro.
5. ¿Qué se ha incorporado al Marco SOMF?
A. Una notación para Cloud Computing.
B. Una notación para Internet de las Cosas.
C. Una notación para Big Data.
D. Una notación para BPMN.
6. ¿Qué capas arquitectónicas analiza TOGAF®?
A. Negocio, Aplicaciones y Servicios, Procesos, Datos y Tecnologías.
B. Negocio, Software, Datos y Tecnologías.
C. Negocio, Aplicaciones, Datos y Tecnologías.
7. En el Marco TOGAF®, ¿cuántos puntos de vista de la arquitectura pueden
representarse en un Artefacto?
A. Uno.
B. Dos.
C. Tres.

Tema 2. Test
Test
8. En el Marco Zachman, ¿qué representa el modelo del sistema (Diseñador)?
A. Los elementos de datos y funciones de software que representan el modelo
de negocio.
B. Las limitaciones de las herramientas, la tecnología y los materiales.
C. Muestra todas las entidades y procesos de negocio y cómo interactúan.
9. En el Marco Zachman, ¿qué representa el modelo tecnológico (Constructor)?
de negocio.
10. En el Marco Zachman, ¿qué representa el modelo de negocio (Dueño)?
de negocio.

Tema 2. Test

Tema 2

Cargado por

Copyright:

Formatos disponibles

Tema 2

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema 2

Cargado por

Copyright:

Formatos disponibles

Tema 2

Planificación Estratégica mediante Arquitectura

2.1. Introducción y objetivos

2.2. Definición y contenido de un Marco de Referencia

2.3. Análisis de los diferentes Marcos de Referencia y

2.4. Selección de un Marco de Arquitectura Empresarial

2.5. Fases principales en el ciclo de creación y utilización

2.6. Referencias bibliográficas

Innovación, Transformación y Arquitectura Empresarial

Marco de Arquitectura Zachman

Marcos de Arquitectura Empresarial

Iniciativa de adopción de AE en la empresa

Arquitectura Empresarial y Gestión de Procesos

Planificación Estratégica mediante Arquitectura Empresarial 3

2.1. Introducción y objetivos

El propósito de este tema, una vez realizada la introducción a la Arquitectura

Empresarial del tema «Fundamentos de Arquitectura Empresarial», es profundizar en

el entendimiento del concepto y utilidad de un Marco de Referencia de Arquitectura

Empresarial (y por qué es relevante añadir «de Referencia» a la nomenclatura

aplicada hasta ahora, ya sea de manera explícita o implícita), considerando sus

componentes o piezas básicas, la taxonomía de Marcos y los principales Marcos

existentes, y terminando con la ubicación de este elemento clave de la Arquitectura

Empresarial en el proceso de adopción o implantación de la Arquitectura Empresarial

en una compañía u organización.

Teniendo en cuenta lo anterior, este tema tiene por objeto:

▸ Ampliar la definición de Marco de Referencia de Arquitectura Empresarial junto con

▸ Introducir los componentes de un Marco de Referencia de Arquitectura Empresarial.

▸ Conocer una taxonomía de marcos en cuanto a criterios de aplicación.

▸ Proporcionar una visión introductoria de los principales marcos existentes.

▸ Presentar un proceso o secuencia de actividades requeridas para la adopción de la

Arquitectura Empresarial en una organización y en qué punto posicionar el Marco de

Planificación Estratégica mediante Arquitectura Empresarial 4

2.2. Definición y contenido de un Marco de

Hablar de Arquitectura Empresarial signiﬁca considerar la organización completa

junto con todos los elementos que la conforman, existiendo, en consecuencia, un

consenso generalizado en que esto implica hablar del alineamiento pleno de la

organización, en todas sus facetas, con los objetivos corporativos.

la componen y sobre la estructuración de los mismos; pero esto, en el caso de la

Empresarial» utilizábamos la analogía de la Arquitectura Empresarial con la

arquitectura de un ediﬁcio (para ilustrar la relación con otra disciplina clave en la

aproximarla más a la realidad. Dado que la Arquitectura Empresarial tiene en

consideración toda la empresa, debe tener en cuenta igualmente su contexto, es

decir, la ciudad y, consecuentemente debe entenderse más como la planificación

urbanística donde se planifica un área completa y no solo un edificio.

Marcos de Arquitectura Empresarial

A la luz del reﬁnamiento conceptual anterior, queda patente, no solo la diﬁcultad de

alcanzar un consenso acerca de la estructuración y composición de una Arquitectura

Empresarial, sino igualmente la necesidad de disponer de una herramienta que

posibilite crear y usar las arquitecturas empresariales. Esta herramienta es un Marco

de Referencia de Arquitectura Empresarial, o si preferimos la aproximación

terminológica de John A. Zachman, una Ontología Empresarial.

Planificación Estratégica mediante Arquitectura Empresarial 5

▸ Porque necesitamos un mecanismo para definir y documentar una Arquitectura

Empresarial de manera transparente, que considere las complejidades y las

▸ Porque necesitamos un elemento de referencia de comunicación entre las partes

▸ Porque necesitamos una guía, adaptable y no necesariamente completa, que nos

permita planificar no solo la arquitectura empresarial, y nuestra estrategia, actual

sino su evolución y desarrollo para adoptar nuevos modelos de negocio acordes al

Componentes de un Marco de Arquitectura Empresarial

Un Marco de Arquitectura Empresarial deﬁne como crear y utilizar una arquitectura