Building data architectures for TOGAF phase C

Architecting and designing : TOGAF : Building deliverables for the TOGAF Architecture Development Method : Building deliverables for phase C: Information systems architecture : Building data architectures for TOGAF phase C

You model the data architecture for TOGAF Phase C using various TOGAF Viewpoints.

Prerequisite

See the TOGAF documentation at:

http://www.opengroup.org/architecture/togaf9-doc/arch/

Inputs to this phase

The following list of artifacts describes part of the inputs to this phase:

▪Applications Principle

▪Data Principle

▪Request for Architecture Work

▪Statement of Architecture Work

▪Vision (see Vision statements)

▪Refined Business architecture

Viewpoints of the TOGAF method, Phase C, Data Architecture, are provided below. Appropriate links are provided to reference how to build referenced artifacts in System Architect.

Catalogs

▪Data Entity/Data Component catalog: Represented by applicable definition types, accessible via the applicable grouping in Explorer (Browser).

Matrices

▪Data Entity/Business Process matrix: A Business Process (BPMN) to Entity matrix is available in the Data tab of the Matrix Browser.

▪System/Data matrix: An Entity to System matrix is not provided; you can create your own via user-definable matrices. System Architect does offer an Entity to Application Component matrix.

Core diagrams

▪Class diagram: Depict the relationships among the critical data entities (or classes) within the enterprise. Use a UML class diagram (see UML class diagrams) or an entity relation diagram (see Components of an entity relation diagram).

▪Creating data dissemination diagrams: Show the relationship between data entity, business service, and application components.

Extension diagrams

▪Data Security diagram: Depict which actor (person, organization, or system) can access which enterprise data. This relationship can be shown in a matrix form between two objects or can be shown as a mapping. You can create this as a customized diagram or report.

▪Creating class hierarchy diagrams: Show the technical stakeholders a perspective of the class hierarchy. This diagram gives the stakeholders an idea of who is using the data, how, why, and when.

▪Data Migration diagram: Show the flow of data from the source to the target applications, critical when implementing a package or packaged service-based solution: especially when replacing a legacy application with a package, or migrating an enterprise to a larger packaged services footprint. You can use the System Architecture diagram for this (see System architecture diagrams for the Application Model).

▪Data Lifecycle diagram: Manage business data throughout its lifecycle from conception until disposal within the constraints of the business process. The data is considered as an entity in its own right, decoupled from business process and activity. Each change in state is represented on the diagram, which can include the event or rules that trigger that change in state. You can use a UML state diagram for this.