Tema 2

Planificación Estratégica Mediante Arquitectura

Empresarial

Marcos de Referencia de
Arquitectura Empresarial
 Índice
Esquema 3

Ideas clave 4
2.1. Introducción y objetivos 4
2.2. Definición y contenido de un Marco de
Referencia de Arquitectura Empresarial 5
2.3. Análisis de los diferentes Marcos de Referencia y
estándares de AE 10
2.4. Selección de un Marco de Arquitectura
© Universidad Internacional de La Rioja (UNIR)

Empresarial 41
2.5. Fases principales en el ciclo de creación y
utilización de la Arquitectura Empresarial 45
2.6. Referencias bibliográficas 52

A fondo 54

Test 58
 Esquema
© Universidad Internacional de La Rioja (UNIR)

Planificación Estratégica Mediante Arquitectura Empresarial

3
Tema 2. Esquema
 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.
© Universidad Internacional de La Rioja (UNIR)

Planificación Estratégica Mediante Arquitectura Empresarial

4
Tema 2. 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.

Marcos de Arquitectura Empresarial

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
© Universidad Internacional de La Rioja (UNIR)

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
Tema 2. 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.
© Universidad Internacional de La Rioja (UNIR)

Planificación Estratégica Mediante Arquitectura Empresarial

6
Tema 2. Ideas clave
 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.

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
© Universidad Internacional de La Rioja (UNIR)

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.

Planificación Estratégica Mediante Arquitectura Empresarial

7
Tema 2. Ideas clave
 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.

 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

© Universidad Internacional de La Rioja (UNIR)

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

Planificación Estratégica Mediante Arquitectura Empresarial

8
Tema 2. Ideas clave
 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.

 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
© Universidad Internacional de La Rioja (UNIR)

implementar bienes, productos o servicios, brindar un servicio excelente al

cliente, etc.

Planificación Estratégica Mediante Arquitectura Empresarial

9
Tema 2. 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.
© Universidad Internacional de La Rioja (UNIR)

Figura 1. Historia resumida de los Marcos de Arquitectura Empresarial (y lenguajes de modelización).

Planificación Estratégica Mediante Arquitectura Empresarial

10
Tema 2. 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).
© Universidad Internacional de La Rioja (UNIR)

 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.

Planificación Estratégica Mediante Arquitectura Empresarial

11
Tema 2. 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
© Universidad Internacional de La Rioja (UNIR)

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.

Planificación Estratégica Mediante Arquitectura Empresarial

12
Tema 2. 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.

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
© Universidad Internacional de La Rioja (UNIR)

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).

Planificación Estratégica Mediante Arquitectura Empresarial

13
Tema 2. Ideas clave
 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.

 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
© Universidad Internacional de La Rioja (UNIR)

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

Planificación Estratégica Mediante Arquitectura Empresarial

14
Tema 2. Ideas clave
 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.

 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.
© Universidad Internacional de La Rioja (UNIR)

 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

Planificación Estratégica Mediante Arquitectura Empresarial

15
Tema 2. Ideas clave
 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.
© Universidad Internacional de La Rioja (UNIR)

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

[Link]

Planificación Estratégica Mediante Arquitectura Empresarial

16
Tema 2. Ideas clave
 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.

 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).
© Universidad Internacional de La Rioja (UNIR)

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

Planificación Estratégica Mediante Arquitectura Empresarial

17
Tema 2. Ideas clave
 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.

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.
© Universidad Internacional de La Rioja (UNIR)

Planificación Estratégica Mediante Arquitectura Empresarial

18
Tema 2. Ideas clave
 Figura 3. Ejemplo de relación entre Perspectivas de MoDAF. Fuente:
[Link]
0090219_MODAF_Layers_and_Viewpoint_Linkages_U.pdf

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.
© Universidad Internacional de La Rioja (UNIR)

 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.

Planificación Estratégica Mediante Arquitectura Empresarial

19
Tema 2. Ideas clave
  Todas las vistas (AVs). Proporcionan una descripción y glosario de contenidos de
la arquitectura.

Figura 4. Agrupación de Vistas en MoDAF. Fuente:

[Link]
[Link]

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

© Universidad Internacional de La Rioja (UNIR)

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

Planificación Estratégica Mediante Arquitectura Empresarial

20
Tema 2. Ideas clave
 Architecture Framework for Information Management, del Departamento de
Defensa de los Estados Unidos). La última versión es TOGAF 9.2 publicada en 2018.
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:
© Universidad Internacional de La Rioja (UNIR)

Figura 5. Estructura y contenido de TOGAF. Fuente: [Link]

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

Planificación Estratégica Mediante Arquitectura Empresarial

21
Tema 2. 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).
© Universidad Internacional de La Rioja (UNIR)

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

Planificación Estratégica Mediante Arquitectura Empresarial

22
Tema 2. Ideas clave
 artefactos de arquitectura, la reutilización de componentes (Bloques
Constructivos de Arquitectura) y un resumen de entregables de Arquitectura
típicos.

 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 el 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.
© Universidad Internacional de La Rioja (UNIR)

 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.

Planificación Estratégica Mediante Arquitectura Empresarial

23
Tema 2. 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: [Link]

doc/arch/[Link]

Las fases del ciclo ADM de TOGAF, de manera resumida son las siguientes:
© Universidad Internacional de La Rioja (UNIR)

 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.

Planificación Estratégica Mediante Arquitectura Empresarial

24
Tema 2. Ideas clave
  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.
© Universidad Internacional de La Rioja (UNIR)

 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.

Planificación Estratégica Mediante Arquitectura Empresarial

25
Tema 2. Ideas clave
  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.
© Universidad Internacional de La Rioja (UNIR)

Planificación Estratégica Mediante Arquitectura Empresarial

26
Tema 2. 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
© Universidad Internacional de La Rioja (UNIR)

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».

Planificación Estratégica Mediante Arquitectura Empresarial

27
Tema 2. 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.
© Universidad Internacional de La Rioja (UNIR)

 Las Perspectivas, siendo únicas, capturan todos los modelos críticos para el
desarrollo del sistema.

Planificación Estratégica Mediante Arquitectura Empresarial

28
Tema 2. 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. [Link]). Fuente:
[Link]
background-description-and-utility-by-john-a-zachman

La descripción de las filas es la siguiente:

 Objetivo (Planificador): corresponde a un resumen ejecutivo de un planificador

© Universidad Internacional de La Rioja (UNIR)

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

Planificación Estratégica Mediante Arquitectura Empresarial

29
Tema 2. Ideas clave
 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-

 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
© Universidad Internacional de La Rioja (UNIR)

el nivel de sistemas de información.

 Sistema de trabajo: muestra el sistema operativo.

Planificación Estratégica Mediante Arquitectura Empresarial

30
Tema 2. Ideas clave
 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.

 Red (¿dónde?): muestra las localizaciones y las interconexiones dentro de la

empresa. Esto incluye lugares geográficos empresariales importantes, secciones
© Universidad Internacional de La Rioja (UNIR)

separadas dentro de una red logística, la asignación de los nodos del sistema, o
incluso las direcciones de memoria dentro del sistema.

Planificación Estratégica Mediante Arquitectura Empresarial

31
Tema 2. Ideas clave
 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 ([Link]). Fuente:

[Link]

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).

© Universidad Internacional de La Rioja (UNIR)

 Todas las celdas de la matriz deben estar rellenas (artefactos arquitecturales)

para que la arquitectura sea completa.

 Una celda se considera rellena cuando contiene artefactos que determinan el

sistema (empresa) para un participante determinado y para un aspecto específico.

Planificación Estratégica Mediante Arquitectura Empresarial

32
Tema 2. Ideas clave
  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.
 Un usuario puede modelar cualquier tecnología, lenguaje de programación,
plataforma de arquitectura, infraestructura, software.
 Cada etapa de desarrollo requiere diagramas distintos.
© Universidad Internacional de La Rioja (UNIR)

 Se pueden utilizar patrones de diseño para agilizar la elaboración de un

diagrama.
 Acelera el tiempo de entrega.

Planificación Estratégica Mediante Arquitectura Empresarial

33
Tema 2. Ideas clave
 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.

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.
© Universidad Internacional de La Rioja (UNIR)

 Herramientas de modelo de Cloud Computing.

Planificación Estratégica Mediante Arquitectura Empresarial

34
Tema 2. Ideas clave
 Figura 9. Estructura de SOMF v2.0. Fuente: [Link]
oriented_modeling#/media/File:SOMF_V_2.[Link]

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
© Universidad Internacional de La Rioja (UNIR)

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.

Planificación Estratégica Mediante Arquitectura Empresarial

35
Tema 2. 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).
© Universidad Internacional de La Rioja (UNIR)

Planificación Estratégica Mediante Arquitectura Empresarial

36
Tema 2. 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:
[Link]

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
© Universidad Internacional de La Rioja (UNIR)

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).

Planificación Estratégica Mediante Arquitectura Empresarial

37
Tema 2. Ideas clave
  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 empresa que 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.

 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
© Universidad Internacional de La Rioja (UNIR)

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.

Planificación Estratégica Mediante Arquitectura Empresarial

38
Tema 2. Ideas clave
 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.

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.
© Universidad Internacional de La Rioja (UNIR)

Planificación Estratégica Mediante Arquitectura Empresarial

39
Tema 2. Ideas clave
 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:

[Link]

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):

 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.
© Universidad Internacional de La Rioja (UNIR)

 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.

Planificación Estratégica Mediante Arquitectura Empresarial

40
Tema 2. Ideas clave
  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.

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,
© Universidad Internacional de La Rioja (UNIR)

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é

Planificación Estratégica Mediante Arquitectura Empresarial

41
Tema 2. Ideas clave
 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 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
© Universidad Internacional de La Rioja (UNIR)

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
Arquitectura Empresarial.

Planificación Estratégica Mediante Arquitectura Empresarial

42
Tema 2. 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
Arquitectura Empresarial.

 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

© Universidad Internacional de La Rioja (UNIR)

establecimiento de un catálogo prescriptivo de activos de arquitectura que

puedan ser reutilizados en actividades futuras.

Planificación Estratégica Mediante Arquitectura Empresarial

43
Tema 2. Ideas clave
  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.

 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.
© Universidad Internacional de La Rioja (UNIR)

Planificación Estratégica Mediante Arquitectura Empresarial

44
Tema 2. 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

Arquitectura Empresarial.

 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.
© Universidad Internacional de La Rioja (UNIR)

Planificación Estratégica Mediante Arquitectura Empresarial

45
Tema 2. 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.
• Consideración de las personas y la tecnología en la organización.
• El nivel de resistencia al cambio en la organización.
© Universidad Internacional de La Rioja (UNIR)

• 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.

Planificación Estratégica Mediante Arquitectura Empresarial

46
Tema 2. Ideas clave
 • 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.

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).
© Universidad Internacional de La Rioja (UNIR)

Planificación Estratégica Mediante Arquitectura Empresarial

47
Tema 2. Ideas clave
 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ón de 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.

2. Obtención del Mandato de 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
© Universidad Internacional de La Rioja (UNIR)

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.

Planificación Estratégica Mediante Arquitectura Empresarial

48
Tema 2. Ideas clave
 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 este paso proceder igualmente a la selección de una
© Universidad Internacional de La Rioja (UNIR)

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.

Planificación Estratégica Mediante Arquitectura Empresarial

49
Tema 2. Ideas clave
 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
© Universidad Internacional de La Rioja (UNIR)

que debe incluir igualmente 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

Planificación Estratégica Mediante Arquitectura Empresarial

50
Tema 2. Ideas clave
 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.
© Universidad Internacional de La Rioja (UNIR)

Planificación Estratégica Mediante Arquitectura Empresarial

51
Tema 2. 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.
© Universidad Internacional de La Rioja (UNIR)

Zachman, J. A. (1987). A framework for information systems architecture. IBM

Systems Journal, vol. 26, no. 3, pp. 276-292.

Planificación Estratégica Mediante Arquitectura Empresarial

52
Tema 2. Ideas clave
 Zachman, J. A y Spewak, S. H. (2008) Enterprise Architecture Planning: Developing a
Blueprint for Data, Applications, and Technology. Wiley-QED Publishing Group.

Información sobre Marcos de Arquitectura Empresarial:

AGATE:
[Link]
[Link]

DoDAF:
[Link]

FEAF:
[Link]

MoDAF:
[Link]

OBASHI:
[Link]

SOMF:
[Link]
framework-somf-using-enterprise-architect/

TOGAF:
[Link]
© Universidad Internacional de La Rioja (UNIR)

ZACHMAN:
[Link]

Planificación Estratégica Mediante Arquitectura Empresarial

53
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. [Link]
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.

Marco de Arquitectura Zachman

Sparks. G., Constable, B. y Ugavina, N. (Eds.). (2008). MDG Technology for Zachman
Framework User Guide. Sparx Systems.
[Link]

En este documento se explica el uso del Marco de Arquitectura

Empresarial Zachman.
© Universidad Internacional de La Rioja (UNIR)

Planificación Estratégica Mediante Arquitectura Empresarial

54
Tema 2. A fondo
 Marcos de Arquitectura Empresarial

Survey of Architecture Frameworks. (20 de marzo de 2020). [Link].

[Link]

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).

Modelo de Madurez de AE

Schekkerman. J. (2006). Extended Enterprise Architecture Maturity Model Support

Guide. Institute for Enterprise Architecture developments.
[Link]
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.
© Universidad Internacional de La Rioja (UNIR)

Planificación Estratégica Mediante Arquitectura Empresarial

55
Tema 2. 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.
[Link]

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.

Arquitectura Empresarial y Gestión de Procesos

Orensanz, D. (n. d.). Arquitectura Empresarial. [Archivo de vídeo].

[Link]
© Universidad Internacional de La Rioja (UNIR)

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.).

Planificación Estratégica Mediante Arquitectura Empresarial

56
Tema 2. A fondo
 Relación entre estándares de Gobierno y Gestión TI, y un Marco de AE

ITEducation Latam. (2014). TOGAF el framework para desarrollar SOA, BPM, ITIL, y
COBIT. [Archivo de vídeo]. [Link]

Este webinar tiene como fin presentar una visión alto nivel del Marco de AE TOGAF
y conocer su pertinencia en la implementación de mejores prácticas en relación con
BPM, ITIL, COBIT, SOA e incluso sistemas de gestión basados en ISO.
© Universidad Internacional de La Rioja (UNIR)

Planificación Estratégica Mediante Arquitectura Empresarial

57
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.
© Universidad Internacional de La Rioja (UNIR)

Planificación Estratégica Mediante Arquitectura Empresarial

58
Tema 2. 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.

8. En el Marco Zachman, ¿qué representa el modelo de negocio (Dueño)?

© Universidad Internacional de La Rioja (UNIR)

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.

Planificación Estratégica Mediante Arquitectura Empresarial

59
Tema 2. Test
 9. 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.

10. En el Marco Zachman, ¿qué representa el modelo tecnológico (Constructor)?

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.
© Universidad Internacional de La Rioja (UNIR)

Planificación Estratégica Mediante Arquitectura Empresarial

60
Tema 2. Test