Enterprise Property Data Model standards
Title : The Enterprise Property data model standard
Purpose : To establish the data standard in the Property subject areas for interoperbility and sharing information resources.
Audience: Data architects, Application developers.
Purpose : To establish the data standard in the Property subject areas for interoperbility and sharing information resources.
Audience: Data architects, Application developers.
Enterprise Location Data model baseline standard
The Enterprise Data Model Standards in the Location subject area.
Title : The Enterprise Location data model standard
Purpose : To establish the data standard in the Location subject areas for interoperbility and sharing information resources.
Audience: Data architects, Application developers.
Title : The Enterprise Location data model standard
Purpose : To establish the data standard in the Location subject areas for interoperbility and sharing information resources.
Audience: Data architects, Application developers.
Enterprise Organization data model baseline standard
Title : The Enterprise Organization data model standard
Purpose : To establish the data standard in the Organization subject areas for interoperbility and sharing information resources.
Audience: Data architects, Application developers.
Purpose : To establish the data standard in the Organization subject areas for interoperbility and sharing information resources.
Audience: Data architects, Application developers.
Person data model baseline standards
The Enterprise Data Model Standards in the persons subject area.
Title : The Enterprise Organization data model standard
Purpose : To establish the data standard in the Organization subject areas for interoperbility and sharing information resources.
Audience: Data architects, Application developers.
Title : The Enterprise Organization data model standard
Purpose : To establish the data standard in the Organization subject areas for interoperbility and sharing information resources.
Audience: Data architects, Application developers.
Data Architecture
1.0 INTRODUCTION
Data architecturse describe how data architecture support the enterprise information structure and business need. The data architecture leverage on the FEAPMO Data Reference Model.
2.0 DATA/BUSINESS ALIGNMENT (Why)
2.1 Data concept
2.2 The CURD matrix
3.0 Data Description (What)
3.1 Data description in DRM
3.2 Data Context
Data landscape
Data dictionary
Enterprise Architecture establish the common data resourses to enable agile and simple informtion managment for enterprise mission need. The fundamental data architecture include enterprise knowledge, people and oranication information, Location and property information and finance information as described in the following sections.
4.0 Data Exchange (How)
4.1 Data sharing
4.2 Information Exchange Matrix
The Information Exchange Matrix documents the Information Exchange Requirements (IERs) for an EA. IERs express the relationships across three basic entities (activities, business nodes and their elements, and information flow) and focus on characteristics of the information exchange, such as performance and security. IERs identify who exchanges what information with whom, why the information is necessary, and in what manner. IERs identify the elements of information exchanged between nodes in support of a particular activity. Relevant attributes of the exchange are noted. The specific attributes included are dependent on the objectives of the specific architecture effort, but may include the type of information media (e.g., data, voice, and video), quality (e.g., frequency, timeliness, and security), and quantity (e.g., volume and speed).
The IEM can be produced at three levels:
• Conceptual Information Exchange Matrix—an essential work product
that describes the prominent, high-level information exchanges between prominent nodes
• Logical Information Exchange Matrix—a supporting work product that describes the design that details all categories and classes of information exchanges, but does not describe the physical implementation of them
• Physical Information Exchange Matrix— a supporting work product that describes the physical characteristics of the implementation of information exchanges.
Particular capabilities such as security level of communications may also be captured for each exchange. This work product emphasizes the logical and operational characteristics of the information, namely, what information is needed by whom, from whom, and when. Table 6 illustrates an example of an entry in the Logical IEM of the US Customs Service EA. In the table, AIS is the automated information system at the source and destination that sends and receives the information exchange and LISI is the Level of Information System Interoperability. LISI is scaled from zero for a totally manual interface to five for a fully electronic connection.
Table 6. Example Logical Information Exchange Matrix
The IEM is not intended to be an exhaustive listing of all the details contained in every IER of every node associated with the architecture. That would be too much detail for an architecture description. Rather, this work product is intended to capture the most important aspects of selected information exchanges. Selecting the important details of the information exchanges depends on the purpose of the architecture description.
The number of information exchanges associated with an architecture may be quite large, even though the matrix may not contain all details about all IERs. To aid in understanding the nature of the information exchanges, developers and users of the architecture may want to view the IER data sorted in multiple ways, such as by task, by node, or by attribute. Consequently, using a matrix to present that information is limiting and frequently not practical. A spreadsheet or relational database is well suited to the highly structured format of the IEM. In practice, hardcopy versions of this product should be limited to high-level summaries or highlighted subsets of particular interest.
This section identify the as-is knowledge management environment, design the target knowledge managment architecture and plan for transition.
5.0 HUMAN CAPITAL DATA MANAGEMENT (WHO)
This section identify the as-is organization and human capital environment, conduct the target data architecture and plan for transition.
6.0 PROPERTY DATA MANAGEMENT (WHERE)
This section identify the as-is of enterprise property and facility environment, conduct the target data architecture and plan for transition.
7.0 FINANCE DATA MANAGEMENT (WHEN)
This section identify the as-is of budget and finance environment, conduct the target data architecture and plan for transition.
Data architecturse describe how data architecture support the enterprise information structure and business need. The data architecture leverage on the FEAPMO Data Reference Model.
2.0 DATA/BUSINESS ALIGNMENT (Why)
2.1 Data concept
2.2 The CURD matrix
3.0 Data Description (What)
3.1 Data description in DRM
3.2 Data Context
Data landscape
Data dictionary
Enterprise Architecture establish the common data resourses to enable agile and simple informtion managment for enterprise mission need. The fundamental data architecture include enterprise knowledge, people and oranication information, Location and property information and finance information as described in the following sections.
4.0 Data Exchange (How)
4.1 Data sharing
4.2 Information Exchange Matrix
The Information Exchange Matrix documents the Information Exchange Requirements (IERs) for an EA. IERs express the relationships across three basic entities (activities, business nodes and their elements, and information flow) and focus on characteristics of the information exchange, such as performance and security. IERs identify who exchanges what information with whom, why the information is necessary, and in what manner. IERs identify the elements of information exchanged between nodes in support of a particular activity. Relevant attributes of the exchange are noted. The specific attributes included are dependent on the objectives of the specific architecture effort, but may include the type of information media (e.g., data, voice, and video), quality (e.g., frequency, timeliness, and security), and quantity (e.g., volume and speed).
The IEM can be produced at three levels:
• Conceptual Information Exchange Matrix—an essential work product
that describes the prominent, high-level information exchanges between prominent nodes
• Logical Information Exchange Matrix—a supporting work product that describes the design that details all categories and classes of information exchanges, but does not describe the physical implementation of them
• Physical Information Exchange Matrix— a supporting work product that describes the physical characteristics of the implementation of information exchanges.
Particular capabilities such as security level of communications may also be captured for each exchange. This work product emphasizes the logical and operational characteristics of the information, namely, what information is needed by whom, from whom, and when. Table 6 illustrates an example of an entry in the Logical IEM of the US Customs Service EA. In the table, AIS is the automated information system at the source and destination that sends and receives the information exchange and LISI is the Level of Information System Interoperability. LISI is scaled from zero for a totally manual interface to five for a fully electronic connection.
Table 6. Example Logical Information Exchange Matrix
The IEM is not intended to be an exhaustive listing of all the details contained in every IER of every node associated with the architecture. That would be too much detail for an architecture description. Rather, this work product is intended to capture the most important aspects of selected information exchanges. Selecting the important details of the information exchanges depends on the purpose of the architecture description.
The number of information exchanges associated with an architecture may be quite large, even though the matrix may not contain all details about all IERs. To aid in understanding the nature of the information exchanges, developers and users of the architecture may want to view the IER data sorted in multiple ways, such as by task, by node, or by attribute. Consequently, using a matrix to present that information is limiting and frequently not practical. A spreadsheet or relational database is well suited to the highly structured format of the IEM. In practice, hardcopy versions of this product should be limited to high-level summaries or highlighted subsets of particular interest.
This section identify the as-is knowledge management environment, design the target knowledge managment architecture and plan for transition.
5.0 HUMAN CAPITAL DATA MANAGEMENT (WHO)
This section identify the as-is organization and human capital environment, conduct the target data architecture and plan for transition.
6.0 PROPERTY DATA MANAGEMENT (WHERE)
This section identify the as-is of enterprise property and facility environment, conduct the target data architecture and plan for transition.
7.0 FINANCE DATA MANAGEMENT (WHEN)
This section identify the as-is of budget and finance environment, conduct the target data architecture and plan for transition.