1. Architecture Definition Document - description to communicate the intent of the architect. To act as a deliverable container for artifacts created during a project
2. Part VI (TOGAF Reference Models)
2.1. Technical Reference Model - includes a set of graphical models and a corresponding taxonomy. Is a example and should be tailored to the needs of an organization. Is a fundamental a upon which more specific a can be based
2.2. Integrated Information Infrastructure Reference Model - example of Application A ref. model
3. Part V (Enterprise Continuum and Tools)
3.1. Enterprise Continuum - describes classification methods for A and solution artifacts within enterprise; view of the A repository; used to structure reusable A and solution assets; aids communication and understanding between architects
3.1.1. Enterprise Continuum
3.1.1.1. Provides methods for classifying a artifacts as they evolve from generic a to Org Specific A
3.1.2. Architecture Continuum
3.1.2.1. Foundation A - most generic artifact. Contains bb and their corresponding standards
3.1.2.2. Common system A
3.1.2.3. Industry A - encourages levels of interoperability within the industry
3.1.2.4. Organization-Specific A
3.1.3. Solutions Continuum - As the A evolves, its assets progress toward Organization Specific A. Represents impl of a A Continuum
4. Part IV (Architecture Content Framework) - step by step approach to develop EA
4.1. Architecture repository - used to store different classes of a output created in ADM
4.1.1. Architecture metamodel
4.1.2. Architecture capability - to promote effective architectural activity within the enterprise. Defines processes that support governance of A repository
4.1.3. Architecture landscape - shows which bb are currently in use
4.1.3.1. Strategic Architecture - provides view of the entire enterprise
4.1.3.2. Segment A
4.1.3.3. Capability A
4.1.4. Standard Information Base - holds specifications to which architecture must conform
4.1.5. Reference library - holds best practice or template materials that can be used to construct a. Guidelines and templates used to crate new a
4.1.6. Governance Log
4.1.6.1. Decision Log
4.1.6.2. Compliance Assessments - to govern a throughout its impl process
4.1.6.3. Capability Assessments
4.1.6.4. Calendar
4.1.6.5. Project Portfolio
4.1.6.6. Performance Measurement
5. Part III (ADM Guidelines and techniques) - to support tasks within the ADM. Techniques:
5.1. Stakeholder Management
5.2. Architecture Patterns - a way to put bb togather
5.3. Business Scenarios - recommended to help identify and understand requirements. Define them and articulate the Arch Vision created in phase A
5.3.1. Gap Analysis - to identify potential missing or overlapping functions. Highlights services that are yet to be developed. NOT identifies potential vendors for bb. Validates target a on forgotten elements
5.4. Migration Planning Techniques
5.5. Interoperability Requirements
5.6. Risk is pervasive in all enterprise a activity
5.7. Business Transformation Readiness Assessment - determine if organization is ready to accept change
5.7.1. Communication plan - to ensure that a info is communicated to the right stakeholders at the right time
5.8. Risk Management
5.8.1. Initial risk assessment - categorization before determining and impl mitigating actions
5.8.2. Residual risk assessment - after initial
5.9. Capability-Based Planning - a business planning technique that focuses on business outcomes
6. Part II (Architecture Development Method) - should be adapted to suit specific needs of the enterprise. AMD - process for developing org specific eterprise a
6.1. Numbering Scheme - 0.1, .... To permit adaptation as required
6.2. Artifact
6.3. Building block - Should be reused in other a projects. NOT equivalent to software component objects or web services. Reusable bb - legacy system/process that will be reused. Becomes more impl specific in phase E. Its spec should be loosely coupled to its impl
6.3.1. Architecture BB - defines functionality
6.3.2. Solution BB - defines implementation of functionality
6.4. Phases
6.4.1. Architecture Requirements Specification - quantitative view of the solution to measure the implementation
6.5. Deliverable - contractual outputs from the project
6.5.1. Change request - if the original A Definition is not suitable