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 infraestructura de visualización para inquietudes específicas de las partes interesadas a través de puntos de vista. organizado 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 conceptuales tabulares, estructurales, conductuales, ontológicos, pictóricos, temporales, gráficos, probabilísticos o alternativos. La versión actual es DoDAF 2.02.

Este marco de arquitectura es especialmente adecuado para sistemas grandes con desafíos complejos de integración e interoperabilidad, y aparentemente es único en su empleo de "vistas operativas". Estas vistas ofrecen una visió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.

Descripción general

El DoDAF proporciona un marco fundamental para desarrollar y representar descripciones de arquitectura que garanticen un denominador común para comprender, comparar e integrar arquitecturas a través de fronteras organizativas, conjuntas y multinacionales. Establece definiciones, reglas y relaciones de elementos de datos y un conjunto básico de productos para el desarrollo coherente 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 un entorno sin combate.

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

• El propósito de DoDAF es definir conceptos y modelos utilizables en los seis procesos centrales de DoD:
  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 operacional (OPLAN)
  6. Capability Portfolio Management (CPM)
• Además, DoDAF Los objetivos específicos de 2.0 fueron:
  1. Establecer guías para el contenido de arquitectura como función de propósito – “fit for purpose”
  2. Aumentar la utilidad y eficacia de las arquitecturas a través de un modelo de datos riguroso – el modelo DoDAF Meta (DM2) – para que las arquitecturas puedan ser integradas, analizadas y evaluadas con más precisión.

Historia

La primera versión del desarrollo DoDAF fue desarrollada en el decenio de 1990 bajo el nombre C4ISR Architecture Framework. En el mismo período se desarrolló aún más el modelo de referencia TAFIM, iniciado en 1986. El primer Marco de Arquitectura C4ISR v1.0, lanzado el 7 de junio de 1996, se creó en respuesta a la aprobación de la Ley Clinger-Cohen. Abordó la directiva de 1995 de la Vicesecretaria de Defensa de que se hiciera un esfuerzo en todo el Departamento de Defensa para definir y desarrollar un mejor medio y proceso para asegurar que las capacidades de la C4ISR fueran interoperables y satisfagan las necesidades de los combatientes. Los esfuerzos continuos de desarrollo dieron lugar en diciembre de 1997 en la segunda versión, C4ISR Architecture Framework v2.0.

En agosto de 2003 se lanzó DoDAF v1.0, que reestructuró el marco C4ISR 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 la arquitectura a todas las áreas de la misión en lugar de solo 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 soporte 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 poniendo énfasis en Elementos de datos de arquitectura que componen productos de arquitectura. 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 "Libro de escritorio". En abril de 2007 se lanzó 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 diferentes enfoques. Por ejemplo, una Declaración de necesidades de la misión (MNS) era un tipo de documento del Departamento de Defensa de 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 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, 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 el Open Group Architecture Framework (TOGAF), DoDAF está organizado en torno a un repositorio compartido para contener productos de trabajo. El repositorio está definido por el esquema de base de 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 está organizada 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 de datos internos sino también las del marco operativo en el que se inserta.

Capacidades y misión

Consulte el diagrama para obtener una descripción del énfasis en capacidades, vinculado con la misión/curso de acción, subprocesos, actividades y arquitecturas.

El Departamento de Defensa se ha centrado en la entrega de capacidades, que son la razón para crear el sistema/servicio. Los Modelos de Capacidad describen la taxonomía de capacidades y la evolución de las capacidades. Un hilo de capacidad 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 de metamodelo, permite responder preguntas como:

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

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

• Las capacidades son descritas por los hilos.
• Los hilos son descritos por Actividades ejecutadas en serie o paralelo.
• Las actividades se agrupan en zonas de misión. Actividades definen operaciones para una Arquitectura.
• Las arquitecturas están organizadas por áreas de misión. Las arquitecturas proporcionan una adecuada contratación de capacidades requeridas por la Misión o Curso de Acción.

Vistas de la versión 1.5

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 bajo cuatro vistas:

• Toda la vista (AV)
• Vista operacional
• Vista de sistemas (SV)
• Vista de las 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 desempeño, y para medir el impacto de los valores de estas métricas en la misión operativa y la efectividad de las tareas.

Ver todos

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

AV-1 Información general y resumida

Alcance, propósito, usuarios previstos, medio ambiente representado, conclusiones analíticas (si procede)

Diccionario integrado AV-2

Definiciones de todos los términos utilizados en todos los productos.

Vista operativa

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

Gráfico de concepto 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.).

OV-2 Conectividad Nodo Operacional Descripción

Nodos operativos, actividades realizadas en cada nodo, y conectividad e flujo de información entre nodos.

Matriz de intercambio de información operacional OV-3

La información intercambiada entre los nodos y los atributos pertinentes de ese intercambio, como los medios, la calidad, la cantidad y el nivel de interoperabilidad requerido.

OV-4 Relaciones de organización Chart

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

Modelo de actividad operacional OV-5

Actividades, relaciones entre actividades, insumos y productos. Además, las superposiciones pueden mostrar costos, nodos de ejecución, u otra información pertinente.

Modelo de normas operacionales OV-6a

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

OV-6b Transition Estatal Operacional Descripción

Uno de los tres productos utilizados para describir la secuencia de actividades operacionales y el calendario que identifica las respuestas de un proceso empresarial a los eventos.

OV-6c Event-Trace Descripción

Uno de los tres productos utilizados para describir la secuencia de actividad operacional y el tiempo que traza las acciones en un escenario o secuencia crítica de eventos.

OV-7 Logical Modelo de datos

Documentación de los requerimientos de datos y reglas del proceso de negocio estructural de la Vista Operacional. (En DoDAF V1.5. Esto corresponde a DIV-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, servicios e interconexiones que proporcionan o respaldan funciones del Departamento de Defensa. 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 la arquitectura a través del SV y el OV se puede ejemplificar a medida que los sistemas se adquieren y se implementan para respaldar a las organizaciones y sus operaciones. Los productos DoDAF V1.5 SV son:

SV-1 Sistemas/Servicios Interfaz Descripción

Depicts systems nodes and the systems resident at these nodes to support organizations/human roles represented by operational nodes of the OV-2. SV-1 también identifica las interfaces entre sistemas y nodos de sistemas.

SV-2 Sistemas/Servicios Comunicaciones Descripción

Depicts pertinent information about communications systems, communications links, and communications networks. SV-2 documenta los tipos de medios de comunicación que apoyan los sistemas e implementan sus interfaces como se describe en SV-1. Así, SV-2 muestra los detalles de comunicaciones de 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 interfaz descritas en SV-1 para la arquitectura, dispuestas en forma de matriz.

SV-4a/SV-4b Sistemas/Servicios Funcionalidad Descripción

El sistema SV-4a documenta las jerarquías funcionales y las funciones del sistema, y los datos del sistema fluyen entre ellas. El SV-4 de DoDAF v1.0 es designado como 'SV-4a' en DoDAF v1.5. Aunque hay una correlación entre las jerarquías OV-5 o de procesamiento de negocios y la jerarquía funcional del sistema de SV-4a, no necesita ser un mapeo de uno a uno, por lo tanto, la necesidad de la matriz de trazabilidad de la función operativa a los sistemas (SV-5a), que proporciona esa asignación.

SV-5a, SV-5b, SV-5c Actividad Operacional a la Función de Sistemas, Actividad Operacional a los Sistemas y Servicios

Actividad Operacional a SV-5a y SV-5b es una especificación de las relaciones entre el conjunto de actividades operacionales aplicables a una arquitectura y el conjunto de funciones del sistema aplicables a esa arquitectura. El SV-5 y la extensión al SV-5 de DoDAF v1.0 se designa como 'SV-5a' y 'SV-5b' en DoDAF v1.5 respectivamente.

SV-6 Sistemas/Servicios Matriz de intercambio de datos

Especifica las características de los datos del sistema intercambiados entre sistemas. Este producto se centra en intercambios de información automatizados (de OV-3) que se implementan en sistemas. Los intercambios de información no automatizados, como órdenes verbales, se capturan únicamente en los productos OV.

SV-7 Systems/Services Performance Parameters Matrix

Especifica las características cuantitativas de los sistemas y los elementos hardware/software del sistema, sus interfaces (datos del sistema llevados por la interfaz, así como datos de 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 de rendimiento técnico de los sistemas para los cuales se pueden desarrollar requisitos y definir la especificación. El conjunto completo de parámetros de rendimiento puede no ser conocido en las primeras etapas de la definición de arquitectura, por lo que se debe esperar que este producto se actualice a través de las fases de especificación, diseño, desarrollo, pruebas, y posiblemente incluso su despliegue y operaciones de ciclo de vida.

SV-8 Sistemas/Servicios Evolución Descripción

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

SV-9 Systems/Services Technology Forecast

Define las tecnologías de apoyo actuales y esperadas subyacentes que se han centrado en métodos de pronóstico estándar. Las tecnologías de apoyo esperadas son aquellas que pueden predecirse 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 del SV-8.

Modelo SV-10a Sistemas/Reglas de Servicios

Describe las reglas bajo las cuales la arquitectura o sus sistemas se comportan bajo condiciones especificadas.

SV-10b Systems/Services State Transition Descripción

Un método gráfico para describir una respuesta del sistema (o función del sistema) a diversos eventos cambiando su estado. El diagrama representa básicamente los conjuntos de eventos a los que los sistemas de la arquitectura responderán (actuando para pasar a un nuevo estado) como una función de su estado actual. Cada transición especifica un evento y una acción.

SV-10c Systems/Services Event-Trace Descripción

Proporciona un examen ordenado por tiempo de los elementos de datos del sistema intercambiados entre los sistemas participantes (externo e interno), las funciones del sistema o las funciones humanas como resultado de un escenario determinado. Cada diagrama de evento-trace debe tener una descripción adjunta que define el escenario o situación particular. SV-10c en la Vista de Sistemas y Servicios puede reflejar aspectos específicos del sistema o refinaciones de secuencias críticas de eventos descritos en la Vista Operacional.

SV-11 Esquema Física

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

Vista de normas técnicas

Los productos de vista de estándares técnicos (TV) definen estándares técnicos, convenciones de implementación, reglas comerciales y criterios que gobiernan la arquitectura. Los productos de TV DoDAF V1.5 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.)
• StdV-2 Technical Standards Forecast - Descripción de estándares emergentes que se espera aplicar a la arquitectura dada, dentro de un conjunto adecuado de plazos. (En DoDAF V1.5. Renombrado a StdV-2 en DoDAF V2.0.)

Versión 2.0 puntos de vista

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

All Viewpoint (AV)

Describe los aspectos generales del contexto de arquitectura que se relacionan con todos los puntos de vista.

Punto de vista de la capacidad (VC)

Nuevo en DoDAF V2.0. Articula los requisitos de capacidad, el calendario de entrega y la capacidad de despliegue.

Data and Information Viewpoint (DIV)

Nuevo en DoDAF V2.0. Articula las relaciones de datos y las estructuras de alineación en el contenido de arquitectura para la capacidad y necesidades operacionales, procesos de ingeniería del sistema y sistemas y servicios.

Punto de vista operacional (OV)

Incluye los escenarios operacionales, las actividades y las necesidades que apoyan la capacidad.

Project Viewpoint (PV)

Nuevo en DoDAF V2.0. Describe las relaciones entre las necesidades operacionales y de capacidad y los diversos proyectos que se están ejecutando. The Project Viewpoint also details dependencies among capacity and operational requirements, system engineering processes, systems design, and services design within the Defense Acquisition System process.

Punto de vista de servicios (SvcV)

Nuevo en DoDAF V2.0. Presenta el diseño de soluciones que articulan a los desarrolladores, actividades, servicios y sus intercambios, proporcionando o apoyando funciones operacionales y de capacidad.

Punto de vista estándar (StdV)

Renombrado de Vista de Normas Técnicas. Diseña las políticas, normas, orientaciones, limitaciones y previsiones operacionales, empresariales, técnicas e industriales aplicables que se aplican a las necesidades de capacidad y operacionales, los procesos de ingeniería de sistemas y los sistemas y servicios.

Punto de vista de sistemas (SV)

Articula, para apoyo legado, el diseño de soluciones que articulan los sistemas, su composición, interconectividad y contexto que proporcionan o apoyan funciones operacionales y de capacidad. Nota, Sistema ha cambiado en DoDAF V2.0 de DoDAF V1.5: El sistema no es sólo hardware informático y software informático. El sistema se define ahora en el sentido general de un conjunto de componentes - máquina, humano - que realizan actividades (ya que son subtipos de Performer) y están interactuando o interdependiendo. Esto podría ser cualquier cosa, es decir, cualquier cosa de piezas pequeñas de equipo que tengan elementos de interacción o interdependientes, a la Familia de Sistemas (FoS) y Sistema de Sistemas (SoS). Tenga en cuenta que los sistemas están compuestos por Materiel (por ejemplo, equipo, aeronaves y buques) y Tipos de Personal.

Las arquitecturas para DoDAF V1.0 y DoDAF V1.5 pueden seguir utilizándose. Cuando sea apropiado (generalmente indicado por la política o por quien toma las 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 de concepto (como Nodo) para la arquitectura más nueva. En cuanto a los productos DoDAF V1.5, se han transformado en piezas 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. Nodo es un concepto lógico complejo que se representa con conceptos más concretos.

Todos los puntos de vista (AV)

AV-1 Información general y resumida

Describe las Visiones, Objetivos, Objetivos, Planes, Actividades, Eventos, Condiciones, Medidas, Efectos (Outcomes), y los objetos producidos.

Diccionario integrado AV-2

Un repositorio de datos arquitectónico con definiciones de todos los términos utilizados a lo largo de todo

Punto de vista de la capacidad (CV)

CV-1 Visión

Aborda las preocupaciones de la empresa relacionadas con la visión general de los esfuerzos transformadores y define así 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 Arquitectura.

CV-2 Capability Taxonomy

Captura taxonomías de capacidad. El modelo presenta una jerarquía de capacidades. Estas capacidades pueden presentarse en el contexto de un cronograma. El CV-2 especifica todas las capacidades que se refieren a través de una o más arquitecturas.

CAPACIDAD CV-3

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

Dependencias de Capacidad CV-4

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

CV-5 Capacidad para el desarrollo organizacional

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

CV-6 Capacidad para las actividades operacionales

Una cartografía entre las capacidades necesarias y las actividades operacionales que esas capacidades apoyan.

CV-7 Capacidad para el cultivo de servicios

Una asignación entre las capacidades y los servicios que estas capacidades permiten.

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

Conceptual Modelo de datos

Los conceptos necesarios de datos de alto nivel y sus relaciones.

DIV-2 Logística Modelo de datos

La documentación de los requisitos de datos y las reglas del proceso estructural (actividad). En DoDAF V1.5, éste era el OV-7.

DIV-3 Física Modelo de datos

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

Nota: consulte Modelo de datos lógicos para conocer la relación de estos tres modelos de datos DIV, con una comparación de los modelos conceptual, lógico y de datos. Modelos de datos físicos.

Punto de vista operativo (OV)

Gráfico OV-1 Concepto operativo de alto nivel

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

OV-2 Flujo de recursos operacionales

A description of the Resource Flows exchanged between operational activities.

OV-3 Matriz de flujo de recursos operacionales

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

OV-4 Relaciones de organización Chart

El contexto organizativo, el papel u otras relaciones entre las organizaciones.

OV-5a Árbol de Descomposición de Actividad Operacional

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

Modelo de actividad operacional OV-5b

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

Modelo de normas operacionales OV-6a

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

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

Uno de los tres modelos utilizados para describir la actividad operacional (actividad). Se identifican las respuestas del proceso empresarial (actividad) a los eventos (generalmente, actividades muy cortas).

OV-6c Event-Trace Descripción

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

Punto de vista del proyecto (PV)

PV-1 Project Portfolio Relationships

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

PV-2 Timelines Project

Una perspectiva de tiempo en programas o proyectos, con los hitos y interdependencias clave.

PV-3 Project to Capability Mapping

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

Punto de vista de servicios (SvcV)

SvcV-1 Servicios Context Descripción

La identificación de servicios, artículos de servicio y sus interconexiones.

SvcV-2 Servicios Recursos Flujo Descripción

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

Matriz SvcV-3a Systems-Services

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

SvcV-3b Servicios-Servicios Matriz

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

SvcV-4 Servicios Funcionalidad Descripción

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

SvcV-5 Actividad Operacional a los Servicios Matriz de Trazabilidad

A mapping of services (activities) back to operational activities (activities).

SvcV-6 Servicios Soporte de flujo de recursos

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

Matriz de medidas de servicios SvcV-7

Las medidas (métricas) de los Servicios Modelo de elementos para el marco de tiempo apropiado.

SvcV-8 Servicios Evolution Descripción

Los pasos incrementales previstos para migrar una serie de servicios a una suite más eficiente o para evolucionar los servicios actuales a una futura implementación.

SvcV-9 Servicios Tecnología " Previsión de habilidades

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

Modelo de normas de servicios SvcV-10a

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

SvcV-10b Servicios Transition Estatal Descripción

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

Servicios SvcV-10c Event-Trace Descripción

Uno de los tres modelos utilizados para describir la funcionalidad de servicio. Se identifican refinaciones específicas de servicios de secuencias críticas de eventos descritos en el punto de vista operacional.

Punto de vista de estándares (StdV)

Estándares StdV-1 Perfil

La lista de normas que se aplican a los elementos de solución. En DoDAF V1.5, éste era el TV-1.

StdV-2 Standards Forecast

La descripción de las nuevas normas y los posibles efectos en los elementos de solución actuales, dentro de un conjunto de plazos. En DoDAF V1.5, éste era el TV-2.

Punto de vista de sistemas (SV)

SV-1 interfaz de sistemas Descripción

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

SV-2 Sistemas de flujo de recursos Descripción

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 tipo sistema, interfaces planificadas vs. interfaces existentes).

Función de los sistemas SV-4 Descripción

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

SV-5a Actividad Operacional a la matriz de trazabilidad de la función de sistemas

Una asignación de funciones (actividades) del sistema a las actividades operacionales (actividades).

SV-5b Actividad Operacional para la Matriz de Trazabilidad de Sistemas

Una cartografía de los sistemas de regreso a las capacidades o actividades operacionales (actividades).

Matriz de flujo de recursos SV-6

Proporciona detalles sobre los elementos de flujo de recursos del sistema intercambiados entre sistemas y los atributos de ese intercambio.

Matriz de medidas de sistemas SV-7

Las medidas (métricas) de los elementos modelo de sistemas para el marco de tiempo apropiado.

SV-8 Sistemas Evolución Descripción

Los pasos incrementales previstos para migrar un conjunto de sistemas a una suite más eficiente, o para evolucionar un sistema actual a una futura implementación.

SV-9 Tecnología de sistemas " Previsión de habilidades

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

Modelo de Reglas de Sistemas SV-10a

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

SV-10b Sistemas Estatal de Transición Descripción

Uno de los tres modelos utilizados para describir la funcionalidad del sistema. Identifica respuestas de sistemas a eventos.

SV-10c Systems Event-Trace Descripción

Uno de los tres modelos utilizados para describir la funcionalidad del sistema. Se identifican las mejoras específicas del sistema de secuencias críticas de los acontecimientos descritos en el punto de vista operacional.

Creando una arquitectura integrada usando DoDAF

La Guía de Arquitectos DODAF 2.0 repitió la definición de la Instrucción 4630.8 del DOD de una arquitectura integrada como "Una arquitectura que consta de múltiples vistas que facilitan la integración y promueven la interoperabilidad entre capacidades y entre arquitecturas integradas". A los efectos del desarrollo de la arquitectura, El término integrado significa que los datos requeridos en más de uno de los modelos arquitectónicos se definen y entienden comúnmente en todos esos modelos. Las arquitecturas integradas son una propiedad o principio de diseño para arquitecturas en todos los niveles: capacidad, componente, solución y empresa (en el contexto de que DoD Enterprise Architecture (EA) es una federación [de] arquitecturas). En términos más simples, la integración se ve en la conexión de elementos comunes entre productos de arquitectura, donde los elementos que se muestran en un producto de arquitectura (como sitios utilizados o sistemas interconectados o servicios proporcionados) deben tener el mismo número, nombre y significado que aparecen en la arquitectura relacionada. vistas del producto."

Existen muchos enfoques diferentes para crear una arquitectura integrada utilizando DoDAF y para determinar qué productos se requieren. El enfoque depende de los requisitos y de los resultados esperados; es decir, para qué se utilizará la arquitectura resultante. Como ejemplo, DoDAF v1.0 enumeró los siguientes productos como el "conjunto mínimo de productos necesarios para satisfacer la definición de OV, SV y TV". Una nota: si bien el DoDAF no incluye el artefacto OV-1 como producto principal, se recomienda encarecidamente su desarrollo. La secuencia de los artefactos que se enumeran a continuación ofrece un orden sugerido en el que se podrían desarrollar los artefactos. La secuencia real de generación de vistas y su posible personalización es función del dominio de la aplicación y de las necesidades específicas del esfuerzo.

• AV-1: Información general y resumida
• AV-2: Diccionario integrado
• OV-1: Gráfico de Concepto Operativo de Alto Nivel
• OV-5: Modelo de actividad operacional
• OV-2: Conectividad Nodo Operacional Descripción
• OV-3: Matriz de intercambio de información operacional
• SV-1: Interfaz del sistema Descripción
• TV-1: Perfil de normas técnicas

Una de las preocupaciones sobre el DoDAF es qué tan bien estos productos satisfacen las preocupaciones reales de las partes interesadas para cualquier sistema de interés determinado. Se pueden ver los productos DoDAF, o al menos las 3 vistas, como ANSI/IEEE 1471-2000 o ISO/IEC 42010 puntos de vista. Pero para crear una descripción de arquitectura que corresponda a ANSI/IEEE 1471-2000 o ISO/IEC 42010, es necesario identificar claramente a las partes interesadas y sus preocupaciones que se corresponden con cada producto DoDAF seleccionado. De lo contrario existe el riesgo de producir productos sin clientes.

La figura "Matriz de productos DoDAF V1.5" muestra cómo el Presidente del Departamento de Defensa de la Instrucción del Estado Mayor Conjunto (CJCSI) 6212.01E especifica qué productos DoDAF V1.5 son necesarios para cada tipo de análisis, en el contexto del parámetro clave de rendimiento Net-Ready (NR-KPP):

• Documento de Capacidades Iniciales (ICD). Documenta la necesidad de una solución de material a una brecha de capacidad específica derivada de un análisis inicial de las alternativas ejecutadas por el usuario operacional y, según sea necesario, un análisis independiente de las alternativas. Define la brecha de capacidad en cuanto a la zona funcional, la gama pertinente de operaciones militares, los efectos deseados y el tiempo.
• Documento de Desarrollo de la Capacidad (CDD). Un documento que captura la información necesaria para desarrollar un programa(s) propuesto, normalmente utilizando una estrategia de adquisición evolutiva. El CDD describe un aumento asequible de la capacidad militarmente útil, logísticamente compatible y técnicamente madura.
• Capability Production Document (CPD). Un documento que aborda los elementos de producción específicos a un solo incremento de un programa de adquisición.
• Plan de Apoyo a la Información (ISP). La identificación y documentación de las necesidades de información, el apoyo a las infraestructuras, los requisitos de interfaz de TI y NSS y las dependencias que se centran en cuestiones de importancia neta, interoperabilidad, apoyo y suficiencia (DODI 4630.8).
• Plan de Apoyo a la Información (TISP). El objetivo del proceso TISP es proporcionar un vehículo dinámico y eficiente para ciertos programas (ACAT II y abajo) para producir los requisitos necesarios para la certificación I implicaS. Select program managers may request to tailor the content of their ISP (ref ss). Para los programas no designados interés especial de la OSD por ASD (NII)/DOD CIO, el componente tomará una decisión final sobre los detalles del plan ajustado sujeto a los mínimos especificados en los procedimientos TISP vinculados a la página de recursos CJCSI 6212 y cualquier necesidad especial identificada por el J-6 para el proceso de certificación I divideS.

Representación

Las representaciones de los productos DoDAF se pueden extraer a partir de muchas técnicas de diagramación, entre ellas:

• Cuadros
• IDEF
• Diagramas de relación-entidad (ERDs)
• UML
• SysML

Existe un esfuerzo UPDM (Perfil Unificado para DoDAF y MODAF) dentro de OMG para estandarizar la representación de los productos DoDAF cuando se utiliza UML.

DoDAF describe genéricamente la representación de los artefactos a generar, pero permite una flexibilidad considerable con respecto a los formatos y técnicas de modelado específicos. El libro de escritorio de DoDAF proporciona ejemplos del uso de técnicas tradicionales de ingeniería de sistemas e ingeniería de datos y, en segundo lugar, el formato UML. DoDAF proclama libertad en el formato del producto de trabajo, sin preferir una técnica de diagramación sobre otra.

Además de la representación gráfica, normalmente existe el requisito de proporcionar metadatos al Repositorio de cartera de tecnología de la información de defensa (DITPR) u otros repositorios arquitectónicos.

Metamodelo

DoDAF tiene un metamodelo que sustenta el marco, 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 utilizaron el metamodelo CADM, que se definió en IDEF1X (luego en UML) con un esquema XML derivado de la base de datos relacional resultante. Desde la versión 2.0, DoDAF ha adoptado la ontología fundamental del Grupo IDEAS como base para su nuevo metamodelo. Este nuevo metamodelo se llama "DM2"; acrónimo de "Metamodelo DoDAF". Cada uno de estos tres niveles del DM2 es importante para un espectador particular de los procesos departamentales:

1. El nivel conceptual o Modelo de Datos Conceptuales (CDM) define los constructos de datos de alto nivel de los cuales se crean descripciones arquitectónicas en términos no técnicos, de modo que los ejecutivos y administradores de todos los niveles puedan entender la base de datos de la Descripción Arquitectónica. Representado en el punto de vista DoDAF V2.0 DIV-1.
2. El modelo de datos lógicos agrega información técnica, como atributos al MDL y, cuando sea necesario, aclara las relaciones en una definición de uso inequívoca. Representado en el punto de vista DoDAF V2.0 DIV-2.
3. La especificación de intercambio físico (PES) consiste en el LDM con tipos de datos generales especificados y atributos de implementación (por ejemplo, fuente, fecha) añadidos, y luego generados como XSD. Representado en el punto de vista DoDAF V2.0 DIV-3.

Los propósitos del DM2 son:

1. Establecer y definir el vocabulario limitado para la descripción y el discurso sobre los modelos DoDAF (antes “productos”) y su uso en los 6 procesos básicos
2. Especifique la semántica y el formato para el intercambio federado de datos EA entre:architecture development and analysis tools and architecture databases across the DoD Enterprise Architecture (EA) Community of Interest (COI) y con otras fuentes de datos autorizadas
3. Apoyar el descubrimiento y la comprensión de los datos de EA:
   1. Discovery of EA data using DM2 categories of information
   2. Comprensión de los datos de EA utilizando la semántica precisa de DM2 aumentada con trazabilidad lingüística (aliases)
4. Proporcionar una base para la precisión semántica en descripciones arquitectónicas para apoyar la integración y análisis de la descripción arquitectónica heterogénea en apoyo de la toma de decisiones de procesos básicos.

DM2 define 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 entre las descripciones arquitectónicas. De esta manera, DM2 apoya el intercambio y la reutilización de información arquitectónica entre JCA, componentes y socios federales y de la coalición, facilitando así la comprensión y la implementación de la interoperabilidad de procesos y sistemas. A medida que DM2 madure para cumplir con los requisitos de datos continuos de los propietarios de procesos, tomadores de decisiones, arquitectos y nuevas tecnologías, evolucionará hasta convertirse en un recurso que admita de manera más completa los requisitos de datos arquitectónicos, publicados de manera consistente y comprensible, y permitirá una mayor Facilidad para descubrir, compartir y reutilizar datos arquitectónicos a través de los límites organizacionales.

Para facilitar el uso de la información en la capa de datos, el DoDAF describe un conjunto de modelos para visualizar datos a través de medios gráficos, tabulares o textuales. Estos puntos de vista se relacionan con los requisitos de las partes interesadas para producir una descripción arquitectónica.

Relación con otros marcos de arquitectura

UPDM (Perfil Unificado para DoDAF y MODAF) es una iniciativa de OMG para estandarizar el uso de UML y SysML para marcos de arquitectura de defensa de EE. UU. y Reino Unido. Además, el grupo multinacional IDEAS, que cuenta con el apoyo de Australia, Canadá, Suecia, el Reino Unido y los EE. UU., con observadores de la OTAN, ha lanzado una iniciativa para desarrollar una ontología formal para arquitecturas empresariales.