1 / 9

FEADRM Person

FEADRM Person. Person Harmonization Workgroup Data Architecture Subcommittee Meeting January 11, 2007. Gathering Information. We asked those on the workgroup to share their models of PERSON with us.

remedios-valdez
Download Presentation

FEADRM Person

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. FEADRM Person Person Harmonization Workgroup Data Architecture Subcommittee Meeting January 11, 2007

  2. Gathering Information • We asked those on the workgroup to share their models of PERSON with us. • We received documents from the Department of the Interior (DOI), the Veterans’ Administration (VA), the Federal Aviation Administration (FAA), and the Environmental Protection Agency (EPA). • You can view them on CORE.gov at https://collab.core.gov/CommunityBrowser.aspx?id=10833

  3. Analyzing the Data • We compared the entities and attributes from all the documentation. • We created an Excel Workbook. • The first sheet contains all the entities and attributes from each model. • The second sheet contains a mapping of the entities from the other agencies to those of the Social Security Administration (SSA) • The third sheets contains the entities, attributes, and their definitions from the SSA FEADRM Model • The Excel document is named ‘Person Entities and Attributes from Various Feds’ and you can view it on CORE.gov at https://collab.core.gov/CommunityBrowser.aspx?id=11682

  4. Producing a FEADRM PERSON Model • We started with an extract of the SSA Enterprise Data Model (EDM). We model using entity relationship diagrams (ERD) in the ERwin tool. • We adjusted it to make it less SSA-centric and to include granularity required to span agencies. • We named it ‘Federal Enterprise Architecture Data Reference Model Person’and defined it as “This Business Data Model (BDM) is a view of the United States Government Enterprise Data Model (EDM) containing the data required to support the characterization and relationships of a uniquely identified person.” • You can view it as a pdf document on CORE.gov at https://collab.core.gov/CommunityBrowser.aspx?id=11892.The ERD starts on page 3 and the subject areas are in alphabetical order. If you have ERwin, contact us and we can send you the model in that format.

  5. Observations • A data model should have a point of view, we should have a common one at the Federal level. • Everyone should be modeling business data rather than creating logical data base models. • PERSON is probably the area in which resides most of the non-administrative sharable data. This is what we at SSA call “common shared.” • The definition of business concepts represented by entities at the “top” of the data model should not be in terms so rigorously tied to the business of any one agency. • Data that are “regulated” require formal agreement to be sharable. • PERSON cannot be addressed in a vacuum. The concepts of organization, party, and role should be addressed at the same time.

  6. Challenges • Allowing aliases in naming without underlying concept creep • Identifying an authoritative source for a concept • Formalizing a vocabulary for naming • Agreeing on the description notation at the Business Reference Model level • Managing configurations and versions • Structuring a process for DRM governance

  7. SSA Disciplines • Lexicon of Terms • Rigorously enforced naming standards • Logical value tables • Business Data Models (views of Enterprise Data Models that support specific business functions or projects.) • Availability of the above on the SSA intranet website

  8. Proposed Next Steps • Sponsor a conference call to discuss these artifacts • Publish DRAFT Scope Statement • Publish DRAFT Objectives • Establish guidelines for BRM relationships • Establish guidelines for SRM relationships • Initiate contacts to evaluate NIEM • Establish guidelines for data exchange

  9. SSA Contacts • Bob Ridgely OESAE Technical Advisor for Data Administration & Enterprise Architecture 410.965.3849 Bob.Ridgely@ssa.gov • Kay Sybert SSA Enterprise Data Modeler DCS, OESAE, DEADA 4-M-19-a Operations 443.514.7531 kay.sybert@ssa.gov • Nicholas Martin SSA Business Data Modeler OESAE/ DEADA/ DAB nicholas.l.martin@ssa.gov 410.965.5669

More Related