Consolidated Guidance: Describing the Data Stores and Related Technologies
| Guidelines |
Synopsis
The data store and rule definitions describe the Agency-wide data repositories and how the integrity and validity of the data will be maintained. This document provides some initial suggestions for what to consider when creating and updating these descriptions.
Guidelines
-
Consider the types of user for this information. The following individuals may use the service descriptions:
-
A-TARS Service Designers and Builders. Services may abstract and hide the data source implementation from the rest of the applications (e.g., DOM , SAX , or Microsoft ADO ). Templates may also be provided to build business logic components. Members of the architecture and IT project teams that define or use data access services must coordinate with authors of these descriptions.
-
Database Design and Administration Specialists. Those that will implement and maintenance the design on a specific data storage and retrieval technology rely on the guidance contained within these descriptions.
-
Business Analysts. Those that will define and update the business rules for each specific application system use this information to determine how to record and manage the business rules.
-
Quality Assurance. These individuals confirm that the implementation of the data stores and related technology conforms to the description, checking for consistency, noting and reconciling discrepancies.
-
Consider all the usage environments .
-
Consider the following when describing the data stores and message formats:
- Data store design (e.g., data models, implementation guidance, and formats such as MP3 or DVD+RW ).
- Data element and message descriptions (e.g., data dictionaries, data definition languages, DTDs , or schemas).
- Data size and use estimates (e.g., expected size and growth, transaction rates, and peak access times).
- Functions such as data security, integrity, privacy, records retention, backup, disposition, auditing, logging, and replication.
- Data storage/access technology (e.g., relational, compound documents, flat files, data manipulation languages, data compression, and caching).
- Data management policy, procedures, responsibilities for administration, backup, and disaster recovery.
- Standards that apply to data definition and modeling, manipulation and how they have been adapted (e.g., IDEF1X , SQL , XML ), referring to and updating the agency standards , as needed.
- General guidelines (e.g., normalization, application-specific parameter storage, naming conventions, data modeling conventions).
- Establish responsibilities for defining, managing, and sharing data across different levels of ownership (e.g., personal, workgroup, departmental, and Agency).
- Reference published items such as business documentation and existing data stores as identified in the IT inventory created during the strategic planning, as applicable.
-
You need to define only those data sources that will be used across the Enterprise. Provide guidelines on handling program-unique data.
- In addition to the data sources, describe the management, security, integrity, growth, and other life-cycle aspects of Enterprise-wide data management policy and procedures.
- Specify technology for ad hoc data retrieval, as needed.
-
Consider the following when describing the rules and rule processing technologies:
- Identify Agency-wide policy and practices documentation as the basis for common business knowledge (e.g., HS program regulations), adding these to the list of agency standards , as needed. Analyze existing systems (code) to recover existing rules and their sources.
- Establish general guidelines or conventions, such as:
- Isolating business rules from the application logic that uses the rule
- Specifying, abstracting, and modularizing rules
- Verifying rules and their implementation
- Life-cycle management of rules, such as ownership and how rules are changed and maintained
- Establishing, administering, and controlling a repository for the rules
- Catalog specific rules as applicable, organized around a taxonomy, such as rules on data presentation, processing/state transitions, data access and integrity, domains, relations, and data aggregates.
- Identify the rule sources, such as by policy classes: Federal, State, County, Agency, HS program, department, etc.
- Use prototypes or reference implementations for rule processing.
- For all the descriptions, consider including the following information:
- Implementation notes or guidelines to implementing the data store or rules. Delegate generic guidelines to the Technical Guidelines Descriptions , as needed.
- Identify the basis on which the data entities, message formats, or processing technology is described (e.g., SQL as described in the ISO/IEC 9075 series). This includes any adaptation of the standard. Compile the list of standards in use throughout the Agency within the Standards Reference Set and reference them from each description.
- When necessary, suggest preferred implementations.
- Provide any expected modifications to the definitions and the time frame. This is particularly necessary for early adopters of a technology, especially if the basis for the description (the standards) is still under review and not yet formally approved.
- Specify guidelines to help ensure conformance to the definitions.
- Reference the specific instances of source documents (e.g., business process models, vendor materials) that provide insight into the definitions.
- The descriptions should be formally reviewed before finally approved. Techniques such as Peer Reviews ( CMU SEI 1995 ) can be used to structure these reviews. Individuals representing the users of the descriptions should attend.
- Changes to the any part of the description need to be evaluated in terms of the impact to the applications implemented to the description. These evaluations will take place during the change processing described in the Manage Technical Architecture Activities .
- Place all descriptions under change control, allowing for different versions of each description to be tracked.
