MarketDriven XML Data Strategy

1
Market-DrivenXML Data Strategy
Dr. Glenda Hayes The MITRE Corporation
2
Contrasting Management Styles
TIGHT

• Top-down, Command approach
• versus
• Market Driven approach

SPECTRUM OF CONTROL
LOOSE
3
DoDs Business Environment

• NOT a single Enterprise but . . .
• Conglomerate of Many Diverse Businesses
• Various business connections
• Close support with frequent transactions
• Remote, infrequent trading
• Adversarial behavior (competition)
• Relationship with IT suppliers
• Vendors/developers want fragmentation
• Each stovepipe is a market
• Government-Industry teams compete for Market Share

Hostile to Interoperability Requirements
4
Which Management Approach?
Market with some Controls appropriate for DoD
- Complex, many-to-many problem - Deals with
competition - Constrained to lightweight admin
overhead - - Modest visibility enforcement
tools - Capitalize on existing acquisition
oversight
LOOSE
TIGHT
5
Market Characteristics
DoD Conglomerate
DoD Enterprise
Intel
Log
Pers
C2
Etc.
Fin
Communities of Interest (COIs)
Acquisition Reviewers

CINC-to-Shooter Customers
RQMTS
Operators (Users)
PMs
RQMTS IMPLN

Spiral Development Process
6
COE Data Management Strategy

• XML Part of larger Market Driven Data Strategy
• PMs as change agents
• COIs (Namespaces) as arena for change
• Components as unit of exchange (commodity)
• Electronic Marketplace as change mechanism

7
Market used to govern Data Components

• Common Modular Architecture
• Common Representation
• Common Data Exchange Language
• Common Metadata Mgmt Facilities
• Common Data Access Services

XML
8
Common Data Exchange LanguageeXtensible Markup
Language (XML)

• Data packaged with interpretation rules
• tailored tags and document structure
• community of interest (namespace) agreement on
  tags structure
• ASCII text ? machine man readable
• DBMS not required to examine schema or retrieve
  data
• users can leverage search engines to locate
  appropriate data sources
• Emerging industry data/metadata interchange
  standard
• Microsoft Office 2000, Oracle 8i
• Messages (USMTF EC/EDI)

Tactical Report encoded in XML
lt?xml version"1.0" encoding"UTF-8"?gt ltTacticalRe
portgt ltMessageIdentificationgt ltMessageIdentifiergtT
ACREPlt/MessageIdentifiergt ltOriginatorgtCTF
124lt/Originatorgt lt/TacticalReportgt
End Tag
Begin Tag
Value
9
COE 4.x Data Sharing Techniques
COE Applications
App
COP
App
GCSS
Browser
Java Classes
API Layer
C Interface
JDBC
ODBC
Integrated Data Object Model (UML)
Mediation
Data Access Mechanism
Base-level Objects
Data Source Connectivity
XML
GSORTS
JTAV
Portal (JCC)
Data Sources
Medium
TDBM
GF
XML
HTTP
XML- Web
(JCC)
Shared Data Server
Tightest
Loose
Common Representation
10
XML is GREAT, BUT . . .

• Management Required for Interoperability
• Conflicting XML must be avoided!
• Tags with overlapping definitions will make
  horizontal integration difficult or impossible
• Each tag must be unique within its namespace
• Without aggressive management

COE Developers Asking for Help!!
XML Tower of Babel
11
Principles which shapeMarket-Driven Data Strategy

• Focus on Common implementable Components
• Seek commonality mainly within Communities of
  Interest (COIs)
• Develop common representations for 20 of data to
  satisfy 80 requirements
• Create market environment to exploit survival of
  fit data representations in various domains
• PMs and their engineering staffs are primary
  marketplace players
• Provide visibility for existing implementations
  thru Data Component registry with low barriers to
  entry

12
Data Component Market
Acquisition Review Processes
Electronic Mktplace


Chief Engr
Data Engrs
Common Infrastructure Program
Simple, non-bureaucratic organization
Program Data Engineers
PMs
Info Systems Programs
13
XML Governance . . .COE Approach

• Sticks
• Distribute accountability
• Set reasonable interoperability technical goals
• Measure progress version-to-version
• Carrots
• Reduce developers cost, schedule, risk
• (give em components that are tested and free)
• Enablers
• Common Representation
• XML Registry (market visibility service)
• Namespace (communities of interest) concept

14
Market for XML Tags

• Developers KNOW they need matching tags
• Must be easy to locate and down-load
• Developers come from multiple communities with
  different but overlapping semantic legacies
• C2, Intell
• Combat Support Logistics
• Personnel/Medical
• Finance
• XML tied into other data engineering initiatives
• Re-use previous investments in Battle space data
  definition
• Need XML Tags and Valid Values ASAP

15
COE XML Management Structure

• Visibility Service
• XML Registry within COE Data Emporium
• Coordination
• XML Sub-panel to COE Data TWG (SSD-MD)
• Individual Community CM venues
• Must deal with other DoD, Allied, and Commercial
  XML activities
• XML CM Responsibility
• distributed across COE Engineering Staff and
  Namespace Managers

16
What is a Namespace?

• A set of names that are managed by
  Agencies/activities/system builders/PEOPLE who
• Share a relatively discrete Subject Area
• common world view
• common abstractions, common data representations,
  and common metadata.
• Publish existence of Namespace AND available
  XML documents so that outsiders may
• discover XML tags
• assess whether or not they want to use them
• download XML for re-use

17
XML Namespaces

• Definition a collection of names, identified by
  a URI reference
• namespace prefix (COE) serves as a proxy for a
  URI reference (COE_Enterprise)
• Example xmlnsCOEhttp//diides.ncr.disa.mil/xml
  reg/COE
• Purpose to distinguish homonyms
• tank as large vessel for storing fuel
• tank as armored vehicle
• Status W3C Recommendation (14-January-1999)
• Example of Qualified Tag ltCOECTRY_NMgt
• Example XML Fragment
• ltCOECTRY_NMgt AFGHANISTAN lt/COECTRY_NMgt

Namespace Prefix
Separator
Tag
Source http//www.w3.org/TR/REC-xml-names/
18
Guiding Principles for COE XML Registry

• Technical requirement
• Ensure uniqueness of tags and schemas in use
  (e.g., port assignment on network)
• Management Objectives
• Provide opportunity to identify synonyms across
  namespaces
• Arrange process to converge identified synonyms
  within a CM process using a cost-benefit,
  prioritization basis

Purpose is uniqueness via visibility, not
standardization through coercion!
19
Market Visibility ServiceCOE Data Emporium
XML guidance for developers Registry of tags,
data structures, and DTDs
COE Data Components

• Reference Data Sets
• FIPS ISO Country Codes
• Ship Control Number
• Database Segments
• Organization
• Facilities
• Plans
• Integration Views
• GCSS UML Model
• FIPS to ISO country cross-reference
• XML Registry

Key to Consistent Interpretation of XML Data
20
COE XML Registrycontains many types of
relationships
XML schema Maintenance Schedule
contains
XML schema ATO confirmation
contains
XML_Element latitude
XML_Element helicopter_type_and_model
Is styled by styles
Is constrained by
Domain helicopter_type_and_model domain
XML Stylesheet ATO as Gantt Chart
21
Leveraging a 30-year investment in semantics
3141 in generalized domain for aircraft! 648 in
specialized domain for helicopter!!
22
Lessons We Share

• Leveraging current investment - USMTF and XML
  conceptually the same, yet
• Punctuation
• Spaces, Commas, Quotes, Apostrophes, Leading
  digit, Parens, Slashes, Hyphens
• Duplicates
• Composite (aggregations or complex) tags
• Must be named uniquely
• Deconflicted with atomic tags
• Security Concerns
• Release-ability (FUD vs Group vs Set vs Segment
  vs Msg)
• Registration process provides additional quality
  control
• USMTF head start over industry
• Configuration Mgmt process in place
• Large constituency
• Represents an extensive set of common concepts,
  complete with valid values
• Not just a specification, but also an
  implementation

23
Notional use case for Registry
In Registry Information Resource
Namespace MSG Name HELICOPTER_TYPE_AND_MODEL
Version 1.0.0 Description A
non-negative, decimal amount used in
transactions. Data Type STRING(6)
Domain 2000_513_2_helicopter_type_and_model.xml
In DTD lt!ELEMENT HELICOPTER_TYPE_AND_MODEL
(PCDATA)gt lt!ATTLIST HELICOPTER_TYPE_AND_MODEL
xmlnsnsname CDATA FIXED 'http//diides.ncr.disa.
mil/xmlreg/MSG' xmlnsversion CDATA FIXED
'1.0.0'gt In XML document lt!DOCTYPE ATO SYSTEM
ato.dtd"gt ltHELICOPTER_TYPE_AND_MODELgtAB206Alt/HELI
COPTER_TYPE_AND_MODELgt ltHELICOPTER_TYPE_AND_MODELgt
AH1Glt/HELICOPTER_TYPE_AND_MODELgt
AB-206A JETRANGER
AH-1G HUEY COBRA
24
Recommendation 1(XML Tag Registration
Requirement)

• Configuration Review Control Board (CRCB) direct
  (via IRTS 4.0) COE Developers using XML for
  public interfaces to
• Consult XML Registry before creating new Tags and
  reuse existing XML where practical
• Indicate planned use of Registered Tags by
  formally subscribing to them
• Submit (where required)
• additional XML tags (and amplifying information)
  or
• recommended modifications to existing tags

Approved
25
Recommendation 2 (Management of Namespaces)
With CRCB concurrence, DII COE Chief Engineer
will Charter selected agents to manage XML
Namespaces Example USMTF Program AO to manage
XML-MTF tags Manage COE Enterprise Namespace
Approved

• CRCB Response
• Namespace Managers Roles and Responsibilities
• Candidate Namespaces

26
Namespace Management Tasks

• Coordinate Stakeholders
• Establish and Run Coordination Venue(s)
• Resolve Issues within Namespace
• Coordination across Namespaces
• Oversee Development of XML Documents, DTDs, XSL
  style sheets
• Submit Information Resource Packages to XML
  Registry
• Approve Tags and Publish Status
• Perform Versioning

27
Namespace Selection CriteriaK.I.S.S.

• START SMALL!! Dont want lots of Namespaces
• Dont want to create NEW organizations
• Look for existing Data groups (stay at PM level)
• Capitalize on investment in Data Stores/ Messages
• Look for existing Data Resources (which can be
  efficiently converted to Tag Starter sets)
• Look for Key Data Resources on which mainline
  C2I/CS systems depend to form XML Starter Sets
• Management load distribution
• Look for a few complementary Namespaces which
  cover C2I/CS requirements

28
Namespaces and Designated Managers

• COE Enterprise/DISA
• COE Chief Engineer
• Ground Operations/Army
• PM for JCDB
• General Military Intelligence/DoDIIS
• PM for MIDB
• Aerospace Operations/USAF
• AF Common Data Environment staff
• Messages/DISA
• Chair USMTF Configuration Control Board
• Tracks and Reports/Navy
• Common Track Data Store Engineer
• Geospatial and Imagery/NIMA
• NIMA Engineer
• METOC/Navy
• Principal on developer of meteorological and
  oceanographic models
• Combat Support/DISA
• GCSS Engineer

29
XML Convergence Process

• AOG and CRCB designate namespaces managers
• Overlap among Namespaces is inevitable
• Namespaces as Buckets for in-use XML
• Entry points for XM L Registry submissions
• Status mechanism (developmental, candidate
  approved) provides ability to express preference
• COE Enterprise Namespace holds preferred XML
• Identified and approved by Chief Engineer
• SSD-MD Subpanel as Namespace Managers Forum
• Each Namespace has collaborative venue
• Registry provides XML Market visibility
• Includes system and developer usage information

30
Proposed Additional Namespaces

• Personnel/DIMHRS (Bob Buckley)
• Defense Integrated Military Human Resources
  System
• Finance/DFAS (Wayne Bodle)
• Defense Finance and Accounting System

31
The Race for XML Mgmt Guidance

• COE Configuration Review Control Board
• NATO
• Data Systems Interoperability Panel (DP),
  Military Communications Electronics Board
• Joint Battle Center
• Office of Secretary of Defense
• DoN XML Implementation Guidelines
• Intel Community
• AF XML Policy
• OSD Acquisition and Technology

32
DII COE XML Registry

• IOC 17 May 1999
• Public Access
• Password protected
• Secret coming soon
• CRCB Approved
• XML Registration
• Namespace Creation
• Namespace Status
• 9 Approved, 2 more Proposed
• Registration Status
• 7K elements
• NATO request for software

http//diides.ncr.disa.mil/shade
33
For more information contact

• COE Chief Engineer Mr. Kenneth Wheeler -
  wheele1k_at_ncr.disa.mil
• Mr. Pete Pasek - pasekp_at_ncr.disa.mil
• Mr. Jim Pipher - pipherj_at_ncr.disa.mil
• Ms. Toni Weir - weirt_at_ncr.disa.mil
• Mr. Stan Davis - davis2s_at_ncr.disa.mil
• Ms. Ellen Minderman (FGM) - minderma_at_fgm.com
• Dr. Glenda Hayes (MITRE) - ghayes_at_mitre.org

SHADE Data Emporium http//diides.ncr.disa.mil/sha
de
34
BACK-UP
35
XML Registry Payoff

• Enables developers to easily share data
  definitions and valid values
• Obviates need to reinvent data structures
  already available
• Applications can be developed faster-cheaper
  because data definitions and data values are
  reused
• Appropriate metadata can be found easily because
  tags have amplifying information
• Metadata stored in COE-compliant DBMS provides
  for easy access, analysis, and manipulation
• Bottom Line
• Interoperability - System As XML matches System
  Bs XML

Improved service for the warfighter
36
Federated Communities of Interest
COI
COI
COI
COI
COI
More standardized within COIs (tightly coupled)
Less standardized between COIs (loosely coupled)
Need some horizontal some vertical
37
Principles (contd)

• Manage DoD Data Component registry via enterprise
  level engineering organization
• Re-use existing implementable data components
  vice inventing new representations
• Grade Data Components using interoperability
  investment and usage Metrics
• Apply interoperability metrics, usage metrics and
  incentives to evolve commonality among
  representations over time
• Evaluate components in registry using systems
  builders and warrior-customer reps

38
Principles (contd)

• Identify key existing data resources and engage
  their management in distributed CM processes