1

SUT- ITMSP 2

The key wordsIntroductionJTA Terminology and OrganizationThe structure of the JTA coreThe core service areasTAFIMFederal Enterprise Architecture Reference

ModelsTRMFRMDoD EA BRMDoD EA SRMDoD EA PRMDoD EA DRMJTA Relationships with other DoD ProgramsThe relationship of the JTA to other DoD

architecture guidance and initiativesThe key acquisition planning documentsApplying the JTA to SystemsBuilding a Standards ProfileAn excerpt from a JTA profileSystem MigrationSBA Methodology

SUT- ITMSP

SUT- ITMSP 5

SUT- ITMSP 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”.

SUT- ITMSP 7

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.

SUT- ITMSP 8

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!

SUT- ITMSP 9

SUT- ITMSP 10

SUT- ITMSP 11

Information Processing Standards .Information Transfer Standards .Information Modeling, Metadata, and Information

Exchange Standards .Human-Computer Interface Standards .Information Security Standards .

SUT- ITMSP 12

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.

SUT- ITMSP 13

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 .

SUT- ITMSP 14

The Technical Architectural Framework for Information Managementdeveloped 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)

SUT- ITMSP 15

SUT- ITMSP 16

SUT- ITMSP 17

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.

SUT- ITMSP 18

A software-based modelTRM 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.

SUT- ITMSP 19

SUT- ITMSP 20

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.

SUT- ITMSP 21

SUT- ITMSP 22

SUT- ITMSP 23

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

SUT- ITMSP 24

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 .

SUT- ITMSP 25

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.

SUT- ITMSP 26

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 Strategyestablish 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 AgenciesIt 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.

SUT- ITMSP 27

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.)

SUT- ITMSP 28

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 Architectureuse the DoD JTA as the basis of their technical

architectures

SUT- ITMSP 29

SUT- ITMSP 30

serve as roadmaps to program managers and contractors for program execution from initiation

through postproduction support

The mission needs statementThe operational requirements document C4I Support Plan (C4ISP) The request for proposalThe contract statement of work

SUT- ITMSP 31

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

SUT- ITMSP 32

Selecting a minimum set of standards that provide coverage for all system services

.1Identify 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 .

.2Map these requirements to the JTA.Map these operational requirements to the base

service areas contained in the Core, domains, and subdomains.

SUT- ITMSP 33

SUT- ITMSP 34

SUT- ITMSP 35

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.

SUT- ITMSP 36

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.

SUT- ITMSP 37

The SBA methodology is a

straightforward approach to the

migration of legacy systems with the

added requirement that the system be

designed to standards .

SUT- ITMSP 38

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.

SUT- ITMSP 39

http://www-jta.itsi.disa.mil/http://www.opengroup.org/architecture/togaf7-doc/arch/p4/

others/others.htm#TAFIMwww.dsp.dla.mil/interop.htmhttp://www.boeing.com/fcshttp://www-library.itsi.disa.mil/tafim/tafim.htmlhttp://www.sei.cmu.edu/http://www.fas.org/irp/doddir/dod/c4isr/es.htmhttp://www.c3i.osd.mil/org/cio/doc/GPM11-8450.pdfhttp://www-trm.itsi.disa.mil/http://www.jauswg.org