1285:
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.
497:
interface, or system function, and the expected or required performance parameters at specified times in the future. Performance parameters include all technical performance characteristics of systems for which requirements can be developed and specification defined. The complete set of performance parameters may not be known at the early stages of architecture definition, so it should be expected that this product will be updated throughout the system’s specification, design, development, testing, and possibly even its deployment and operations life-cycle phases.
254:
39:
383:(OV) products provide descriptions of the tasks and activities, operational elements, and information exchanges required to accomplish DoD missions. The OV provides textual and graphical representations of operational nodes and elements, assigned tasks and activities, and information flows between nodes. It defines the type of information exchanged, the frequency of exchanges, the tasks and activities supported by these exchanges and the nature of the exchanges. The DoDAF V1.5 OV products are defined as:
1069:
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.
1064:
Capability,Component, Solution, and
Enterprise (in the context of the DoD Enterprise Architecture (EA) being a federation 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."
310:
31:
1053:
583:
575:
1117:
591:
318:
665:
concept differences (such as Node) must be defined or explained for the newer architecture. In regard to DoDAF V1.5 products, they have been transformed into parts of the DoDAF V2.0 models. In most cases, the DoDAF V2.0 Meta-model supports the DoDAF V1.5 data concepts, with one notable exception: Node. Node is a complex, logical concept that is represented with more concrete concepts.
195:. It addressed the 1995 Deputy Secretary of Defense directive that a DoD-wide effort be undertaken to define and develop a better means and process for ensuring that C4ISR capabilities were interoperable and met the needs of the warfighter. Continued development effort resulted in December 1997 in the second version, C4ISR Architecture Framework v2.0.
176:
127:
information technology system acquisitions are required to develop and document an enterprise architecture (EA) using the views prescribed in the DoDAF. While it is clearly aimed at military systems, DoDAF has broad applicability across the private, public and voluntary sectors around the world, and represents one of a large number of systems
1068:
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
462:
Depicts pertinent information about communications systems, communications links, and communications networks. SV-2 documents the kinds of communications media that support the systems and implements their interfaces as described in SV-1. Thus, SV-2 shows the communications details of SV-1 interfaces
261:
The DoD has moved toward a focus on the delivery of capabilities, which are the reason for creating the system/service. The
Capability Models describe capability taxonomy and capability evolution. A capability thread would equate to the specific activities, rules, and systems that are linked to that
203:
v1.01, and moved towards a repository-based approach by placing emphasis on architecture data elements that comprise architecture products. In
February 2004 the documentation of Version 1.0 was released with volume "I: Definitions and Guidelines", "II: Product Descriptions" and a "Deskbook". In April
1245:
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
710:
The planned achievement of capability at different points in time or during specific periods of time. The CV-3 shows the capability phasing in terms of the activities, conditions, desired effects, rules complied with, resource consumption and production, and measures, without regard to the performer
198:
In August 2003 the DoDAF v1.0 was released, which restructured the C4ISR Framework v2.0 to offer guidance, product descriptions, and supplementary information in two volumes and a Desk Book. It broadened the applicability of architecture tenets and practices to all
Mission Areas rather than just the
631:
New in DoDAF V2.0. Describes the relationships between operational and capability requirements and the various projects being implemented. The
Project Viewpoint also details dependencies among capability and operational requirements, system engineering processes, systems design, and services design
523:
A graphical method of describing a system (or system function) response to various events by changing its state. The diagram basically represents the sets of events to which the systems in the architecture will respond (by taking an action to move to a new state) as a function of its current state.
510:
Defines the underlying current and expected supporting technologies that have been targeted using standard forecasting methods. Expected supporting technologies are those that can be reasonably forecast given the current state of technology and expected improvements. New technologies should be tied
496:
Specifies the quantitative characteristics of systems and system hardware/software items, their interfaces (system data carried by the interface as well as communications link details that implement the interface), and their functions. It specifies the current performance parameters of each system,
475:
The SV-4a documents system functional hierarchies and system functions, and the system data flows between them. The SV-4 from DoDAF v1.0 is designated as 'SV-4a' in DoDAF v1.5. Although there is a correlation between OV-5 or business-process hierarchies and the system functional hierarchy of SV-4a,
126:
DoD Components are expected to conform to DoDAF to the maximum extent possible in development of architectures within the department. Conformance ensures that reuse of information, architecture artifacts, models, and viewpoints can be shared with common understanding. All major U.S. DoD weapons and
241:
2.0 and the DoD Architecture
Registry System (DARS). A key feature of DoDAF is interoperability, which is organized as a series of levels, called Levels of Information System Interoperability (LISI). The developing system must not only meet its internal data needs but also those of the operational
1144:
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
659:
has changed in DoDAF V2.0 from DoDAF V1.5: System is not just computer hardware and computer software. System is now defined in the general sense of an assemblage of components - machine, human - that perform activities (since they are subtypes of
Performer) and are interacting or interdependent.
349:
Each view depicts certain perspectives of an architecture as described below. Only a subset of the full DoDAF viewset is usually created for each system development. The figure represents the information that links the operational view, systems and services view, and technical standards view. The
482:
Operational Activity to SV-5a and SV-5b is a specification of the relationships between the set of operational activities applicable to an architecture and the set of system functions applicable to that architecture. The SV-5 and extension to the SV-5 from DoDAF v1.0 is designated as 'SV-5a' and
1129:
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
447:
Systems and services view (SV) is a set of graphical and textual products that describe systems and services and interconnections providing for, or supporting, DoD functions. SV products focus on specific physical systems with specific physical (geographical) locations. The relationship between
118:
The DoDAF provides a foundational framework for developing and representing architecture descriptions that ensure a common denominator for understanding, comparing, and integrating architectures across organizational, joint, and multinational boundaries. It establishes data element definitions,
664:
The architectures for DoDAF V1.0 and DoDAF V1.5 may continue to be used. When appropriate (usually indicated by policy or by the decision-maker), DoDAF V1.0 and V1.5 architectures will need to update their architecture. When pre-DoDAF V2.0 architecture is compared with DoDAF V2.0 architecture,
1284:
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
216:) to resolve a mission deficiency or to enhance operational capability. This type of document has been superseded by the description of capability needs called an Initial Capabilities Document, as of CJCSI 3170.01E. The CJCSI 3170.01 and 6212.01 were superseded by the CJCSI 5123.01 Series.
109:
This Architecture Framework is especially suited to large systems with complex integration and interoperability challenges, and it is apparently unique in its employment of "operational views". These views offer overview and details aimed to specific stakeholders within their domain and in
1133:
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
1063:
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:
1113:. 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.
660:
This could be anything, i.e., anything from small pieces of equipment that have interacting or interdependent elements, to Family of Systems (FoS) and System of Systems (SoS). Note that Systems are made up of Materiel (e.g., equipment, aircraft, and vessels) and Personnel Types.
696:
Addresses the enterprise concerns associated with the overall vision for transformational endeavours and thus defines the strategic context for a group of capabilities. The purpose of the CV-1 is to provide a strategic context for the capabilities described in the Architecture
598:
In DoDAF V2.0, architectural viewpoints are composed of data that has been organized to facilitate understanding. To align with ISO Standards, where appropriate, the terminology has changed from Views to Viewpoint (e.g., the Operational View is now the Operational Viewpoint).
350:
three views and their interrelationships – driven by common architecture data elements – provide the basis for deriving measures such as interoperability or performance, and for measuring the impact of the values of these metrics on operational mission and task effectiveness.
204:
2007 the Version 1.5 was released with a documentation of "Definitions and Guidelines", "Product Descriptions" and "Architecture Data Description". This period further developed the concepts and terms that have since been replaced with different approaches. For example, a
644:
Renamed from Technical Standards View. Articulates the applicable operational, business, technical, and industry policies, standards, guidance, constraints, and forecasts that apply to capability and operational requirements, system engineering processes, and systems and
1124:
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):
489:
Specifies the characteristics of the system data exchanged between systems. This product focuses on automated information exchanges (from OV-3) that are implemented in systems. Non-automated information exchanges, such as verbal orders, are captured in the OV products
542:
One of the architecture products closest to actual system design in the Framework. The product defines the structure of the various kinds of system data that are utilized by the systems in the architecture. (In DoDAF V1.5. This corresponds to DIV-3 in DoDAF
1149:/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.
1140:
Information Support Plan (ISP). 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
1060:
The DODAF 2.0 Architects Guide 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
1265:
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
1288:
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.
503:
Captures evolution plans that describe how the system, or the architecture in which the system is embedded, will evolve over a lengthy period of time. Generally, the timeline milestones are critical for a successful understanding of the evolution
723:
The fulfillment of capability requirements shows the planned capability deployment and interconnection for a particular Capability Phase. The CV-5 shows the planned solution for the phase in terms of performers and locations and their associated
535:
should have an accompanying description that defines the particular scenario or situation. SV-10c in the Systems and Services View may reflect system-specific aspects or refinements of critical sequences of events described in the Operational
1200:
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
199:
C4ISR community. This document addressed usage, integrated architectures, DoD and Federal policies, value of architectures, architecture measures, DoD decision support processes, development techniques, analytical techniques, and the
1240:
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:
703:
Captures capability taxonomies. The model presents a hierarchy of capabilities. These capabilities may be presented in the context of a timeline. The CV-2 specifies all the capabilities that are referenced throughout one or more
329:, that act as mechanisms for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through graphic, tabular, or textual means. These products are organized under four views:
1253:
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
1845:
455:
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 also identifies the interfaces between systems and systems
1249:
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
119:
rules, and relationships and a baseline set of products for consistent development of systems, integrated, or federated architectures. These architecture descriptions may include families of systems (FoS),
530:
Provides a time-ordered examination of the system data elements exchanged between participating systems (external and internal), system functions, or human roles as a result of a particular scenario. Each
811:
The context of capabilities and activities (operational activities) and their relationships among activities, inputs, and outputs; Additional data can show cost, performers or other pertinent information.
618:
New in DoDAF V2.0. Articulates the data relationships and alignment structures in the architecture content for the capability and operational requirements, system engineering processes, and systems and
552:
Technical standards view (TV) products define technical standards, implementation conventions, business rules and criteria that govern the architecture. The DoDAF V1.5 TV products are as follows:
1224:
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
164:
Increase utility and effectiveness of architectures via a rigorous data model – the DoDAF Meta Model (DM2) -- so the architectures can be integrated, analyzed, and evaluated with more precision.
885:
The relationships among services in a given Architectural Description. It can be designed to show relationships of interest, (e.g., service-type interfaces, planned vs. existing interfaces).
638:
New in DoDAF V2.0. Presents the design for solutions articulating the Performers, Activities, Services, and their Exchanges, providing for or supporting operational and capability functions.
1280:
Provide a basis for semantic precision in architectural descriptions to support heterogeneous architectural description integration and analysis in support of core process decision making.
983:
The relationships among systems in a given Architectural Description. It can be designed to show relationships of interest, (e.g., system-type interfaces, planned vs. existing interfaces).
448:
architecture data elements across the SV to the OV can be exemplified as systems are procured and fielded to support organizations and their operations. The DoDAF V1.5 SV products are:
927:
One of three models used to describe service functionality. It identifies constraints that are imposed on systems functionality due to some aspect of system design or implementation.
1031:
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.
565:- Description of emerging standards that are expected to apply to the given architecture, within an appropriate set of timeframes. (In DoDAF V1.5. Renamed to StdV-2 in DoDAF V2.0.)
358:
All view (AV) products provide overarching descriptions of the entire architecture and define the scope and context of the architecture. The DoDAF V1.5 AV products are defined as:
921:
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 service development.
1025:
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.
655:, the design for solutions articulating the systems, their composition, interconnectivity, and context providing for or supporting operational and capability functions. Note,
939:
One of three models used to describe service functionality. It identifies service-specific refinements of critical sequences of events described in the Operational Viewpoint.
1043:
One of three models used to describe system functionality. It identifies system-specific refinements of critical sequences of events described in the Operational Viewpoint.
1615:
1823:
191:, which was initiated in 1986, was further developed. The first C4ISR Architecture Framework v1.0, released 7 June 1996, was created in response to the passage of the
1662:
Dodaf Wizdom: a Practical Guide to Planning, Managing and Executing Projects to Build Enterprise Architectures using the Department of Defense Architecture Framework
823:
One of three models used to describe operational activity (activity). It identifies business process (activity) responses to events (usually, very short activities).
761:
The physical implementation format of the Logical Data Model entities, e.g., message formats, file structures, physical schema. In DoDAF V1.5, this was the SV-11.
476:
it need not be a one-to-one mapping, hence, the need for the Operational Activity to Systems Function Traceability Matrix (SV-5a), which provides that mapping.
438:
Documentation of the data requirements and structural business process rules of the Operational View. (In DoDAF V1.5. This corresponds to DIV-2 in DoDAF V2.0.)
1262:
Establish and define the constrained vocabulary for description and discourse about DoDAF models (formerly “products”) and their usage in the 6 core processes
402:
Information exchanged between nodes and the relevant attributes of that exchange such as media, quality, quantity, and the level of interoperability required.
1019:
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.
915:
The planned incremental steps toward migrating a suite of services to a more efficient suite or toward evolving current services to a future implementation.
842:
It describes the dependency relationships between the organizations and projects and the organizational structures needed to manage a portfolio of projects.
219:
This term was introduced as a fundamental step in CJCSI 3170.01B (Apr 2001), 6212.01D (Apr 2005), and the Interim Defense Acquisition Guidebook (Oct 2004).
1850:
1640:
432:
One of the three products used to describe operational activity sequence and timing that traces the actions in a scenario or critical sequence of events.
958:
The description of emerging standards and potential impact on current solution elements, within a set of time frames. In DoDAF V1.5, this was the TV-2.
390:
High level graphical and textual description of operational concept (high level organizations, missions, geographic configuration, connectivity, etc.).
222:
On May 28, 2009, DoDAF v2.0 was approved by the Department of Defense. The current version is DoDAF 2.02 DoDAF V2.0 is published on a public website.
414:
Activities, relationships among activities, inputs and outputs. In addition, overlays can show cost, performing nodes, or other pertinent information.
1714:
420:
One of the three products used to describe operational activity sequence and timing that identifies the business rules that constrain the operation.
1209:
techniques, and secondly, UML format. DoDAF proclaims latitude in work product format, without professing one diagramming technique over another.
300:
Architectures are organized by mission areas. Architectures provide proper resourcing of capabilities required by the Mission or Course of Action.
1788:
1137:
Capability Production Document (CPD). A document that addresses the production elements specific to a single increment of an acquisition program.
250:
See the diagram for a depiction of the Capabilities Emphasis, as tied in with mission/course of action, threads, activities, and architectures.
1720:
426:
One of the three products used to describe operational activity sequence and timing that identifies responses of a business process to events.
677:
Describes a Project's Visions, Goals, Objectives, Plans, Activities, Events, Conditions, Measures, Effects (Outcomes), and produced objects.
1762:
1305:) is an OMG initiative to standardize UML and SysML usage for USA and UK defense architecture frameworks. In addition, the multi-national
769:
for discussion of the relationship of these three DIV data models, with comparison of the Conceptual, Logical & Physical Data Models.
1726:
1708:
59:
854:
A mapping of programs and projects to capabilities to show how the specific projects and program elements help to achieve a capability.
1206:
237:(TOGAF), DoDAF is organized around a shared repository to hold work products. The repository is defined by the common database schema
1779:
1684:
1669:
1580:
67:
479:
SV-5a, SV-5b, SV-5c Operational Activity to Systems Function, Operational Activity to Systems and Services Traceability Matrices
1322:
1619:
755:
The documentation of the data requirements and structural business process (activity) rules. In DoDAF V1.5, this was the OV-7.
817:
One of three models used to describe activity (operational activity). It identifies business rules that constrain operations.
83:
829:
One of three models used to describe activity (operational activity). It traces actions in a scenario or sequence of events.
62:(DoD) that provides visualization infrastructure for specific stakeholders concerns through viewpoints organized by various
903:
It provides details of service Resource Flow elements being exchanged between services and the attributes of that exchange.
1804:
70:
for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through
1855:
238:
1677:
DoD Architecture Framework 2.0: A Guide to Applying Systems Engineering to Develop Integrated, Executable Architectures
1007:
Provides details of system resource flow elements being exchanged between systems and the attributes of that exchange.
226:
1602:
Procedures for Interoperability and Supportability of Information Technology (IT) and National Security Systems (NSS)
287:
The Mission or Course of Action is described by a Concept of Operations (CONOPS), and is organized by Capabilities.
1810:
559:- Extraction of standards that applies to the given architecture. (In DoDAF V1.5. Renamed to StdV-1 in DoDAF V2.0.)
209:
1178:
1172:
469:
provides detail on the interface characteristics described in SV-1 for the architecture, arranged in matrix form.
1830:
European Space Agency Architectural Framework (ESAAF) - a framework for European space-based Systems of Systems
253:
38:
1463:
989:
The functions (activities) performed by systems and the system data flows among system functions (activities).
612:
New in DoDAF V2.0. Articulates the capability requirements, the delivery timing, and the deployed capability.
1749:
1194:
396:
Operational nodes, activities performed at each node, and connectivities and information flow between nodes.
1743:
1275:
Understandability of EA data using DM2's precise semantics augmented with linguistic traceability (aliases)
730:
A mapping between the capabilities required and the operational activities that those capabilities support.
265:
The concept of capability, as defined by its Meta-model Data Group allows one to answer questions such as:
212:
type of document which identified capability needs for a program to satisfy by a combination of solutions (
1737:
1702:
1391:
933:
One of three models used to describe service functionality. It identifies responses of services to events.
128:
75:
55:
1378:
1216:
to the Defense Information Technology Portfolio Repository (DITPR) or other architectural repositories.
1037:
One of three models used to describe system functionality. It identifies responses of systems to events.
1815:
1785:
717:
The dependencies between planned capabilities and the definition of logical groupings of capabilities.
123:(SoS), and net-centric capabilities for interoperating and interacting in the non-combat environment.
1099:
1831:
1102:
concerns for any given system of interest. One can view DoDAF products, or at least the 3 views, as
891:
The functions performed by services and the service data flows among service functions (activities).
1202:
532:
79:
71:
517:
Describes the rules under which the architecture or its systems behave under specified conditions.
1657:
1313:
observers, has launched an initiative to develop a formal ontology for enterprise architectures.
766:
120:
1759:
1697:
1158:
Representations for the DoDAF products may be drawn from many diagramming techniques including:
511:
to specific time periods, which can correlate against the time periods used in SV-8 milestones.
1680:
1665:
1634:
1404:
848:
A timeline perspective on programs or projects, with the key milestones and interdependencies.
192:
1476:
1437:
879:
The relationships among or between systems and services in a given Architectural Description.
805:
The capabilities and activities (operational activities) organized in a hierarchal structure.
1772:
1513:
1338:
1233:
1162:
380:
336:
309:
297:
Activities are grouped into Mission Areas. Activities define operations for an Architecture.
278:
What is the functional scope and organizational span of a capability or set of capabilities?
272:
What outcomes are expected to be achieved by a particular capability or set of capabilities?
103:
30:
952:
The listing of standards that apply to solution elements. In DoDAF V1.5, this was the TV-1.
625:
Includes the operational scenarios, activities, and requirements that support capabilities.
1792:
1766:
135:
The purpose of DoDAF is to define concepts and models usable in DoD's six core processes:
99:
365:
Scope, purpose, intended users, environment depicted, analytical findings (if applicable)
1554:
1489:"DODAF - DOD Architecture Framework Version 2.02 - DOD Deputy Chief Information Officer"
1236:
derived from the resulting relational database. From version 2.0, DoDAF has adopted the
1052:
606:
Describes the overarching aspects of architecture context that relate to all viewpoints.
161:
Establish guidance for architecture content as a function of purpose – “fit for purpose”
1438:"CJCSM 3170.01C OPERATION OF THE JOINT CAPABILITIES INTEGRATION AND DEVELOPMENT SYSTEM"
995:
A mapping of system functions (activities) back to operational activities (activities).
582:
574:
1782:
Information resource dedicated to DoDAF as it relates to other architecture frameworks
1721:
Meta-model Ontology Foundation and Physical Exchange Specification – Developer’s Guide
1130:
functional area, the relevant range of military operations, desired effects, and time.
1116:
793:
A description of the resources exchanged and the relevant attributes of the exchanges.
590:
1839:
1212:
In addition to graphical representation, there is typically a requirement to provide
1107:
652:
183:
The first version of the development DoDAF was developed in the 1990s under the name
1594:
281:
What is our current set of capabilities that we are managing as part of a portfolio?
269:
How does a particular capability or capabilities support the overall mission/vision?
909:
The measures (metrics) of Services Model elements for the appropriate timeframe(s).
736:
A mapping between the capabilities and the services that these capabilities enable.
317:
1013:
The measures (metrics) of Systems Model elements for the appropriate timeframe(s).
1001:
A mapping of systems back to capabilities or operational activities (activities).
179:
Evolution of the DoDAF since the 1990s. The DoDAF V2.0 was released in May, 2009.
1328:
1306:
1237:
897:
A mapping of services (activities) back to operational activities (activities).
683:
An architectural data repository with definitions of all terms used throughout
326:
175:
63:
787:
A description of the Resource Flows exchanged between operational activities.
1146:
1103:
799:
The organizational context, role or other relationships among organizations.
408:
Command, control, coordination, and other relationships among organizations.
1442:
mandatory appendices for ICD, CDD, and CPD, e.g. pg E-A-5 "Mandatory: OV-1"
867:
The identification of services, service items, and their interconnections.
1501:
1488:
1213:
91:
1417:
971:
The identification of systems, system items, and their interconnections.
781:
The high-level graphical/textual description of the operational concept.
1797:
213:
184:
95:
1197:
to standardize the representation of DoDAF products when UML is used.
1229:
17:
1098:
One concern about the DoDAF is how well these products meet actual
294:
Threads are described by Activities executed in serial or parallel.
1302:
1183:
992:
SV-5a Operational Activity to Systems Function Traceability Matrix
589:
581:
573:
466:
SV-3 Systems-Systems, Services-Systems, Services-Services Matrices
316:
308:
252:
234:
230:
188:
174:
87:
37:
1309:, which is supported by Australia, Canada, Sweden, UK, USA, with
110:
interaction with other domains in which the system will operate.
1343:
1333:
1310:
1298:
1225:
1190:
1167:
200:
187:
Architecture Framework. In the same period the reference model
749:
The required high-level data concepts and their relationships.
894:
SvcV-5 Operational Activity to Services Traceability Matrix
873:
A description of Resource Flows exchanged between services.
463:
that automate aspects of the needlines represented in OV-2.
1846:
United States Department of Defense information technology
977:
A description of Resource Flows exchanged between systems.
1811:
Department of Defense Information Enterprise Architecture
1807:
on DoDAF 2.0 from Integrated EA Conferences 2008 and 2009
1145:
ss). For programs not designated OSD special interest by
998:
SV-5b Operational Activity to Systems Traceability Matrix
1272:
Discovery of EA data using DM2 categories of information
1193:(Unified Profile for DoDAF and MODAF) effort within the
586:
Evolution of DoDAF V1.5 Views to DoDAF V2.0 Viewpoints.
225:
Other derivative frameworks based on DoDAF include the
1535:
Evolution of DoDAF V1.5 Views to DoDAF V2.0 Viewpoints
472:
SV-4a/SV-4b Systems/Services Functionality Description
141:
Planning, Programming, Budgeting, and Execution (PPBE)
138:
Joint Capabilities Integration and Development (JCIDS)
1679:. CreateSpace Independent Publishing Platform, 2015.
1088:
OV-3 : Operational Informational Exchange Matrix
1085:
OV-2 : Operational Node Connectivity Description
720:
CV-5 Capability to Organizational Development Mapping
594:
Mapping of DoDAF V1.5 Views to DoDAF V2.0 Viewpoints.
1544:
Mapping of DoDAF V1.5 Views to DoDAF V2.0 Viewpoints
1269:
Support discovery and understandability of EA data:
520:
SV-10b Systems/Services State Transition Description
493:
SV-7 Systems/Services Performance Parameters Matrix
275:
What services are required to support a capability?
1079:OV-1 : High Level Operational Concept Graphic
1715:Architectural Data and Models – Architect’s Guide
1581:"Information Support Plan (DAU ACQuipedia entry)"
727:CV-6 Capability to Operational Activities Mapping
524:Each transition specifies an event and an action.
158:In addition, DoDAF 2.0's specific goals were to:
918:SvcV-9 Services Technology & Skills Forecast
459:SV-2 Systems/Services Communications Description
1555:"DoDAF V2.0 Volume 2 Architects Guide May 2009"
1048:Creating an integrated architecture using DoDAF
527:SV-10c Systems/Services Event-Trace Description
1786:DoD CMO Business Enterprise Architecture (BEA)
930:SvcV-10b Services State Transition Description
632:within the Defense Acquisition System process.
423:OV-6b Operational State Transition Description
393:OV-2 Operational Node Connectivity Description
371:Definitions of all terms used in all products.
1780:DoDAF section of Architecture Framework Forum
1293:Relationship to other architecture frameworks
1022:SV-9 Systems Technology & Skills Forecast
802:OV-5a Operational Activity Decomposition Tree
8:
1073:AV-1 : Overview and Summary Information
1056:Illustration of the integrated architecture.
399:OV-3 Operational Information Exchange Matrix
325:The DoDAF V1.5 defines a set of products, a
48:Department of Defense Architecture Framework
1034:SV-10b Systems State Transition Description
778:OV-1 High-Level Operational Concept Graphic
500:SV-8 Systems/Services Evolution Description
452:SV-1 Systems/Services Interface Description
387:OV-1 High Level Operational Concept Graphic
784:OV-2 Operational Resource Flow Description
486:SV-6 Systems/Services Data Exchange Matrix
231:Ministry of Defence Architecture Framework
106:means. The current release is DoDAF 2.02.
1323:Federal Enterprise Architecture Framework
936:SvcV-10c Services Event-Trace Description
888:SvcV-4 Services Functionality Description
870:SvcV-2 Services Resource Flow Description
507:SV-9 Systems/Services Technology Forecast
429:OV-6c Operational Event-Trace Description
257:Capabilities Described with Architectures
1115:
1091:SV-1 : System Interface Description
1051:
233:. Like other EA approaches, for example
42:DoDAF Architecture Framework Version 2.0
29:
1798:DoD BEA 10.0 Architecture Product Guide
1709:Overview and Concepts – Manager’s Guide
1373:
1371:
1369:
1367:
1365:
1363:
1361:
1359:
1355:
1094:TV-1 : Technical Standards Profile
796:OV-4 Organizational Relationships Chart
405:OV-4 Organizational Relationships Chart
1639:: CS1 maint: archived copy as title (
1632:
1392:DoD Architecture Framework Version 2.0
1379:DoD Architecture Framework Version 1.5
1082:OV-5 : Operational Activity Model
1040:SV-10c Systems Event-Trace Description
986:SV-4 Systems Functionality Description
974:SV-2 Systems Resource Flow Description
291:Capabilities are described by Threads.
1458:
1456:
1454:
1452:
1450:
1448:
912:SvcV-8 Services Evolution Description
790:OV-3 Operational Resource Flow Matrix
674:AV-1 Overview and Summary Information
362:AV-1 Overview and Summary Information
235:The Open Group Architecture Framework
153:Capability Portfolio Management (CPM)
7:
900:SvcV-6 Services Resource Flow Matrix
839:PV-1 Project Portfolio Relationships
741:Data and Information Viewpoint (DIV)
615:Data and Information Viewpoint (DIV)
864:SvcV-1 Services Context Description
733:CV-7 Capability to Services Mapping
563:StdV-2 Technical Standards Forecast
514:SV-10a Systems/Services Rules Model
483:‘SV-5b’ in DoDAF v1.5 respectively.
60:United States Department of Defense
1851:Enterprise architecture frameworks
1016:SV-8 Systems Evolution Description
968:SV-1 Systems Interface Description
851:PV-3 Project to Capability Mapping
820:OV-6b State Transition Description
557:StdV-1 Technical Standards Profile
25:
1750:Architecture Data Description pdf
1595:"E4.A2 ISP Architecture Guidance"
1228:meta-model, which was defined in
1076:AV-2 : Integrated Dictionary
1004:SV-6 Systems Resource Flow Matrix
578:Diagram of DoDAF V2.0 Viewpoints.
27:Enterprise architecture framework
1526:Diagram of DoDAF V2.0 Viewpoints
1514:"DODAF 2.0 Capability Viewpoint"
1477:DoD CIO Memo Releasing DoDAF 2.0
882:SvcV-3b Services-Services Matrix
808:OV-5b Operational Activity Model
313:DoDAF V1.5 Linkages Among Views.
242:framework into which it is set.
144:Defense Acquisition System (DAS)
34:DoD Architecture Framework v1.5.
1301:(Unified Profile for DoDAF and
906:SvcV-7 Services Measures Matrix
876:SvcV-3a Systems-Services Matrix
411:OV-5 Operational Activity Model
1738:Definitions and Guidelines pdf
1664:. Wizdom Systems, Inc., 2004.
1:
1258:The purposes of the DM2 are:
924:SvcV-10a Services Rules Model
826:OV-6c Event-Trace Description
814:OV-6a Operational Rules Model
417:OV-6a Operational Rules Model
345:Technical standards view (TV)
1418:"Architecture Framework FAQ"
1232:(then later in UML) with an
1173:Entity-relationship diagrams
1010:SV-7 Systems Measures Matrix
714:CV-4 Capability Dependencies
239:Core Architecture Data Model
150:Operational Planning (OPLAN)
980:SV-3 Systems-Systems Matrix
746:DIV-1 Conceptual Data Model
227:NATO Architecture Framework
1872:
1773:Definitions and Guidelines
1675:Dr. Steven H. Dam (2015).
1570:DoDAF V1.5 Products Matrix
1120:DoDAF V1.5 Products Matrix
1028:SV-10a Systems Rules Model
944:Standards Viewpoint (StdV)
773:Operational Viewpoint (OV)
680:AV-2 Integrated Dictionary
641:Standards Viewpoint (StdV)
622:Operational Viewpoint (OV)
368:AV-2 Integrated Dictionary
210:U.S. Department of Defense
1698:DoDAF Homepage at DoD CIO
955:StdV-2 Standards Forecast
859:Services Viewpoint (SvcV)
758:DIV-3 Physical Data Model
688:Capability Viewpoint (CV)
635:Services Viewpoint (SvcV)
609:Capability Viewpoint (CV)
443:Systems and services view
1744:Product Descriptions pdf
1733:DoDAF v1.5, 23 Apr 2007
1727:Journal - Best Practices
1703:DODAF 2.02 pdf, Aug 2010
1464:"DoDAF Meta Model (DM2)"
949:StdV-1 Standards Profile
752:DIV-2 Logical Data Model
700:CV-2 Capability Taxonomy
548:Technical standards view
246:Capabilities and mission
147:Systems Engineering (SE)
1824:CJCSI 6212.01F document
707:CV-3 Capability Phasing
435:OV-7 Logical Data Model
262:particular capability.
206:Mission Needs Statement
129:architecture frameworks
1121:
1057:
963:Systems Viewpoint (SV)
845:PV-2 Project Timelines
834:Project Viewpoint (PV)
711:and location solutions
648:Systems Viewpoint (SV)
628:Project Viewpoint (PV)
595:
587:
579:
570:Version 2.0 viewpoints
322:
314:
258:
180:
56:architecture framework
43:
35:
1820:CJCSI 6212.01 Series
1756:DoDAF V1, 9 Feb 2004
1502:DoD CIO DoDAF Website
1119:
1055:
593:
585:
577:
539:SV-11 Physical Schema
320:
312:
256:
178:
41:
33:
1856:Systems engineering
1203:systems engineering
1104:ANSI/IEEE 1471-2000
533:event-trace diagram
321:DoD C4ISR Framework
1791:2020-11-02 at the
1765:2017-11-15 at the
1660:and Joseph Vogel.
1658:Dennis E. Wisnosky
1604:, 2004, p. 83
1122:
1058:
767:Logical data model
669:All Viewpoint (AV)
603:All Viewpoint (AV)
596:
588:
580:
323:
315:
259:
181:
121:systems of systems
66:. These views are
44:
36:
1816:Metadata Registry
1805:Two Presentations
1405:Zachman Framework
651:Articulates, for
342:Systems view (SV)
305:Version 1.5 views
193:Clinger-Cohen Act
102:, or alternative
16:(Redirected from
1863:
1707:Volume (Vol) I:
1645:
1644:
1638:
1630:
1628:
1627:
1618:. Archived from
1612:
1606:
1605:
1599:
1591:
1585:
1584:
1577:
1571:
1568:
1562:
1561:
1559:
1551:
1545:
1542:
1536:
1533:
1527:
1524:
1518:
1517:
1510:
1504:
1499:
1493:
1492:
1485:
1479:
1474:
1468:
1467:
1460:
1443:
1441:
1434:
1428:
1427:
1425:
1424:
1414:
1408:
1401:
1395:
1388:
1382:
1375:
1339:MODAF Meta-Model
1246:DIV-1 Viewpoint.
1207:data engineering
381:Operational View
376:Operational view
337:Operational view
21:
1871:
1870:
1866:
1865:
1864:
1862:
1861:
1860:
1836:
1835:
1793:Wayback Machine
1767:Wayback Machine
1694:
1654:
1652:Further reading
1649:
1648:
1631:
1625:
1623:
1616:"Archived copy"
1614:
1613:
1609:
1597:
1593:
1592:
1588:
1579:
1578:
1574:
1569:
1565:
1557:
1553:
1552:
1548:
1543:
1539:
1534:
1530:
1525:
1521:
1512:
1511:
1507:
1500:
1496:
1487:
1486:
1482:
1475:
1471:
1462:
1461:
1446:
1436:
1435:
1431:
1422:
1420:
1416:
1415:
1411:
1402:
1398:
1389:
1385:
1381:. 23 April 2007
1376:
1357:
1352:
1319:
1295:
1222:
1156:
1050:
965:
946:
861:
836:
775:
743:
690:
671:
572:
550:
445:
378:
356:
307:
248:
173:
116:
28:
23:
22:
15:
12:
11:
5:
1869:
1867:
1859:
1858:
1853:
1848:
1838:
1837:
1834:
1833:
1828:
1827:
1826:
1818:
1813:
1808:
1802:
1801:
1800:
1783:
1777:
1776:
1775:
1769:
1754:
1753:
1752:
1746:
1740:
1731:
1730:
1729:
1723:
1717:
1711:
1705:
1693:
1692:External links
1690:
1689:
1688:
1673:
1653:
1650:
1647:
1646:
1607:
1586:
1572:
1563:
1546:
1537:
1528:
1519:
1505:
1494:
1480:
1469:
1444:
1429:
1409:
1396:
1383:
1354:
1353:
1351:
1348:
1347:
1346:
1341:
1336:
1331:
1326:
1318:
1315:
1294:
1291:
1282:
1281:
1278:
1277:
1276:
1273:
1267:
1263:
1256:
1255:
1251:
1247:
1221:
1218:
1187:
1186:
1181:
1176:
1170:
1165:
1155:
1154:Representation
1152:
1151:
1150:
1142:
1138:
1135:
1131:
1096:
1095:
1092:
1089:
1086:
1083:
1080:
1077:
1074:
1061:architectures.
1049:
1046:
1045:
1044:
1041:
1038:
1035:
1032:
1029:
1026:
1023:
1020:
1017:
1014:
1011:
1008:
1005:
1002:
999:
996:
993:
990:
987:
984:
981:
978:
975:
972:
969:
964:
961:
960:
959:
956:
953:
950:
945:
942:
941:
940:
937:
934:
931:
928:
925:
922:
919:
916:
913:
910:
907:
904:
901:
898:
895:
892:
889:
886:
883:
880:
877:
874:
871:
868:
865:
860:
857:
856:
855:
852:
849:
846:
843:
840:
835:
832:
831:
830:
827:
824:
821:
818:
815:
812:
809:
806:
803:
800:
797:
794:
791:
788:
785:
782:
779:
774:
771:
763:
762:
759:
756:
753:
750:
747:
742:
739:
738:
737:
734:
731:
728:
725:
721:
718:
715:
712:
708:
705:
704:architectures.
701:
698:
694:
689:
686:
685:
684:
681:
678:
675:
670:
667:
662:
661:
653:legacy support
649:
646:
642:
639:
636:
633:
629:
626:
623:
620:
616:
613:
610:
607:
604:
571:
568:
567:
566:
560:
549:
546:
545:
544:
540:
537:
528:
525:
521:
518:
515:
512:
508:
505:
501:
498:
494:
491:
487:
484:
480:
477:
473:
470:
467:
464:
460:
457:
453:
444:
441:
440:
439:
436:
433:
430:
427:
424:
421:
418:
415:
412:
409:
406:
403:
400:
397:
394:
391:
388:
377:
374:
373:
372:
369:
366:
363:
355:
352:
347:
346:
343:
340:
334:
306:
303:
302:
301:
298:
295:
292:
283:
282:
279:
276:
273:
270:
247:
244:
172:
169:
168:
167:
166:
165:
162:
156:
155:
154:
151:
148:
145:
142:
139:
115:
112:
26:
24:
14:
13:
10:
9:
6:
4:
3:
2:
1868:
1857:
1854:
1852:
1849:
1847:
1844:
1843:
1841:
1832:
1829:
1825:
1822:
1821:
1819:
1817:
1814:
1812:
1809:
1806:
1803:
1799:
1796:
1795:
1794:
1790:
1787:
1784:
1781:
1778:
1774:
1770:
1768:
1764:
1761:
1758:
1757:
1755:
1751:
1747:
1745:
1741:
1739:
1735:
1734:
1732:
1728:
1724:
1722:
1718:
1716:
1712:
1710:
1706:
1704:
1701:
1700:
1699:
1696:
1695:
1691:
1686:
1685:1-502757-62-1
1682:
1678:
1674:
1671:
1670:1-893990-09-5
1667:
1663:
1659:
1656:
1655:
1651:
1642:
1636:
1622:on 2007-09-27
1621:
1617:
1611:
1608:
1603:
1596:
1590:
1587:
1582:
1576:
1573:
1567:
1564:
1556:
1550:
1547:
1541:
1538:
1532:
1529:
1523:
1520:
1515:
1509:
1506:
1503:
1498:
1495:
1490:
1484:
1481:
1478:
1473:
1470:
1465:
1459:
1457:
1455:
1453:
1451:
1449:
1445:
1440:. 1 May 2007.
1439:
1433:
1430:
1419:
1413:
1410:
1406:
1400:
1397:
1394:. 28 May 2009
1393:
1387:
1384:
1380:
1374:
1372:
1370:
1368:
1366:
1364:
1362:
1360:
1356:
1349:
1345:
1342:
1340:
1337:
1335:
1332:
1330:
1327:
1324:
1321:
1320:
1316:
1314:
1312:
1308:
1304:
1300:
1292:
1290:
1286:
1279:
1274:
1271:
1270:
1268:
1264:
1261:
1260:
1259:
1252:
1248:
1244:
1243:
1242:
1239:
1235:
1231:
1227:
1219:
1217:
1215:
1210:
1208:
1204:
1198:
1196:
1192:
1185:
1182:
1180:
1177:
1174:
1171:
1169:
1166:
1164:
1161:
1160:
1159:
1153:
1148:
1143:
1139:
1136:
1132:
1128:
1127:
1126:
1118:
1114:
1112:
1109:
1108:ISO/IEC 42010
1105:
1101:
1093:
1090:
1087:
1084:
1081:
1078:
1075:
1072:
1071:
1070:
1066:
1065:
1054:
1047:
1042:
1039:
1036:
1033:
1030:
1027:
1024:
1021:
1018:
1015:
1012:
1009:
1006:
1003:
1000:
997:
994:
991:
988:
985:
982:
979:
976:
973:
970:
967:
966:
962:
957:
954:
951:
948:
947:
943:
938:
935:
932:
929:
926:
923:
920:
917:
914:
911:
908:
905:
902:
899:
896:
893:
890:
887:
884:
881:
878:
875:
872:
869:
866:
863:
862:
858:
853:
850:
847:
844:
841:
838:
837:
833:
828:
825:
822:
819:
816:
813:
810:
807:
804:
801:
798:
795:
792:
789:
786:
783:
780:
777:
776:
772:
770:
768:
760:
757:
754:
751:
748:
745:
744:
740:
735:
732:
729:
726:
722:
719:
716:
713:
709:
706:
702:
699:
695:
692:
691:
687:
682:
679:
676:
673:
672:
668:
666:
658:
654:
650:
647:
643:
640:
637:
634:
630:
627:
624:
621:
617:
614:
611:
608:
605:
602:
601:
600:
592:
584:
576:
569:
564:
561:
558:
555:
554:
553:
547:
541:
538:
534:
529:
526:
522:
519:
516:
513:
509:
506:
502:
499:
495:
492:
488:
485:
481:
478:
474:
471:
468:
465:
461:
458:
454:
451:
450:
449:
442:
437:
434:
431:
428:
425:
422:
419:
416:
413:
410:
407:
404:
401:
398:
395:
392:
389:
386:
385:
384:
382:
375:
370:
367:
364:
361:
360:
359:
353:
351:
344:
341:
338:
335:
333:All view (AV)
332:
331:
330:
328:
319:
311:
304:
299:
296:
293:
290:
289:
288:
285:
280:
277:
274:
271:
268:
267:
266:
263:
255:
251:
245:
243:
240:
236:
232:
228:
223:
220:
217:
215:
211:
207:
202:
196:
194:
190:
186:
177:
170:
163:
160:
159:
157:
152:
149:
146:
143:
140:
137:
136:
134:
133:
132:
130:
124:
122:
113:
111:
107:
105:
101:
100:probabilistic
97:
93:
89:
85:
81:
77:
73:
69:
65:
61:
57:
53:
49:
40:
32:
19:
1676:
1661:
1624:. Retrieved
1620:the original
1610:
1601:
1589:
1575:
1566:
1549:
1540:
1531:
1522:
1508:
1497:
1483:
1472:
1432:
1421:. Retrieved
1412:
1403:(reference:
1399:
1386:
1296:
1287:
1283:
1257:
1223:
1211:
1199:
1188:
1157:
1123:
1110:
1097:
1067:
1062:
1059:
764:
697:Description.
663:
656:
597:
562:
556:
551:
446:
379:
357:
348:
324:
286:
284:
264:
260:
249:
224:
221:
218:
208:(MNS) was a
205:
197:
182:
125:
117:
108:
51:
47:
45:
1390:DoD (2009)
1377:DoD (2007)
1329:IDEAS Group
1307:IDEAS Group
1238:IDEAS Group
1189:There is a
1134:capability.
1100:stakeholder
693:CV-1 Vision
84:ontological
1840:Categories
1626:2007-08-05
1423:2007-08-07
1350:References
1254:Viewpoint.
1250:Viewpoint.
1234:XML Schema
1220:Meta-model
1111:viewpoints
765:Note, see
327:view model
229:(NAF) and
104:conceptual
80:behavioral
76:structural
1748:Vol III:
1719:Vol III:
1147:ASD (NII)
724:concepts.
645:services.
619:services.
504:timeline.
96:graphical
88:pictorial
68:artifacts
1789:Archived
1763:Archived
1760:Deskbook
1742:Vol II:
1725:Vol IV:
1713:Vol II:
1635:cite web
1317:See also
1214:metadata
1141:4630.8).
354:All view
114:Overview
92:temporal
58:for the
54:) is an
1771:Vol I:
1736:Vol I:
1266:sources
214:DOTMLPF
171:History
72:tabular
1683:
1668:
1325:(FEAF)
1230:IDEF1X
1175:(ERDs)
1163:tables
657:System
543:V2.0.)
456:nodes.
1598:(PDF)
1558:(PDF)
1303:MODAF
1184:SysML
536:View.
490:only.
189:TAFIM
185:C4ISR
64:views
52:DoDAF
18:DoDAF
1681:ISBN
1666:ISBN
1641:link
1344:NCOW
1334:IUID
1311:NATO
1299:UPDM
1297:The
1226:CADM
1205:and
1191:UPDM
1168:IDEF
339:(OV)
201:CADM
46:The
1195:OMG
1179:UML
1106:or
1842::
1637:}}
1633:{{
1600:,
1447:^
1358:^
131:.
98:,
94:,
90:,
86:,
82:,
78:,
74:,
1687:.
1672:.
1643:)
1629:.
1583:.
1560:.
1516:.
1491:.
1466:.
1426:.
1407:)
50:(
20:)
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.
