documento de dodaf tecnologia de datos y analisis

1. UNIVERSIDAD NACIONAL AGRARIA DE LA SELVA
FACULTAD DE INGENIERÍA EN INFORMÁTICA Y SISTEMAS
TEMA:
Integrantes: Jara Venancio, Gian Jairo
Borja Reyes, Leidy
Docente: Ing. Edwin Jesús Vega Ventocilla
Curso: Arquitectura Empresarial
Ciclo: X
Tingo María – Perú
2020
FRAMEWORK DoDAF

3. ÍNDICE DE CONTENIDO
I. INTRODUCCIÓN....................................................................................................... 4
II. OBJETIVOS.............................................................................................................. 5
2.1. GENERAL.......................................................................................................... 5
2.2. ESPECIFICO ..................................................................................................... 5
III. MARCO DODAF ................................................................................................... 5
IV. PORQUE DODAF ................................................................................................. 6
V. HISTORIADE DODAF ............................................................................................. 7
VI. DODAF ACTUALIZADO....................................................................................... 9
VII. DESARROLLO DE LA ARQUITECTURA......................................................... 20
7.1. METAMODELO.............................................................................................. 24
VIII. SOFTWARE DODAF .......................................................................................... 26
IX. CASO DE ÉXITO................................................................................................. 27
X. CONCLUSIONES.....................................................Error! Bookmark not defined.
XI. BIBLIOGRAFÍA................................................................................................... 27
ÍNDICE DE FIGURAS
Figura 1 Evolución del DoDAF desde la década de 1990. El DoDAF V2.0 fue
promulgado en mayo de 2009.......................................................................................... 8
Figura 2 Modelo de Datos de Arquitectura .................................................................... 16
Figura 3 Vista general de la versión 2.02....................................................................... 20
Figura 4 Desarrollo de la Arquitectura 6 pasos.............................................................. 23
Figura 5 Visual Paradigm ............................................................................................... 26

4. I. INTRODUCCIÓN
El Marco de Arquitectura del Departamento de Defensa (DoDAF), Versión 2.0 es
el marco general, integral y modelo conceptual que permite el desarrollo de
arquitecturas para facilitar la capacidad de los gerentes del Departamento de Defensa
(DoD) en todos los niveles para tomar decisiones clave de manera más eficaz a través
del intercambio organizado de información en todo el Departamento, las áreas
conjuntas de capacidad (JCA), los límites de la Misión, el Componente y el Programa. El
DoDAF sirve como uno de los pilares principales que apoyan al Director de Información
(CIO) del Departamento de Departamento de Salud en sus responsabilidades de
desarrollo y mantenimiento de las arquitecturas requeridas por la Ley Clinger-Cohen.
DoDAF se prescribe para el uso y desarrollo de Descripciones Arquitectónicas en el
Departamento. También proporciona una amplia orientación sobre el desarrollo de
arquitecturas que apoyen la adopción y ejecución de servicios centrados en la red
dentro del Departamento.
Los gerentes del Departamento de Servicios de Calidad, como propietarios de
procesos, especifican los requisitos y controlan el desarrollo de arquitecturas dentro de
sus áreas de autoridad y responsabilidad. Seleccionan un arquitecto y un equipo de
desarrollo de arquitectura para crear la arquitectura de acuerdo con los requisitos que
definen.
Se espera que los componentes DoD se ajusten al DoDAF al desarrollar
arquitecturas dentro del Departamento. La conformidad con DoDAF garantiza la
reutilización de la información y que los artefactos de arquitectura, los modelos y los
puntos de vista se pueden compartir con un entendimiento común.

5. II. OBJETIVOS
2.1. GENERAL
 Conocer e interpretar el framework DODAF de la arquitectura empresarial
2.2. ESPECIFICO
 Profundizar el conocimiento sobre la Arquitectura Empresarial
 Profundizar el conocimiento sobre la Arquitectura Empresarial usando el
Framework DODAF.
III. MARCO DODAF
Según (Urbaczewski & Mrdalj, 2006), DoDAF es un marco de arquitectura para el
Departamento de Estados Unidos de Defensa (DoD) que proporciona la infraestructura
de visualización para los grupos de interés específicos inquietudes a través de puntos de
vista organizados por diversos puntos de vista. Estos puntos de vista son artefactos para
visualizar, comprender y asimilar el amplio alcance y la complejidad de una descripción
de la arquitectura a través de tablas, estructural, de comportamiento, ontológica,
pictórica, temporal, gráfica, probabilística, o alternativas conceptuales medios.
Este Marco de Arquitectura es especialmente adecuado para grandes sistemas
con integración e interoperabilidad complejos desafíos, y es aparentemente único en su
empleo de los “puntos de vista operacionales”. Estos puntos de vista ofrecen
información general y datos destinados a los interesados específicos dentro de su
dominio y en la interacción con otros ámbitos en los que el sistema funcione
El DoDAF proporciona un marco fundamental para el desarrollo y la
representación de las descripciones de arquitectura que aseguren un denominador
común para la comprensión, la comparación, y la integración de arquitecturas a través
de fronteras organizacionales, conjuntos y multinacionales. Establece definiciones de
elementos de datos, reglas y relaciones y un conjunto básico de productos para el
desarrollo coherente de sistemas integrados, o arquitecturas federados. Estas
descripciones de arquitectura pueden incluir familias de sistemas (FOS), sistemas de
sistemas (SOS) y netcentric capacidades para interoperar e interactuar en el entorno
fuera de combate.

6. Se requiere que todas las principales armas de Estados Unidos del Departamento
de Defensa y adquisiciones de sistemas de tecnología de información para desarrollar y
documentar una arquitectura empresarial (EA), utilizando los puntos de vista
establecidos en el DoDAF. Si bien es claramente dirigido a los sistemas militares, DoDAF
tiene amplia aplicabilidad a través de los sectores privado, público y voluntario de todo
el mundo, y representa uno de un gran número de marcos de arquitectura de sistemas.
IV. PORQUEDODAF
Según (Ang, Dandashi,& Mcfarren, n.d.), DoDAF ayuda aarquitectos de sistemas,
ingenieros de sistemas, desarrolladores de software y otros que buscan pasar de
procesos de desarrollo de sistemas tradicionales basados en documentos y centrados
en código, a procesos de ingeniería basada en modelos que son procesos de ingeniería
basada en modelos que son basados en requisitos y centrados en la arquitectura.
Todas las principales adquisiciones de sistemas de armas y tecnología de la
información del DoD de los Estados Unidos están obligadas a desarrollar y documentar
una arquitectura empresarial (EA)utilizando las opiniones prescritas en elDoDAF. Si bien
está dirigido a los sistemas militares, DoDAF tiene una amplia aplicabilidad en los
sectores privado, público y voluntario en todo el mundo, y representa uno de un gran
número de marcos de arquitectura de sistemas.
Como el marco de arquitectura empresarial de elección para aplicaciones de
defensa/aeroespacial,DoDAF es una tecnología claveque permite organizar y compartir
arquitecturas de sistemas grandes y complejas para sistemas distribuidos (cf.
Arquitecturas de guerra operativa centrada en la red).
El propósito de DoDAF es definir conceptos y modelos utilizables en los seis
procesos principales del DoD:
 Integración y desarrollo de capacidades conjuntas (JCIDS)
 Planificación, programación, presupuestación y ejecución (PPBE)

7.  Sistema de Adquisición de Defensa (DAS)
 Ingeniería de sistemas (SE)
 Planificación operacional (OPLAN)
 Administración de cartera de capacidad (CPM)
El objetivo de DoDAF es definir concretamente modelos y conceptos que sean
utilizables en los seis procesos principales del DoD:
 Capacidades conjuntas y desarrollo de integración (JCIDS)
 Planificación, programación, presupuestación y ejecución (PPBE)
 Sistema de Adquisición de Defensa (DAS)
 Ingeniería de sistemas (SE)
 Planificación operacional (OPLAN)
 Administración de cartera de capacidad (CPM)
V. HISTORIA DE DODAF
La primera versión del desarrollo DoDAF fue desarrollada en la década de 1990
bajo el nombre C4ISR architectural architecture framework. En el mismo período se
desarrolló elmodelo de referencia TAFIM, iniciado en 1986. El primer C4ISRArchitecture
Framework v1.0, publicado el 7 de junio de 1996, fue creado en respuesta a la
aprobación de la Ley Clinger-Cohen. Se dirigió a la directiva del Secretario Adjunto de
Defensa de 1995 de que se emprendiera un esfuerzo en todo el Trabajo para definir y
desarrollar mejores medios y procesos para garantizar que las capacidades del C4ISR
fueran interoperables y satisfagan las necesidades del combatiente de guerra. El
esfuerzo continuo de desarrollo dio lugar a diciembre de 1997 en la segunda versión,
C4ISR Architecture Framework v2.0. En agosto de 2003 se lanzó DoDAF v1.0, que
reestructuró C4ISR Framework v2.0 para ofrecer orientación, descripciones de
productos e información complementaria en dos volúmenes y un libro de escritorio.
Amplió la aplicabilidad de los principios y prácticas de arquitectura a todas las áreas de
la misión en lugar de sólo a la comunidad C4ISR. Este documento abordó el uso, las
arquitecturas integradas, las políticas dod y federales, el valor de las arquitecturas, las
medidas de arquitectura, los procesos de apoyo a la toma de decisiones del DoD, las

8. técnicas de desarrollo, las técnicas analíticas y el CADM v1.01, y se dirigió hacia un
enfoque basado en repositorios poniendo énfasis en los elementos de datos de
arquitectura que componen los productos de arquitectura. En febrero de 2004 la
documentación de la versión 1.0 fue publicada con el volumen "I: Definiciones y
directrices", "II: Descripciones de productos" y un "Deskbook". En abril de 2007, la
versión 1.5 fue lanzada con una documentación de "Definiciones y directrices",
"Descripciones de productos" y "Descripción de datos de arquitectura".
El 28 de mayo de 2009 DoDAF v2.0 fue aprobado por el Departamento de
Defensa.La versión actual es DoDAF 2.02 DoDAF V2.0 se publica en un sitio web público.
Otros marcos derivados basados en DoDAF incluyen el Marco de Arquitectura de
la OTAN (NAF) y el Marco de Arquitectura del Ministerio de Defensa. Al igual que otros
enfoques de EA,por ejemplo, The Open Group Architecture Framework (TOGAF),DoDAF
se organiza en torno a un repositorio compartido para mantener productos de trabajo.
El repositorio se define mediante el esquema de basede datos común Core Architecture
Data Model 2.0 y el DoD Architecture Registry System (DARS). Una característica clave
de DoDAF es la interoperabilidad, que se organiza como una serie de niveles, llamados
Niveles de interoperabilidad del sistema de información (LISI). El sistema en desarrollo
no sólo debe satisfacer sus necesidades internas de datos, sino también las del marco
operativo en el que se establece.
Figura 1 Evolución del DoDAF desde la década de 1990. El DoDAF V2.0 fue promulgado en mayo de
2009
Fuente: Wikipedia1
1 https://military.wikia.org/wiki/Department_of_Defense_Architecture_Framework

9. VI. DODAF ACTUALIZADO
La versión actual a partir de este escrito es 2.022 y tenía los siguientes objetivos
específicos:
 Establecer orientación para crear contenido de arquitectura en
función de propósito o "adecuado para el propósito".
 Mejore la eficacia y la utilidad de las arquitecturas a través de un
modelo de datos riguroso para que pueda ser analizada, evaluada y
eventualmente integrada con mayor precisión. Este modelo de datos
se denomina DoDAF Meta Model (DM2).
DoDAF es un gran marco completo de EA, pero si lo resumo brevemente aquí:
 Proporciona un medio para comparar arquitecturas
 Permite esta comparación definiendo un conjunto de vistas de una
arquitectura (también pueden hacerlo productos)
 En la versión 1.5 y anteriormente, estos productos se agrupaban en 4
vistas:
 Vista operativa: Los productos de Operational View (OV)
proporcionan descripciones de las tareas y actividades, los
elementos operativos y los intercambios de información necesarios
para llevar a cabo misiones del DoD. El OV proporciona
representaciones textuales y gráficas de nodos y elementos
operativos, tareas y actividades asignadas y flujos de información
entre nodos. Define el tipo de información intercambiada, la
frecuencia de los intercambios, las tareas y actividades apoyadas por
estos intercambios y la naturaleza de los intercambios. Los productos
DoDAF V1.5 OV se definen como:
2 https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_background/

10.  Gráfico de concepto operacional de alto nivel OV-1:
Descripción gráfica y textual de alto nivel del concepto
operativo (organizaciones de alto nivel, misiones,
configuración geográfica, conectividad, etc.).
 Descripción de la conectividad del nodo operativo
OV-2: Nodos operativos, actividades realizadas en
cada nodo y conectividades y flujo de información
entre nodos.
 Matriz de intercambio de información operacional
OV-3: Información intercambiada entre nodos y los
atributos relevantes de ese intercambio, como los
medios, la calidad, la cantidad y el nivel de
interoperabilidad requerido.
 Tabla de relaciones organizativas OV-4: Mando,
control, coordinación y otras relaciones entre
organizaciones.
 Modelo de actividad operacional OV-5: Actividades,
relaciones entre actividades, entradas y salidas.
Además, las superposiciones pueden mostrar el costo,
los nodos de rendimiento u otra información
pertinente.
 Modelo de reglas operativas OV-6a: Uno de los tres
productos utilizados para describir la secuencia de
actividad operativa y eltiempo que identificalas reglas
de negocio que restringen la operación.
 Descripción de la transición del estado operativoOV-
6b: Uno de los tres productos utilizados para describir
la secuencia de actividad operativa y el tiempo que
identifica las respuestas de un proceso empresarial a
eventos.

11.  Descripción del seguimiento de eventos
operacionales OV-6c: Uno de los tres productos
utilizados para describir la secuencia de actividad
operativa y la sincronización que realiza un
seguimiento de las acciones en un escenario o
secuencia crítica de eventos.
 Modelo de datos lógicos OV-7: Documentación de los
requisitos de datos y reglas de proceso estructural de
proceso empresarial de la Vista Operativa. (En DoDAF
V1.5. Esto corresponde a DIV-2 en DoDAF V2.0.)
 Vista de Normas Técnicas: Los productos de vista de normas técnicas
(TV) definen estándares técnicos, convenciones de implementación,
reglas de negocio y criterios que rigen la arquitectura. Los productos de
DODAF V1.5 TV son los siguientes:
 Perfil de normas técnicas StdV-1 - Extracción de estándares que
se aplica a la arquitectura dada. (En DoDAF V1.5. Renombrado a
StdV-1 en DoDAF V2.0.)
 Pronóstico de normas técnicas StdV-2 - Descripción de las
normas emergentes que se espera que se apliquen a la
arquitectura dada,dentro de un conjunto adecuado de plazos. (En
DoDAF V1.5. Renombrado a StdV-2 en DoDAF V2.0.)
 Vista de sistemas y servicios: La vista de sistemas y servicios (SV) es un
conjunto de productos gráficos y textuales que describen sistemas y
servicios e interconexiones que proporcionan o admiten funciones DoD.
Los productos SV se centran en sistemas físicos específicos con
ubicaciones físicas (geográficas) específicas. La relación entre los
elementos de datos de arquitectura a través del SV con el OV se puede
ejemplificar a medida que los sistemas se adquieren y se distribuyen en

12. el campo para apoyar a las organizaciones y sus operaciones. Los
productos DoDAF V1.5 SV son:
 Descripción de la interfaz de sistemas/servicios SV-1:
Representa los nodos de sistemas y los sistemas residentes en
estos nodos para dar soporte a las organizaciones/roles
humanos representados por nodos operativos del OV-2. SV-1
también identifica las interfaces entre los nodos de sistemas y
sistemas.
 Descripción de las comunicaciones de sistemas/servicios SV-
2: Representa información pertinente sobre sistemas de
comunicaciones, enlaces de comunicaciones y redes de
comunicaciones. SV-2 documenta los tipos de medios de
comunicación que soportan los sistemas e implementa sus
interfaces como se describe en SV-1. Por lo tanto, SV-2
muestra los detalles de comunicaciones de las interfaces SV-1
que automatizan aspectos de las líneas de necesidad
representadas en OV-2.
 SV-3 Sistemas-Sistemas, Servicios-Sistemas, Servicios-
Servicios Matrices: proporciona detalles sobre las
características de la interfaz descritas en SV-1 para la
arquitectura, dispuestas en forma de matriz.
 Descripción de la funcionalidad de sistemas/servicios SV-
4a/SV-4b: El SV-4a documenta las jerarquías funcionales del
sistema y las funciones del sistema, y los flujos de datos del
sistema entre ellas. El SV-4 de DoDAF v1.0 se designa como
'SV-4a' en DoDAF v1.5. Aunque existe una correlación entre
ov-5 o jerarquías de procesos empresariales y la jerarquía
funcional del sistema de SV-4a, no es necesario que sea una
asignación uno a uno, por lo tanto, la necesidad de la matriz
de trazabilidad de la función de actividad operativa a sistemas
(SV-5a), que proporciona esa asignación.

13.  SV-5a, SV-5b, SV-5c Actividad operativa a la función de los
sistemas, Actividad operativa a matrices de trazabilidad de
sistemas y servicios: La actividad operativa a SV-5a y SV-5b es
una especificación de las relaciones entre el conjunto de
actividades operativas aplicables a una arquitectura y el
conjunto de funciones del sistema aplicables a dicha
arquitectura. El SV-5 y la extensión al SV-5 de DoDAF v1.0 se
designan como 'SV-5a' y 'SV-5b' en DoDAF v1.5
respectivamente.
 Matriz de intercambio de datos de sistemas/servicios SV-6:
Especifica las características de los datos del sistema
intercambiados entre sistemas. Este producto se centra en los
intercambios de información automatizados (de OV-3) que se
implementan en los sistemas. Los intercambios de
información no automatizados, como los pedidos verbales, se
capturan únicamente en los productos OV.
 Matriz de parámetros de rendimiento de sistemas/servicios
SV-7: Especifica las características cuantitativas de los
sistemas y los elementos de hardware/software del sistema,
sus interfaces (datos del sistema transportados por la interfaz,
así como los detalles del enlace de comunicaciones que
implementan la interfaz) y sus funciones. Especifica los
parámetros de rendimiento actuales de cada sistema, interfaz
o función del sistema, y los parámetros de rendimiento
esperados o necesarios en momentos especificados en el
futuro. Los parámetros de rendimiento incluyen todas las
características técnicas de rendimiento de los sistemas para
los que se pueden desarrollar los requisitos y definir las
especificaciones. Es posible que el conjunto completo de
parámetros de rendimiento no se conozca en las primeras
etapas de la definición de arquitectura, por lo que debe
esperarse que esteproducto seactualicea lo largo de las fases

14. de ciclo de vida de la especificación, diseño, desarrollo,
pruebas y posiblemente incluso sus fases de ciclo de vida de
implementación y operaciones.
 Descripción de la evolución de los sistemas/servicios SV-8:
Captura planes de evolución que describen cómo el sistema, o
la arquitectura en la que está incrustado el sistema,
evolucionará durante un largo período de tiempo.
Generalmente, los hitos de la línea de tiempo son críticos para
una comprensión exitosa de lalíneade tiempo de laevolución.
 Pronóstico de tecnología de sistemas/servicios SV-9: Define
las tecnologías de soporte actuales y esperadas subyacentes
que se han orientado mediante métodos de previsión
estándar. Las tecnologías de apoyo esperadas son aquellas
que se pueden pronosticar razonablemente dado el estado
actual de la tecnología y las mejoras esperadas. Las nuevas
tecnologías deben estar vinculadas a períodos de tiempo
específicos, que pueden correlacionarse con los períodos de
tiempo utilizados en los hitos SV-8.
 Modelo de reglas de sistemas/servicios SV-10a: Describe las
reglas bajo las cuales la arquitectura o sus sistemas se
comportan en condiciones especificadas.
 Descripción de la transición del estado de los
sistemas/servicios SV-10b: Un método gráfico para describir
una respuesta del sistema (o función del sistema) a varios
eventos cambiando su estado. El diagrama representa
básicamente los conjuntos de eventos a los que responderán
los sistemas de la arquitectura (realizando una acción para
pasar a un nuevo estado) en función de su estado actual. Cada
transición especifica un evento y una acción.
 Descripción de slata de eventos de SV-10c Systems/Services:
Proporciona un examen de tiempo ordenado de los elementos

15. de datos del sistema intercambiados entre los sistemas
participantes (externos e internos), las funciones del sistema
o los roles humanos como resultado de un escenario
determinado. Cada diagrama de seguimiento de eventos debe
tener una descripción adjunta que defina el escenario o la
situación concretos. SV-10c en la vista Sistemas y servicios
puede reflejar aspectos específicos del sistema o
refinamientos de secuencias críticas de eventos descritos en la
vista operativa.
 Esquema físico SV-11: Uno de los productos de arquitectura
más cercanos aldiseño real del sistema en el marco de trabajo.
El producto define la estructura de los distintos tipos de datos
del sistema que utilizan los sistemas de la arquitectura. (En
DoDAF V1.5. Esto corresponde a DIV-3 en DoDAF V2.0.).
 All-View: Todos los productos de vista (AV) proporcionan descripciones
generales de toda la arquitectura y definen el ámbito y el contexto de la
arquitectura. Los productos DoDAF V1.5 AV se definen como:
 Resumen de AV-1 e información resumida: Alcance, propósito,
usuarios previstos, entorno representado, hallazgos analíticos (si
corresponde)
 Diccionario integrado AV-2: Definiciones de todos los términos
utilizados en todos los productos.

16. Figura 2 Modelo de Datos de Arquitectura
Fuente: Pagina Oficial
DoDAF(https://dodcio.defense.gov/Portals/0/Documents/DODAF/DoDAF_v2-
02_web.pdf)
En la versión 2.0 añadieron:
 Vista de capacidad: Nuevo en DoDAF V2.0. Articula los requisitos de
capacidad, el tiempo de entrega y la capacidad implementada.
 Visión CV-1: Aborda las preocupaciones empresariales asociadas
con la visión general de los esfuerzos transformadores y, por lo
tanto, define el contexto estratégico para un grupo de
capacidades. El propósito del CV-1 es proporcionar un contexto
estratégico para las capacidades descritas en la Descripción de la
Arquitectura.
 Taxonomía de capacidad CV-2: Captura taxonomías de
capacidad. El modelo presenta una jerarquía de capacidades.
Estas capacidades se pueden presentar en el contexto de una
línea de tiempo. El CV-2 especifica todas las capacidades a las que
se hace referencia en una o más arquitecturas.
 NivelacióndecapacidadCV-3:Ellogro planificadode lacapacidad
en diferentes momentos en el tiempo o durante períodos de
tiempo específicos. El CV-3 muestra la capacidad de la fase en
términos de las actividades,condiciones, efectos deseados,reglas

17. cumplidas, consumo y producción de recursos, y medidas, sin
tener en cuenta las soluciones de ejecutante y ubicación
 Dependencias de capacidad CV-4: Las dependencias entre las
capacidades planificadas y la definición de agrupaciones lógicas
de capacidades.
 Asignación de capacidad CV-5 para el desarrollo organizacional:
El cumplimiento de los requisitos de capacidad muestra la
implementación de capacidad planificada y la interconexión para
una fase de capacidad determinada. El CV-5 muestra la solución
planificada para la fase en términos de artistas intérpretes o
ejecutantes y ubicaciones y sus conceptos asociados.
 Asignación de capacidad CV-6 a actividades operativas: Una
asignación entre las capacidades necesarias y las actividades
operativas que admiten esas capacidades.
 Asignación de capacidad para servicios CV-7: Una asignación
entre las capacidades y los servicios que estas capacidades
habilitan
 Vista de datos e información
 Modelo de datos conceptuales DIV-1: Los conceptos de datos de
alto nivel requeridos y sus relaciones.
 Modelo de datos lógicos DIV-2: La documentación de los
requisitos de datos y las reglas de proceso empresarial estructural
(actividad). En DoDAF V1.5, este era el OV-7.
 Modelo de datos físicos DIV-3: El formato de implementación
física de las entidades del modelo de datos lógicos, por ejemplo,
formatos de mensaje, estructuras de archivos, esquema físico. En
DoDAF V1.5, este era el SV-11.
Tenga en cuenta que consulte Modelo de datos lógicos para
obtener información sobre la relación de estos tres modelos de
datos DIV, con la comparación de los modelos de datos
conceptuales, lógicos y físicos

18.  Vista del programa
 PV-1 Relaciones de cartera de proyectos: Describe las relaciones
de dependencia entre las organizaciones y los proyectos y las
estructuras organizativas necesarias para gestionar una cartera
de proyectos.
 Plazos del proyecto PV-2: Una perspectiva de cronograma sobre
programas o proyectos, con los hitos clave y las
interdependencias.
 Proyecto PV-3 a asignación de capacidades: Un mapeo de
programas y proyectos a capacidades para mostrar cómo los
proyectos específicos y los elementos del programa ayudan a
lograr una capacidad.
 Vista de servicios (independiente de Sistemas)
 DescripcióndelcontextodelosserviciosSvcV-1: Laidentificación
de servicios, artículos de servicio y sus interconexiones.
 Descripción del flujo de recursos de los servicios SvcV-2: Una
descripción de los flujos de recursos intercambiados entre
servicios.
 Matrizde sistemas-serviciosSvcV-3ª: Las relaciones entre o entre
sistemas y servicios en una descripción arquitectónica
determinada.
 Matriz de servicios de SvcV-3b: Las relaciones entre los servicios
en una descripción arquitectónica determinada. Se puede diseñar
para mostrar relaciones de interés (por ejemplo, interfaces de
tipo de servicio, interfaces planificadas frente a interfaces
existentes).
 Descripción de la funcionalidad de los servicios SvcV-4: Las
funciones realizadas por los servicios y los datos de serviciofluyen
entre funciones de servicio (actividades).
 Matriz de trazabilidad de la actividad operativade SvcV-5 a los
servicios: Una asignación de servicios (actividades) de vuelta a las
actividades operativas (actividades).

19.  Matriz de flujo de recursos de servicios SvcV-6: Proporciona
detalles de los elementos de flujo de recursos de servicio que se
intercambian entre los servicios y los atributos de ese
intercambio.
 Matrizde medidasde serviciosde SvcV-7:Las medidas (métricas)
de los elementos del modelo de servicios para los períodos de
tiempo adecuados.
 SvcV-8 Servicios Descripción de la Evolución: Los pasos
incrementales planificados hacia la migración de un conjunto de
servicios a un conjunto más eficiente o hacia la evolución de los
servicios actuales a una implementación futura.
 Pronóstico de tecnología y habilidades de svcV-9 Services: Las
tecnologías emergentes, los productos de software/hardware y
las habilidades que se espera que estén disponibles en un
conjunto determinado de marcos de tiempo y que afectarán al
desarrollo futuro del servicio.
 Modelo de reglas de servicios SvcV-10a: Uno de los tres modelos
utilizados para describir lafuncionalidad del servicio.Identifica las
restricciones que se imponen a la funcionalidad del sistema
debido a algún aspecto del diseño o la implementación del
sistema.
 Descripción de la transición del estado de los servicios SvcV-10b:
Uno de los tres modelos utilizados para describir la funcionalidad
del servicio. Identificalas respuestas de los servicios alos eventos.
 Descripción del seguimiento de eventos de svcV-10c Services:
Uno de los tres modelos utilizados para describir la funcionalidad
del servicio.Identifica los refinamientos específicos delservicio de
secuencias críticas de eventos descritos en el punto de vista
operativo

20. Figura 3 Vista general de la versión 2.02
Fuente: Página Oficial de DoDAF3
VII. DESARROLLO DELA ARQUITECTURA
El proceso de desarrollo de arquitectura de 6 pasos de alto nivel proporciona
orientación al arquitecto y al equipo de desarrollo de Descripción Arquitectónica y hace
hincapié en los principios rectores. El proceso está centrado en los datos en lugar de en
el producto (por ejemplo, hace hincapié en el enfoque en los datos y las relaciones entre
los datos, en lugar de los productos DoDAF V1.0 o V1.5). Este enfoque centrado en los
datos garantiza la concordancia entre las vistas de la Descripción arquitectónica, a la vez
que garantiza que todas las relaciones de datos esenciales se capturen para admitir una
amplia variedad de tareas de análisis. Las vistas creadas como resultado del proceso de
desarrollo de la arquitectura proporcionan representaciones visuales de los datos
arquitectónicos subyacentes y transmiten información de interés de la Descripción
arquitectónica que necesitanlas comunidades de usuarios o los responsables de latoma
de decisiones específicos.
Paso 1: Determine el uso previsto de la arquitectura. Define el propósito y el
uso previsto de laarquitectura ("Fit-for-Purpose"); cómo sellevará a cabo el esfuerzo de
3 https://dodcio.defense.gov/Library/DoD-Architecture-Framework/

21. Descripción Arquitectónica; los métodos que se utilizarán en el desarrollo de la
arquitectura; las categorías de datos necesarias; el impacto potencial en los demás; y el
proceso por el cual el éxito del esfuerzo se medirá en términos de rendimiento y
satisfacción del cliente. Esta información es generalmente proporcionada por el
propietario del proceso para apoyar el desarrollo de la arquitectura que describe algún
aspecto de su área de responsabilidad (proceso, actividad, etc.).
Paso 2: Determinar el alcance de la arquitectura. El ámbito define los límites
que establecen la profundidad y la amplitud de la Descripción arquitectónica y
establecen el conjunto de problemas de la arquitectura, ayuda a definir su contexto y
define el nivel de detalle necesario para el contenido arquitectónico. Si bien muchos
esfuerzos de desarrollo de la arquitectura son similares en su enfoque, cada esfuerzo
también es único en el sentido de que los resultados o efectos deseados pueden ser muy
diferentes. Por ejemplo, los esfuerzos de desarrollo del sistema generalmente se
centran primero en el cambio de procesos y, a continuación, se concentran en esas
funciones automatizadas que soportan procesos o actividades de trabajo. Además de
comprender el proceso, el descubrimiento de estas "funciones del sistema" es
importante para decidir cómo proceder con el desarrollo o la compra de soporte de
automatización.
Paso 3: Determinar los datos necesarios para admitir el desarrollo de la
arquitectura. El nivel de detalle requerido que se capturará para cada una de las
entidades de datos y atributos se determina mediante el análisis del proceso sometido
a revisión realizado durante el ámbito en el paso 2. Esto incluye los datos identificados
como necesarios para la ejecución del proceso y otros datos necesarios para realizar el
cambio en el proceso actual (por ejemplo, los datos administrativos requeridos por la
organización para documentar el esfuerzo de Descripción Arquitectónica). Estas
consideraciones establecen el tipo de datos recopilados en el paso 4, que se relacionan
con la estructura arquitectónica, y la profundidad de detalle requerida. El tipo inicial de
contenido de datos arquitectónicos que se va a recopilar viene determinado por el
ámbito establecido de la Descripción arquitectónica y se registra como atributos,
asociaciones y conceptos como se describe en el DM2. Una asignación de conceptos,
asociaciones y atributos de DM2 a modelos de arquitectura sugiere vistas
arquitectónicas relevantes que el arquitecto puede desarrollar (utilizando técnicas de

22. arquitectura asociadas) durante la recopilación de datos más completa y coherente del
paso 4.
Paso 4: Recopilar, organizar, correlacionary almacenar datos arquitectónicos.
Los arquitectos suelen recopilar y organizar datos mediante el uso de técnicas de
arquitectura diseñadas para utilizar vistas (por ejemplo, la actividad, el proceso, la
organización y los modelos de datos como vistas) con fines de presentación y toma de
decisiones. Los datos arquitectónicos deben almacenarse en una herramienta de
arquitectura comercial o gubernamental reconocida. Los términos y definiciones
registrados están relacionados con elementos del (DM2). La designación de una
estructura de datos para el esfuerzo de Descripción Arquitectónica implica la creación
de una taxonomía para organizar los datos recopilados. Este esfuerzo se puede hacer
considerablemente más sencillo aprovechando los artefactos registrados existentes
para incluir taxonomías de datos y conjuntos de datos. Cada COI mantiene sus datos
registrados directamente o a través de un enfoque federado. Además, algunas
organizaciones han desarrollado plantillas, que proporcionan la base de una solución
personalizable a problemas comunes, o requisitos, que incluye conjuntos de datos ya
descritos y registrados en el DMR.
Paso 5: Realizar Análisis en Apoyo a los Objetivos de Arquitectura. El análisis de
datos arquitectónicos determina el nivel de cumplimiento de los requisitos del
propietario del proceso. Este paso también puede identificar pasos de proceso
adicionales y requisitos de recopilación de datos necesarios para completar la
Descripción arquitectónica y facilitar mejor su uso previsto. La validación aplica los
principios rectores, objetivos y objetivos al requisito del proceso, según lo definido por
el propietario del proceso, junto con las medidas de rendimiento publicadas (métricas),
para determinar el nivel alcanzadode éxito en el esfuerzo de Descripción arquitectónica.
La finalización de este paso prepara la Descripción arquitectónica para su aprobación
por el propietario del proceso. Los cambios necesarios en el proceso de validación dan
lugar a la iteración del proceso de arquitectura (repita los pasos 3 a 5 según sea
necesario).
Paso 6: Resultados del documento de acuerdo con las necesidades del
responsable de la toma de decisiones. El último paso en el proceso de desarrollo de la
arquitectura implica la creación de vistas arquitectónicas basadas en consultas de los

23. datos subyacentes. Presentar los datos arquitectónicos a audiencias variadas requiere
transformar los datos arquitectónicos en presentaciones significativas para los
responsables de la toma de decisiones. Esto se ve facilitado por los requisitos de datos
determinados en el paso 3 y los métodos de recopilación de datos empleados durante
el paso 4. DoDAF V2.0 proporciona modelos y vistas. Los modelos descritos por DoDAF
son aquellos modelos que permiten a un arquitecto y equipo de desarrollo cuyos datos
ya sehan definido y descrito de acuerdo con elDM2. Los modelos seconvierten en vistas
cuando se rellenan con datos arquitectónicos. Estos modelos incluyen los descritos
anteriormente en versiones anteriores de DoDAF, junto con nuevos modelos
incorporados del MODAF,el NAF de la OTAN y TOGAF que tienen relevancia para los
esfuerzos de desarrollo de la arquitectura Del DoD.
Figura 4 Desarrollo de la Arquitectura 6 pasos
Fuente: Página Oficial DoDAF4
4 https://dodcio.defense.gov/Library/DoD-Architecture-
Framework/dodaf20_arch_development/#step4

24. 7.1. META MODELO
DoDAF tiene un metamodelo que basa el marco de trabajo, definiendo
los tipos de elementos de modelado que se pueden utilizar en cada vista y las
relaciones entre ellos.Las versiones 1.0 a 1.5 de DoDAF utilizaban elmetamodelo
CADM, que se definió en IDEF1X (luego más adelante en UML) con un esquema
XML derivado de la base de datos relacional resultante. A partir de la versión 2.0,
DoDAF ha adoptado la ontología de la fundación del Grupo IDEAS como base
para su nuevo metamodelo. Este nuevo meta-modelo se llama "DM2"; un
acrónimo de "DoDAF Meta-Model". Cada uno de estos tres niveles del DM2 es
importante para un espectador particular de los procesos departamentales:
a. El nivel conceptual o Modelo de datos conceptual (CDM) define
las construcciones de datos de alto nivel a partir de las cuales se
crean descripciones arquitectónicas en términos no técnicos, para
que los ejecutivos y gerentes de todos los niveles puedan
comprender la base de datos de Architectural Descripción.
Representado en el punto de vista DoDAF V2.0 DIV-1.
b. El modelo de datos lógicos (LDM) agrega información técnica,
como atributos al CDM y, cuando es necesario, aclara las
relaciones en una definición de uso inequívoca. Representado en
el punto de vista DoDAF V2.0 DIV-2.
c. La especificación de intercambio físico (PES) consta del LDM con
los tipos de datos generales especificados y los atributos de
implementación (por ejemplo, origen, fecha) agregados y, a
continuación, generados como un XSD. Representado en el punto
de vista DoDAF V2.0 DIV-3.

25. Los propósitos del DM2 son:
1) Establecer y definir el vocabulario restringido para la descripción
y el discurso sobre los modelos DoDAF (anteriormente
"productos") y su uso en los 6 procesos principales
2) Especifique la semántica y el formato para el intercambio de
datos de EA federado entre: herramientas de desarrollo y análisis
de arquitectura y bases de datos de arquitectura en laComunidad
de Interés (COI) de DoD Enterprise Architecture (EA) y con otras
fuentes de datos autorizadas
3) Soporte de descubrimiento y comprensión de datos de EA:
 Descubrimiento de datos de EA utilizando categorías de
información DM2
 Comprensión de los datos de EA utilizando la semántica
precisa de DM2 aumentada con trazabilidad linguística (alias)
4) Proporcionar una base para la precisión semántica en las
descripciones arquitectónicas para apoyar la integración y el
análisis heterogéneos de la descripción arquitectónica en apoyo
de la toma de decisiones de procesos principales.
El DM2 define los elementos de datos arquitectónicos y permite la
integración y federación de descripciones arquitectónicas. Establece una base
para la coherencia semántica (es decir, la comprensión) dentro y a través de las
descripciones arquitectónicas. De esta manera, el DM2 apoya el intercambio y la
reutilización de información arquitectónica entre los AJC, componentes y socios
federales y de la coalición, facilitando así la comprensión e implementación de la
interoperabilidad de los procesos y sistemas. A medida que el DM2 madura para
cumplir con los requisitos de datos en curso de los propietarios de procesos,
tomadores de decisiones, arquitectos y nuevas tecnologías, evolucionará a un
recurso que respalde más completamente los requisitos de datos
arquitectónicos, publicados de una manera coherentemente comprensible, y
permitirá una mayor facilidad para descubrir, compartir y reutilizar datos
arquitectónicos a través de los límites de la organización.

26. Para facilitarel uso de información en lacapa de datos, el DoDAF describe
un conjunto de modelos para visualizar datos a través de medios gráficos,
tabulares o textuales. Estas opiniones se refieren a los requisitos de las partes
interesadas para producir una descripción arquitectónica.
VIII. SOFTWAREDODAF
Visual Paradigm proporciona un software DoDAF fácil de usar y basado en
modelos que admite el desarrollo de vistas y modelos DeDAF 2.02. Cree productos
DoDAF integrados con trazabilidad mantenida entre vistas. Genere documentos
arquitectónicos que faciliten a las organizaciones coordinar de manera eficiente las
iniciativas de arquitectura empresarial.
Figura 5 Visual Paradigm
Fuente: https://www.visual-paradigm.com/features/dodaf-tool/

27. IX. CASO DE ÉXITO
X. BIBLIOGRAFÍA
Ang, H., Dandashi, F., & Mcfarren, M. (n.d.). Tailoring DoDAF For Service-
Oriented Architectures. Space Weather The InternationalJournalOf
Research And Applications, (06), 2–9.
Urbaczewski, L., & Mrdalj, S. (2006). a Comparison of Enterprise
Architecture Frameworks. Issuesin Information Systems, 7(2), 18–23.