Information Architecture Domain
The information architecture perspective describes what knowledge, information and data an organisation needs to know and needs to produce in order to perform its business processes.
- Business Object Models
- Application Data Models
- Data management principles and policies
- Patterns of information
- Persistent Storage Schemas for storage of Application Data
- Unstructured information stored in documents and other content
Principles about Information Architecture. A useful starter set of Data Principles can be found in the TOGAF Architecture Principles web page.
Information Vision Statement
A vision statement asserts a common vision of the desired nature of the information architecture domain.
It is both a qualitative and quantitative statement that the information architects can use repeatedly to measure adherence to the information objectives, for measuring progress, and to keep improvement activities going.
The Information Vision Statement will state how the Information Management functions will avoid developing islands of databases and will develop a common, shared, distributed, accurate, and consistent data resource.
Information Best Practices
Consists of the architectural principles, strategies, and policies required to develop and implement data models, databases, and the infrastructure that support them.
Data Naming Conventions
Standards for assigning names to class/data elements.
It usually includes standard abbreviations and acronyms.
Information Standards and Guidelines
Standards and guidelines concerning procedures and methods of managing data, information and knowledge.
Information Design Review Guidelines
Guidelines for performing and participating in design reviews and modelling walkthroughs.
Business Object Model
A Conceptual level UML Class Diagram or Conceptual level Entity Relationship Diagram.
The Business Object Model is different from the more detailed Application Data Model in that the Business Object Model:
* Contains conceptual (not necessarily normalised) data entities or classes
* Will contain many to many relationships
* May not contain information about the optionality of relationships
* Should contain all supertype classes/data entities but not necessarily all subtypes
* May not contain any class/data properties. Any included will be only those data elements that are easy to find and define, and are particularly interesting and will raise data issues and ambiguities
Application Data Model
A Logical level UML Class Diagram or Entity Relationship Diagram.
Should be stored and maintained in the Enterprise Architecture repository.
Database Design Model
A graphical representation of tables and their logical relationship to each other.
These may only be developed within an development project but should be stored and maintained in the Enterprise Architecture repository.
Data Distribution Diagram
A graphical representation of distributed data server nodes and the data stored on them. These may or may not be developed within an Enterprise Architecture but should be stored and maintained in the Enterprise Architecture repository.
Operational Data Source Diagram
A graphical representation of legacy databases that are the sources of new or planned operational databases.
Business Object/Application Data Matrix
A table that shows one or more Application Data Object derived from a Business Object.
Business Object/Business Process Matrix
A table that shows one or more Business Process related to a Business Object (that is input or output)
Application Data/Persistent Data Artifact