The DRM’s primary purpose is to promote the common identification, use, and appropriate sharing of data/information across the federal government. To meet this purpose requires an approach to the common categorization, exchange, and structure of data. Each of the areas of the DRM is described in the sections following Exhibit C. Exhibit C illustrates the integrated approach of the DRM. (2IW1)
Exhibit C: DRM Approach (2IW2)
The DRM presents a common approach to the categorization of data. To categorize data in a common way, the DRM establishes a Business Context. The business context represents the business use of a given set of data and makes use of the Subject Area and Super Type to further describe the business context of a given set of data. Subject areas represent a high-level set of business functions and are obtained from the FEA’s Business Reference Model (BRM). Super types represent an additional level of definition with the business context and are generally related to specific business activities and/or processes that support the subject area. (2IW3)
Exchange of Data (2IW4)
The exchange of data can be enabled through the DRM’s information exchange package concept. The Information Exchange Package represents the actual message or combination of data that is exchanged between users of the data. The information exchange package brings the business context and data element (described in the structure of data section) together to define how a common transaction (the exchange of information and data) might appear. Exhibit D illustrates the information exchange package concept. Future volumes of the DRM will continue to expand on the definition and scope of the information exchange package. (PO)
Note: The information exchange package can apply to data that is transmitted or to data that is shared or retrieved. (2IW5)
Exhibit D: Information Exchange Package (2IW6)
Structure of Data (2J0D)
The DRM uses the Data Element to describe the structure of data within a given business context. The structure of data is comprised of three elements adapted from the ISO/IEC 11179 standard. The Data Object is the set of ideas, abstractions, or things that can be identified with explicit business meaning and whose properties and behavior follow the same business rules. In the context of population health management, for example, the data object could be a vaccination. To further define the data object, the DRM’s approach uses a Data Property and a Data Representation. The data property describes the data element. In the population health management example, the data property could be name, weight, potency, etc. (of a vaccine). The data representation is the value type of the data object. For example, representations could be plain text, integers, whole numbers, etc. (PS)
================================================================================================ (2JRY)
Comments (2JRZ)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/OverviewOfThe_DRM_VolIv1#nid2IW1 (2JX9)
- Comment: Establish the relationship between data stewardship and enterprise-wide definition and reuse of Categorizations and Structures of Data. (2JXA)
- Introduce stewardship as an explicit construct in the DRM. To meet its common identification/data sharing goals, the DRM needs to explictly introduce the concept of data sourcing patterns and data stewardship. In informal comments on earlier drafts of the DRM, there was support expressed for the insertion of the horizontal axis (information exchange) into the classical, vertically-oriented approach to data categorization. In order to fulfil the promise of the horizontal view, the FEA needs to analyze business processes and data products together and identify the best source and steward for data that needs to be widely shared. In fact, witness the wide re-use of Census data in the federal government, the government is adept at re-using data that is difficult or prohibitively expensive to re-collect. As processes become more interconnected, progress is being made concerning data that is relatively easy to repeatedly collect but difficult to maintain consistently in different sources (business partner identifying information). At least two relatively new data sourcing patterns are emerging in service-oriented applications: single sourcing of key data (birth registry data subscription, business partner identification) and multiple sourcing of data exchanged according to a single standard for activities shared at multiple levels of government (law enforcement). Continued progress in data sharing requires the creation of data stewardship accountabilities that align with the desired patterns of data sourcing. Whether single or multiple sources, the original sources of key data, that is, its stewards, need to understand explicitly the downstream requirements on data they create and collaborate with representatives for the whole value stream of the data to ensure that it is structured and managed so as to be fit for enterprise purposes.(agency comment / compiled 2004.12.06) (2JXC)
- Comment: Establish the relationship between data stewardship and enterprise-wide definition and reuse of Categorizations and Structures of Data. (2JXA)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheFoundation_DRM_VolIv1#nid2IWR and http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/OverviewOfThe_DRM_VolIv1#nid2IW3 (2JWZ)
- Comment: Explicitly define and manage the relationship between the layers/components/levels of Categorization of Data. Explictly define and provide for the horizontal management of Super Types necessary to achieve the DRM's stated goals of a) common identification and b) sharing of data. (2JX0)
- Fully aligning subject area with business area, as the DRM proposes, is a valid and simplifying assumption to use as the foundation for the DRM categorization schema for data. However, data has a horizontal relationship to business processes (i.e. it moves across processes). The choice of Business Area/ Subject Area alignment as the foundation of the DRM categorization schema therefore puts constraints on the definition and management of Super Types that must be explicitly recognized and provided for in the DRM: Because data moves between business areas, different business areas will use the same Super Types. (2JX1)
- To facilitate common identification and sharing, therefore, the same Super Type identified by the same name and definition must occur in multiple business/ subject areas, because a) some business areas supply information to downstream business areas (financial funds management supplies funding allocation information to grants management funding opportunity development) and b) multiple business areas today re-create information that, in the best environments we can build today, would be provided definitively by another source (Central Contracts Registry/ Business Partner Network would supply grantee identifying information to Grants.gov, who would pass the same information through to the grantor as part of the grant application package). (2JX2)
- Since the multiple re-sourcing and/or underuse of single authoritative sources for common data is the problem the DRM wants to address, the DRM needs to explicitly acknowledge that multiple Subject Areas will have the same Super Types and that the true usefulness of categorization is to identify the common Super Types across Subject Areas, name them the same way, identify the existing and needed data exchanges that support data sharing, and get the needed exchanges built. (agency coment / compiled 2004.12.06) (2JX3)
- Comment: Explicitly define and manage the relationship between the layers/components/levels of Categorization of Data. Explictly define and provide for the horizontal management of Super Types necessary to achieve the DRM's stated goals of a) common identification and b) sharing of data. (2JX0)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/OverviewOfThe_DRM_VolIv1#nid2IW3 (2JS0)
- Comment: This agency uses the information engineering rule that a subject area is defined by a kernel entity. A subject area is a logical collection of entities based on a major resource of an enterprise. A subject area consists of a cohesive set of entities that are used by common business activities. This cohesive set of entities contains one kernel entity type that forms the “back bone” of that subject area. Kernel entities represent a business object that can be identified independently of other entities. Kernel entities are the parent entities. It is recommended that this rule be used to define DRM Subject Areas as it is clear, leads to non-redundancy and avoids defining or identifying data in a way that is dependent on function. The Draft DRM uses the term “subject area” differently. Why use a well recognized term in data management in a completely different way? It is recommended that another term should be used or the DRM subject area ought to use the above definition of subject area from information engineering. (agency coment / compiled 2004.12.06) (2JS1)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/OverviewOfThe_DRM_VolIv1#nid2IW3 (2JU8)
- Inconsistencies exist between the textual descriptions and the examples of the Subject Areas: While the DRM states here in Section 2 that the Subject Areas represent a high-level set of business functions and are obtained from the FEA’s Business Reference Model (BRM) and in Section 3 implies that Subject Areas in the DRM equate to Sub-functions in the BRM, the examples - Exhibit E: DRM Example and Exhibit H: Use of the DRM do not support this statement. (agency comment / compiled 2004.12.06) (2JUA)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/OverviewOfThe_DRM_VolIv1#nid2IW3 (2KFY)
- Comment: A single DRM or Multiple Agency-specifi DRMs? The Department of Homeland Security is developing a DRM and taxonomy to suit its purposes. Either that will heavily influence the development of a government-wide DRM or other agencies will follow DHS' example and create their own specific DRMs. Is the intent to have a single taxonomy or multiple distinctive taxonomies? Whatever the result, would that help or hinder federated queries across the Government? (agency comment / compiled 2004.12.06) (2KFZ)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/OverviewOfThe_DRM_VolIv1#nid2IW3 (2K4Q)
- Comment: This paragraph states that the Subject Areas “are obtained from the FEA’s Business Reference Model (BRM)”. As such, it now appears that Subject areas are not even DRM constructs. Based upon the definition that a subject area is a function, this makes complete sense. However, as a BRM construct, it then appears that the “ownership” of Subject Areas is outside the scope of the DRM. Therefore, it would seem that the Subject Area construct, and even possibly the Super Type, as functions and processes, would be more appropriately defined and referenced within the BRM, not the DRM. (agency comment / compiled 2004.12.06) (2K4R)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/OverviewOfThe_DRM_VolIv1#nid2IW3 (2JXM)
- Suggested Change: Please rename the construct Super Type. Both type and class are industry standard terms that present problems as names for components in a categorization scheme. Information Groups is an industry standard term that would do as a replacement. (agency comment / compiled 2004.12.06) (2JXK)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/OverviewOfThe_DRM_VolIv1#nid2IW3 (2JY7)
- Comment: The FEA DRM Volume I discusses the DRM concepts and ties it directly to the BRM. However, it fails to mention any relationship to the SRM or TRM. While the BRM offers a business context to the data, the SRM facilitates the transactions of a business process, while the TRM identifies the access channels and other tools needed to support the use of data. (agency comment / compiled 2004.12.06) (2JY8)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/OverviewOfThe_DRM_VolIv1#nid2IW3 (2JYB)
- Comment: The FEA DRM indicates that the BRM is the data categorization taxonomy. Fundamentally, data may satisfy the needs of more than one business function. Using the BRM as the data categorization taxonomy risks redundancy from a data taxonomy standpoint. In the accompanying powerpoint presentation, slide 22 states, “The DRM establishes a common taxonomy around which agency can categorize their data”, but slide 49 states, “The BRM is the taxonomy.” The messages are conflicting and hard to interpret. The FEA DRM should be the mechanism that provides a taxonomy supporting the business functions and sub-functions in the BRM. Data in the data taxonomy can conceivably serve the needs of more than one business function in the BRM taxonomy. (agency comment / compiled 2004.12.06) (2JYC)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/OverviewOfThe_DRM_VolIv1#nid2IW3 (2JYD)
- Comment: Under categorization of data, do not concur with the FEA DRM definition for data subject areas. The FEA DRM defines data subject area as follows: “Identifies lines of business which perform activities that create and use closely related information to achieve similar outcomes.” In practice, data subject areas are groupings of data categorized to support the business functions and processes. (agency comment / compiled 2004.12.06) (2JYE)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/OverviewOfThe_DRM_VolIv1#nid2IW3 (2K1U)
- Comment: It is not possible to create a single taxonomy (such as business context) to define the meaning of messages. Classification diversity is important. The DRM defines "categorization of data" as "business context" as defined by the BRM. Business context is not a sufficiently rich method of defining meaning of messages. "Categorization of data" should not merely refer to assigning objects to a category within a single hierarchy, but should embrace the numerous ways that meaning is described, including: (2K25)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/OverviewOfThe_DRM_VolIv1#nid2IW3 (2K3G)
- Comment: We use the information-engineering rule that a subject area is defined by a kernel entity. A subject area is a logical collection of entities based on a major resource of an enterprise. A subject area consists of a cohesive set of entities that are used by common business activities. This cohesive set of entities contains one kernel entity type that forms the “back bone” of that subject area. Kernel entities represent a business object that can be identified independently of other entities. Kernel entities are the parent entities. It is recommended that this rule be used to define DRM Subject Areas as it is clear, leads to non-redundancy and avoids defining or identifying data in a way that is dependent on function. The Draft DRM uses the term “subject area” differently. Why use a well-recognized term in data management in a completely different way? It is recommended that another term should be used or the DRM subject area ought to use the above definition of subject area from information engineering. (agency comment / compiled 2004.12.06) (2K3H)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/OverviewOfThe_DRM_VolIv1#nid2IW3 (2K3Y)
- Comment: It appears that the Business Context layers of Subject Area and Super Type could easily overlap, as there is no guidance on how to objectively bound these layers. Presumably, as these are BRM constructs, the methodology involved in bounding these two layers is, or will be, addressed in the BRM. However, this implies that these two constructs really do not belong in the DRM. (agency comment / compiled 2004.12.06) (2K3Z)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/OverviewOfThe_DRM_VolIv1#nid2J0D (2JX6)
- Comment:Explicitly define and manage the relationship between Data Objects/ Data Properties/ Data Representations in multiple Information Exchange Packages categorized by the same Super Types. (2JX7)
- Rather than employ the classical structural approach to categorizing and defining data that views data independently of its business context, the DRM a) aligns Subject Areas with Business Areas and b) supplements the data categorization hierarchy in the middle by introducing the horizontal concept of Exchange of Data. This is, again, a valid and simplifying assumption for the DRM framework (see comments on Categorization of Data above). However, the choice again puts constraints on the definition and management of Data Objects, Properties and Representations and their relationships to multiple Information Exchange Packages and multiple Super Types. These relationships are not explicitly provided for in the DRM framework and must be provided for in order for it to fulfill its common identification/information sharing objectives. The DRM needs to explitly acknowledge that multiple Information Exchange Packagess and, potentially, Super Types, will have the same Data Objects and Properties, name and define Objects and Properties the same way in different Information Exchange Packagess, identify the most important property and representation standardizations that would enable rapid construction of Information Exchange Packages (state codes, county codes, date formats), and get the foundational standards and stewardship relationships built.(agency comment / compiled 2004.12.06) (2JX8)
- Comment:Explicitly define and manage the relationship between Data Objects/ Data Properties/ Data Representations in multiple Information Exchange Packages categorized by the same Super Types. (2JX7)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/OverviewOfThe_DRM_VolIv1#nid2J0D (2K2N)
- Comment: We understand the intent of the "Structure of Data", but are not exactly sure where this is leading. The alias "Data Element" is a bit troubling. In the first section, the alias is "Business Context". Perhaps a better alias for this section would be "Application Context" or "Implementation Context". The terminology "Data Object", "Data Property" and "Data Representation" is used to refer to the more common terms Entity, Attribute and Data Domain. Our recommendation in this area, unlike the first section, in which we thought the Federal Enterprise Architecture (FEA) should establish a true reference model with standard data objects, but to let this section be largely established at the department or agency level, and aligned with objects in the "Business Context" level. Maybe that’s the intent, but it's not totally clear. (agency comment / compiled 2004.12.06) (2K2O)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/OverviewOfThe_DRM_VolIv1#nid2J0D (2K4M)
- Comment: The section “Structure of Data” seems quite consistent with 11179. (agency comment / compiled 2004.12.06) (2K4N)
- Suggested Change: In the second sentence of this paragraph, the simplest solution is to delete the word actual: in a model, which the DRM is, the components represent the schemas for actual messages, not the actual messages themselves. (agency comment / compiled 2004.12.06) (2JXI)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/OverviewOfThe_DRM_VolIv1#nidPO (2KFW)
- Comment: Better for Transactional that Relational Data? The DRM-I may work better for transactional data than for relational data; for example, for doing electronic commerce business but not for agency web site content nor for agency email content. Perhaps this is intentional. Unstructured data such as web site content and email do not seem to be included in the DRM. Interoperable sharing of email may raise significant security and privacy issues. If the DRM is aimed exclusively at transactional data, this should be clarified. (agency comment / compiled 2004.12.06) (2KFX)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/OverviewOfThe_DRM_VolIv1#nidPO (2JXH)
- Comment: According to our understanding of the Gartner Group’s recent database market analyses, relational DBMS’s will continue to dominate the market for database implementations for the next decade. New developments and needs (BLOBs, etc.) are expected to be met through the RDBMS products on the marketplace today and systems will be built using RDBMS’s predominantly. If this view is correct, then there is a continuing need for entity-relationship diagrams since they translate readily into physical models for RDBMS implementation. (2K43)
- In light of that, we suggest that the DRM augment its term “data object” with “data entity”. Entities can be augmented with and mapped to lists of objects for support of object-oriented systems design work. This would also fit with using the information engineering definition for “subject area”. (2K44)
- By issuing only Volume I at this time, it makes it difficult to review and comment on this top-level approach without knowing the tangible underpinnings. As a result of the above, the draft DRM seems to be divorced from existing data methodologies and seems to be striving to invent its own approach. If the DRM is intended to be at a very high or abstract level, perhaps divorced from systems life cycle methodologies (particularly design and development), then it needs to state that. Currently, it describes its relationship to data exchange. It might help if the DRM described its linkage to system life cycle development methodologies more clearly. (agency comment / compiled 2004.12.06) (2K45)
- Comment: According to our understanding of the Gartner Group’s recent database market analyses, relational DBMS’s will continue to dominate the market for database implementations for the next decade. New developments and needs (BLOBs, etc.) are expected to be met through the RDBMS products on the marketplace today and systems will be built using RDBMS’s predominantly. If this view is correct, then there is a continuing need for entity-relationship diagrams since they translate readily into physical models for RDBMS implementation. (2K43)