Phase C: Information System Architecture - Data
Objective Approach Inputs
Steps Outputs
Mapping to Zachman Framework
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.)
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. Table 1 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 of the current
architecture on the vertical axis, and all the Data architecture 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 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 is available in both the current and target
architectures, record this with 'Included' at the intersecting cell.
- Where a Data architecture building block from the current 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 in the next iteration of the architecture design - mark it as
such in the appropriate 'Eliminated' cell.
- Where a Data architecture building block from the target architecture cannot be found in
the current 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.
Table 1 in Phase D illustrates an example of a gap
analysis matrix.
Inputs to this phase are:
- Data 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 describe under Approach, above. 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:
- Conceptual data model (entities, attributes, and relationships)
- Entity-Relationship diagrams illustrating 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
- Data entity / business function matrix in the Business Architecture
- 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, 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
- 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 has defined a Data Model for the Retail Industry
- POSC has defined a 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 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
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.
- 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)
- Identify required building blocks and check against existing library of building blocks,
re-using as appropriate.
- Where necessary, define new Data architecture building blocks.
- Conduct a formal checkpoint review of the architecture model and
building blocks with stakeholders.
- Review the Entity-Business Function matrices generated in step 3, and the Business
Architecture generated in Phase B.
- Review the qualitative criteria (e.g., security, availability,
accuracy, performance, costs, volumes), providing as many measurable criteria as possible
(e.g., privacy / confidentiality, reliability, 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).
- 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, reusing 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 reused, and publish
via the architecture repository.
- Document rationale for building block decisions in architecture document.
- Prepare Data Architecture Report. Generate the Data Architecture document, comprising
some or all of:
- Conceptual 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.
- Checkpoint/Impact 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 Application Architecture (if generated at this point) may
need to change to cater for changes in the Data Architecture (or to identify constraints
on the Application Architecture about to be designed).
- If the impact is significant, this may warrant the Application 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.
- Gap analysis (see under Approach, above) and 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.
The outputs of this phase are:
- Statement of Architecture Work
(updated if necessary)
- Data Baseline Description - if appropriate
- Validated Data Principles, or new Data Principles (if generated here)
- Target Data Architecture
- Conceptual 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; e.g.:
- 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, 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)
Copyright © The Open Group, 2002