EA3 artifact

EA3 artifact D-7: The State Transition Diagram

The State Transition Diagram uses the notation from the Unified Modeling Language (UML) to show how the lifecycle of a specific data object. This diagram shows changes to attributes, links, and/or behavior(s) of the “On-Line Order” object that are a result of internal or external system events which trigger changes in state.

EA3 artifact D-6: The Activity/Entity Matrix

An Activity/Entity Matrix is developed by mapping which data entities are affected by related line of business activities. Often called a ‘CRUD’ matrix because it identifies the basic types of transformations that are performed on data (Create, Read, Update, Delete) through a process.

EA3 artifact D-5: Physical Data Model

The Physical Data Model (PDM) is used to describe how the information represented in the Logical Data Model is actually implemented in an information system. There should be a mapping from a given Logical Data Model to the PDM. The PDM is a composite model whose components can vary greatly, as shown in the template below. For some purposes, an entity-relationship style diagram of the physical database design will suffice. The Data Definition Language may also be used in the cases where shared databases are used to integrate systems.

Physical Data Model Provides
Message Format:

• Standards Reference
• Message Type(s)
• Message Fields with Representation
• Map from the Logical Data Model to the Message Fields

File Structure:

• Standards Reference
• Record and File Descriptions
• Map from Logical Interface Model to Record Fields

Physical Schema:

• DDL or ERA Notification with sufficient detail to generate the schema
• Map from the Logical Data Model to the Physical Data Model with Rationale

EA3 artifact D-4: Data Flow Diagram

The Data Flow Diagram (DFD) is intended to show the processes within a system that exchange data, and how those exchanges occur. This artifact compliments the B-1 Business Process Diagram, and can be decomposed to show additional detail.

EA3 artifact D1.1 / D-2a: The Information Exchange Matrix

The Information Exchange Matrix describes relevant attributes of data exchanges between systems. These attributes include size, logical specification of the information i.e., media, timeliness required, and the security classification and properties of the information.

Information exchanges express the relationships across four important aspects of the architecture (information, activities, locations, and times) with a focus on the specific aspects of the information flow. Information exchanges identify which business nodes exchange what information during the performance of what activities and in response to which events. Additional information on who is performing the activity can be added, if needed for security analysis. The detailed information in the Information Exchange Matrix may be hard to collect but it is necessary to fully understand the information flow in the enterprise and its security aspects.

The matrix also identifies the event that triggers the information exchange (e.g., set schedule or citizen request). The matrix keys the exchange to the producing and using activities and nodes and to the needline (from the Node Connectivity Diagram) the exchange satisfies. The Information Exchange Matrix partitions each high-level needline into its component parts, i.e., into distinct information exchanges between business nodes. An example format for this artifact is provided below. Additional characteristics may be added to the D-1 matrix based on the purpose or goals of the enterprise.

EA3 artifact D-3: Data Quality Plan

The Data Quality Plan addresses the processes and internal controls implemented over spending information, including data quality control procedures.

A Data Quality Plan is mandatory in the US Federal government to support the Open Government objective of creating and sustaining transparency across Government over data related to Federal spending information and improving the quality and integrity of such information.

EA3 artifact D-2: The Knowledge Management Plan

The Knowledge Management (KM) Plan provides a detailed description of how knowledge, information, and data are shared across the enterprise. The KM Plan includes descriptions and diagrams of information sharing between systems, applications, knowledge warehouses, and databases. The KM Plan includes:

• The approach to managing data, information, knowledge across the enterprise
• How data and information-sharing support the Business Plan
• Data and information-sharing strategies and diagrams for each line of business
• Data/information sharing strategies w/ external partners & customers
• Which types of data in the enterprise require extra protection
• The lifecycle for data and information that is key to the success of the enterprise (data creation, sharing, updating, storage, retrieval, and deletion)
• A high-level Concept of Operations graphic to depict the KM strategy

The KM plan should support EA standards for business process reengineering, improvement,  and management.

EA3 artifact D-1 Logical Data Model (core)

A semantic data model can be developed using traditional structured methods and symbology (Entity Relationship Diagram), or one can use the object-oriented method and symbology of the Unified Modeling Language (UML), which produces a Class Diagram or Object Diagram (Entity Relationship Diagram).

An Investment Business Case uses a standard format to describe the value, risk, and return on investments made in technology and other resources. The Business Case also contains an alternatives analysis, program performance tracking metrics, architecture information, and security status information. It should include:

• New Requirement Description
• Existing Solution Check
• New Solution Business Case
• New Solution Evaluation
• New Solution Approval
• New Solution Implementation -> Benefit Realization

Example
1. New Requirement. A new requirement for resource(s) or support is identified in a line of business (LOB), which is brought to the EA and capital planning teams for evaluation.
2. Existing Solution Check. The EA and capital planning teams determine that an existing EA component cannot meet the requirement.
3. New Solution Business Case. The sponsoring LOB determines that the requirement is of sufficient importance to merit the cost of developing a business case:

• Business Need. Describe the requirement in terms of the gap in operational or administrative performance it represents to the LOB and the enterprise.
• Impact if Not Resolved. Describe the impact to the enterprise if the performance gap is not resolved, including strategic, business, and technology impact.
• Alternatives Analysis. Identify 3 or more viable alternative solutions (if 3 exist).
• Cost-Benefit Analysis. Quantify the direct and indirect costs and benefits for each alternative on a lifecycle basis, including qualitative items.
• Return on Investment. Do a ROI calculation for each alternative.
• Net Present Value Adjustment. Do a NPV adjustment for each ROI calculation to account for anticipated cost increases over the investment’s lifecycle.

4. Business Case Evaluation. The business case’s alternatives are evaluated by the Architecture Working Group (AWG) for the correctness of the analysis, and alignment with the EA at each level of the framework. The Capital Planning Working Group (CPWG) then reviews the business case for the correctness of the financial analysis. A coordinated recommendation is made to the executive-level Capital Planning Board (CPB) as to whether the business case should be approved or disapproved.
5. Business Case Approval. The CPB reviews and approves/disapproves the business case in the context of the enterprise’s overall investment portfolio using criteria that identify value from a strategic, business, and technology perspective:
6. Implementation. If the business case is “selected” (approved) for funding by the CPB, the proposed solution becomes an implementation project that is managed by the sponsoring LOB. The project is reviewed by the CPB at key milestones and/or periodically as part of the capital planning process’ oversight of all projects.

A Use Case narrative follows the Unified Modeling Language (UML) format for identifying business requirements, their context, stakeholders, and business rules for their interaction with systems, services, and applications that are identified as technology solutions requiring development.