Posted on by bhaumikadmin

Fundamental of Data Architecture while using TOGAF

Class Diagram

The key purpose of the class diagram is to depict the relationships among the critical data entities (or classes) within the enterprise. This diagram is developed to clearly present these relationships and to help understand the lower-level data models for the enterprise. This diagram is at a high level of representation (conceptual). We are interested here in modeling the main business entities, their properties and relationships.

The TOGAF class diagram as defined is situated at an early, conceptual stage. The highest level allows the essential business notions of enterprise to be represented, without being distracted by organizational or historical complexities specific to each organization. This conceptual level enables you to think about the business, in order to define an ideal organization with regard to this particular business. These entities will be used to define business processes (products handled by processes), and will be derived to define service application components, exchange data between services and repository data schemas.

Data Dissemination Diagram

The purpose of the data dissemination diagram is to show the relationship between data entities, business services, and application components. The diagram shows how the logical entities are to be physically realized by application components. This allows effective sizing to be carried out and the IT footprint to be refined. Moreover, by assigning business value to data, an indication of the business criticality of application components can be gained. Additionally, the diagram may show data replication and system ownership of the master reference for data. In this instance, it can show two copies and the master-copy relationship between them. This diagram can include services; that is, services encapsulate data and they reside in an application, or services that reside in an application and access data encapsulated within the application.

Entity application component: An entity component is frequently derived from business entities, and is responsible for managing the access to the entity, and its integrity.

Interaction application component: Represents the top level components that manage the interaction with elements outside the IS. In most cases, it is a GUI component, such as here a web interface.

Process application component: A process application component is responsible for a business process execution. It orchestrates the tasks of the process.

Utility component: Represents an application component that is frequently reused, and most of the cases bought off the shelf.

Database application component: Represents a repository. In pure SOA architecture, these elements should not appear. However, for legacy analysis or technology architecture, modeling repositories or repository deployment can be useful.

System federation: A system federation is the coarser-grained application component. It assembles systems to federate them, such as in the example of cooperation between different information systems between different companies.

Application: This application component corresponds to legacy applications, off the shelf products, or can be an assembly of application components.

Business Entity: Describes the semantics of the entities in the business, independently of any IS consideration (e.g. storage, technology, etc).

Data flow: Expresses that data (for example business entity) is input or output from a dynamic entity.

Data Lifecyle Diagrams

The data lifecycle diagram is an essential part of managing business data throughout its lifecycle, from conception through disposal, within the constraints of the business process. The data is considered as an entity in its own right, detached from business processes and activities. Each change in state is represented in the diagram, which may include the event or rules that trigger that change in state. The separation of data from process allows common data requirements to be identified, thereby enabling more effective resource sharing to be achieved.

Identify the possible states of the entity (for example, a document can be “under-Creation”, “under-Revision”, “approved”, and so on), and then define the possible transitions between each states. A state must be a stable data situation: when no action is executed on it, the data is always in one of the identified states.

Defining the lifecycle of business entities enables better formalization of these business entities, as well as the determination of the steps that are essential to their management. This very simple state model will be a guide in the definition of business processes, since these processes will themselves have to respect the constraints defined for transitions between states: if a business entity has not passed through all its states within the business processes that handle it, then these are incomplete. If the business processes transgress the lifecyle of the business entities, then they are incorrect.

 

Data migration Diagram

The purpose of the data migration diagram is to show the flow of data from the source to the target applications. The diagram will provide a visual representation of the spread of sources/targets and serve as a tool for data auditing and establishing traceability. This diagram can be elaborated or enhanced as detailed as necessary. For example, the diagram can contain just an overall layout of migration landscape or could go into individual application metadata element level of detail.

Data migration can be expressed at conceptual, logical or physical level. Application communication diagrams can also be used to express the data migration. The “migrate” dependency is the key element to formalize migration.

Data security diagrams

Data is considered as an asset to the enterprise and data security simply means ensuring that enterprise data is not compromised and that access to it is suitably controlled. The purpose of the data security diagram is to depict which actor (person, organization, or system) can access which enterprise data. This relationship can be shown in matrix form between two objects or can be shown as a mapping. The diagram can also be used to demonstrate compliance with data privacy laws and other applicable regulations (HIPAA, SOX, etc). This diagram should also consider any trust implications where an enterprise’s partners or other parties may have access to the company’s systems, such as an outsourced situation where information may be managed by other people and may even be hosted in a different country.

Large diagrams can become hard to read. It is recommended that you create one data security diagram per business entity, and/or per participant (typically a role). In particular, diagrams focused on actors and their missions can provide habilitation links. Diagrams may also be focused on the external access to the system, that is on which data the external actors can access.