- Ref: DataReferenceModel_09_2004 (2KIM)
- Comment: Below are some general questions that we felt were key to addressing in our feedback as we read through the DRM. (2KIN)
- 1. Is the purpose and description of the draft DRM clear? If not, what additional information needs to be provided? (2KIO)
- The purpose and description of the DRM are clear with a general understanding of it’s intended use and future considerations. We understand that it’s primary purpose is to “promote common identification, use, and appropriate sharing of data/information across the federal government. Business and technical outcomes of the DRM were noted in Exhibit B. (2KIP)
- Given these outcomes, we are unclear as to how they will be realized at the federal level to provide value across the agencies. Specifically, several known “opportunities” exist such as 1) developing a common definition and purpose of data, 2) identifying data ownership to the point that data quality and completeness can be achieved, and 3) addressing security/privacy and accessibility concerns. These are challenges that not only are faced just within an agency but are magnified when addressing across agencies. What the DRM does not indicate (and is critical if the purpose and outcomes are to be achieved) is how those challenges will be addressed at the federal level, how an integrated DRM will be established, and how, through use of the DRM, agencies can better manage the quality of their data. (2KIQ)
- The DRM mentions that agencies, through categorization of data, will provide linkages of “data elements” to the BRM - lines of business and sub-functions. However, the data objects, data properties, and data representations are left up to the individual agencies to identify. Without controls and standards/guidelines in place, this leaves open the possibility of similar data objects named differently, incomplete or varying set of attributes, and varying quality controls (e.g. validations). Given this possibility, how can the DRM effectively be used across agencies? (2KIR)
- As one example, consider the following situation: (2KIS)
- Under Support of Delivery of Services, General Government (LoB), Central Property Management may have an FEA DRM data object identified as “Building” with FEA DRM Data Properties, for example, of Name, Address, City, State, Zip, Country. This data may be of interest to Department of Homeland Security (DHS) since they monitor buildings where federal agencies reside. So DHS contacts GSA/PBS to obtain this information only to find out that GSA/PBS addresses are USPS validated (not E911 compliant and validated) and as a result this data is of little benefit to them. At this juncture, what occurs? Who owns the issue? More importantly, who “owns” this data object? How does the data ownership get decided so that cross agency issues can most efficiently be resolved to create a beneficial environment of sharable data across government? If indeed the DRM is to address information sharing, it will have to address data ownership. (2KIT)
- One can take that same example above to address data object naming inconsistencies, data properties that are lacking and need to be added to help another agency, or quality of data that is provided by one agency to another is sub-par. All of these affect the overall purpose and expected outcomes of the DRM. (2KIU)
- It is also not clear how security, privacy, and accessibility will be addressed. It was noted that a subsequent volume of the DRM will discuss this. It may be useful to have the DRM classify data by security considerations, privacy considerations, and whether it is accessible. This additional information can help facilitate agency collaboration of shared data by understanding the breadth of data that other agencies capture and can make available. (2KIV)
- The draft FEA DRM states that DRM is a “framework” to enable data sharing across government but not a data model or ERD, as such it is unclear if the outcome of DRM will include a set of related reference data objects that are common across two or more agencies, and/or a framework/methodology for agencies to define data that is to be shared between them and the data exchange method to be used. Furthermore, the concept of data re-use has a lot of merit, however, data sharing in the context of shared services is far more beneficial and promotes the interoperability goals of the FEA. Although the intent of the FEAPMO is understood, the draft FEA DRM does not articulate how common services in SRM & TRM relate to DRM. Without common services, at best, DRM shall promote proliferation of Point to Point Interfaces which are architecturally undesirable. (2KIW)
- May want to consider a classification of data with respect to it’s storage, retention, and disposal. This information can be useful in agency collaborations to better understand how long data that is desired from another agency will be made accessible and what happens to it after it reaches it’s retention period. Furthermore, it can help ensure cross agency compliance of government regulations on federally “owned” data. (2KIX)
- 2. Does your agency have a good understanding of who the intended users of the DRM are? If not, what additional information needs to be provided? (2KIY)
- The information of who the audience is was very clear in the presentation through the DRM Roadmap Guide. However, it is unclear as to how these audiences will apply the DRM in IT Capital Investment process and in maintaining agency architectures. There should be some examples given to supplement the DRM documentation so that consistency across agencies in mapping the DRM to agency architectures and IT investments is achieved. (2KIZ)
- For example, in the FEA framework, there is a business and data layer of the architecture. The data layer is related to the business processes (through inputs and outputs). Business processes are related to the BRM and in some cases, a business process can be related to multiple LoBs and sub-functions. (2KJ0)
- As such, our agencies' “As Is” EA business process “Develop new construction / renovation project” can map to Service for Citizens LoB : Disaster Management – Disaster Repair and Restore and Service for Citizens LoB : Education, Outreach, and Historic Preservation. How would the data that is input into this business process be categorized? How would data that is output to this process be categorized? Is the categorization based on the data being an output to that process or an input and output? Can categorizations cut across multiple LoBs? If there is an IT investment solely identified for Historic Preservation then how does FEAMs report this data? Specific guidelines can help agencies ensure that the use of the DRM is properly and consistently applied. (2KJ1)
- LoBs are critical in aligning with the DRM, furthermore, they will benefit from DRM in identifying potential data re-use. However, it is the business that owns the data. It is not obvious as to what role the business owners play in the DRM. (2KJ2)
- 3. Does the DRM provide the appropriate framework for assisting your agency in providing a common approach to categorization, exchange, and structure of data for future initiatives or investments? Do you feel the DRM will help promote agency collaboration? (2KJ3)
- There is no doubt that the DRM can become a useful reference model for cross agency collaboration. FEAMs will be a useful tool to help promote this collaboration for process and data represented in agencies’ IT investments. It may be useful however, to categorize data from an agency’s business enterprise perspective rather than limit one to only that data contained in IT capital investments. For example, Department of Homeland Security which relies heavily on data from other agencies as well as state and local governments may find it useful to know information captured by agencies through business processes and address accessibility of that data through discussion with that agency. This may help drive an agency’s future IT investments based on benefits to other agencies. (2KJ4)
- 4. Provide any additional comments or information that you feel would help to improve the DRM. (2KJ5)
- It was noted that there are future volumes of the DRM forthcoming so they might address these other comment areas. But based on the documentation we have reviewed, our additional comments include: (2KJ6)
- a. Will the DRM have any relationship to the TRM in addressing the technology that is currently capturing the data and how the data can be exchanged or will this be implied through the IT capital investments mapping to the TRM? (2KJ7)
- b. For each of the outcomes of the DRM, how should the DRM address how they will be achieved? For example, how will clear data ownership and stewardship be achieved? How will global identification of security and privacy issues and solutions be achieved? How will a common vocabulary and structure be achieved? (2KJ8)
- c. May be helpful to have the DRM address relationships between data objects such as, for example, in the context of a UML Domain Model. This will help organizations understand not only the data objects but relationships that might be of interest. For example, Buildings and Agencies are two sets of data objects that are captured by GSA/ PBS but it may be of interest for an agency to know that GSA/ PBS can provide not only both sets of data objects but also what agencies are in what buildings. (2KJ9)
- d. Will other DRM volumes address issues concerning data accuracy and data cleansing of existing common data? (2KJA)
- e. The Overview and [http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel_09_2004/RoadmapGuide#nid2IW0 Roadmap state that DRM enables agencies to see linkages and commonalities across IT investments. An example to show how this may be achieved would be useful. It is obvious how FEA and its reference models would achieve this, however, it is not so clear how DRM alone may achieve this. (2KJB)
- f. It is not clear how some of the business benefits of DRM can be realized. For example: Facilitation of Electronic Reporting, standards for electronic form design and generation, etc. (2KJC)
