1 / 26

Mike Lubash 703.607.1166 Mike.Lubash@DFAS.mil XML Team Leader

Proposal: The Establishment of a Task Force within the SHADE Namespace community to address the challenges of the DoD Enterprise. Mike Lubash 703.607.1166 Mike.Lubash@DFAS.mil XML Team Leader DoD Finance and Accounting Namespace Manager. Agenda. Background: DFAS XML Principles

leann
Download Presentation

Mike Lubash 703.607.1166 Mike.Lubash@DFAS.mil XML Team Leader

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Proposal: The Establishment of a Task Force within the SHADE Namespace community to address the challenges of the DoD Enterprise Mike Lubash 703.607.1166 Mike.Lubash@DFAS.mil XML Team Leader DoD Finance and Accounting Namespace Manager

  2. Agenda • Background: DFAS XML Principles • - Stakeholders have a choice - multiple sets of standards • - DFAS endorses SHADE as the mechanism to achieve interoperability • - XML development tenets • Share lessons learned • - Issues uncovered • - Share few key XML constructs • - ‘Address’ artifact candidate to resolve design issues • Are these good constructs? • - Call for Task Force to address issues - no pun intended

  3. DFAS XML Principles Choice: All of DFAS stakeholders have a choice and we cannot control what they choose. There will always be multiple standards and implementations We need to build a management mechanism flexible to support the mission... 1. Register: We will register all XML tags that are used by DFAS applications in the DoD SHADE XML Registry. 2. Alignment: Come to agreement - from both physical and concept levels

  4. Alignment Register Phase 1 Phase 2 Delivering Business Value Relationships Registered Entity Maximum Payback 1 2 3 4 5 6 Collect Catalog Communicate Connect Correlate Contract / Choose

  5. DFAS XML Development Tenets 1 - Work within SHADE on Alignment (Phase II) issues 2 - Public interface centric 3 - Mission Requirements - Align with similar programs / stakeholders (Business and Technical) 4 - DoD Architecture-centric: - Align DoD Architecture concepts to many different physical implementations (map) - CADM (Core Architecture Data Model) as exists de-emphasizes Finance & Accounting support role; i.e. ‘Fund’ is not in CADM 5 - Take the past forward - support legacy environment (map) 6 - Development is business case sponsored and customer-focus

  6. Share Lessons Learned

  7. Challenges & Questions of XML Design & Alignment • Scope: • - Standards:DOD, Federal Government, North America, Global • - Standard/Tool Support:just because one can use the specification to author a schema doesn’t mean that tools can interpret the schema or if it works effectively at runtime • Business Layer: • - Dilution of Constraints:mandatory become optional • - Varying Granularity:resolution differs depending on application • - Codelist:reuse yet subset domain values between communities • Registry: “help from above” • - Multi-field Dependencies:no validation for dependent elements/attributes • - Versioning:create schema and systems that understand change management

  8. Versioning <SFC xsi:noNamespaceSchemaLocation=“D:SFC\XML\SFC_0_02.xsd”> <TreasuryCode versionId=“0.02”> 2. Libraries / Files 1. Roll per logical unit / component (UID) Versioning at the XML Instance

  9. XML Provides Greater Structure and Varying Types We can take great advantage of the ability to hold any type and structure… we can include metadata for describing this... UID Classword Legacy

  10. Choice • Set • Details Expand DoD Classwords to Accommodate XML Structures Classword Three additional classwords to assist in describing XML tree structure:

  11. Choice • Set • Details Classword: Details Collection of differing types to describe a concept or logical unit. One concept Different attributes / types The least restrictive of the three

  12. Choice • Set • Details Classword: Set Collection of children that are of same type - equivalent to a rowset query result from a relational database. <RowSet> <Row> <Value>3</Value> <Title>Library of Congress<Title> </Row> <Row> <Value>4</Value> <Title>Government Printing Value<Title> </Row> </RowSet> Repeating Group

  13. Choice • Set • Details Classword: Choice Where the tree branches for different child types (structures) or differing default values. Schema Instance A Selected B B C D The most restrictive of the three

  14. SHADE Registry UID VI304 Dollars Collaboration Partner #1 Collaboration Partner #2 X12 UnitPrice EDIFACT ListPrice Currency Schema or Template <Rep href= “http://www.SHADE.mil”>SHADE</Rep> <ELEMENTname=‘ListPrice’uid =‘VI304’ > <Rep href= “http://www.SHADE.mil”>SHADE</Rep> <ELEMENTname=‘UnitPrice’uid =‘VI304’ > Schema or Template XML Instance XML Instance Data <ListPrice>9.99</ListPrice> <UnitPrice>9.99</UnitPrice> <Currency>$</Currency> UIDs allow for domain crosswalks and light transactions

  15. Multi-field Requirements 1. Linking additional information, i.e. code list 2. Multi-fields to describe additional structure based on choice Case 1: <Name DoDclassWord="Name">Management & Consolidated Working Funds</Name> Case 2: Just like relational databases, when serializing data we lose important linkage information which we usually document via a paper trail. It would be nice to have a better mechanism.

  16. Multi-field Requirements - ‘ help from above’ In addition to enumeration, we include a reference to a Registry. DCR

  17. ‘Address’ Artifactcanary in a coal mine Resolve Impediments, Architectural and Design Issues

  18. Address (4 approaches) • "DDDS XML" • Mix-n-match • Pick-n-choose • Dual resolution

  19. "DDDS XML" Modeled directly from DDDS addressing the requirements of the DoD and the DoD only.

  20. Mix-n-Match Intermeshing elements from different standards (HR-XML, AR/AP, qbXML, "DDDS XML") into one schema by mapping. Elements from multiple standards intermeshed/mapped

  21. Pick-n-Choose From the root element, allowing the possibility of choosing one of several standards (HR-XML, AR/AP, qbXML, "DDDS XML") and populating just the subtree of the chosen standard.

  22. Dual-Resolution Creating elements to account for the superset of all elements from a set of chosen standards (HR-XML, AR/AP, qbXML, and "DDDS XML"). High and low resolutions are made available for elements where applicable. Low Resolution High Resolution

  23. Dual-Resolution (contd.) The following depicts how we can handle the challenge of exposing two levels of resolution: 1. Simple “PrimaryText” <PrimaryText>1931 Jefferson Davis Hwy, CM-3, Room 315</PrimaryText> 2. More fielded with “PrimaryTextDetails” Global <PrimaryTextDetails> <PrimaryText>1931 Jefferson Davis Hwy, CM-3, Room 315 </PrimaryText> <StreetNumber>1931</StreetNumber> <StreetName>Jefferson Davis Hwy.</StreetName> <BuildingID>CM-3</BuildingID> <Suite>315</Suite> </PrimaryTextDetails> Local

  24. Tradeoffs • "DDDS XML" • Exclusionary (DoD-only thinking) • Limited scope • Mix-n-match • Quickly becomes very complex for developers • Too many confusing decisions for users • Pick-n-choose • Many standards (which to include?) • Complex mappings on the backend to a potential RDBMS • Dual-Resolution • Addresses high and low ends of complexity spectrum but leaves out the middle

  25. Summary • We as namespace managers need to make sure SHADE is in position to provide DoD enterprise alignment to support to our business cases. • - We need to build mechanisms that can record entities and handle relationships to multiple entries/standards • - We need to capture rationale & alignments at business and technical levels • Call for a task force to address critical phase II (Alignment) issues • - Continue work to flesh out solutions to challenges introduced in this presentation • - How do we build on established DoD architecture models? How do we deal with the quality of the DDDS (Defense Data Dictionary System)? • - Define enterprise core components, instances such as ‘Address’, person, organization, etc. and develop the Namespace ‘procedure’ for dealing with any issues raised

  26. Thank you If it isn’t used, it isn’t a standard

More Related