Strategy and
Architectural
Representation for
Describing Authoritative
Sources in BEA 4.0
A BTA Net-Centric Team White
Paper
28 February 2006
Call 0011, Task 4.2.4.1
Version 1.0
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
1.0
This Page Intentionally Blank
Call 11 - 4.2.4.1
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
0.9
Table of Contents
Table of Contents ........................................................................................................................... i
Index of Tables .............................................................................................................................. ii
Index of Figures............................................................................................................................. ii
1
Introduction ...........................................................................................................................1
1.1
Nature of Problem ..........................................................................................................1
1.2
Objectives for Describing Authoritative Sources ..........................................................1
1.3
Assumptions and Caveats ..............................................................................................2
1.4
Document Organization .................................................................................................3
2
Background ............................................................................................................................5
2.1
Related Directives and Guidance ...................................................................................5
2.2
Key Concept Definitions................................................................................................6
2.3
Supporting Concepts ......................................................................................................6
2.4
Types of Data Sources To Be Addressed by the Authoritative Sources Description
Approach ........................................................................................................................8
3
Examples of Current Authoritative Sources .......................................................................9
3.1
Designated by Law and Regulation ...............................................................................9
3.1.1
Central Contractor Registry ................................................................................9
3.2
Designated by DoD Component ....................................................................................9
3.2.1
Defense Enrollment and Eligibility Reporting System .....................................10
3.2.2
Army Designation of Army Portfolio Management Solution ...........................10
3.2.3
DoD Metadata Registry and Clearinghouse ......................................................11
3.2.4
BEIS for SFIS Library Terms ...........................................................................11
4
Authoritative Source Use Cases .........................................................................................12
4.1
Use Case for Local Contractor Information.................................................................12
4.2
Use Case for Financial Management ...........................................................................13
5
Guidance for Describing Authoritative Sources in the BEA ...........................................15
5.1
Characterization of Sources and Authoritative Sources in the BEA ...........................15
5.2
Metadata for Describing Sources and Authoritative Sources in the BEA ...................16
5.3
Architectural Representation of Sources and Authoritative Sources in the BEA........18
5.4
Examples of Use of the Architectural Representations ...............................................20
6
Guidance for Describing Authoritative Sources for Visibility and Discovery in the NetCentric Environment...........................................................................................................22
6.1
Visibility and Discovery Overview .............................................................................22
6.2
Defense Discovery Metadata Specification Background ............................................23
6.3
Authoritative Source Representation in DDMS ..........................................................24
Call 11 - 4.2.4.1
i
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
6.4
7
1.0
Sharing and Visibility of Authoritative Sources ..........................................................27
6.4.1
Traditional Implementation of Authoritative Sources Approach......................28
6.4.2
Net-Centric—SOA and Web Services – Implementation of Authoritative
Sources Approach .............................................................................................29
Next Steps .............................................................................................................................30
7.1
Updates to BEA ...........................................................................................................30
7.2
Registration of Authoritative Sources in a Net-Centric Environment .........................31
7.3
Related Strategy Work .................................................................................................31
Appendix A – References ......................................................................................................... A-1
Index of Tables
Table 6-1, Authoritative Source Description Table Definition .................................................... 24
Table 6-2, Authoritative Source Category Elements Table .......................................................... 25
Table 6-3, Example of DDMS Authoritative Source metadata .................................................... 26
Table A-1, Reference Documents ............................................................................................... A-1
Index of Figures
Figure 4-1, Authoritative Sources for Contractor Information ..................................................... 12
Figure 4-2, Authoritative Sources for Financial Information ....................................................... 13
Figure 5-1, Sources and Authoritative Source Descriptions at Different Levels of Abstraction . 15
Figure 5-2, Existence of an Authoritative Source Description Identifies a Source as
Authoritative. .......................................................................................................................... 16
Figure 5-3, Initial Architectural Use of Authoritative Source Description. ................................. 18
Figure 5-4, Representation of Sources and Authoritative Sources in the Architecture. ............... 19
Figure 5-5, Example of the Architectural Representation of Source. ........................................... 21
Figure 5-6, Example Architectural Representation of Source as an Authoritative Source. ......... 21
Figure 6-1, Source Discovery in a Net-Centric Environment....................................................... 22
Figure 6-2, DDMS Logical Model................................................................................................ 23
Figure 6-3, DDMS Logical Model Extended to Accommodate Authoritative Sources. .............. 24
Call 11 - 4.2.4.1
ii
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
1.0
Acronym
AITR
API
AS
BEA
BEIS
BEP
BMA
BTA
CCR
CES
CFO
CORBA
COI
COM
DBIDS
DBSAE
DCCIS
DCOM
DDMS
DEAMS
DEERS
DFARS
DIMHRS
DNTS
DNVC
DoD
DoDAF
EDI
EJB
ERP
ESB
FACTS
FAR
FASA
FISMA
GFEBS
GIG
GL
HTML
HTTP
IA
IC
Call 11 - 4.2.4.1
Definition
Army Information Technology Registry
Application Program Interface
Authoritative Source
Business Enterprise Architecture
Business Enterprise Information Services
Business Enterprise Priority
Business Mission Area
Business Transformation Agency
Central Contractor Registry
Core Enterprise Services
Chief Financial Officer
Common Object Request Broker Architecture
Community of Interest
Component Object Model
Defense Biometric Identification System
Defense Business Systems Acquisition Executive
Defense Cross-Credentialing Identification System
Distributed Component Object Model
Department of Defense Discovery Metadata Specification
Defense Enterprise Accounting and Management System
Defense Enrollment and Eligibility Reporting System
Defense Federal Acquisition Regulation Supplement
Defense Integrated Military Human Resources System
Defense Non-Combatant Evacuation Operations Tracking System
Defense National Visitors Center
Department of Defense
Department of Defense Architecture Framework
Electronic Data Interchange
Enterprise Java Beans
Enterprise Resource Planning
Enterprise Service Bus
Federal Agencies Centralized Trial-Balance System
Federal Acquisition Regulation
Federal Acquisition Streamlining Act
Federal Information Security Management Act
General Fund Enterprise Business System
Global Information Grid
General Ledger
HyperText Markup Language
HyperText Transfer Protocol
Information Assurance
Intelligence Community
iii
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
IM
IT
JDBC
MOA
MS
NCE
NCOW RM
NEO
ODBC
OMB
OMG
P&R
PIA
PIP
RAPIDS
SFIS
SLA
SOA
SPS
SQL
SRS
UDDI
US
USA
USD
VAN
XML
ZIP
Call 11 - 4.2.4.1
1.0
Information Management
Information Technology
Java DataBase Connectivity
Memorandum of Agreement
Microsoft
Net Centric Environment
Net-Centric Operations and Warfare Reference Model
Non-Combatant Evacuation Operations
Open DataBase Connectivity
Office of Management and Budget
Object Management Group
Personnel and Readiness
Privacy Impact Assessment
Personal Identify Protection
Real-time Automated Personnel Identification System
Standard Financial Information Structure
Service Level Agreement
Service Oriented Architecture
Standard Procurement System
Structured Query Language
Strategic Readiness System
Universal Description, Discovery and Integration
United States
United States of America
Under Secretary of Defense
Value-Added Network
eXtensible Markup Language
Zone Improvement Plan
iv
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
1
1.0
Introduction
In pursuit of the net-centric environment in which information consumers can discover and make
use of information to achieve their mission objectives, the DoD Directive 8320.2 Data Sharing
in a Net-Centric Department and the BMA Net-Centric Strategy call for the designation and
description of authoritative sources. Consumers of information need to be able to trust and be
confident in the information available to them. To provide reliable and timely data, the mission
area will identify and designate authoritative sources.
This white paper recommends an approach for describing authoritative sources of data and/or
information in the Business Enterprise Architecture (BEA). Section 5 of this paper sets forth the
recommended approach with Sections 1-4 providing the reader with background and examples
for a better understanding of the topic. Section 6 provides the associated approach for registering
the authoritative sources in a net-centric environment, and Section 7 recommends the next steps
for moving this work forward.
1.1
Nature of Problem
On the surface, the notion of identifying an authoritative source seems straightforward enough.
However, as our research has gone on, we have found numerous complications in this seemingly
simple concept. Data moves in numerous ways from its point of origin, through many processes,
coming to rest in various places with other data flowing in from other processes to meet
important implementation and performance objectives in the real world. Because of this, there
can be many sources for a given piece of information. The notion of trust with regard to such
information grows in complexity as this web of information movement and availability grows
more complex. In addition, there are issues about what, at various levels of abstraction and from
various viewpoints, constitutes a source, and so an authoritative source. An authoritative source
may be an organization, such as the US Postal Service for ZIP codes. The authoritative source
may also be the system or systems through which the Postal Service makes the information
available. Again, it may be specific capabilities, functions or access points provided by the
Postal Service or its systems that are taken to be the authoritative source. To some extent, the
authoritative source is a function of the audience and its particular needs. In the course of this
discussion, we hope to exhibit some of these issues, and show ways to manage and mitigate the
difficulties and complexities that arise.
1.2
Objectives for Describing Authoritative Sources
In order to best guide this white paper, the BTA has defined a set of objectives to be supported
and/or achieved by describing authoritative sources in the BEA. These business transformation
objectives include:
•
Support Information Sharing: Provide programs and initiatives with clear guidance on
sharing information that others need to achieve their mission.
•
Support Visibility of Information: Provide information consumers of the business
community with enough information about sources in order to discover available
information and assess its appropriateness for their task
Call 11 - 4.2.4.1
1
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
1.0
•
Support Data Interoperability: Provide programs and initiatives with clear guidance
on the sources for the information they need to achieve their mission—ensuring they
interoperate around appropriate and trusted information.
•
Support Portfolio Management: Provide the BTA Investment Review Boards with
information on trusted and available sources so that portfolio management can take into
account the need to support authoritative sources within the portfolio and to and/or use
the information from authoritative sources. The efforts to designate and describe
authoritative sources can reduce duplicate sources, saving resources and money.
Through supporting these objectives, this approach provides support for the DoD Enterprise
Transition Plan and the ongoing transformation of business processes and systems. Additionally,
programs and initiatives can leverage this work on authoritative sources as they implement in the
net-centric environment. Specifically, the authoritative source descriptions will support:
•
Making Data Visible: This net-centric data goal is supported by the designation of
authoritative sources in the federated architectures and eventually in the registry of
shared data assets.
•
Enabling Data to be Trusted: This net-centric data goal is supported by the description
of the source of information. Consumers of the information can use the descriptive
metadata to assess the appropriateness of the information to their mission.
•
Transitioning to Net-Centricity: Designating and describing authoritative sources is a
step toward the net-centric environment characterized by Service-Oriented
Architectures (SOA), Information Assurance (IA), and data sharing.
Achieving these objectives and representing authoritative sources in the BEA improves the
foundation for BMA transformation initiatives.
1.3
Assumptions and Caveats
In the development of this white paper, we made several assumptions in order to define an
approach that would be applicable for the expected hybrid environment in which systems,
services, and ERPs will co-exist to support the business management of the department. These
assumptions and caveats are:
•
We define an architecture object called ‘service interface’ to be the representation of a
contract between a service provider (e.g., a source) and the consumer of the service (e.g.
information consumer). While there are specific definitions of service interface related
to SOA and Web Services, we are using it in a wider architectural sense in order to
allow for a variety of ways in which access to data, or other functionality, may be
provided including: Web Service, SQL Service (e.g. Oracle ODBC, JDBC), Java
Service, Proprietary API, or other access facility. This interpretation enables the
approach to support the move to a Service-Oriented Architecture, in particular one
based on Web Services, along with existing data access approaches. See the discussions
in the body of the white paper.
Call 11 - 4.2.4.1
2
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
1.0
•
For some concepts, such as the notion of partitioning a body of data via its semantic
range, we are presenting the concept, and using just one such partitioning in the
discussion, there will be others. The full extent of these is an open research item.
•
One of the complex issues associated with the concept of authoritative sources revolves
around trust and transitive trust. If a given source cites an authoritative source for a
component of its data offering, and is otherwise trusted, is the trust for the original
authoritative source transitive—transferred to the new source—such that a process can
do “one-stop-shopping” at the new source, thereby not requiring access two sources by
consumers? We will provide further discussion on this topic as background in the next
section, but we have left complete exploration of this topic for further research and
analysis, focusing on the primary sources in this white paper.
•
The concepts of service interface and service instantiation presented here may have key
roles in supporting federation across DoD by providing a well-defined boundary for
component architecture and/or programs and initiatives. These key roles are not further
investigated here as it is outside of the scope of this white paper.
•
This white paper presents an approach for describing and representing authoritative
sources in the architecture. We have not yet addressed the mechanisms or procedures
for stakeholders and Communities of Interest (COIs) to identify which data sources in
the BEA should be designated as authoritative sources of data or information. Per the
Next Steps, the identification of the authoritative sources would follow an adoption of
this approach and would be planned and executed as part of architecture development
for the appropriate architecture release.
1.4
Document Organization
This white paper has the following sections and appendices:
•
Section 1 – Introduction – This section provides the reader with a guide to this white
paper including the purpose and scope, a description of the nature of the problem, the
objectives of describing authoritative sources, and assumptions that the paper makes in
addressing the issues.
•
Section 2 – Background – This section provides the reader with information
underlying the approach set forth in this white paper, and which will help the reader
understand the remainder of the paper. The background includes related guidance from
the department, discussion of supporting concepts, key definitions, and a discussion of
the types of data sources to which this approach is directed.
•
Section 3 – Examples of Current Authoritative Source Designations – This section
shows the reader that some authoritative source designations may already exist through
either law, regulation, or other management assertions. These current designations need
to be accounted for in the guidance to be provided by the white paper.
•
Section 4 – Authoritative Source Use Cases – To aid the understanding of use and
approaches for designating authoritative sources, this section describes use cases for
Call 11 - 4.2.4.1
3
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
1.0
authoritative sources. These illustrations demonstrate some of the complexities and
issues uncovered when considering approaches to designating authoritative sources.
•
Section 5 – Guidance for Describing Authoritative Sources in the BEA – This
section presents the reader with a model for thinking about the levels of abstraction
represented in the BEA and with associated specifics to describe authoritative sources at
those levels.
•
Section 6 – Guidance for Describing Authoritative Sources for Visibility and
Discovery in the Net-Centric Environment – This section provides the specifics of
additional metadata representations that will be needed to support the discovery and/or
access of the source through the Core Enterprise Services (CES).
•
Section 7 – Next Steps – This section identifies the next set of steps for testing the
approach presented for describing authoritative sources and the eventual inclusion of
this information in the BEA. This section also includes next steps for registering
authoritative sources in the net-centric environment and related strategy work such as
data interoperability and service oriented architecture (SOA).
•
Appendix A – References – Identifies the documents used or references in this
document.
Call 11 - 4.2.4.1
4
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
2
1.0
Background
This section provides the reader with background and key definitions on which the approach
presented in this white paper is based. The section starts with the related net-centric guidance
and builds to the specific definitions that are important to this approach. We also address the
types of sources that are candidates for being designated as authoritative, and which COIs should
investigate.
2.1
Related Directives and Guidance
This white paper approach has been developed in light of other existing guidance within DoD
that addresses the issue of authoritative sources for information or data.
Relevant information on the topic from these sources is provided in the following quotes:
Information asset owners (e.g., system owners, information producers, information management staff) participate in COIs
identify the authoritative sources information assets. COIs may support information providers in resolving potentially
conflicting sources and, where appropriate, coordinate with the DoD-wide governance bodies to identify authoritative
source(s). The community should provide authoritative source metadata to the NCE, so users and applications can evaluate
and understand the community-implied authority of information assets (see “Discover Information Asset”) to ensure Users
are able to make informed decisions in accessing an information asset. Moreover, Users discovering and identifying a COI
should be able to determine the authoritative information sources controlled or maintained by the Community. This is a subactivity of “Identify Information Assets.”
— From Net-Centric Operations and Warfare Reference Model (NCOW RM) Version 1.1 on
defining authoritative sources
E1.1.2
Authoritative Source. A source of data or information that is recognized by members of a COI to be valid or
trusted because it is considered to be highly reliable or accurate or is from an official publication or reference
(e.g., the United States (U.S.) Postal Service is the official source of U.S. mailing ZIP codes).
4.5.
To enable trust, data assets shall have associated information assurance and security metadata, and an
authoritative source for the data shall be identified when appropriate.
— From DoD Directive 8320.2 Data Sharing in a Net-Centric Department of Defense
C4.5.3.1.
Identify authoritative data sources. When appropriate, the COI should identify data assets that are
authoritative sources for data, and in what contexts the data is authoritative. In situations where there is more
than one authoritative source depending on how the data is used, a COI should indicate the business process
for which the authority is valid.
AP1.1.
Authoritative source implies a data asset that has been determined and defined by a Community of Interest to
be a valid or official source of data. Authoritative sources may vary by COI (e.g., one community may define
an authoritative source for location data to be the US Postal Service and while another community might define
an authoritative source for location data to be an intelligence database). Additionally, a community may define
more than one authoritative source for a particular type of data (e.g., a budget and planning community may
have an authoritative source for budget data for each Military Service)
— From the 8320.2-G Implementation Guide for Department of Defense Directive
8320.2
Call 11 - 4.2.4.1
5
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
2.2
1.0
Key Concept Definitions
The definition of authoritative source we provide here is somewhat wider than definitions
provided in the cited guidance, as we include the cases beyond COI identification to include
sources designated by law or regulation, and so required to be authoritative. COIs may establish
the means by which such laws or regulations are satisfied, but cannot remove the
authoritativeness of the source.
Source (of data or information)
The lowest level and most technical definition for a source is as the interface & mechanism
through which a person or automated process obtains a defined set of information or data (such
as that contained in a data flow or data exchange). This can be as basic as a database
management system’s data access machinery, or as abstracted as a Web Service that makes the
data or information available. As noted in the introduction, at higher levels of abstraction, and
for less specific purposes, a source may be the system function behind such interfaces or
mechanisms, or even just the system itself. At even higher levels, and for non-technical
purposes, the source is the organization or information steward supported by the system, system
functions, and specific mechanisms. Key is that these views of the source of information or data
should all be connected and traceable from the most technical and specific to the most general
conception.
Authoritative Source
The source of data that is designated as the definitive source of the data, whether through law
and regulation, or through enterprise and COI decisions as to what source should be taken as
ground truth (and for what purposes or audiences).
Trusted Schema
Any data source, to be usable, is defined by a schema that makes its data decipherable and
intelligible; the trusted schema for any given source is one that a user obtains from an
authoritative source of such schemas. We expect that such an authoritative source will be the
DoD enterprise catalog of registered data sources—a repository of metadata about data sources
and services
This notion of trusted schemas becomes important in actual implementation, when people need
to connect to sources and authoritative sources in a loosely coupled Net-Centric environment,
and need to trust not only the source, but also how they are to interpret the source through a
definition of the structure of the source information.
2.3
Supporting Concepts
In this white paper, we distinguish between the notion of designating a source as authoritative,
and describing a source as authoritative.
Designation
‘Designation’ refers to the process by which a source of data or information gets its status as
authoritative. For some sources, law or regulation confers this status, and requires them to be the
Call 11 - 4.2.4.1
6
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
1.0
authoritative source. For others, the relevant COIs, in particular, the Business Enterprise
Priorities (BEPs) or Core Business Missions (CBMs), may identify from the data sources within
their purview those that they will designate as authoritative, based on the common interests that
form and define the COI.
Description
The description is metadata that provides information about the source or its authoritative status,
captured in the architecture or an appropriate repository. The information can be used by the
information consumer to assess the appropriateness of the information for the task at hand.
Trust – direct and transitive
Any process requiring information as input is dependent upon the reliability of the information
that drives the process. Implementers must be able to trust the source of the data they process in
order to ensure that the results of the process are trusted by the users of the process, including
other processes that are dependent on the subject process for their own activities.
Primary sources of trusted information are what we are calling authoritative sources, as defined
above. Describing these primary Authoritative Sources, defining the basic parameters of the
metadata needed to describe them, and recommending appropriate representations of them in the
architecture and in net-centric service registries and catalogs, is the main focus of this white
paper.
A related concept of source is one that provides information from these primary trusted sources,
and is itself also trusted. Such a secondary source may be a derivative or transitively trusted
source from which to obtain trusted information even though it is not a primary source. It may
bring together information from multiple authoritative sources, so adding value. This secondary
source, by providing the credentials for the pedigree of its information, may itself thereby be
capable of designation as an authoritative source.
Examples of trust, transitive trust and authoritative sources include:
•
A direct trusted authoritative source may be the source for financial detailed
transactions, i.e. the GL transactions in the Army ERP, GFEBS
•
A type of a transitive trusted authoritative source may be the source of summary
financial transactions, i.e., BEIS that is the Corporate General Ledger for DoD where
the financial detailed transactions have been summarized from the direct Authoritative
Source, such as GFEBS.
•
Another type of transitive trusted authoritative source may be where data is cached in a
local database for performance reasons, i.e., Standard Procurement System (SPS) may
copy the Central Contractor Registry data to improve performance in the field or to
support disconnected operations.
The complexities of determining how extensive chains of transitive trust can be, and of
determining appropriate modes of representation and governance, are issues requiring further
Call 11 - 4.2.4.1
7
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
1.0
study and analysis. This white paper does not provide specifics on describing them or
representing them in the BEA, but leaves that to a future effort.
2.4
Types of Data Sources To Be Addressed by the Authoritative Sources Description
Approach
The approach presented in this white paper is applicable across sources of many types of data
and information. Below is a listing of different types of data in order to give the reader a sense
of what the approach covers.
•
Operational or Transactional data sources include:
•
•

Data with which the business operates

Sources of transactions and business documents used in the operation of the
business (e.g., Purchase Requests, Contracts)
Business Management data sources include:

Sources of data for tracking the state of business operations

Sources of metrics of business operation

Analytical data sources used for business intelligence and decision-making
Metadata sources include:

Sources that contain data schemas: These are likely to be different sources than
those that provide information in a format compliant with the schemas.

Sources of registry information that serves as metadata about shared data assets,
services, or other objects within the operating environment
It is possible that this approach for describing designating and authoritativeness could be used for
architectural objects in addition to sources that might be so designated. For example, there may
be authoritative algorithms, processes, and services that could be designated authoritative across
the enterprise or some subset thereof.
Call 11 - 4.2.4.1
8
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
3
1.0
Examples of Current Authoritative Sources
Authoritative source designations already exist through either law, regulation, or other
management assertions. This white paper accounts for these current designations in the guidance
it provides. This section describes examples of these existing authoritative sources designations.
3.1
Designated by Law and Regulation
Laws and Regulations may designate authoritative sources. The example discussed in this
subsection is the designation of the Central Contractor Registry as the authoritative repository of
vendors that want to do business with DoD.
3.1.1
Central Contractor Registry
The Central Contractor Registry (CCR) is an example of an authoritative source designated by
regulation.
Why CCR was created:
In the past, any vendor who wanted to do business with more than one DoD site was required to
submit the same business information to each site. This redundancy of paperwork not only
created an administrative burden for both the government and the vendor, but also was a major
source of administrative error and expense in terms of both time and money.
Because DoD is the largest purchaser of good and services in the world, the cost savings to be
incurred by streamlining these administrative processes are dramatic. CCR was created to be the
single repository of vendor data for the entire DoD to avoid this administrative duplication and
allow contractors to take responsibility for the accuracy of their own important business
information by supplying it directly to the government through a single registration.
The CCR Mandate:
In October 1993, the President issued a memorandum that mandated the Government reform its
acquisition processes. Subsequently, the Federal Acquisition Streamlining Act (FASA) of 1994
was passed, requiring the establishment of a "single face to industry." To accomplish this, the
DoD identified a centralized, electronic registration process known as CCR as the single point of
entry for vendors that want to do business with the DoD. To this end, the Defense Federal
Acquisition Regulation Supplement (DFARS), Subpart 204.7300, requires contractors to register
in the CCR to conduct business with the Department of Defense.
Federal Acquisition Regulation (FAR), published March 2005, Section A, Subpart 4.11 states
that “Prospective contractors shall be registered in the CCR database prior to award of a contract
or agreement …”
3.2
Designated by DoD Component
DoD Components and agencies may designate authoritative sources to support their mission
within the department. This subsection will describe these examples of such designations:
Call 11 - 4.2.4.1
9
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
1.0
•
Defense Enrollment and Eligibility Reporting System (DEERS),
•
Army Designation of Army Portfolio Management Solution
•
DoD Metadata Registry and Clearinghouse
•
BEIS for SFIS Library values
3.2.1
Defense Enrollment and Eligibility Reporting System
The Defense Enrollment and Eligibility Reporting System (DEERS) is an example of an
authoritative source designated by directive. From DoD Directive 1000.25, “DoD Personnel
Identify Protection (PIP) Program”, published 19 July 2004:
1.2. Establishes policy for the implementation and operation of the DoD
Personnel Identity Protection (PIP) program to include use of authoritative
identity information, issuance and use of DoD identity credentials, and
operation of the Defense Enrollment and Eligibility Reporting System
(DEERS), Real-time Automated Personnel Identification System (RAPIDS)
and associated systems, Defense Biometric Identification System (DBIDS),
Defense Cross-Credentialing Identification System (DCCIS), Defense National
Visitors Center (DNVC), and the Defense Non-Combatant Evacuation (NEO)
Operations Tracking System (DNTS).
4.1.2. Capture uniquely identifying characteristics that bind an individual to
the identity information maintained on that individual in DEERS and to the
identification credentials issued by RAPIDS. These characteristics shall
include, but are not limited to, digital photographs and fingerprints. DEERS
shall be the sole authoritative repository for storing these characteristics.
The DoD Components shall avoid updating and maintaining redundant
repositories without a compelling justification.
5.3. The Director, Defense Manpower Data Center, under the USD(P&R)
shall:
5.3.3. Serve as the authoritative source for identity confirmation.
3.2.2
Army Designation of Army Portfolio Management Solution
The Army Information Technology Registry (AITR) is an example of an authoritative source
designated by a component, in this case the Army.
From the Army Information Technology Registry Instruction Manual, 9 April 2004, which may
be found at http://www.army.mil/aeioo/docs/AITR_Instr_Man_9-Apr-04.pdf:
“The Army Information Technology Registry (AITR) is the Army’s single,
definitive registry of IT systems. The AITR provides data on:

Call 11 - 4.2.4.1
The inventory of Army systems/applications
10
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
1.0

Current status of webification

System milestones for reduction/webification

Tracking of Federal Information Security Management Act (FISMA) data

Privacy Impact Assessment (PIA) data [planned for early 2004]
In addition, it is used to support IM/IT resource management
business/functional process improvement efforts, provide input to the Strategic
Readiness System (SRS), and for compiling information for FISMA status
reports to OMB and Congress. PIA fields will also be included because they
are required by the provisions in OMB Memorandum Guidance for
Implementing the Privacy Provision of the E-Government Act of 2002, dated
September 26, 2002
3.2.3
DoD Metadata Registry and Clearinghouse
The DoD Metadata Registry and Clearinghouse is an example of an authoritative source
designated by a component. It’s web address is http://diides.ncr.disa.mil/xmlreg/user/index.cfm.
XML registries are a vital component in the implementation of shared data
exchanges. Developers looking to express information using XML need
support in establishing common lexicons and grammars. This Registry enables
the consistent use of XML, both vertically within projects and horizontally
across organizations.
The DoD XML Gallery constitutes guidance in the generation and use of XML
among DoD communities of interest and is the authoritative source for
registered XML data and metadata components.
3.2.4
BEIS for SFIS Library Terms
Business Enterprise Information Services (BEIS) is an example of an authoritative source
designated by a component. From the Business Enterprise Information Services (BEIS) Baseline
System Specification, Version 1.0, December 9, 2005:
“SFIS Library Services
BEIS will establish the authoritative source for SFIS data elements for the
entire DoD enterprise. This will be accomplished through the development
and deployment of an SFIS library database structure within the BEIS
environment. This environment will be maintained by data stewards which
have been designated for each of the 62 SFIS Phase 1 data elements.”
Call 11 - 4.2.4.1
11
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
4
1.0
Authoritative Source Use Cases
To aid the understanding of the use and approaches for designating authoritative sources, this
section describes use cases for authoritative sources. These illustrations demonstrate some of the
complexities and issues uncovered in considering approaches to authoritative sources.
4.1
Use Case for Local Contractor Information
While it is required to use contractors that are registered in the Central Contractor Registry, there
are specific exceptions, including “Awards made to foreign vendors for work performed outside
the United States, if it is impractical to obtain CCR registration” 1.
As show in Figure 4-1, there are situations in which local contractor information may be
available from an authoritative source that is not CCR.
Figure 4-1, Authoritative Sources for Contractor Information
Federal Acquisition Regulation, Issued March 2005 by General Services Administration, Department of Defense,
National Aeronautics and Space Administration
1
Call 11 - 4.2.4.1
12
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
1.0
The scenario depicted in Figure 4-1 is further described as follows:
•
An Afghanistan installation has an SPS implementation for local use.
•
SPS loads Contractor Data from CCR, the authoritative source, before disconnect.
•
Awards for the use of trucks for transportation needs were given to local contractors for
trucks acquired in Afghanistan.
•
User 1 enters local contractor data into SPS as a contingency contractor, because it is
impractical to expect the contractor in Afghanistan to register in the Central Contractor
Registry.
•
SPS Local Installation is the authoritative source for local contractor data.
The approach for designating authoritative sources must be able to represent that authoritative
contractor data is available from CCR and from the specific installations of SPS.
4.2
Use Case for Financial Management
The To-Be view for financial reporting for DoD is shown in the graphic below, to be provided in
a system name Business Enterprise Information Services (BEIS). Specifically:
•
Financial transactions across the Components are recorded in several applications.
Summaries of the transactions are passed to BEIS as trial balance records.
•
BEIS posts the information to the general ledger.
•
BEIS provides Budgetary Reporting, CFO Financial Statements, and FACTS I & II
reporting to Treasury for the DoD Enterprise.
Figure 4-2, Authoritative Sources for Financial Information
Call 11 - 4.2.4.1
13
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
1.0
The Component financial systems and BEIS are authoritative sources for financial and
accounting information. However, their authoritative designations are for specific partitions of
financial information:
•
Component financial management systems are authoritative sources for financial
transactions for a defined scope. For example, Navy ERP is the authoritative source for
financial transactions generated by Navy activity.
•
BEIS is the authoritative source for Budgetary Reporting, CFO Financial Statements,
and FACTS I & II reporting to Treasury.
The approach for designating authoritative sources must be able to represent that authoritative
financial transactions are partitioned across sources and that summary level information and
statements applicable DoD-wide are authoritatively sourced from BEIS.
Call 11 - 4.2.4.1
14
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
5
1.0
Guidance for Describing Authoritative Sources in the BEA
This section presents the reader with the recommendations for describing authoritative sources in
the BEA, based on proposed extensions around the concept of sources in the architecture.
5.1
Characterization of Sources and Authoritative Sources in the BEA
The BEA presents the DoD business architecture at different levels of abstraction, from high to
low. It also produces DoDAF views intended to exhibit various aspects of the architecture from
particular perspectives, such as operational and system that emphasize different characteristics of
the architecture’s elements. The specificity with which a source is identified at a particular level
of abstraction depends on that level of abstraction. At a high level, we may see only large
clumps of data without internal structure. At a lower level, we may see fine-grained definition of
the data contents.
From an operational perspective, the important aspect of a data source may be the organization
that produces it. From a systems perspective, the key characteristic is the system, or at a lower
level, the particular function or service that delivers the information. The notion of a source of
information or data thus has differing representations in the architecture depending on the level
of abstraction and the particular view. Figure 5-1 depicts this graphically.
Figure 5-1, Sources and Authoritative Source Descriptions at Different Levels of Abstraction
Call 11 - 4.2.4.1
15
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
1.0
In the architecture, these different representations of a source should be traceable from the
highest level characterization down to that lowest level in the Systems Views. The lowest level
of abstraction of source in the architecture, when it is fleshed out to this level of detail, should
correspond well with the type of net-centric service envisioned in the BMA Net-Centric Strategy,
Version 4.0. as well as in the vision of net-centricity and data sharing found in such DoD NetCentricity publications as DoD Net-Centric Data Strategy, and NCOW RM. In this way, the
architecture can provide clear guidance and a solid foundation for implementation in a netcentric environment.
As noted above in Figure 5-1, the amount and type of metadata needed to characterize a source
as authoritative varies with the view and level of abstraction. The general approach to
identifying data sources in the architecture as authoritative sources is based first on being able to
clearly identify sources in the architecture, and then characterizing appropriate sources as
authoritative with additional metadata. This metadata describes a source with a set of elements
constituting an Authoritative Source Description. The description also uses the identifier of the
source to associate itself with the source, as shown in Figure 5-2. In this way, we can identify
and describe authoritative sources non-invasively—no change is needed to the way in which a
source is described, just this additional set of information. The source description remains the
same whether we ever characterize it as an authoritative source or not.
Figure 5-2, Existence of an Authoritative Source Description Identifies a Source as Authoritative.
5.2
Metadata for Describing Sources and Authoritative Sources in the BEA
The Authoritative Source Description metadata needs to capture information that allows an
information consumer to understand the source, from whence comes its authority, and the
purposes and coverage of the source. Our recommendation in this white paper is that the basic
metadata set include the following items:
•
Designating Authority – The authority that prescribes the source as authoritative; the
locus of the source’s authoritativeness. As a consumer of information from the
authoritative source, the information about the designating authority provides me with a
Call 11 - 4.2.4.1
16
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
1.0
pointer to the appropriate organization or policy that I can explore and use for assessing
the appropriateness of the information for my task. Examples of types of designating
authorities include:
•
•

An organization, e.g. General Services Administration, Department Of Defense,
Department of the Navy, and USD (AT&L)

A law, regulation, policy, directive, instruction, or guidance, e.g., DoD Directive
1000.25, “DoD Personnel Identify Protection (PIP) Program”, and “FAR
Subchapter A—General, Subpart 4.11”,

A COI, through its data sharing decision making process, e.g. Financial
Management Community of Interest, Spend Analysis, and Blue Force Tracking
Authority Scope – The purpose and/or audience for which the source is to be taken as
authoritative. There may be a need for more than one authoritative source for
information, not because the information if different, but driven by the need for
different access details or information assurance requirements.

Organization may include, e.g., Congress, DoD, or a particular COI

Purposes can include logistics tracking versus financial accounting when
describing the same objects, or trend analysis and forecasting versus day to day
management control
Semantic Range – The constraints that differentiate an authoritative source based on
semantics, where semantics is taken to be the set of things to which an element or
complex data item may refer. This is akin to domain values in relational database
theory—sets of permissible values. In the near term, such semantics can be used for
partitioning sets of data by its set of valid values. In the longer run, an ontology
representation of semantics, as described in the BMA Net-Centric Strategy Version 4
may provide another and better method of describing semantics and handling this
partitioning. Examples of such partitioning are:

A source may be authoritative only for a specific organization’s data, e.g. Navy
ERP is the authoritative source for financial transactions generated by Navy
activity.

A source may be authoritative for a location.
In this white paper we have focused on partitioning by organization in our examples.
More work on possible partitioning schemes will be driven by the BMA system entities.
•
Data Scope – The set of authoritative data or information that the consumer can get
from the source. The specification of the Data Scope is critical for characterizing each
authoritative source because it tells the information consumer which of the data they
can trust from that source. The Data Scope can be defined in the following ways:
Call 11 - 4.2.4.1
17
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
5.3
1.0

A simple enumerated set of data elements not the data values. The Data Scope
could list “ADDRESS” and “BIRTH_DATE” for a given authoritative source, but
not “1851 Bell St” or “02/13/2000”.

An aggregate (collection of data elements) such as “Travel Request Data” with or
without an associated list or enumeration of data elements, depending on the level
of abstraction or completeness of detail in the associated architectural items

A combination of enumerated data elements and aggregates
Architectural Representation of Sources and Authoritative Sources in the BEA
At the upper levels of abstraction in the architecture, we believe there to be appropriate
representations of sources that can be associated with Authoritative Source Descriptions to
communicate where authoritative sources exist within the architecture. However, at the lowest
level in Systems Views, the notion of source needs further elaboration. This paper recommends
a set of extensions to these lowest levels to better capture the nature of source in support of
eventual net-centric implementations. We provide a depiction of these extensions in Figure 5-4.
However, in the short run, the lowest level in architecture that can be described as a source is the
System/System Function architectural element. Initially, these can be characterized as
authoritative sources, as shown in Figure 5-3. We also show in that figure a schematic
representation of the Authoritative Source Description metadata described earlier in this section.
Figure 5-3, Initial Architectural Use of Authoritative Source Description.
Call 11 - 4.2.4.1
18
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
1.0
While identification of Authoritative Sources can be done at this level, as it can at higher levels
of abstraction in the architecture, refinement of the definitions of System Functions in the
architecture, and ultimately, the provision of the Service Interface and Service Instantiation
architectural elements, as shown in Figure 5-4, will yield more precise identification of sources.
These improved definitions will provide better guidance for implementation, and ready support
for making these sources shared and visible in a Net-Centric environment, as described in the
next section of this white paper.
Note that the term ‘service,’ as used here, is that usage found in the concept and discussions of
SOA current in the industry. Like many terms in information technology, it is an overloaded
term. Services can be taken more broadly to mean such things as that one organization provides
a valuable function for another, independent of the mechanisms of such provision. The term is
also already used in other senses than ours in the BEA, and care will be required to ensure that
ambiguity does not arise in communications. Here we are looking at service as indicating a
particular technological solution by which one automated system can make its information and
functionality available to other automated systems in a standard and infrastructure-support way
across a robust network like the GIG.
Figure 5-4, Representation of Sources and Authoritative Sources in the Architecture.
Call 11 - 4.2.4.1
19
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
1.0
At this low level of abstraction and high level of specificity in guidance of implementation, we
can see how multiple authoritative sources can exist for a given kind of data, as the architecture
shows multiple systems as implementing a given System Function. This is the motivation for
our inclusion of the Semantic Range as a partitioning of data or information across authoritative
sources. Appropriate use of such partitioning allows distribution of the management of a given
kind of information across multiple implementations while avoiding redundancy and potential
synchronization and control issues.
Service Interface is the specification or definition of a standard interface—a collection of method
or operation signatures that collectively provide access to the information or capabilities of more
system functions. Depending on the granularity of the System Function in the architecture, a
particular System Function may be made available through more than one interface. It is also
possible that a particular interface may provide access to the capabilities of more than one
System Function, to create a unified or controlled access point.
As the architecture comes to show specific systems, it will also show multiple instances of a
System Function through the System/System Function entity. Likewise, there will come to be
multiple implementations or instantiations of Service Interfaces associated with System
Functions, as the realization of the interface for a specific system entity. These are represented
by the proposed Service Instantiation entity. These should be associated with the appropriate
System/System Function elements, and through them, with the correct System Entities. The
instantiation of a Service Interface describes a connection to the real-world source of
information, and represents a service to be implemented and registered and cataloged in a netcentric environment.
It should also be noted that while we here tend to speak of services with an eye to net-centricity
and the emerging DoD SOA environment built around Web Services, our actual intent is to
remain faithful to the broader definition of service we spoke of earlier. We recognize that the
service interface may refer to older modalities of delivering information as well as to Web
Services. One way that a source, and so an authoritative source, can have multiple service
interfaces is through having multiple modalities of delivery of the relevant information in
question. We can imagine that a single source may be able to deliver its information through a
Web Service, an FTP interface, an EDI/VAN interface and perhaps even an email service. This
is an area we have not specifically drilled down into, and which is a good area for further
research.
5.4
Examples of Use of the Architectural Representations
The set of architectural objects includes those that represent both logical descriptions and system
descriptions that are realizations of the logical descriptions. For example, the architecture has a
set of system functions such as “Manage GL”. The architecture also describes System Entities
such as DEAMS that instantiate that functionality for a specific scope. Similarly, the Service
Instantiation extension we recommend is a realization of the recommended Service Interface
extension. Figure 5-5 graphically depicts an example of using this approach:
Call 11 - 4.2.4.1
20
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
1.0
Figure 5-5, Example of the Architectural Representation of Source.
In order for this source to be characterized as an authoritative source as this level of the
architecture, it is only necessary that a metadata set describing it as authoritative be created and
populated, including a reference to the specific service instantiation element in the architecture,
as shown in Figure 5-6:
Figure 5-6, Example Architectural Representation of Source as an Authoritative Source.
Call 11 - 4.2.4.1
21
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
6
1.0
Guidance for Describing Authoritative Sources for Visibility and Discovery in the NetCentric Environment
This section provides the reader with guidance on making authoritative sources visible and
sharable through the emerging net-centric mechanisms within DoD. The reader is first provided
a short overview of visibility and discovery using CES. The remainder of Section 6 is a technical
discussion of recommended extensions to the metadata for describing authoritative sources in the
net-centric environment and an example of such a description in text, XML, and HTML.
6.1
Visibility and Discovery Overview
During implementation in a net-centric environment, one of the steps is to enable GIG Users to
discover sources of information and authoritative sources as a subset thereof. To provide
visibility of these sources, data assets shared across the enterprise are registered in the Federated
Enterprise Catalog.
The Federated Enterprise Catalog is a set of data assets metadata catalogs containing a list of
data assets and associated descriptive metadata (such as name, subject, creator, security,
location) about the data asset. The specification for this metadata is the DoD Discovery
Metadata Specification (DDMS). Content Discovery Service (a CES on the GIG) can be
invoked to search the Federated Enterprise Catalog for data assets that meet search criteria,
including assets designated as authoritative sources as shown in Figure 6-1.
Figure 6-1, Source Discovery in a Net-Centric Environment.
In order to appropriately describe data assets as authoritative sources, the Federated Enterprise
Catalog and it’s specification, the DDMS must be extended, as discussed in Section 6.3. An
assumption of the design of the Content Discovery Service is that Mission Areas, Components,
Call 11 - 4.2.4.1
22
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
1.0
and/or COIs will need to create it’s portion of the Federated Enterprise Catalog and populate it
with the appropriate information. This is discussed in the next steps.
6.2
Defense Discovery Metadata Specification Background
The DDMS is a DoD specification for the construction of schemas used in making specific
metadata descriptions of data assets. These metadata descriptions are to be placed into catalogs
that can support discovery—users can query the catalogs in terms of the metadata schemas to
find data assets that have descriptions showing they are useful to the user. The DDMS plays a
role similar to that of XML in relation to the specific XML schemas that constrain particular
documents to a specified format. DDMS-compliant schemas constrain metadata descriptions of
data assets to a certain format. Different types of data assets may require different types of
descriptive metadata. Note that this descriptive metadata is in addition to the schemas such as
XML or DBMS schemas that constraint the actual data of the data asset to a specific format. The
logical model of the DDMS is shown in Figure 6-2. The DDMS consists of a Core Layer made
up of Category Sets along with an Extensible Layer for use by COIs or Domains.
Figure 6-2, DDMS Logical Model.
To accommodate description of data assets or sources as authoritative sources, we are
recommending extension of the DDMS. This extension could be done as a COI or Domainspecific extension, but we believe that the concept of authoritative source is a common one, that
should be captured in the base metadata specifications. For this reason, we are recommending
extension of DDMS through the addition of another category set to the Core Layer of DDMS, as
shown in Figure 6-3.
Call 11 - 4.2.4.1
23
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
1.0
Figure 6-3, DDMS Logical Model Extended to Accommodate Authoritative Sources.
A detailed description of the extension is provided in section 6.3 below.
6.3
Authoritative Source Representation in DDMS
The DDMS Schema describes the metadata to be used in creating schemas for descriptions of
sources of information. For authoritative sources, we recommend that the DDMS be extended as
shown in Figure 6-3 above to include the additional metadata needed for describing the
authoritativeness of sources. In this section, we describe specific additions or extensions to the
DDMS to allow the description of authoritative sources, and provide examples using HTTP and
XML. These are new metadata elements or constructs that we propose be added to DDMS. We
refer to this set of metadata as the “Authoritative Source Category Set.”
As part of the Authoritative Source Category Set, we propose the addition of a new table or
structure to the DDMS, Authoritative Source Description. Based on the format of the current
DDMS, the structure of this table is shown in Table 6-1, which defines the Authoritative Source
Description table and its purpose.
Table 6-1, Authoritative Source Description Table Definition
Authoritative Source Description
Metadata
This category is used to tag the data asset and authoritative and to describe the
Category
nature of its authoritativeness.
Description
Obligation
Call 11 - 4.2.4.1
Optional
24
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
1.0
Modification
Date
Source or
Related
Reference
Comment
The actual elements with which the Authoritative Source Description table is populated are
shown in here in Table 6-2 at a high level. Some elements may be aggregates composed of a
number of elements. This level of detail remains to be worked out. The entries for Designating
Authority and Authority Scope are only Foreign Key entries, as the DDMS already contains a
table that captures information about DoD organizations, currently the organization’s
classification, owner/Producer, name, phone number, and email information.
Table 6-2, Authoritative Source Category Elements Table
Authoritative Source Category Elements
Name
Definition
Obligation Comment
Designating The authority that prescribes the source Mandatory
Authority as authoritative; the locus of the source’s
authoritativeness.
Authority
Scope
The purpose and/or audience for which Mandatory
the source is to be taken as authoritative.
Semantic
Range 2
The constraints that differentiate an
Optional
authoritative source based on a principle
of partitioning, such as by organization.
Data Scope The set of authoritative data or
information that the consumer can get
from the source.
Mandatory
Semantic Range is a unifying concept across possible partitioning criteria. It does not appear
here as a category element because at this time, the only partitioning criteria supported is by
organization. “Organization Semantic Range” is included to allow the description of this
semantic range in the metadata. Additional work is needed for Location, another possible
partitioning criteria, and other possible partitioning criteria as needed..
2
We have only investigated organization as a partitioning principle so far.
Call 11 - 4.2.4.1
25
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
1.0
The following table is an example of the Authoritative Source Description information a source
provider registers in the Enterprise Catalog, based on the requirements established by DDMS and
the extensions defined here. The examples contain the same information in three different
formats: Text, XML, and HTML.
Table 6-3, Example of DDMS Authoritative Source metadata
Authoritative Source Category Examples
Text
Designating Authority EntityType: Organization
Designating Authority Scope classification: U
Designating Authority ownerProducer: USA
Designating Authority Name: Joint Chief of Staff
Designating Authority Phone Number: 111-111-1111
Designating Authority Email: somecontact@dod.mil
Designating Authority Reference: Joint Publication 4-02
Authority Scope EntityType: Organization
Authority Scope classification: U
Authority Scope ownerProducer: USA
Authority Scope Name: U.S. Department of Defense
Semantic Range – Organization: EntityType: Organization
Semantic Range – Organization: classification: U
Semantic Range – Organization: ownerProducer: USA
Semantic Range – Organization: Name: U.S. Department of the Army
Data Scope: Organization Description
Authoritative Source Category Examples
XML
<Designating Authority IC:classification=”U” IC:ownerProducer=”USA”>
<Organization>
<Name>Joint Chief of Staff</Name>
<PhoneNumber>111-111-1111</PhoneNumber>
<Email>somecontact@dod.mil</Email>
</Organization>
<Authority Reference >
Joint Publication 4-02
</Authority Reference >
</Designating Authority>
<Authority Scope IC:classification=“U” IC:ownerProducer=“USA”>
<Organization>
<Name>U.S. Department of Defense</Name>
</Organization>
</Authority Scope>
Call 11 - 4.2.4.1
26
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
1.0
<Semantic Range Type=“Organization”>
<Organization IC:classification=“U” IC:ownerProducer=“USA”>
<Name>U.S. Department of the Army</Name>
</Organization>
</Semantic Range>
<Data Scope >
Organization Description
</Data Scope >
HTML
6.4
<meta name=“designatingauthority.classification” content=“U”>
<meta name=“designatingauthority.ownerProducer” content=“USA”>
<meta name=“designatingauthority.entityType” content=“Organization”>
<meta name=“designatingauthority.name” content=“Joint Chief of Staff”>
<meta name=“designatingauthority.phone” content= “111-111-1111”>
<meta name=“designatingauthority.email” content=“somecontact@dod.mil”>
<meta name=“authorityreference” content=‘Joint Publication 4-02”>
<meta name=“authorityscope.classification” content=“U”>
<meta name=“authorityscope.ownerProducer” content=“USA”>
<meta name=“authorityscope.entityType” content=“Organization”>
<meta name=“authorityscope.name” content=“U.S. Department of the Army”>
<meta name=“semanticrange.classification” content=“U”>
<meta name=“semanticrange.ownerProducer” content=“USA”>
<meta name=“semanticrange.entityType” content=“Organization”>
<meta name=“semanticrange.name” content=“U.S. Department of Defense”>
<meta name=“datascope” content= “Organization Description”>
Sharing and Visibility of Authoritative Sources
There are two basic ways of sharing data from sources, traditional and net-centric. Traditional
approaches are often tightly coupled, based on specific agreements, point-to-point
implementations from one system to another using Memoranda of Agreement or Service Level
Agreements. An example might be an interface between DEAMS to DIMHRS. These
implementations contain detailed and specific knowledge about both end-points in the interface,
and as such are brittle, requiring coordinated change between both participants.
A net-centric view of sharing data decouples the end-points with standards-based infrastructure,
allowing the end-points to interoperate through registered metadata information and formal
definition of capabilities, perhaps implemented through a common broker. This allows each side
to develop their connection to or provision of, services independently, and in a way that allows
for alternate providers and unanticipated consumers to construct or join in wide-scale business
processes. Providers register a source, in this case an authoritative source, providing necessary
information as metadata in a catalog to make the source visible and discoverable. By being
registered and provided through a standards-based service interface, the authoritative source is
Call 11 - 4.2.4.1
27
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
1.0
accessible, published to a shared space, available to any consumer that meets the requirements of
the service specification in the metadata, which may include stringent identification and
authentication as well as specific authorization of the consumer.
Many patterns for such net-centric sharing are available in the SOA, including publish-subscribe
models that can connect many providers with many consumers in a write-once, read-many
fashion without requiring any end-point to know or manage the number of providers or
consumers.
The following paragraphs highlight the traditional and net-centric approaches and the differences
between them.
6.4.1
Traditional Implementation of Authoritative Sources Approach
Users and systems can obtain authoritative data through many different mechanisms, each with
its own specific rules and methods of operation. The approach for identifying sources and
authoritative sources presented in this white paper can be used to describe such sources as well
as the more service-oriented approach we recommend here. Some traditional approaches
include:
•
File transfers, batch and on demand (FTP, EDI VAN)
•
Common Repositories
•
Point-to-point interfaces
•
Proprietary Message-Oriented Middleware (MOM) such as IBM’s WebSphere MQ,
Microsoft Message Queuing (MSMQ)
•
And, in some cases, through locally distributed computing services (MS DCOM, OMG
CORBA)
An information consumer interested in the information from such an authoritative source will
need to find out about its existence and then negotiate a contract in order to set up an exchange
through one of the mechanisms above. Depending on the mechanism, different steps are taken to
make the exchange operational. Traditional methods tend to require proprietary techniques and
produce tight coupling of interfaced systems, which is one of the reasons for the net-centric
move to a standards-based SOA.
A mitigating approach to the use of these traditional mechanisms is to wrap them with a software
layer that exposes their capabilities and information through a well-defined Web Services
interface. This restricts the proprietary techniques and tight-coupling to just the wrapper layer,
which can be dispensed with in favor of a direct implementation of the Web Service as the
underlying functionality provider matures. Similar results for sources required only locally—
within some span of control over the use of technology—can be obtained using other serviceoriented component implementation approaches, as described in the next section.
Call 11 - 4.2.4.1
28
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
6.4.2
1.0
Net-Centric—SOA and Web Services – Implementation of Authoritative Sources
Approach
In a SOA, authoritative data is made available to others through standards-based services—
packages of functionality with well-defined and registered interfaces that define the bounds of
interaction and available content. In a net-centric environment, the enterprise-wide approach to
such a SOA is through Web Services coordinated in an enterprise-wide SOA infrastructure,
providing ESB-style support and other common and important capabilities revolving around
security and dynamic configuration and version management to ensure the robustness of the
network of providers and consumers and the business processes they execute.
Locally, within a node where more detailed architectural control can be exercised, an SOA may
be encapsulated islands of other component architectures providing the implementation of a
SOA’s features—dotNET, COM/DCOM, CORBA, or Java EJBs. Where these local capabilities
need to be made available outside the domain of control, they are still made available to the
enterprise through Web Services. This process, which can be used to transition traditional
sharing mechanisms to a net-centric, service-oriented approach as well, involves several steps:
•
Define a service interface that cleanly exposes the source
•
Define XML-based message sets, specifying the format and tagging of the data in an
XML Schema
•
Implement the service so that it can access the existing functionality on the one hand, and
expose it through standard Web Services mechanisms on the other
•
Registering the service, including registration as an authoritative source, in DDMS,
thereby advertising the service and so the authoritative source
•
Place the needed service metadata in a catalog, such as a UDDI Registry (Service
Registry), enabling other GIG users to consume the service.
Call 11 - 4.2.4.1
29
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
7
1.0
Next Steps
The approach presented in this white paper begins to meet its objectives when it is realized in
updates to the architecture and the net-centric metadata. This section articulates recommended
next steps in three areas: (1) updates to the BEA, (2) registration of authoritative sources in a netcentric environment, and (3) related strategy work for guiding implementation.
7.1
Updates to BEA
To move the approach forward, the next step is to test the approach for describing authoritative
sources in the BEA. As described below, the recommended next steps include a test phases in
which the authoritative source descriptions and linkages to the architectures are developed for a
subset of Business Enterprise Systems. This test will be “on paper” with an assessment and
report at its conclusion. The results of the test phase will be used to best plan for rigorous
designation of authoritative systems and population of relevant metadata across the BMA. The
specific recommended steps are:
1.
Collaborate with stakeholders to refine and come to consensus on approach presented in
this white paper
2.
Identify DBSAE systems for test of authoritative source description approach
3.
Develop paper test

Work with appropriate BEP staff for the designated DBSAE systems

Develop and populate the authoritative source metadata for those systems

Develop, modify and/or populate the appropriate DoDAF views with the
authoritative source metadata

Develop and populate the enterprise catalog to describe the designated systems
within the GIG environment
4.
Assess the results against the objectives with BEA architects and BEP staff
5.
Draft a report on the test of the authoritative source description approach
6.
Document the recommended approach for describing authoritative sources in BEA 4.0
in a BEA Decision Memorandum
7.
Modify BEA System Architect meta-model as appropriate
8.
Work with the architecture development team to plan for further population of
authoritative source designations for BEA release 4.0 and future BEA releases
Through the designation and description of authoritative sources of information across the
business community, portfolio management processes can make associated decisions to maintain
and enhance the trusted sources of data across the BMA. This will in turn, create the
environment in which consumers of information can be confident in the information they use for
making decisions.
Call 11 - 4.2.4.1
30
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
7.2
1.0
Registration of Authoritative Sources in a Net-Centric Environment
As described in Section 6, the net-centric environment will support data sharing across the
department by providing mechanisms and standards for making data assets visible and for
finding those data assets. We recommend the following steps for moving the BMA toward this
operating environment:
7.3
1.
Collaborate with NII to assess applicability of authoritative source description DDMS
extensions to the department.
2.
Work with BMA stakeholders to determine its plan for registering data assets with the
Enterprise Catalog by standing up its own Data Assets Catalog or looking to an existing
program or initiative for this functionality.
3.
Work with data assets owners to tag their assets according to DDMS and the
authoritative source description extensions.
Related Strategy Work
As mentioned in Section1, there are some topics related to authoritative sources that deserve
further examination. Specifically, the issue of transitive trust and its role in allowing further
designation of authoritative sources may prove useful in the business operating environment in
which data sets can be very large in volume and not conducive to real-time cross-source access.
Allowing sources to assert authoritativeness through transitive trust may allow more efficient
access to information and more confidence in the quality of the information.
In addition, the approach for partitioning data sets by semantic range in order to assert
authoritativeness needs additional work. This paper addresses partitioning by organization as
appears to be the most common case. Additional exploration is needed to address the general
case of partitioning any element. The need for this work will be driven by the department’s
operating environment and the situations in which partitioning of authoritative data is useful to
the community.
Identifying and describing authoritative sources in the BEA and the operational environment is a
step toward data interoperability for the business community. As the approach for authoritative
sources is approved and implemented, we anticipate developing an approach for data
interoperability that begins to address the data that moves across the constituents of the
enterprise for operational and decision-making purposes.
Lastly, the approach set forth here is a step toward the vision for service-oriented architecture
and how it might impact or shape the BEA and the federation constituents. The refinement of
the systems view to include service interfaces and service instantiations allows the architecture to
define technology-independent specifications to guide and constrain implementations whether
they be initiatives making use of traditional technologies or those adopting net-centric
technologies. This SOA work will include the approach for representing CES and ESB in the
BEA and/or the constituents of the federation of architectures.
Call 11 - 4.2.4.1
31
February 28, 2006
Strategy and Architectural Representation for Describing
Authoritative Sources in BEA 4.0
1.0
Appendix A – References
Table A-1 lists documents referenced in this document and other documents used for background
research.
Table A-1, Reference Documents
Ref #
Referenced Document
Date/Version
1
Business Enterprise Architecture
30 September 2005
Version 3.0
2
BMA Net-Centric Strategy
29 March 2005,
Version 4.0
3
Data Sharing in a Net-Centric Department of Defense Directive 8320.2
2 December 2004
4
Department of Defense Discovery Metadata Specification (DDMS)
29 July 2005,
Version 1.3
5
Department of Defense Enterprise Transition Plan Volume 1: Defense Business
Transformation Overview
30 September 2005
6
DoD Net-Centric Data Strategy
9 May 2003
7
Implementation Guide for Department of Defense Directive 8320.2 (DoD
8320.2-G)
23 May 2005,
Version 0.7 (Draft)
8
Net-Centric Operations and Warfare Reference Model (NCOW RM)
17 November 2005,
Version 1.1
9
Service-Oriented Architecture: A Field Guide to Integrating XML and Web
Services, by Thomas Erl, Prentice-Hall PTR, Upper Saddle River, New Jersey
07458,
2004, ISBN 0-13142898-5
10
Service-Oriented Architecture: Concepts, Technology, and Design, by Thomas
Erl, Prentice-Hall PTR, Upper Saddle River, New Jersey 07458,
2005, ISBN-0-13185858-0
11
Tailoring DoDAF to Support a Service-Oriented Architecture, Huei-Wan Ang,
Christopher Bashioum, Fatma Dandashi, William Kirkman
January 2006
12
Web Services Architecture, W3C Working Group Note 11
February 2004
http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/
Version 20040211
13
Web Services Architecture and its Specifications: Essentials for Understanding
WS-*, Luis Felipe Cabrera and Chris Kurt, Microsoft Press, Redmond
Washington
2005, ISBN 0-73562162-4
14
Web Service Standard C2 User Requirements
8 December 2003,
Final
Call 11 - 4.2.4.1
A-1
February 28, 2006