Phase C: Information System Architectures - Data
Architecture
Phase C: Information Systems Architectures - Data Architecture
Objective |
Approach |
Inputs |
Steps |
Outputs
This chapter describes the Data Architecture part of Phase C.
Objective
The objective here is to define the major types and sources of data necessary to support the business, in a way that is:
- Understandable by stakeholders
- Complete and consistent
- Stable
It is important to note that this effort is not concerned with database design. The goal is to define the data entities
relevant to the enterprise, not to design logical or physical storage systems. (However, linkages to existing files and databases
may be developed, and may demonstrate significant areas for improvement.)
Approach
Enterprise Continuum
As part of this phase, the architecture team will need to consider what relevant Data Architecture resources are available in
the organization's Enterprise Continuum; in particular, generic data models relevant to the organization's industry "vertical"
sector. For example:
- ARTS has defined a data model for the Retail industry.
- POSC has defined a data model for the Petrotechnical industry.
Gap Analysis
A key step in validating an architecture is to consider what may have been forgotten. The architecture must support all of the
essential information processing needs of the organization. The most critical source of gaps that should be considered is
stakeholder concerns that have not been addressed in architectural work.
Types of data gap:
- Data not located where it is needed
- Not the data that is needed
- Data not available when needed
- Data not created
- Data not consumed
- Data relationship gaps
- etc.
Gap analysis highlights shortfalls in data services and/or data elements that have been accidentally left out, deliberately
eliminated, or are yet to be defined. Gap Analysis Matrix in Phase D illustrates an
example of a gap analysis matrix. The suggested steps are as follows:
- Draw up a matrix with all the Data Architecture
building blocks Building Blocks of the current architecture Baseline Architecture on the vertical axis, and all the Data Architecture building
blocks Building Blocks of the Target Data Architecture on the horizontal axis. In
creating the matrix, it is imperative to use terminology that is accurate and consistent.
- Add to the
Current Baseline Architecture axis a
final row labeled "New Data Architecture Building Blocks", and to the Target Architecture axis a final column labeled
"Eliminated Data Architecture Building Blocks".
- Where a Data Architecture
building block Building
Block is available in both the current Baseline and Target Architectures, record this with "Included" at the intersecting cell.
- Where a Data Architecture
building block Building
Block from the current architecture Baseline
Architecture is missing in the Target Architecture, each must be reviewed. If it was correctly eliminated, mark it as
such in the appropriate "Eliminated" cell. If it was not, you have uncovered an accidental omission in your new architecture that
must be addressed by reinstating the Data Architecture building block Building Block in the next iteration of the architecture design - mark it as such in the appropriate
"Eliminated" cell.
- Where a Data Architecture
building block Building
Block from the Target Architecture cannot be found in the current
architecture, Baseline Architecture, mark it at the intersection with the "New"
row, as a gap that needs to filled, either by defining or inheriting the building block.
When the exercise is complete, anything under "Eliminated Services" or "New Services" is a gap, which should either be
explained as correctly eliminated, or marked as to be addressed by reinstating or developing/procuring the function.
Inputs
Inputs to this phase are:
- Data principles (Data Principles), if existing
- Request for Architecture Work (Request for Architecture Work)
- Statement of Architecture Work (Major Output Descriptions)
- Architecture Vision (Business Scenario/Architecture Vision)
- Relevant technical requirements that will apply to this phase
- Gap analysis results (from Business Architecture)
- Baseline Business Architecture, Version
2 1.0
(detailed), if appropriate
- Target Business Architecture (Business Architecture), Version
2 1.0 (detailed)
- Baseline Data Architecture, Version 0.1, if available
- Target Data Architecture, Version 0.1, if available
- Re-usable building blocks, from organization's Enterprise Continuum (Introduction to the Enterprise Continuum), if available (in particular, definitions of current
data)
Steps
- Develop Baseline Data Architecture
Baseline
Description
Develop a Baseline Description of the existing Data Architecture, to the extent necessary to support the Target Data
Architecture. The scope and level of detail to be defined will depend on the extent to which existing data elements are likely to
be carried over into the Target Data Architecture, and on whether existing architectural descriptions exist, as described in Approach . To the extent possible, identify the relevant Data Architecture building blocks, drawing on the
Architecture Continuum, and review/verify the following primitives from the Zachman Framework:
- Review and Validate Principles, Reference Models, Viewpoints, and Tools
- Review and validate (or generate, if necessary) the set of data principles.
These will normally form part of an overarching set of architecture principles. Guidelines for developing and applying
principles, and a sample set of data principles, are given in Part IV: Resource Base , Architecture Principles .
- Select relevant Data Architecture resources (reference models, patterns, etc.) from the Architecture Continuum, on the basis of
the business drivers, and the stakeholders and concerns.
- Select relevant Data Architecture viewpoints (for example, stakeholders of the data - regulatory bodies, users, generators,
subjects, auditors, etc.; various time dimensions - real-time, reporting period, event-driven, etc.; locations; business
processes); i.e., those that will enable the architect to demonstrate how the stakeholder concerns are being addressed in the Data
Architecture.
- Identify appropriate tools and techniques (including forms) to be used for data capture, modeling, and analysis, in association
with the selected viewpoints. Depending on the degree of sophistication warranted, these may comprise simple documents or
spreadsheets, or more sophisticated modeling tools and techniques such as data management models, data models, etc. Examples of
data modeling techniques are:
- IDEF
- Object Role Modeling
- Create Architecture Model(s)
- For each viewpoint, create the model for the specific view required, using the selected tool or method.
Examples of logical data models are:
- The C4ISR Architecture Framework Logical Data Model
- ARTS Data Model for the Retail industry
- POSC Data Model for the Petrotechnical industry
- Assure that all stakeholder concerns are covered. If they are not, create new models to address concerns not covered, or
augment existing models (see above). Model the following:
Conceptual Business data model (entities,
attributes, and relationships)
Draw entity-relationship diagrams to illustrate views of the Data Architecture to address the concerns of stakeholders.
- Logical data model (logical views of the actual data of interest)
- Data management process models, including:
- Data dissemination view
- Data lifecycle view
- Data security view
- Data model management view
- Relate data entities to business functions in the Business Architecture, indicating which of the CRUD operations (Create,
Reference, Update, and Delete) are performed by which functions.
- Relate each lowest-level business function in the Business Architecture to the set of data entities, indicating which of the
CRUD operations (Create, Reference, Update, and Delete) are performed by the function concerned.
- Generate entity-business function matrices tabulating all the relationships.
- Review and validate the entity-business function matrices, checking that each entity is created by at least one function, and
referenced or updated by at least one other function.
- Time permitting, relate entities to the application systems described in the Baseline Applications
Architecture Description.
- Ensure that all information requirements in the Business Architecture are met.
- Perform trade-off analysis to resolve conflicts (if any) among the different views.
One method of doing this is CMU/SEI's Architecture Trade-off Analysis (ATA) Method (refer to www.sei.cmu.edu/ata/ata_method.html).
- Validate that the models support the principles, objectives, and constraints.
- Note changes to the viewpoint represented in the selected models from the Architecture Continuum, and document.
- Test architecture models for completeness against requirements.
- Select Data Architecture
building blocks (e.g., metamodels) Building Blocks
- Identify required building blocks and check against existing library of building blocks, re-using as appropriate.
- Where necessary, define new Data Architecture
building blocks. Building Blocks.
- Conduct
a formal checkpoint review Formal Checkpoint
Review of the architecture model Architecture
Model and building blocks Building Blocks
with stakeholders. Stakeholders
Review the entity-business function matrices generated in Step 3, and the Business Architecture generated in Phase B.
- Review
the qualitative criteria Qualitative
Criteria (e.g., security, availability, accuracy, performance, costs, volumes), reliability, security, integrity)
Review the qualitative criteria, providing as many measurable criteria as possible (e.g.,
privacy/confidentiality, reliability, costs, minimum
tolerable data losses, maximum data volumes at peak times, etc.). Use to specify required service levels for data services (for
example, via formal Service Level Agreements (SLAs)).
The goal here is to guide the Applications and Technology Architecture efforts as to the qualities required in the applications,
and the underlying technology, that manage and process the data.
- Complete
the Data Architecture
- Select standards for each of the Architecture Building Blocks, re-using as much as possible from the reference models selected
from the Architecture Continuum.
- Fully document each Architecture Building Block.
- Final cross-check of overall architecture against business requirements. Document rationale for building block decisions in
architecture document.
- Document final requirements traceability report.
- Document final mapping of the architecture within the Architecture Continuum. From the selected Architecture Building Blocks,
identify those that might be re-used, and publish via the architecture repository.
- Document rationale for building block decisions in architecture document.
- Prepare Data Architecture
report. Report. Generate
the Data Architecture document, comprising some or all of:
Conceptual Business data model
- Logical data model
- Data management process model
- Data entity/business function matrix
- Data interoperability requirements (e.g., XML schema, security policies)
If appropriate, use reports and/or graphics generated by modeling tools to demonstrate key views of the architecture. Route the
Data Architecture document for review by relevant stakeholders, and incorporate feedback.
- Conduct Checkpoint/Impact
Analysis: check Analysis
Check the original motivation for the architecture project and the Statement of Architecture
Work against the proposed Data Architecture. Conduct an Impact Analysis, to:
- Identify any areas where the Business Architecture (e.g., business practices) may need to change to cater for changes in the
Data Architecture (for example, changes to forms or procedures, application systems, or database systems).
If the impact is significant, this may warrant the Business Architecture being revisited.
- Identify any areas where the Applications Architecture (if generated at this point) may need to change to cater for changes in
the Data Architecture (or to identify constraints on the Applications Architecture about to be designed).
If the impact is significant, this may warrant the Applications Architecture being revisited, if already developed in this
cycle.
- Identify any constraints on the Technology Architecture about to be designed.
- Refine the proposed Data Architecture only if necessary.
- Perform Gap
analysis Analysis (see Approach) and report Create Report
- Create gap matrix as described above.
- Identify building blocks to be carried over, classifying as either changed or unchanged.
- Identify eliminated building blocks.
- Identify new building blocks.
- Identify gaps and classify as those that should be defined and those inherited.
Outputs
The outputs of this phase are:
- Statement of Architecture Work (Major Output Descriptions), updated if
necessary
Data Architecture Baseline Description,
Data Architecture, Version 1.0, if appropriate
- Validated data principles (Data Principles), or new data principles (if
generated here)
- Target Data
Architecture Architecture, Version 1.0
Conceptual Business data model
- Logical data model
- Data management process models
- Data entity/business function matrix
- Data interoperability requirements
- Viewpoints addressing key stakeholder concerns
- Views corresponding to the selected viewpoints; for example:
- Data dissemination view
- Data lifecycle view
- Data security view
- Data model management view
- Gap analysis results
- Relevant technical requirements that will apply to this evolution of the architecture development cycle
- Data Architecture
report, Report, summarizing what
was done and the key findings
- Impact Analysis
- Areas where the Business Architecture may need to change to cater for changes in the Data Architecture
- Identify any areas where the Applications Architecture (if generated at this point) may need to change to cater for changes in
the Data Architecture
- Constraints on the Technology Architecture about to be designed
- Updated business requirements, if appropriate
return to top of page
Navigation
The TOGAF document set is designed for use with frames. To navigate around the document:
- In the main Contents frame at the top of the page, click the relevant hyperlink (Part I, Part II, etc.) to load the Contents
List for that Part of the TOGAF document into the Secondary Index frame in the left margin.
- Then click in that Contents List to load a page into this main frame.
return to top of page
Downloads
Downloads of the TOGAF documentation, are available under license from the TOGAF information web site . The license is free to any
organization wishing to use TOGAF entirely for internal purposes (for example, to develop an information system architecture for
use within that organization). A hardcopy book is also available from The Open Group Bookstore as document G063 .
Copyright © 1999-2006 The Open Group, All Rights Reserved
TOGAF is a trademark of The Open Group