Marco de arquitectura del Departamento de Defensa

El Marco de Arquitectura del Departamento de Defensa ( DoDAF ) es un marco de arquitectura para el Departamento de Defensa de los Estados Unidos (DoD) que proporciona una infraestructura de visualización para las preocupaciones específicas de las partes interesadas a través de puntos de vista organizados por varias vistas . Estas vistas son artefactos para visualizar, comprender y asimilar el amplio alcance y las complejidades de una descripción de arquitectura a través de medios tabulares , estructurales , conductuales , ontológicos , pictóricos , temporales , gráficos , probabilísticos o conceptuales alternativos . La versión actual es DoDAF 2.02.

Este marco de arquitectura es especialmente adecuado para sistemas de gran tamaño con desafíos complejos de integración e interoperabilidad, y es aparentemente único en su uso de "vistas operativas". Estas vistas ofrecen una descripción general y detalles dirigidos a partes interesadas específicas dentro de su dominio y en interacción con otros dominios en los que operará el sistema. ^[3]

El DoDAF proporciona un marco de referencia para desarrollar y representar descripciones de arquitectura que aseguren un denominador común para comprender, comparar e integrar arquitecturas a través de límites organizacionales, conjuntos y multinacionales. Establece definiciones de elementos de datos, reglas y relaciones, y un conjunto de productos de referencia para el desarrollo consistente de sistemas, arquitecturas integradas o federadas. Estas descripciones de arquitectura pueden incluir familias de sistemas (FoS), sistemas de sistemas (SoS) y capacidades centradas en la red para interoperar e interactuar en el entorno no bélico. ^[1]

Se espera que los componentes del Departamento de Defensa cumplan con el DoDAF en la mayor medida posible en el desarrollo de arquitecturas dentro del departamento. La conformidad garantiza que la reutilización de la información, los artefactos de arquitectura, los modelos y los puntos de vista se puedan compartir con un entendimiento común. Todas las adquisiciones importantes de armas y sistemas de tecnología de la información del Departamento de Defensa de los EE. UU. deben desarrollar y documentar una arquitectura empresarial (EA) utilizando las vistas prescritas en el DoDAF. Si bien está claramente dirigido a los sistemas militares, el DoDAF tiene una amplia aplicabilidad en 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 . ^{[4] [5]}

• El propósito del DoDAF es definir conceptos y modelos utilizables en los seis procesos centrales del Departamento de Defensa: ^[6]
  1. Integración y desarrollo de capacidades conjuntas (JCIDS)
  2. Planificación, Programación, Presupuestación y Ejecución (PPBE)
  3. Sistema de Adquisición de Defensa (DAS)
  4. Ingeniería de sistemas (SE)
  5. Planificación operativa (OPLAN)
  6. Gestión de cartera de capacidades (CPM)
• Además, los objetivos específicos de DoDAF 2.0 eran: ^[6]
  1. Establecer una guía para el contenido de la arquitectura en función del propósito: “apta para el propósito”
  2. Aumente la utilidad y la eficacia de las arquitecturas a través de un modelo de datos riguroso (el metamodelo DoDAF (DM2)) para que las arquitecturas puedan integrarse, analizarse y evaluarse con mayor precisión.

La primera versión del DoDAF de desarrollo se desarrolló en la década de 1990 bajo el nombre de C4ISR Architecture Framework. En el mismo período, se siguió desarrollando el modelo de referencia TAFIM , que se inició en 1986. El primer C4ISR Architecture Framework v1.0, publicado el 7 de junio de 1996, se creó en respuesta a la aprobación de la Ley Clinger-Cohen . Abordaba la directiva del Subsecretario de Defensa de 1995 de que se emprendiera un esfuerzo a nivel de todo el Departamento de Defensa para definir y desarrollar un mejor medio y proceso para garantizar que las capacidades C4ISR fueran interoperables y satisficieran las necesidades del combatiente. El esfuerzo de desarrollo continuo dio como resultado en diciembre de 1997 la segunda versión, C4ISR Architecture Framework v2.0. ^[1]

En agosto de 2003 se publicó la versión 1.0 del DoDAF, que reestructuró el marco C4ISR v2.0 para ofrecer orientación, descripciones de productos e información complementaria en dos volúmenes y un manual de trabajo. Amplió la aplicabilidad de los principios y prácticas de la arquitectura a todas las áreas de misión en lugar de sólo a la comunidad C4ISR. Este documento abordó el uso, las arquitecturas integradas, las políticas federales y del Departamento de Defensa, el valor de las arquitecturas, las medidas de la arquitectura, los procesos de apoyo a la toma de decisiones del Departamento de Defensa, las técnicas de desarrollo, las técnicas analíticas y el CADM v1.01, y avanzó hacia un enfoque basado en repositorios haciendo hincapié en los elementos de datos de arquitectura que comprenden los productos de arquitectura. ^[1] En febrero de 2004 se publicó la documentación de la versión 1.0 con el volumen "I: Definiciones y directrices", "II: Descripciones de productos" y un "manual de trabajo". En abril de 2007 se publicó la versión 1.5 con una documentación de "Definiciones y directrices", "Descripciones de productos" y "Descripción de datos de arquitectura". Este período desarrolló aún más los conceptos y términos que desde entonces han sido reemplazados por enfoques diferentes. Por ejemplo, una Declaración de Necesidades de Misión (MNS) era un tipo de documento del Departamento de Defensa de los EE. UU. que identificaba las necesidades de capacidad que un programa debía satisfacer mediante una combinación de soluciones ( DOTMLPF ) para resolver una deficiencia de la misión o para mejorar la capacidad operativa. Este tipo de documento ha sido reemplazado por la descripción de las necesidades de capacidad denominada Documento de Capacidades Iniciales, a partir de CJCSI 3170.01E. Los CJCSI 3170.01 y 6212.01 fueron reemplazados por la Serie CJCSI 5123.01.

Este término se introdujo como un paso fundamental en CJCSI 3170.01B (abril de 2001), 6212.01D (abril de 2005) y la Guía provisional de adquisiciones de defensa (octubre de 2004).

El 28 de mayo de 2009, el Departamento de Defensa aprobó la versión DoDAF v2.0. ^[7] La ​​versión actual es DoDAF 2.02 . ^[8] La versión DoDAF v2.0 está publicada en un sitio web público. ^[9]

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 el Marco de Arquitectura de Grupo Abierto (TOGAF), DoDAF está organizado en torno a un repositorio compartido para almacenar productos de trabajo. El repositorio está definido por el esquema de base de datos común Core Architecture Data Model 2.0 y el Sistema de Registro de Arquitectura del DoD (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 solo debe satisfacer sus necesidades de datos internos, sino también las del marco operativo en el que se encuentra.

Vea el diagrama para ver una representación del énfasis en capacidades, relacionado con la misión/curso de acción, hilos, actividades y arquitecturas.

El Departamento de Defensa ha avanzado hacia un enfoque en la entrega de capacidades, que son la razón para crear el sistema/servicio. Los modelos de capacidades describen la taxonomía de capacidades y la evolución de las mismas. Un hilo conductor de capacidades equivaldría a las actividades, reglas y sistemas específicos que están vinculados a esa capacidad en particular.

El concepto de capacidad, tal como lo define su Grupo de Datos del Metamodelo, permite responder preguntas como:

• ¿Cómo una capacidad o capacidades particulares respaldan la misión/visión general?
• ¿Qué resultados se espera lograr con una determinada capacidad o conjunto de capacidades?
• ¿Qué servicios se requieren para respaldar una capacidad?
• ¿Cuál es el alcance funcional y la extensión organizacional de una capacidad o un conjunto de capacidades?
• ¿Cuál es nuestro conjunto actual de capacidades que gestionamos como parte de una cartera?

^[10]

La Misión o Curso de Acción se describe mediante un Concepto de Operaciones (CONOPS) y está organizado por Capacidades.

• Las capacidades se describen mediante subprocesos.
• Los hilos se describen mediante actividades ejecutadas en serie o en paralelo.
• Las actividades se agrupan en áreas de misión. Las actividades definen las operaciones de una arquitectura.
• Las arquitecturas se organizan por áreas de misión y proporcionan los recursos adecuados para las capacidades requeridas por la misión o el curso de acción.

La versión DoDAF V1.5 define un conjunto de productos, un modelo de vista , que actúan como mecanismos para visualizar, comprender y asimilar el amplio alcance y las complejidades de una descripción de arquitectura a través de medios gráficos, tabulares o textuales. Estos productos están organizados en cuatro vistas:

• Vista general (AV)
• Vista operativa (VO)
• Vista de sistemas (VS)
• Vista de normas técnicas (TV)

Cada vista representa ciertas perspectivas de una arquitectura, como se describe a continuación. Por lo general, solo se crea un subconjunto del conjunto de vistas DoDAF completo para cada desarrollo de sistema. La figura representa la información que vincula la vista operativa, la vista de sistemas y servicios y la vista de estándares técnicos. Las tres vistas y sus interrelaciones (impulsadas por elementos de datos de arquitectura comunes) proporcionan la base para derivar medidas como la interoperabilidad o el rendimiento, y para medir el impacto de los valores de estas métricas en la misión operativa y la eficacia de las tareas. ^[1]

Todos los productos de vista (AV) proporcionan descripciones generales de toda la arquitectura y definen el alcance y el contexto de la arquitectura. Los productos de AV DoDAF V1.5 se definen como:

Descripción general y resumen de la información del AV-1

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.

Los productos de Vista operativa (OV) proporcionan descripciones de las tareas y actividades, elementos operativos e intercambios de información necesarios para cumplir las misiones del Departamento de Defensa. La OV proporciona representaciones textuales y gráficas de los 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 respaldadas por estos intercambios y la naturaleza de los intercambios. Los productos OV DoDAF V1.5 se definen como:

Gráfico conceptual operativo de alto nivel OV-1

Descripción gráfica y textual de alto nivel del concepto operacional (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 operativa OV-3

Información intercambiada entre nodos y los atributos relevantes de ese intercambio, como el medio, la calidad, la cantidad y el nivel de interoperabilidad requerido.

Diagrama de relaciones organizacionales OV-4

Mando, control, coordinación y otras relaciones entre organizaciones.

Modelo de Actividad Operativa OV-5

Actividades, relaciones entre actividades, entradas y salidas. Además, las superposiciones pueden mostrar costos, nodos en ejecución u otra información pertinente.

Modelo de reglas operativas OV-6a

Uno de los tres productos utilizados para describir la secuencia y el tiempo de la actividad operativa que identifica las reglas de negocio que limitan la operación.

Descripción de la transición del estado operativo OV-6b

Uno de los tres productos utilizados para describir la secuencia y el tiempo de la actividad operativa que identifica las respuestas de un proceso de negocio a los eventos.

Descripción del seguimiento de eventos operativos OV-6c

Uno de los tres productos utilizados para describir la secuencia y el tiempo de la actividad operativa que rastrea 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 las reglas estructurales del proceso empresarial de la Vista operativa. (En DoDAF V1.5. Esto corresponde a DIV-2 en DoDAF V2.0.)

La vista de sistemas y servicios (SV) es un conjunto de productos gráficos y textuales que describen sistemas y servicios e interconexiones que brindan o respaldan funciones del 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 en la SV y la OV se puede ejemplificar a medida que se adquieren y se implementan sistemas para respaldar a las organizaciones y sus operaciones. Los productos SV DoDAF V1.5 son:

Descripción de la interfaz de sistemas/servicios SV-1

Representa los nodos de sistemas y los sistemas residentes en estos nodos para respaldar las organizaciones y los roles humanos representados por los nodos operativos del OV-2. El SV-1 también identifica las interfaces entre los sistemas y los nodos de sistemas.

Descripción de 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 respaldan 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 comunicación representadas en OV-2.

Matrices SV-3 Sistemas-Sistemas, Servicios-Sistemas, Servicios-Servicios

proporciona detalles sobre las características de la interfaz descritas en SV-1 para la arquitectura, organizadas en forma de matriz.

Descripción de la funcionalidad de los sistemas y servicios SV-4a/SV-4b

El SV-4a documenta las jerarquías funcionales 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 las jerarquías de procesos de negocio y la jerarquía funcional del sistema de SV-4a, no es necesario que sea una correspondencia uno a uno, de ahí la necesidad de la Matriz de trazabilidad de la actividad operativa a la función del sistema (SV-5a), que proporciona esa correspondencia.

Matrices de trazabilidad de la actividad operativa a la función de los sistemas, de la actividad operativa a los sistemas y servicios SV-5a, SV-5b, SV-5c

La Actividad operativa de 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 esa arquitectura. El SV-5 y la extensión del 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 que se intercambian 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 las órdenes verbales, se capturan únicamente en los productos OV.

Matriz de parámetros de rendimiento de sistemas y 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 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 requeridos en momentos específicos 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 requisitos y definir especificaciones. Es posible que no se conozca el conjunto completo de parámetros de rendimiento en las primeras etapas de la definición de la arquitectura, por lo que se debe esperar que este producto se actualice a lo largo de las fases de especificación, diseño, desarrollo, prueba y posiblemente incluso de implementación y operaciones del sistema.

Descripción de la evolución de los sistemas y servicios del SV-8

Captura los planes de evolución que describen cómo evolucionará el sistema, o la arquitectura en la que está integrado el sistema, durante un largo período de tiempo. Por lo general, los hitos de la cronología son fundamentales para comprender correctamente la cronología de la evolución.

Previsión tecnológica de sistemas y servicios SV-9

Define las tecnologías de apoyo actuales y esperadas que se han seleccionado utilizando métodos de pronóstico 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 de SV-8.

Modelo de reglas de sistemas/servicios SV-10a

Describe las reglas bajo las cuales la arquitectura o sus sistemas se comportan bajo condiciones específicas.

Descripción de la transición de estado de los sistemas/servicios del SV-10b

Método gráfico para describir la respuesta de un sistema (o función de un sistema) a diversos eventos mediante el cambio de 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 seguimiento de eventos de sistemas/servicios SV-10c

Proporciona un análisis ordenado en el tiempo de los elementos 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 en particular. Cada diagrama de seguimiento de eventos debe tener una descripción que defina el escenario o la situación en particular. SV-10c en la Vista de sistemas y servicios puede reflejar aspectos específicos del sistema o mejoras de secuencias críticas de eventos descritas en la Vista operativa.

Esquema físico del SV-11

Uno de los productos de arquitectura más cercanos al diseño del sistema real en el marco. El producto define la estructura de los distintos tipos de datos del sistema que utilizan los sistemas en la arquitectura. (En DoDAF V1.5. Esto corresponde a DIV-3 en DoDAF V2.0).

Los productos de la vista de estándares técnicos (TV) definen estándares técnicos, convenciones de implementación, reglas de negocios y criterios que rigen la arquitectura. Los productos de TV DoDAF V1.5 son los siguientes:

• Perfil de estándares técnicos StdV-1 : extracción de estándares que se aplican a la arquitectura dada. (En DoDAF V1.5. Renombrado a StdV-1 en DoDAF V2.0).
• Pronóstico de estándares técnicos StdV-2 : descripción de los estándares emergentes que se espera que se apliquen a la arquitectura dada, dentro de un conjunto apropiado de plazos. (En DoDAF V1.5. Renombrado como StdV-2 en DoDAF V2.0).

En DoDAF V2.0, los puntos de vista arquitectónicos están compuestos de datos que se han organizado para facilitar su comprensión. Para alinearse con las normas ISO, cuando corresponde, la terminología ha cambiado de Vistas a Punto de vista (por ejemplo, la Vista operativa ahora es Punto de vista operativo).

Todos los puntos de vista (AV)

Describe los aspectos generales del contexto arquitectónico que se relacionan con todos los puntos de vista.

Punto de vista de la capacidad (CV)

Novedades de DoDAF V2.0. Se articulan los requisitos de capacidad, el plazo de entrega y la capacidad implementada.

Punto de vista de datos e información (DIV)

Novedades de DoDAF V2.0. Articula las relaciones de datos y las estructuras de alineación en el contenido de la arquitectura para los requisitos operativos y de capacidad, los procesos de ingeniería de sistemas y los sistemas y servicios.

Punto de vista operacional (VO)

Incluye los escenarios operativos, actividades y requisitos que respaldan las capacidades.

Punto de vista del proyecto (PV)

Novedades de DoDAF V2.0. Describe las relaciones entre los requisitos operativos y de capacidad y los distintos proyectos que se están implementando. El punto de vista del proyecto también detalla las dependencias entre los requisitos operativos y de capacidad, los procesos de ingeniería de sistemas, el diseño de sistemas y el diseño de servicios dentro del proceso del Sistema de Adquisiciones de Defensa.

Punto de vista de los servicios (SvcV)

Novedades de DoDAF V2.0: presenta el diseño de soluciones que articulan a los ejecutantes, las actividades, los servicios y sus intercambios, proporcionando o respaldando funciones operativas y de capacidad.

Punto de vista de las normas (StdV)

Se renombró de Vista de estándares técnicos. Articula las políticas, estándares, guías, restricciones y pronósticos operativos, comerciales, técnicos e industriales aplicables que se aplican a los requisitos operativos y de capacidad, los procesos de ingeniería de sistemas y los sistemas y servicios.

Punto de vista de sistemas (SV)

Articula, para el soporte heredado , el diseño de soluciones que articulan los sistemas, su composición, interconectividad y contexto que proporciona o respalda funciones operativas y de capacidad. Nota, Sistema ha cambiado en DoDAF V2.0 de DoDAF V1.5: Sistema no es solo hardware y software de computadora. Sistema ahora se define en el sentido general de un conjunto de componentes (máquina, humano) que realizan actividades (ya que son subtipos de Ejecutante) y están interactuando o son interdependientes. Esto podría ser cualquier cosa, es decir, cualquier cosa desde pequeñas piezas de equipo que tienen elementos interactuantes o interdependientes, hasta Familia de Sistemas (FoS) y Sistema de Sistemas (SoS). Tenga en cuenta que los Sistemas se componen de Material (p. ej., equipo, aeronaves y embarcaciones) y Tipos de Personal.

Las arquitecturas de DoDAF V1.0 y DoDAF V1.5 pueden seguir utilizándose. Cuando sea apropiado (normalmente indicado por la política o por el responsable de la toma de decisiones), las arquitecturas DoDAF V1.0 y V1.5 deberán actualizar su arquitectura. Cuando se compara la arquitectura anterior a DoDAF V2.0 con la arquitectura DoDAF V2.0, se deben definir o explicar las diferencias conceptuales (como Node) para la arquitectura más nueva. Con respecto a los productos DoDAF V1.5, se han transformado en partes de los modelos DoDAF V2.0. En la mayoría de los casos, el metamodelo DoDAF V2.0 admite los conceptos de datos DoDAF V1.5, con una excepción notable: Node. Node es un concepto complejo y lógico que se representa con conceptos más concretos.

Descripción general y resumen de la información del AV-1

Describe las visiones, metas, objetivos, planes, actividades, eventos, condiciones, medidas, efectos (resultados) y objetos producidos de un proyecto.

Diccionario integrado AV-2

Un repositorio de datos arquitectónicos con definiciones de todos los términos utilizados en todo el libro.

CV-1 Visión

Aborda las preocupaciones empresariales asociadas con la visión general de los esfuerzos de transformación 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 capacidades CV-2

Captura taxonomías de capacidades. El modelo presenta una jerarquía de capacidades. Estas capacidades pueden presentarse 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.

Fase de capacidad CV-3

El logro planificado de una capacidad en diferentes puntos del tiempo o durante períodos específicos de tiempo. El CV-3 muestra la fase de la capacidad en términos de actividades, condiciones, efectos deseados, reglas cumplidas, consumo y producción de recursos y medidas, sin tener en cuenta el ejecutante y las soluciones de ubicación.

Dependencias de capacidad CV-4

Las dependencias entre las capacidades planificadas y la definición de agrupaciones lógicas de capacidades.

CV-5 Mapeo de capacidades para el desarrollo organizacional

El cumplimiento de los requisitos de capacidad muestra la implementación y la interconexión de capacidades planificadas para una fase de capacidad en particular. El CV-5 muestra la solución planificada para la fase en términos de ejecutantes y ubicaciones y sus conceptos asociados.

CV-6 Mapeo de la capacidad para actividades operativas

Un mapeo entre las capacidades requeridas y las actividades operativas que esas capacidades respaldan.

CV-7 Mapeo de capacidades para servicios

Un mapeo entre las capacidades y los servicios que estas capacidades posibilitan.

Modelo de datos conceptual 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 estructurales del proceso empresarial (actividad). En DoDAF V1.5, esto era OV-7.

Modelo de datos físicos DIV-3

El formato de implementación física de las entidades del modelo lógico de datos, por ejemplo, formatos de mensajes, estructuras de archivos, esquema físico. En DoDAF V1.5, este era el SV-11.

Nota: consulte el modelo de datos lógicos para obtener una discusión de la relación de estos tres modelos de datos DIV, con una comparación de los modelos de datos conceptuales, lógicos y físicos.

Gráfico conceptual operativo de alto nivel OV-1

La descripción gráfica/textual de alto nivel del concepto operativo.

Descripción del flujo de recursos operativos OV-2

Una descripción de los flujos de recursos intercambiados entre actividades operativas.

Matriz de flujo de recursos operativos OV-3

Una descripción de los recursos intercambiados y los atributos relevantes de los intercambios.

Diagrama de relaciones organizacionales OV-4

El contexto organizacional, el rol u otras relaciones entre organizaciones.

Árbol de descomposición de la actividad operativa OV-5a

Las capacidades y actividades (actividades operativas) organizadas en una estructura jerárquica.

Modelo de actividad operativa OV-5b

El contexto de las capacidades y actividades (actividades operacionales) y sus relaciones entre actividades, insumos y productos; datos adicionales pueden mostrar costos, ejecutantes u otra información pertinente.

Modelo de reglas operativas OV-6a

Uno de los tres modelos utilizados para describir la actividad (actividad operativa). Identifica las reglas de negocio que limitan las operaciones.

Descripción de la transición de estado OV-6b

Uno de los tres modelos utilizados para describir la actividad operativa. Identifica las respuestas del proceso empresarial a los eventos (normalmente, actividades muy breves).

Descripción del seguimiento de eventos OV-6c

Uno de los tres modelos utilizados para describir la actividad (actividad operativa). Rastrea acciones en un escenario o secuencia de eventos.

Relaciones de la cartera de proyectos PV-1

Describe las relaciones de dependencia entre las organizaciones y los proyectos y las estructuras organizativas necesarias para gestionar una cartera de proyectos.

Cronograma del proyecto PV-2

Una perspectiva cronológica de los programas o proyectos, con los hitos clave y las interdependencias.

Proyecto PV-3 para mapeo de capacidades

Un mapeo de programas y proyectos a capacidades para mostrar cómo los proyectos y elementos específicos del programa ayudan a lograr una capacidad.

Descripción del contexto de los servicios SvcV-1

La identificación de servicios, elementos de servicio y sus interconexiones.

Descripción del flujo de recursos de servicios SvcV-2

Una descripción de los flujos de recursos intercambiados entre servicios.

Matriz de sistemas y servicios SvcV-3a

Las relaciones entre sistemas y servicios en una descripción arquitectónica dada.

Matriz de servicios de SvcV-3b

Las relaciones entre los servicios en una descripción arquitectónica determinada. Puede diseñarse para mostrar relaciones de interés (por ejemplo, interfaces de tipo de servicio, interfaces planificadas vs. existentes).

Descripción de la funcionalidad de los servicios SvcV-4

Las funciones realizadas por los servicios y los flujos de datos de servicio entre las funciones de servicio (actividades).

Matriz de trazabilidad de actividades operativas y servicios SvcV-5

Un mapeo de servicios (actividades) a actividades operacionales (actividades).

Matriz de flujo de recursos de servicios SvcV-6

Proporciona detalles de los elementos del flujo de recursos de servicio que se intercambian entre servicios y los atributos de ese intercambio.

Matriz de medidas de servicios SvcV-7

Las medidas (métricas) de los elementos del modelo de servicios para los períodos de tiempo apropiados.

Descripción de la evolución de los servicios SvcV-8

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 hacia una implementación futura.

Previsión de habilidades y tecnología de servicios SvcV-9

Las tecnologías emergentes, los productos de software/hardware y las habilidades que se espera que estén disponibles en un conjunto determinado de períodos de tiempo y que afectarán el desarrollo futuro de servicios.

Modelo de reglas de servicios SvcV-10a

Uno de los tres modelos utilizados para describir la funcionalidad de un servicio. Identifica las limitaciones que se imponen a la funcionalidad de los sistemas debido a algún aspecto del diseño o la implementación del sistema.

Descripción de la transición de estado de servicios del SvcV-10b

Uno de los tres modelos utilizados para describir la funcionalidad de un servicio. Identifica las respuestas de los servicios a los eventos.

Descripción del seguimiento de eventos de servicios SvcV-10c

Uno de los tres modelos utilizados para describir la funcionalidad del servicio. Identifica mejoras específicas del servicio en las secuencias críticas de eventos descritas en el punto de vista operativo.

Perfil de estándares StdV-1

Lista de estándares que se aplican a los elementos de la solución. En DoDAF V1.5, este era el TV-1.

Pronóstico de estándares StdV-2

Descripción de las normas emergentes y su posible impacto en los elementos de la solución actual, dentro de un conjunto de marcos temporales. En DoDAF V1.5, este era el TV-2.

Descripción de la interfaz del sistema SV-1

La identificación de sistemas, elementos del sistema y sus interconexiones.

Descripción del flujo de recursos del sistema SV-2

Una descripción de los flujos de recursos intercambiados entre sistemas.

Matriz de sistemas SV-3

Las relaciones entre sistemas en una descripción arquitectónica dada. Puede diseñarse para mostrar relaciones de interés (por ejemplo, interfaces de tipo de sistema, interfaces planificadas vs. interfaces existentes).

Descripción de la funcionalidad de los sistemas SV-4

Las funciones (actividades) realizadas por los sistemas y los flujos de datos del sistema entre las funciones (actividades) del sistema.

Matriz de trazabilidad de la actividad operativa a la función del sistema SV-5a

Un mapeo de las funciones del sistema (actividades) a las actividades operacionales (actividades).

Matriz de trazabilidad de la actividad operativa a los sistemas SV-5b

Un mapeo de los sistemas hacia las capacidades o actividades operacionales (actividades).

Matriz de flujo de recursos de los sistemas SV-6

Proporciona detalles de los elementos del flujo de recursos del sistema que se intercambian entre sistemas y los atributos de ese intercambio.

Matriz de medidas del sistema SV-7

Las medidas (métricas) de los elementos del modelo de sistemas para los períodos de tiempo apropiados.

Descripción de la evolución de los sistemas SV-8

The planned incremental steps toward migrating a suite of systems to a more efficient suite, or toward evolving a current system to a future implementation.

SV-9 Systems Technology & Skills Forecast

The emerging technologies, software/hardware products, and skills that are expected to be available in a given set of time frames and that will affect future system development.

SV-10a Systems Rules Model

One of three models used to describe system functionality. It identifies constraints that are imposed on systems functionality due to some aspect of system design or implementation.

SV-10b Systems State Transition Description

One of three models used to describe system functionality. It identifies responses of systems to events.

SV-10c Systems Event-Trace Description

One of three models used to describe system functionality. It identifies system-specific refinements of critical sequences of events described in the Operational Viewpoint.

The DODAF 2.0 Architects Guide ^[14] repeated DOD Instruction 4630.8 definition of an integrated architecture as "An architecture consisting of multiple views facilitating integration and promoting interoperability across capabilities and among integrated architectures. For the purposes of architecture development, the term integrated means that data required in more than one of the architectural models is commonly defined and understood across those models. Integrated architectures are a property or design principle for architectures at all levels: Capability,Component, Solution, and Enterprise (in the context of the DoD Enterprise Architecture (EA) being a federation [of] architectures). In simpler terms, integration is seen in the connection from items common among architecture products, where items shown in one architecture product (such as sites used or systems interfaced or services provided) should have the identical number, name, and meaning appear in related architecture product views."

There are many different approaches for creating an integrated architecture using DoDAF and for determining which products are required. The approach depends on the requirements and the expected results; i.e., what the resulting architecture will be used for. As one example, the DoDAF v1.0 listed the following products as the "minimum set of products required to satisfy the definition of an OV, SV and TV." One note: while the DoDAF does not list the OV-1 artifact as a core product, its development is strongly encouraged. The sequence of the artifacts listed below gives a suggested order in which the artifacts could be developed. The actual sequence of view generation and their potential customization is a function of the application domain and the specific needs of the effort.

• AV-1 : Overview and Summary Information
• AV-2 : Integrated Dictionary
• OV-1 : High Level Operational Concept Graphic
• OV-5 : Operational Activity Model
• OV-2 : Operational Node Connectivity Description
• OV-3 : Operational Informational Exchange Matrix
• SV-1 : System Interface Description
• TV-1 : Technical Standards Profile

One concern about the DoDAF is how well these products meet actual stakeholder concerns for any given system of interest. One can view DoDAF products, or at least the 3 views, as ANSI/IEEE 1471-2000 or ISO/IEC 42010 viewpoints. But to build an architecture description that corresponds to ANSI/IEEE 1471-2000 or ISO/IEC 42010, it is necessary to clearly identify the stakeholders and their concerns that map to each selected DoDAF product. Otherwise there is the risk of producing products with no customers.

The figure "DoDAF V1.5 Products Matrix" shows how the DoD Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 6212.01E specifies which DoDAF V1.5 products are required for each type of analysis, in the context of the Net-Ready Key Performance Parameter (NR-KPP):

• Initial Capabilities Document (ICD). Documents the need for a materiel solution to a specific capability gap derived from an initial analysis of alternatives executed by the operational user and, as required, an independent analysis of alternatives. It defines the capability gap in terms of the functional area, the relevant range of military operations, desired effects, and time.
• Capability Development Document (CDD). A document that captures the information necessary to develop a proposed program(s), normally using an evolutionary acquisition strategy. The CDD outlines an affordable increment of militarily useful, logistically supportable and technically mature capability.
• Capability Production Document (CPD). A document that addresses the production elements specific to a single increment of an acquisition program.
• Information Support Plan (ISP).^[16] The identification and documentation of information needs, infrastructure support, IT and NSS interface requirements and dependencies focusing on net-centric, interoperability, supportability and sufficiency concerns (DODI 4630.8).^[17]
• Tailored Information Support Plan (TISP). The purpose of the TISP process is to provide a dynamic and efficient vehicle for certain programs (ACAT II and below) to produce requirements necessary for I&S Certification. Select program managers may request to tailor the content of their ISP (ref ss). For programs not designated OSD special interest by ASD (NII)/DOD CIO, the component will make final decision on details of the tailored plan subject to minimums specified in the TISP procedures linked from the CJCSI 6212 resource page and any special needs identified by the J-6 for the I&S certification process.

Representations for the DoDAF products may be drawn from many diagramming techniques including:

• tables
• IDEF
• Entity-relationship diagrams (ERDs)
• UML
• SysML

There is a UPDM (Unified Profile for DoDAF and MODAF) effort within the OMG to standardize the representation of DoDAF products when UML is used.

DoDAF generically describes in the representation of the artifacts to be generated, but allows considerable flexibility regarding the specific formats and modeling techniques. The DoDAF deskbook provides examples in using traditional systems engineering and data engineering techniques, and secondly, UML format.^[18] DoDAF proclaims latitude in work product format, without professing one diagramming technique over another.

In addition to graphical representation, there is typically a requirement to provide metadata to the Defense Information Technology Portfolio Repository (DITPR) or other architectural repositories.

DoDAF has a meta-model underpinning the framework, defining the types of modelling elements that can be used in each view and the relationships between them. DoDAF versions 1.0 thru 1.5 used the CADM meta-model, which was defined in IDEF1X (then later in UML) with an XML Schema derived from the resulting relational database. From version 2.0, DoDAF has adopted the IDEAS Group foundation ontology as the basis for its new meta-model. This new meta-model is called "DM2"; an acronym for "DoDAF Meta-Model". Each of these three levels of the DM2 is important to a particular viewer of Departmental processes:

1. The conceptual level or Conceptual Data Model (CDM) defines the high-level data constructs from which Architectural Descriptions are created in non-technical terms, so that executives and managers at all levels can understand the data basis of Architectural Description. Represented in the DoDAF V2.0 DIV-1 Viewpoint.
2. The Logical Data Model (LDM) adds technical information, such as attributes to the CDM and, when necessary, clarifies relationships into an unambiguous usage definition. Represented in the DoDAF V2.0 DIV-2 Viewpoint.
3. The Physical Exchange Specification (PES) consists of the LDM with general data types specified and implementation attributes (e.g., source, date) added, and then generated as an XSD. Represented in the DoDAF V2.0 DIV-3 Viewpoint.^[6]

The purposes of the DM2 are:

1. Establish and define the constrained vocabulary for description and discourse about DoDAF models (formerly “products”) and their usage in the 6 core processes
2. Specify the semantics and format for federated EA data exchange between:architecture development and analysis tools and architecture databases across the DoD Enterprise Architecture (EA) Community of Interest (COI) and with other authoritative data sources
3. Support discovery and understandability of EA data:
   1. Discovery of EA data using DM2 categories of information
   2. Understandability of EA data using DM2's precise semantics augmented with linguistic traceability (aliases)
4. Provide a basis for semantic precision in architectural descriptions to support heterogeneous architectural description integration and analysis in support of core process decision making.^[6]

The DM2 defines architectural data elements and enables the integration and federation of Architectural Descriptions. It establishes a basis for semantic (i.e., understanding) consistency within and across Architectural Descriptions. In this manner, the DM2 supports the exchange and reuse of architectural information among JCAs, Components, and Federal and Coalition partners, thus facilitating the understanding and implementation of interoperability of processes and systems. As the DM2 matures to meet the ongoing data requirements of process owners, decision makers, architects, and new technologies, it will evolve to a resource that more completely supports the requirements for architectural data, published in a consistently understandable way, and will enable greater ease for discovering, sharing, and reusing architectural data across organizational boundaries.^[6]

To facilitate the use of information at the data layer, the DoDAF describes a set of models for visualizing data through graphic, tabular, or textual means. These views relate to stakeholder requirements for producing an Architectural Description.^[6]

The UPDM (Unified Profile for DoDAF and MODAF) is an OMG initiative to standardize UML and SysML usage for USA and UK defense architecture frameworks. In addition, the multi-national IDEAS Group, which is supported by Australia, Canada, Sweden, UK, USA, with NATO observers, has launched an initiative to develop a formal ontology for enterprise architectures.

• Federal Enterprise Architecture Framework (FEAF)
• IDEAS Group
• IUID
• MODAF Meta-Model
• NCOW

• Dennis E. Wisnosky and Joseph Vogel. Dodaf Wizdom: a Practical Guide to Planning, Managing and Executing Projects to Build Enterprise Architectures using the Department of Defense Architecture Framework. Wizdom Systems, Inc., 2004. ISBN 1-893990-09-5.
• Dr. Steven H. Dam (2015). DoD Architecture Framework 2.0: A Guide to Applying Systems Engineering to Develop Integrated, Executable Architectures. CreateSpace Independent Publishing Platform, 2015. ISBN 1-502757-62-1.

• DoDAF Homepage at DoD CIO
  • DODAF 2.02 pdf, Aug 2010
  • Volume (Vol) I: Overview and Concepts – Manager’s Guide^{[permanent dead link]}
  • Vol II: Architectural Data and Models – Architect’s Guide
  • Vol III: Meta-model Ontology Foundation and Physical Exchange Specification – Developer’s Guide
  • Vol IV: Journal - Best Practices^{[permanent dead link]}
• DoDAF v1.5, 23 Apr 2007
  • Vol I: Definitions and Guidelines pdf
  • Vol II: Product Descriptions pdf
  • Vol III: Architecture Data Description pdf
• DoDAF V1, 9 Feb 2004
  • Deskbook Archived 2017-11-15 at the Wayback Machine
  • Vol I: Definitions and Guidelines
• DoDAF section of Architecture Framework Forum Information resource dedicated to DoDAF as it relates to other architecture frameworks
• DoD CMO Business Enterprise Architecture (BEA) Archived 2020-11-02 at the Wayback Machine
  • Guía de productos de arquitectura BEA 10.0 del Departamento de Defensa
• Dos presentaciones sobre DoDAF 2.0 de las conferencias sobre EA integradas de 2008 y 2009
• Arquitectura empresarial de información del Departamento de Defensa
• Registro de metadatos
• Serie CJCSI 6212.01
  • Documento CJCSI 6212.01F
• Marco arquitectónico de la Agencia Espacial Europea (ESAAF): un marco para sistemas de sistemas espaciales europeos [1]