- Baseline Architecture (2K8B)
- The set of products that portray the existing enterprise, the current business practices, and technical infrastructure (commonly referred to as the “As-Is” architecture) (2IXY)
- Business Functions (2K8E)
- High-level set of business activities that are performed by the organization (2IY1)
- Communities of Practice (2K8F)
- Lines of business within the government that are dedicated to the support of business functions (2IY2)
- Data Element (2K8G)
- Physical description of the data used within an information exchange package (2IY3)
- Data Management Strategy (2K8H)
- Forthcoming document that will describe the role of data and data governance within an agency EA (2IY4)
- Data Model (2K8I)
- Representation of the information required to support the operation of any set of business processes and/or the systems used to automate them (2IY5)
- Data Representation (2K8L)
- Describes how data is described within the property and object layers (2IY8)
- Domain (2K8N)
- High-level approach to the categorization of a set of data elements for purposes of organization and standardization (2IYA)
- FEA (2K8O)
- The Federal Enterprise Architecture, a set of reference models intended to support the use of agency EAs (2IYB)
- FEA Business Integration Patterns (2K8P)
- Conceptual approach to using the data from an agency EA in a common way to identify re-usable information technology investments (2IYC)
- Information Exchange Package (2K8R)
- Set of data elements used to support the sharing of data within a particular business context (2IYE)
- Metadata (2K8T)
- Represents information about the data and could include value constraints, naming rules, etc. (2IYG)
- Relational Table (2K8V)
- Set of elements within a database that organizes data in a meaningful way (2IYI)
- Sub-Function (2K8Y)
- Detailed business activities performed in support of a particular business function (2IYL)
- Subject Areas (2K8Z)
- Broad classification of data and super types related to a business context (2IYM)
- Target Architecture (2K92)
- The set of products that portrays the future or end-state enterprise, generally captured in the organization’s strategic thinking and plans; commonly referred to as the “To-Be” architecture (2IYP)
- Transition Plan (2K93)
- A document that defines the strategy for changing the enterprise from the current baseline to the target architecture; it schedules multiple, concurrent, interdependent activities, and incremental builds that will evolve the enterprise (2IYQ)
=========================================================================================== (2JYJ)
Comments (2JYK)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheGlossary_DRM_VolIv1#nid2K8F (2JYL)
- Comment: While Communities of Practice is listed in the glossary, there does not appear to be an explicit explanation of this concept along with a description of its role in the FEA DRM. (agency comment / compiled 2004.12.06) (2JYM)
- Ref: The DRM Glossary (2KGA)
- Comment: Key technology terms are absent. DRM-I does not mention any of the following that we anticipate will be discussed in later volumes: XML (except in a DOI exhibit), Web services, Core Components (as in Core Components Technical Specification), UBL (Universal Business Language), ebXML (E-business XML), ontology, semantics. Knowing that these terms, concepts, and tools will be relevant to the DRM is important to many of the readers of the initial volume, since it may influence their decision to use certain technology. In fact, the only data standard explicitly mentioned is ISO 11179. Since many readers will not be familiar with ISO 11179, a link should be provided. Similarly, any specific standard mentioned should appear in a bibliography. If explicit references are being saved for later volumes, please reconsider this. (agency comment / compiled 2004.12.06) (2KGB)
- Ref: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/TheGlossary_DRM_VolIv1#nid2K8G data element] (2KGZ)
- Comment: Clarify data element concept. The data elements appear to be atomic/low level (core component) type data and don’t reflect the UBL like hierarchy of combining lower level data into higher and higher semantic constructs – what UBL calls “document message assemblies”. IT staff that grew up with RDBMSs will look at the term “data element” and think low level data element – name, not Invoice. Part of the problem is that the examples are primitive data types, e.g., name is text. Also although the term Data Object could be applied to higher level constructs (aggregates of smaller components) there is nothing to suggest that this is a critical aspect of a useful data reference model. (agency comment / compiled 2004.12.06) (2KH1)