Download presentation
Presentation is loading. Please wait.
Published byValerie Greer Modified over 9 years ago
1
1 The DoD Joint Technical Architecture
2
SUT- ITMSP2 The key words Introduction JTA Terminology and Organization The structure of the JTA core The core service areas TAFIM Federal Enterprise Architecture Reference Models TRM FRM DoD EA BRM DoD EA SRM DoD EA PRM DoD EA DRM JTA Relationships with other DoD Programs The relationship of the JTA to other DoD architecture guidance and initiatives The key acquisition planning documents Applying the JTA to Systems Building a Standards Profile An excerpt from a JTA profile System Migration SBA Methodology
3
SUT- ITMSP
5
5
6
6 According to the DoD JTA Version 3.0 promulgation memorandum dated 29 November 1999: “...the JTA is required for all DoD Acquisition Categories, and all other non-traditional (e.g., Defense Information Infrastructure (DII) Common Operating Environment (COE)), systemic (e.g., Joint Airborne SIGINT Architecture (JASA)), or non-DoD 5000 series acquisitions (e.g., procurement of information technology services, CINC Initiatives) that meet these criteria. In addition, implementation of the JTA is required for pre-acquisition programs such as: Advanced Concept Technology Demonstration (ACTDs), Advanced Technology Demonstrations (ATDs), Joint Warrior Interoperability Demonstrations (JWIDs), “Exploitation-year,” and Battle Laboratory projects that meet these criteria.”
7
SUT- ITMSP7 The need for joint operations in combat and the reality of a shrinking budget “reach consensus on a working set of standards” and “establish a single, unifying DoD technical architecture that will become binding on all future DoD C4I acquisitions” so that “new systems can be born joint and interoperable, and existing systems will have baseline to move toward interoperability.” This document is the JTA ! The DoD JTA guides the acquisition and development of new and emerging systems in the selection of IT functionality. The JTA identifies only the minimum set of mandated and emerging standards that are critical to interoperability. The JTA is based on the Technical Architecture Framework for Information Management (TAFIM), Adopted Information Technology Standards (AITS) – Volume 7 of the TAFIM.
8
SUT- ITMSP8 The Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) Architecture Framework Version 2.0 [12] defines three kinds of architecture views for DoD systems.The three views defined are operational architecture (OA), systems architecture (SA), and technical architecture (TA) views. A technical architecture is defined as “the minimal set of rules governing the arrangement, interaction, and interdependence of system parts or elements, whose purpose is to ensure that a conformant system satisfies a specified set of requirements.” The DoD JTA is such a technical architecture!
9
SUT- ITMSP9
10
10
11
SUT- ITMSP11 Information Processing Standards. Information Transfer Standards. Information Modeling, Metadata, and Information Exchange Standards. Human-Computer Interface Standards. Information Security Standards.
12
SUT- ITMSP12 The core of JTA includes standards specifications for the following key areas: Programming Languages, User Interface, Document Exchange, Computer Graphics, Operating Systems, and Communication and network. Standards include ISO specified C, C++, and Ada languages, CDE/X windows and Win32, and POSIX and Win32. Information and Object Modeling. Standards include IDEF0 for activity modeling, IDEF1X for data modeling, and UML object modeling. Data Definitions and Data Exchange. Standards include the Defense Data Dictionary System (DDDS), Joint Variable Message Format (JVMF), and XML. Computing and Information Security. Standards include Passwords, network authentication services, Cryptographic Algorithms, Secure Sockets Layer (SSL) Protocol for WWW.
13
SUT- ITMSP13 The standards in the JTA Core, domains, and subdomains are revisited and updated All standards are placed in the Core unless they are justified as unacceptable to meet domain-specific requirements. When Core standards cannot meet the requirements of a specific domain they are removed from the JTA Core and placed in the appropriate domain. Likewise, when domain standards cannot meet subdomain-specific requirements! (1) The Core applies to all DoD systems; (2) the JTA Core contains selected standards for as many JTA services as possible; and (3) the JTA provides the minimum number of standards for a specified service or interface. each domain and subdomain provides a list of domain-specific standards and guidance in a format consistent with the JTA Core.
14
SUT- ITMSP14 The Technical Architectural Framework for Information Management developed by the Defense Information Systems Agency (DISA) to guide the evolution of Department of Defense (DoD) systems, including sustaining base, strategic, and tactical systems, as well as interfaces to weapon systems. support applications, communication services, business process services, environment management, and engineering services The latest version of TAFIM, Version 2.0, was published in 1994. Name of technology: TAFIM Reference Model Application category: Software Architecture Models (AP.2.1.1) Distributed Computing (AP.2.1.2) Quality measures category : Maintainability (QM.3.1) Interoperability (QM.4.1) Computing reviews category : Distributed Systems (C.2.4) Software Engineering Design (D.2.10)
15
SUT- ITMSP15
16
SUT- ITMSP16
17
SUT- ITMSP17 The JTA includes a Technical Reference Model (TRM) that describes, from the foundation up, a services view of the architecture. It includes physical environment services (the host computer system), the operating system services and the system services such as software engineering services, user interface services and data management services. The DoD TRM originated from the TAFIM.
18
SUT- ITMSP18 A software-based model TRM identifies a service view that describes multiple computing layers, namely, application entities, application platform entities, and external environment entities, top down. The service view is further elaborated to form the four-layered interface view. The application layer is further subdivided into user applications and support applications. The latter may include functions such as graphic display and communication. These layer and interface names and numbers are parts of the standard vocabulary. TRM identifies three types of interfaces: The direct interface goes between the two consecutive computing layers. The internal direct interface goes between the sub computing layer within a computing layer. The logical interface goes among components, subsystems, or systems at the same computing layer.
19
SUT- ITMSP19
20
SUT- ITMSP20 Domain-specific standardsdo not fit fully within a software-based model.The FRM has therefore been adopted by DARO to encompass the airborne reconnaissance standards. as a standards traceability matrix between the DARP architectures the generic, functional makeup of airborne reconnaissance systems Based on the functional model developed by the JASA working group, additional functions found in IMINT and MASINT systems, expliciting mission planning and control functions, and expanded communications functions for integrating airborne reconnaissance with warfighter and other C4I systems Where the operational functional flow or the system functional flow cannot be traced back to a set of standards (i.e., a "block" as shown in the FRM illustration), the FRM will require updating.
21
SUT- ITMSP21
22
SUT- ITMSP22
23
SUT- ITMSP23 The DoD resources used for the DoD EA BRM include the Universal Joint Task List, the Business Enterprise Architecture, and the Net- Centric Operations and Warfare Reference Model (NCOW RM) V1.0. description of the Federal Government’s Lines of Business, including its internal operations and its services for the citizen
24
SUT- ITMSP24 a business-driven, functional framework that classifies Service Components with respect to how they support the business or mission area of the Department. structured across horizontal service areas that, independent of the business functions, can provide a “leverageable” foundation for reuse of applications, application capabilities, components, and business services. establishing the Department’s foundation for managing the Department’s Service Components in a net-centric environment. The DoD resources used for the DoD EA SRM include the Common System Functions List (CSFL), the Intelligence Common Functions List, the Business Enterprise Architecture, the NCOW RM V1.0, and the Net Centric Enterprise Services.
25
SUT- ITMSP25 a framework for performance measurement that provides common outcome and output measures throughout the DoD and for association with the FEA PRM. The model articulates the linkage between IT and the achievement of mission and customer-centric outcomes. Program Managers should use the measurement areas and measurement categories to properly categorize the measurement indicator for their IT initiative.
26
SUT- ITMSP26 an approach for identifying data and information at an aggregate level to support program and business line operations. based on DoD’s Data Strategy and the FEA Data Management Strategy establish a commonly understood classification for Department data and leads to the identification of duplicative data resources, as well as enable information sharing between DoD Components and Federal Agencies It can be produced on a business line by business line basis, or in DoD parlance, produced on a Community of Interest (COI) basis as opposed to a single cumulative effort. It will categorize the Department’s information along with general content areas specific to the DoD EA BRM sub-functions and decompose those content areas into greater levels of detail, ultimately to data components that are common to many business processes or activities across the entire spectrum of the Department, and Federal, state, and local governments.
27
SUT- ITMSP27 C4ISR Architecture Framework : Both are required in developing a successful technical architecture Global Information Grid (GIG): The TA View for the GIG Architecture is based on the Joint Technical Architecture (JTA). The JTA complements : the DII Common Operating Environment (COE) ((now the GIG COE) addresses needed products for insertion into developments. the C4ISR Architecture Framework ( provides the framework and architectural variations within which products and standards are deployed and implemented. TRM ( provides the common definitions and relationships for the services and interfaces used throughout the enterprise.) the Component-Specific Technical Architecture (address the Components’ technical requirements for standards.)
28
SUT- ITMSP28 DoD Technical Reference Model ( TRM ) : provides the foundation and the common services and interface definitions used in the JTA. the TRM provides the foundation for other DoD initiatives such as the DII COE and the C4ISR Architecture Framework. It supports the C4ISR, the Combat Support, and the Weapon Systems domains contained in the JTA. Defense Information Infrastructure Common Operating Environment: an approach for building interoperable systems; a reference implementation containing a collection of reusable software components; a software infrastructure for supporting mission-area applications; and a set of guidelines, standards, and specifications. JTA standards :(POSIX),(TCP/IP) Component-Specific Technical Architecture use the DoD JTA as the basis of their technical architectures
29
SUT- ITMSP29
30
SUT- ITMSP30 serve as roadmaps to program managers and contractors for program execution from initiation through postproduction support The mission needs statement The operational requirements document C4I Support Plan (C4ISP) The request for proposal The contract statement of work
31
SUT- ITMSP31 The JTA by itself does not select nor provide the capability for the selection of specific standards. Rather, it provides the “list” from which to select standards. The effective selection of standards or development of a standards profile must be accompanied by a complementary process or selection methodology. One such complementary methodology can be found in the DoD TRM. Service Areas and Standards Profiles : The major service areas, as defined in the DoD TRM, provide an area of commonality that enables relationships among disparate entities to be identified and analyzed. The standards chosen for these corresponding base service areas comprise the Standards Profile that is a part of the system Technical Architecture. Building a Standards Profile
32
SUT- ITMSP32 Selecting a minimum set of standards that provide coverage for all system services 1. Identify the operational requirements. the operational requirements for the system(s): High-level requirements by documents such as the Mission Needs Statements (MNS), Universal Joint Task Lists (UJTLs) Identify Standards Profiles utilized by other systems that you have a requirement to operate with. 2. Map these requirements to the JTA. Map these operational requirements to the base service areas contained in the Core, domains, and subdomains.
33
SUT- ITMSP33
34
SUT- ITMSP34
35
SUT- ITMSP35 Selecting the Migration Plan : In many cases, migration will be a complex and costly undertaking if pursued solely for a compliance reason alone, and not recommended if that is the sole reason for pursuing it. Cost/benefit to individual migrating programs and systems may not be seen, where there are economics of scale to be realized only by DoD as a whole. Timing and planning of upgrades for existing systems and programs needs to be carefully coordinated for those systems required to become JTA (including DII COE)-compliant to allow minimal impact to necessary Mission Capabilities and Performance requirements. To become JTA-compliant may require some trade-off analysis for mission capability/performance versus compliance. Once a commitment to being JTA-compliant (including DII COE) is made, sustaining compliance will require a follow-on effort throughout the system/program life cycle. Complying with the DII COE is only a starting point for JTA compliance. If additional functionality is required, the corresponding base service areas within the JTA need to be considered.
36
SUT- ITMSP36 Selecting design options and the migration path requires an understanding of the system parameters—including its requirements, resources, and current status—merged with an awareness of the outside influences on the migration path, including technology and evolving standards. Migrating Legacy Systems Requiring an Upgrade Migration Strategy Standards-Based Architecture (SBA) methodology be used in the design process.the SBA methodology identifies the possible alternative migration approaches and ensures that the target system is designed in compliance with chosen standards.
37
SUT- ITMSP37 The SBA methodology is a straightforward approach to the migration of legacy systems with the added requirement that the system be designed to standards.
38
SUT- ITMSP38 Applying the JTA to the SBA Process : Standards Profiles must exist for both the current and the target systems. the current system’s Standards Profile need only catalog already implemented standards, eliminating the need for standards selection.
39
SUT- ITMSP39 http://www-jta.itsi.disa.mil/ http://www.opengroup.org/architecture/togaf7- doc/arch/p4/others/others.htm#TAFIM www.dsp.dla.mil/interop.htm http://www.boeing.com/fcs http://www-library.itsi.disa.mil/tafim/tafim.html http://www.sei.cmu.edu/ http://www.fas.org/irp/doddir/dod/c4isr/es.htm http://www.c3i.osd.mil/org/cio/doc/GPM11-8450.pdf http://www-trm.itsi.disa.mil/ http://www.jauswg.org
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.