1. The Architecture Development Method (ADM) process can be adapted to deal with a number of different usage scenarios, including different process styles (e.g., the use of iteration). Guidelines included within this part of TOGAF are as follows:
Applying Iteration to the ADM : discusses the concept of iteration and shows potential strategies for applying iterative concepts to the ADM.
Applying the ADM across the Architecture Landscape : discusses the different types of architecture engagement that may occur at different levels of the enterprise. This section then also discusses how the ADM process can be focused to support different types of engagement.
Security Architecture and the ADM : provides an overview of specific security considerations that should be considered during different phases of the ADM.
Using TOGAF to Define & Govern SOAs : shows how SOA concepts can be supported by the TOGAF framework and the specific SOA considerations for different phases of the ADM.
Service-Oriented Architecture (SOA)

2. 1) Applying Iteration to the ADM
Overview
The ADM supports three types of concepts that are characterized as iteration:
Iteration to develop a comprehensive Architecture Landscape:
Projects will exercise through the entire ADM cycle, commencing with Phase A. Each cycle of the ADM will be bound by a Request for Architecture Work. The architecture output will populate the Architecture Landscape, either extending the landscape described, or changing the landscape where required.
Separate projects may operate their own ADM cycles concurrently, with relationships between the different projects.
One project may trigger the initiation of another project. Typically, this is used when higher-level architecture initiatives identify opportunities or solutions that require more detailed architecture, or when a project identifies landscape impacts outside the scope of its Request for Architecture Work.

3. Iteration within an ADM cycle (Architecture Development iteration):
Projects may operate multiple ADM phases concurrently. Typically, this is used to manage the inter-relationship between Business Architecture, Information Systems Architecture, and Technology Architecture.
Projects may cycle between ADM phases, in planned cycles covering multiple phases. Typically, this is used to converge on a detailed Target Architecture when higher-level architecture does not exist to provide context and constraint.
Projects may return to previous phases in order to circle back and update work products with new information. Typically, this is used to converge on an executable Architecture Roadmap or Implementation and Migration Plan.

4. Iteration to manage the Architecture Capability (Architecture Capability iteration):
Projects may require a new iteration of the Preliminary Phase to re-establish aspects of the Architecture Capability identified in Phase A to address a Request for Architecture Work.
Projects may require a new iteration of the Preliminary Phase to adjust the organization's Architecture Capability as a result of identifying new or changed requirements for Architecture Capability as a result of a Change Request in Phase H.

5. Iteration Cycles
The suggested iteration cycles for the TOGAF ADM are shown in the following figure and can be used to effectively group related architectural activities to achieve a specific purpose.

6. Architecture Capability : iterations support the creation1 and evolution of the required Architecture Capability. This includes the initial mobilization of the architecture activity for a given purpose or architecture engagement type by establishing or adjusting the architecture approach, principles, scope, vision, and governance.
Architecture Development : iterations allow the creation of architecture content by integrating Business Information Systems, and Technology Architecture phases. In this type of iteration stakeholder reviews are typically broader.
Transition Planning : iterations support the creation of formal change roadmaps for a defined architecture.
Architecture Governance : iterations support governance of change activity progressing towards a defined Target Architecture.

7. Classes of Architecture Engagement
An architecture function or services organization may be called on to assist an enterprise in a number of different contexts, as the architectures developed can range from summary to detail, broad to narrow coverage, and current state to future state.

8. Typically, there are three areas of engagement for architects:
Identification of Required Change: Outside the context of any change initiative, architecture can be used as a technique to provide visibility of the IT capability in order to support strategic decision-making and alignment of execution.
Definition of Change: Where a need to change has been identified, architecture can be used as a technique to define the nature and extent of change in a structured fashion. Within larges change initiatives, architectures can be developed to provide detailed Architecture Definition for change initiatives that are bounded by the scope of a program or portfolio.
Implementation of Change: Architecture at all levels of the enterprise can be used as a technique to provide design governance to change initiatives by providing big-picture visibility, supplying structural constraints, and defining criteria on which to evaluate technical decisions.

9. Approaches to Architecture Development
Two approaches can be adopted within the ADM for the development of architectures:
Baseline First: an assessment of the baseline landscape is used to identify problem areas and improvement opportunities. This process is most suitable when the baseline is complex, not clearly understood. This approach is common where organizational units have had a high degree of autonomy.
Target First: the target solution is elaborated in detail and then mapped back to the baseline, in order to identify change activity. This process is suitable when a target state is agreed at a high level and where the enterprise wishes to effectively transition to the target model.
Typically, if the baseline is broadly understood a higher value will be obtained focusing on the target first then baseline to the extent necessary to identify changes.

10. 2) Applying the ADM across the Architecture Landscape
Overview
In a typical enterprise, many architectures will be described in the Architecture Landscape at any point in time. Some architectures will address very specific needs; others will be more general. Some will address detail; some will provide a big picture. To address this complexity TOGAF uses the concepts of levels and the Enterprise Continuum to provide a conceptual framework for organizing the Architecture Landscape. 

11. Architecture Landscape
Levels provide a framework for dividing the Architecture Landscape into three levels of granularity:
Strategic Architecture : provides an organizing framework for operational and change activity and allows for direction setting at an executive level.
Segment Architecture : provides an organizing framework for operational and change activity and allows for direction setting and the development of effective architecture roadmaps at a program or portfolio level.
Capability Architecture : provides an organizing framework for change activity and the development of effective architecture roadmaps realizing capability increments.

13. The Architecture Continuum provides a method of dividing each level of the Architecture Landscape by abstraction.
It offers a consistent way to define and understand the generic rules, representations, and relationships in an architecture, including traceability and derivation relationships.
Shows the relationships from foundation elements to organization-specific architecture.
Its a useful tool to discover commonality and eliminate unnecessary redundancy.
provide a comprehensive mechanism to describe and classify the Architecture Landscape.

14. Organizing the Architecture Landscape to Understand the State of the Enterprise
The following characteristics are typically used to organize the Architecture Landscape:
Breadth: The breadth area is generally the primary organizing characteristic for describing an Architecture Landscape. Architectures are functionally decomposed into a hierarchy of specific subject areas or segments.
Depth: With broader subject areas, less detail is needed to ensure that the architecture has a manageable size and complexity. More specific subject matter areas will generally permit more detailed architectures.
Time: For a specific breadth and depth an enterprise can create a Baseline Architecture and a set of Target Architectures that stretch into the future. Broader and less detailed architectures will generally be valid for longer periods of time and can provide a vision for the enterprise that stretches further into the future.

15. 3) Security Architecture and the ADM
Overview
Security architectures generally have the following characteristics:
Security architecture has its own discrete security methodology.
Security architecture composes its own discrete views and viewpoints.
Security architecture introduces its own normative flows through systems and among applications.
Security architecture introduces single-purpose components in the design.

16. Guidance on Security for the Architecture Domains
Security concerns are pervasive throughout the architecture domains and in all phases of the architecture development.
Security is called out separately because it is infrastructure that is rarely visible to the business function. Its fundamental purpose is to protect the value of the systems and information assets of the enterprise. 
The approach of the security architect considers not only the normal flow of the application, but also the abnormal flows, failure modes, and ways the systems and applications can be interrupted and fail.

17. The generally accepted areas of concern for the security architect are:
Authentication: The substantiation of the identity of a person or entity related to the enterprise or system in some way.
Authorization: The definition and enforcement of permitted capabilities for a person or entity whose identity has been established.
Audit: The ability to provide forensic data attesting that the systems have been used in accordance with stated security policies.
Assurance: The ability to test and prove that the enterprise architecture has the security attributes required to uphold the stated security policies.
Availability: The ability of the enterprise to function without service interruption.
Asset Protection: The protection of information assets from loss and resources from unauthorized and unintended use.
Administration: The ability to add and change security policies, add or change how policies are implemented in the enterprise, and add or change the persons related to the systems.
Risk Management: The organization's attitude and tolerance for risk.

18. Typical security architecture would include:
Business rules regarding handling of data/information assets
Written and published security policy
Codified data/information asset ownership and custody
Risk analysis documentation
Data classification policy documentation

19. Preliminary Phase
Security Inputs
Written security policy
Relevant statutes
List of applicable jurisdictions
Security Outputs
List of applicable regulations
List of applicable security policies
Security team roster
List of security assumptions and boundary conditions

20. Phase A: Architecture Vision
Security Inputs
List of applicable security policies
List of applicable jurisdictions
Complete disaster recovery and business continuity plans
Security Outputs
Physical security environment statement
Business security environment statement
Regulatory environment statement
Security policy cover letter signed by CEO or delegate
List of architecture development checkpoints for security sign-off
List of applicable disaster recovery and business continuity plans
Systems criticality statement

21. Phase B: Business Architecture
Security Inputs
Initial business and regulatory security environment statements
List of applicable disaster recovery and business continuity plans
List of applicable security policies and regulations
Security Outputs
List of forensic processes
List of new disaster recovery and business continuity requirements
Validated business and regulatory environment statements
List of validated security policies and regulations
List of target security processes
List of baseline security processes
Statement of security tolerance for each class of security actor
Asset list with values and owners
List of trust paths

22. Phase C: Information Systems Architectures
Security Inputs
Threat analysis matrix
Risk analysis
Documented forensic processes
Validated business policies and regulations
List of interconnecting systems
New disaster recovery and business continuity requirements
Security Outputs
Risk management strategy
Data lifecycle definitions
List of configurable system elements
Baseline list of security-related elements of the system
New security-related elements of the system
Revised disaster recovery and business continuity plans

23. Phase D: Technology Architecture
Security Inputs
List of security-related elements of the system
List of interconnected systems
List of applicable security standards
Risk management strategy
Validated security policies
Validated regulatory requirements
Security Outputs
Baseline list of security technologies
Validated interconnected systems list
Selected security standards list
Resource conservation plan
Security metrics and monitoring plan
User authorization policies
Risk management plan

24. Phase E: Opportunities & Solutions
Identify existing security services available for re-use
Engineer mitigation measures addressing identified risks
Evaluate tested and re-usable security software and security system resources.
Identify new code/resources/assets that are appropriate for re-use
Determine "what can go wrong?"

25. Phase F: Migration Planning
Assess the impact of new security measures upon other new components or existing leveraged systems
Implement assurance methods by which the efficacy of security measures will be measured and communicated on an ongoing basis
Identify correct secure installation parameters, initial conditions, and configurations,.
Implement disaster recovery and business continuity plans 
Determine "what can go wrong?"

26. Phase G: Implementation Governance
Establish architecture, design, and code reviews and define acceptance criteria for the successful implementation of the findings.
Implement methods and procedures to review evidence produced by the system that reflects operational stability and adherence to security policies
Implement necessary training to:
ensure correct deployment, configuration, and operations of security-relevant subsystems and components
ensure awareness training of all users and non-privileged operators of the system and/or its components
Determine "what can go wrong?"

27. Phase H: Architecture Change Management
Incorporate security-relevant changes to the environment into the requirements for future enhancement.
Determine "what can go wrong?"

28. 4) Using TOGAF to Define & Govern SOAs
Overview
As the business environment becomes more sophisticated, the challenges facing organizations are shifting away from questions of efficiency and automation towards questions of complexity management and business agility.
Complex webs of existing applications and interfaces create highly complex landscapes where change becomes more and more difficult and the impacts of change become harder to predict and understand.
The concept of Service-Oriented Architecture (SOA) provides an architectural style that is specifically intended to simplify the business and the interoperation of different parts of that business. By structuring capability as meaningful, granular services as opposed to opaque it becomes possible to quickly identify functional capabilities of an organization, avoid duplicating similar capabilities across the organization and quickly assemble new capabilities.

29. SOA Definition
Service-Oriented Architecture (SOA) is an architectural style that supports service-orientation.
Service-orientation is a way of thinking in terms of services and service-based development and the outcomes of services.
A service is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports, etc.) and:

30. Enterprise Architecture and SOA
Enterprise architecture provides frameworks, tools, and techniques to assist organizations with the development and maintenance of their SOAs. Some of the key benefits that enterprise architecture provides include:
Consistent abstractions of high-level strategies and deliverables to support planning and analysis
Linkage of different perspectives to a single business problem (e.g., business, information systems, technology) providing a consistent model to address various domains and tests for completeness.
Identification of clear roadmaps to achieve future state.
Traceability that links IT and other assets to the business they support
Support for impact assessment, risk/value analysis, and portfolio management
Identified and documented principles, constraints, frameworks, patterns, and standards
Governance frameworks and processes that ensure appropriate authority for decision-making