<ENTERPRISE NAME>
<PLACE LOGO HERE>
<author><version><revision date>
This is a template for the Information Integration Architecture Specification. This page should be removed prior to publication of the specification. The template is a guide for the enterprise and should not be blindly followed. The organization should
Review the chapter in the book that refers to the template to understand its use.
Examine the template outline and determine what additions might be necessary based on unique organizational needs.
If absolutely necessary, remove any sections that will not apply. (The authors strongly discourage this practice.)
Save the template for future use.
Begin to develop the document.
Guidance is given for preparation of the document throughout the template.
Text shown as normal text should be used in the document. It may be modified as necessary.
Text shown in pointed brackets is either instructional guidance in the application of the document or a description of the type of information to be added and should be removed prior to publication.
Text shown in double-pointed brackets is a placeholder for the insertion of text by the authors.
Headers and footers should be customized as necessary as a final step in the completion of the document.
Information Integration Architecture Specification
<This specification provides the design guidance for applying an information-driven approach to integration for <<system name>>. This document is a guide to creating the information architecture specification for the enterprise information integration based applications or information driven business solutions.>
<The scope of an information specification is limited to an integration project. The document should define the business information needs and the underlying integration architecture. The scope should describe the breath of business information covered as well as the systems and data sources involved in the process.>
<This section identifies all stakeholders in the business information being integrated, including business managers who control all or part of the information; system designers and architect(s); and the development team, who will execute the implementation. Any other participants or stakeholders should also be identified, including their roles.>
<This section is used to identify and map all of the requirements to the design patterns for information integration. The two basic design patterns are information aggregation and publishing. To identify the business information requirements that need to be defined as part of this specification start with the Statement of Purpose and the scope of responsibilities defined in the Business Strategies and Initiatives Specification. Then use design patterns to identify the best approach for implementation.>
<The Data Flow Diagram depicts the flow of information across systems. The purpose of the data flow diagram is to determine which systems are involved in the data exchange, and to later determine the integrity rules across systems (done in the Relationship Model, section 7).
The diagram on page 328 is an adaptation of a traditional data flow model in order to focus on the flow of information across systems. Here external systems (depicted as shaded boxes) are systems outside of the enterprise.>
<Each application will require a metadata model that combines the new model for the application with the existing models of each of the data sources used. The Metadata Model is used to define access and transformation rules. It establishes data lineage and enables impact analysis.
Metadata for existing data sources must be captured for each element. The information model can be extended as needed to support the enterprise.>
<The Relationship Table defines the mapping of the data between the new applications and the existing systems as well as the integrity rules across data objects and systems.
Note that the system/service and source data element name are added here to provide lineage. The target system/service is included to enable impact analysis. The business rules can include aggregation and parsing rules particular to that data flow.>
<Information design reviews are critical to the overall success and agility of the system. The design reviews should include all relevant stakeholders, defined above in the key participants section. All parts of the model need to be reviewed and verified. Participants need to verify the portions of the information they are responsible for, including the definition of all elements, how they are created and updated, the formats, and the access mechanisms. The business users need to provide the definitions for the information required in the new application. In addition, it will be critical for the stakeholders to ensure they deal with discrepancies on which data source contains the “gold standard” for the organization when there are conflicts or duplications. This is often the most difficult task that the group will face. The overall process should be reviewed for opportunities to improve consistency and quality of information across the organization.
Use the following guidelines for successful design reviews:
Make sure all the stakeholders are present.
Explain the process and ground rules before the design review.
Criticize the design, not the person.
Designers may only speak to clarify the design and provide background information. They should not “defend” the design.
Identify “owners” of information.
Identify systems of record for information.
Define a process for data quality.>
<The appendix should list any reference documents used in the creation of the document so that its contents can be traced back to their sources if necessary. This should be broken down into internal documents and external documents. Internal documents are those that belong to the organization. External documents are items such as articles, whitepapers, Web sites, or product documentation.>