1. TOGAF
Consists of two continua:
1. Architectural continuum
Foundation Common Systems IndustryOrganisation
Architectures ====> Architectures========> Architectures======> Architecture
reference model, Focus on a specific Aligned to industryleverage architectures
service taxonomy, subject area. i.e. security, of target organisationdeveloped along the
list of products andnetwork mgt, etc. common e.g. POSC (petro-continuum
technologies-logicalacross IT industry e.g. IBM chemical architectures)
Microsoft
2. Solution continuum
Products & Services ====> Systems Solutions ====> Industry Solutions ====>Organisation Solutions
2. TOGAF Structure
Business Strategy and Requirements
ArchitecturesArchitecture Development Method Governance
Business Reference ModelsTechnical Reference Model Standards Information Base
Standards Information Base
A database of open industry standards
Complete set of Open Group endorsed standards
-Content determined by Open Group consensus process
-Structured according to TOGAF Technical Reference Model Taxonomy
Regularly updated
Available for public web access
Gateway to many linked resources
Resource Base
A set of resources including guidelines, templates, and background information to help the architecture in the use of the ADM:
-Guidelines
-Principles
-Mock set of function views
-A method for deriving business requirements for architecture and implied technical requirements
-Real-life examples of TOGAF
-Definitions of key terms
-Tools and techniques helpful in using TOGAF
-Mapping the TOGAF ADM to the Zachman Framework
Architecture Development Methodology
Defined process guiding the development of an enterprise architecture
Essentially a requirements gathering methodology across architecture domains:
-business
-data
-applications
-infrastructure
Iterative across the whole process or between and within phases.
For each iteration of the ADM, new decisions must be taken regarding:
-Breadth of coverage of the enterprise to be defined
-Level of detail to be defined
-Extent of the time horizon aimed at, including the number and extend of any intermediate time horizons
TOGAF does not build model,it allows you to use set of processes,tasks, templates etc. to arrive the importance of your architecture.
Preliminary Framework & Principles
Objectives:
To define 'how we do architecture' in the enterprise
-framework to be used
-Architectural principles
To engage and get commitment from relevant stakeholders incl. major executives, line managers, major customers
-Define the 'architecture footprint' for the organization - the people responsible for performing architecture work, where they are located, and their responsibilities.
-Define the project scope and assumptions
Inputs
Business strategy, Business Principles, Business Goals and Business Drivers
Phase A: Architecture Vision
(check the definition of the framework and principles
details of building the architecture
prepare the grand work for developing the architecture)
Objectives:
-Validate business principles, business goals, and strategic drivers of the organization
-Define scope and constraints
-Breadth of enterprise coverage, level of detail to be defined, specific domains to be covered, timelines, assets to be leveraged
-Project-specific constraints (time, schedule, resources, etc.) and enterprise
-Create vision and prioritize components
-Must reflect requirements and constraints
-High-level description of the baseline ('as-is') and target ('to-be') environments
-Ensure management sponsorship and commitment
-Understand the impact on, and of other enterprise projects
Phase B: Business Architecture
(Gathering business requirements on what we need capture the understand about how we our work)
Objectives:
-Describe the current baseline business architecture
-Develop target Business Architecture
-Organizational, functional, process (inventory), information, and geographic aspects of the enterprise
-Based on the business principles, business goals, and strategic drivers
-Gap analysis of baseline and target Business Architectures
-Select appropriate architectural viewpoints to demonstrate how stakeholder concerns are resolved in the Business Architecture
Phase C: Information Systems Architecture
(What sort of things we need to know and collect the document the way we provide about the ICT infrastructure and information systems)
Objectives:
Data Architecture:
-Define the key data type and sources of data required to support the business
-Data must be complete and consistent
-Presentation of model must be comprehensible to stakeholders
Application Architecture:
-Define what types of application systems are relevant to the enterprise and what services those applications need to provide in order to manage and present the required data
Phase D: Technical Architecture
(Definition of what is doing that and analysis understanding it and place it up interation)
Objectives:
Develop a technology architecture what will form the basis of the implementation project
Steps:
-Technology Baseline Description
Review Business, Data, Application Baseline
Business functions supported
Organizational units supported
Networks accessed
Applications and data supported
System inter-dependencies (for example, fall-back configurations)
-Identify candidate technology architecture building blocks (potential reusable assets)
-Develop a baseline description of As Is Technology Architecture
-Define for each major hardware or software platform type: Name(short and long), Physical location, Owner(s)
Phase E: Opportunities & Solutions
(What are the things we gonna do?how we gonna do,what steps we gonna take?)
Objectives:
To progress the Implementation plan:
Identify parameters of change, major phases
High priority projects for transition from legacy to target environment
Note:
New application may be identified and so it may be necessary to iterate between Phase D
Risk:
Must be careful not to waste time and money in search of the perfect architecture
Phase F: Migration Planning
(why need migration planning?-project management part)
Objectives:
To prioritise implementation projects
- Assess dependencies, costs, benefits
- Assess Risks
- Identify and manage contingent projects/ initiatives
- Identify and Schedule resources
- Build Implementation Plan
Phase G: Implementation Governance
Objectives:
To develop recommendations for each implementation project
Develop architecture contract to govern the system implementation and deployment
System implementation during this phase
Develop Governance modus operand
Phase H: Architecture Change Management
Objectives:
To define the architecture change management process for the new baseline architecture
Provide for the continual monitoring of:
Technology developments
Changes in the business environment
Determine whether or not to initiate a new cycle of the architecture evolution cycle.
3. ADM Benefit
It's Free!
Comprehensive and generalized method
Provide Baseline to start
Can be tailored to the specific needs of an organisation
The whole methodology can be adapted
-Some phases may be unnecessary
-Some procedures might need to be modified
-Some procedures might need to be added