My Repository 2

TOGAF 9

Get Started. It's Free
or sign up with your email address
My Repository 2 by Mind Map: My Repository 2

1. AWS

1.1. 1 Introduction to AWS

1.1.1. 1. Region

1.1.1.1. 1. region is a named set of AWS resources in the same geographical area.

1.1.1.2. 2. A region comprises at least two Availability Zones.

1.1.2. 2. AZ

1.1.2.1. 1. Availability Zone is a distinct location within a region that is insulated from failures in other Availability Zones and

1.1.2.2. 2. provides inexpensive, low-latency network connectivity to other Availability Zones in the same region.

1.1.3. 3. Deployment

1.1.3.1. 1. hybrid deployment is a way to connect infrastructure and applications between cloud-based resources and existing resources that are not located in the cloud.

1.1.3.2. 2. An all-in deployment refers to an environment that exclusively runs in the cloud.

1.2. 2 S3 and Glacier Storage

1.2.1. 1. Glacier

1.2.1.1. provides lowcost archival storage.

1.2.2. S3

1.2.2.1. 4. key characteristics of s3

1.2.2.1.1. All objects have a URL.

1.2.2.1.2. S3 can store unlimited amounts of data.

1.2.2.1.3. S3 uses a REST (Representational State Transfer) Application Program Interface (API).

1.2.2.2. 3. appropriates use cases for s3

1.2.2.2.1. Storing web content

1.2.2.2.2. Storing backups for a relational database

1.2.2.2.3. Storing logs for analytics

1.2.2.3. 2. Objects are stored in buckets, and objects contain both data and metadata.

1.2.2.3.1. objects are private by default

1.3. 3 EC2 and EBS

1.3.1. 1. EBS provides persistent block-level storage volumes for use with Amazon EC2 instances on the AWS Cloud.

1.4. 4 VPC

1.4.1. 1. VPC

1.4.1.1. VPC lets organizations provision a logically isolated section of the AWS Cloud where they can launch AWS resources in a virtual network that they define.

1.5. 5 ELB, CloudWatch and Auto Scaling

1.5.1. 1. CloudWatch

1.5.1.1. CloudWatch is a monitoring service for AWS Cloud resources and the applications organizations run on AWS.

1.5.1.2. CloudWatch metrics provide hypervisor visible metrics.

1.5.2. 2. Auto Scaling

1.5.2.1. helps maintain application availability and allows organizations to scale Amazon Elastic Compute Cloud (Amazon EC2) capacity up or down automatically according to conditions defined for the particular workload. Not only can it be used to help ensure that the desired number of Amazon EC2 instances are running, but it also allows resources to scale in and out to match the demands of dynamic workloads.

1.5.2.2. Auto Scaling Group

1.5.2.2.1. default EC2 capacity (20) for new region.

1.5.2.2.2. launches instances from an AMI specified in the launch configuration associated with the Auto Scaling group

1.5.2.2.3. enforces a minimum number of instances in the min-size parameter of the Auto Scaling group.

1.5.2.2.4. launch configurations

1.5.2.2.5. May use instances

1.5.2.2.6. Supported Plans

1.5.2.3. Auto Scaling is designed to scale out based on an event like increased traffic while being cost effective when not needed.

1.5.2.4. Auto Scaling responds to changing conditions by adding or terminating instances

1.5.3. ELB

1.5.3.1. Websites behind ELB

1.5.3.1.1. An SSL certificate must specify the name of the website in either the subject name or listed as a value in the Subject Alternative Name SAN extension of the certificate in order for connecting clients tonot receive a warning.

1.5.3.2. When Amazon EC2 instances fail the requisite number of consecutive health checks, the load balancer stops sending traffic to the Amazon EC2 instance.

1.5.3.3. ELB Health Checks

1.5.3.3.1. A ping

1.5.3.3.2. A connection attempt

1.5.3.3.3. A page request

1.5.3.4. Connection Draining

1.5.3.4.1. When connection draining is enabled, the load balancer will stop sending requests to a deregistered or unhealthy instance

1.5.3.4.2. attempt to complete in-flight requests until a connection draining timeout period is reached, which is 300 seconds by default.

1.5.3.5. supported types of load balancer

1.5.3.5.1. Internet-facing

1.5.3.5.2. Internal

1.5.3.5.3. HTTPS using SSL

1.6. 6 IAM

1.6.1. IAM Policies

1.6.1.1. Service Name

1.6.1.2. Action

1.6.2. IAM Security Features

1.6.2.1. MFA

1.6.3. Actions Authorized by IAM

1.6.3.1. Launching a Linux EC2 instance

1.6.4. EC2 roles

1.6.4.1. Key rotation is not necessary.

1.6.5. temporary security tokens

1.7. 7 Databases and AWS

1.7.1. 1. Databases

1.7.1.1. 1. DynamoDB

1.7.1.1.1. 1. non-relational database

1.7.1.1.2. 2. fully managed, fast, and flexible NoSQL database service for all applications that need consistent, single-digit millisecond latency at any scale.

1.7.1.1.3. 3. DynamoDB tables

1.7.1.2. 2. RDS

1.7.1.2.1. 1. OLTP

1.7.1.2.2. 2. RDS provides managed relational databases.

1.7.1.2.3. 3. increase resiliency

1.7.1.2.4. 4. RDS supports Microsoft SQL Server Enterprise edition and the license is available only under the BYOL model

1.7.1.2.5. 5. MySQL

1.7.1.3. 3. Redshift

1.7.1.3.1. 1. best suited for traditional Online Analytics Processing (OLAP) transactions

1.7.2. 2. read replicas

1.7.2.1. 1. to increase performance, use read replicas to scale out the database and thus maximize read performance

1.7.2.2. 2. read replicas and a Multi-AZ deployment allow you to replicate your data and reduce the time to failover

1.7.3. 3. DB Snapshots

1.7.3.1. 1. can be used to restore a complete copy of the database at a specific point in time

1.7.3.2. 2. DB snapshots allow you to back up and recover your data

1.7.4. 4. Multi-AZ supported db engines

1.7.4.1. 1. MS SQL Server, MySQL, Aurora, PostgreSQL, Oracle...

1.7.5. 5. database failover

1.7.5.1. 1. Force a Multi-AZ failover from one Availability Zone to another by rebooting the primary instance using the Amazon RDS console.

1.7.5.1.1. 1. rebooting the primary instance using the Amazon RDS console.

1.7.6. 6. General Purpose (SSD) volumes are generally the right choice for databases that have bursts of activity

1.7.7. 7. offload read requests

1.7.7.1. 1. Add a read replica DB instance, and configure the client’s application logic to use a read-replica.

1.7.7.2. 2. Create a caching environment using ElastiCache to cache frequently used data. Update the application logic to read/write from the cache.

1.7.8. 8. securing the database

1.7.8.1. 1. requires a multilayered approach that secures the infrastructure, the network, and the database itself

1.8. 8 SQS, SWF, and SNS

1.8.1. 1. SQS

1.8.1.1. 1. SQS is a fast, reliable, scalable, fully managed message queuing service that allows organizations to decouple the components of a cloud application. With Amazon SQS, organizations can transmit any volume of data, at any level of throughput, without losing messages or requiring other services to be always available.

1.8.1.2. 2. SQS visibility timeout

1.8.1.2.1. 1. max 12 hours

1.8.1.2.2. 2. default 30 sec

1.8.1.3. 3. properties

1.8.1.3.1. 1. Message ID

1.8.1.3.2. 2. Body

1.8.2. 2. SWF

1.8.2.1. helps developers build, run, and scale background jobs that have parallel or sequential steps.

1.8.3. 3. SNS

1.8.3.1. provides a messaging bus complement to Amazon SQS; however, it doesn’t provide the decoupling of components necessary for this scenario.

1.8.4. 2. SNS features

1.8.4.1. 1. Publishers

1.8.4.2. 2. Subscribers

1.8.4.3. 3. Topics

1.8.4.3.1. 1. ARN created

1.8.5. 1. Supported Protocols

1.8.5.1. 1. HTTPS

1.8.5.2. 2. AWS Lambda

1.8.5.3. 3. Email-JSON

1.9. 9 DNS and Route 53

1.9.1. 1. Route 53 provides a highly available and scalable cloud Domain Name System (DNS) web service.

1.10. 10 ElastiCache

1.10.1. 1. ElastiCache is a service that provides in-memory cache in the cloud.

1.11. 11 Additional Key Services

1.11.1. 1. CloudFront is a web service that provides a CDN to speed up distribution of your static and dynamic web content—for example, .html, .css, .php, image, and media files—to end users. Amazon CloudFront delivers content through a worldwide network of edge locations.

1.11.2. 2. CloudFormation gives developers and systems administrators an easy way to create and manage a collection of related AWS resources.

1.11.3. 3. CloudTrail records AWS API calls, and Amazon Redshift is a data warehouse, neither of which would be useful as an architecture component for decoupling components.

1.12. 12 Security on AWS

1.13. 13 AWS Risk and Compliance

1.14. 14 Architecture Best Practices

2. TOGAF 9.2

2.1. Publications

2.1.1. Part 1: Introduction

2.1.1.1. Definitions

2.1.1.1.1. TOGAF

2.1.1.1.2. Enterprise

2.1.1.1.3. Architecture

2.1.1.2. Why do we need Enterprise Architecture?

2.1.1.2.1. 1. Lower costs – development, maintenance, support

2.1.1.2.2. 2. Reduced complexity

2.1.1.2.3. 3. Reduced risk

2.1.1.2.4. 4. Simpler to add new systems

2.1.1.2.5. 5. Faster purchase and implementation

2.1.1.3. What is an Architecture Framework?

2.1.1.3.1. Def 1

2.1.1.3.2. Def 2

2.1.1.4. Core Concepts

2.1.1.4.1. Establishing the Architecture Capability as an Operational Entity, an enterprise architecture practice should establish capabilities in the following areas

2.1.2. Part 2: ADM

2.1.2.1. Intro

2.1.2.1.1. Overview

2.1.2.1.2. Architecture Development Cycle

2.1.2.1.3. Scoping the Architecture

2.1.2.2. Architecture Development Cycle

2.1.2.2.1. The ADM is iterative, over the whole process, between phases and within phases

2.1.2.2.2. For each iteration of the ADM, a fresh decision must be taken as to

2.1.2.2.3. These decisions should be based on a

2.1.2.2.4. As a generic method, the ADM is intended to be used by enterprises in a wide variety of different geographies and applied in different vertical sectors/industry types. As such, it may be, but does not necessarily have to be, tailored to specific needs.

2.1.2.3. Phases

2.1.2.3.1. Preliminary Phase

2.1.2.3.2. Phase A: Architecture Vision

2.1.2.3.3. Phase B: Business Architecture

2.1.2.3.4. Phase C: Information Systems Architecture

2.1.2.3.5. Phase D: Technology Architecture

2.1.2.3.6. Phase E: Opportunities and Solutions

2.1.2.3.7. Phase F: Migration Planning

2.1.2.3.8. Phase H: Architecture Change Management

2.1.2.3.9. Requirements Management

2.1.3. Part 3: ADM Guidelines and Techniques

2.1.3.1. 1. Applying Iteration to the ADM

2.1.3.1.1. Iteration Cycles

2.1.3.1.2. Classes of Architecture Engagement

2.1.3.1.3. Approaches to Architecture Development

2.1.3.2. 2. Applying the ADM at different Enterprise Levels

2.1.3.2.1. Strategic Architectures (executive level)

2.1.3.2.2. Segment Architectures (program or portfolio level)

2.1.3.2.3. Capability Architectures

2.1.3.3. 3. Security Architecture and the ADM

2.1.3.3.1. How to adapt the ADM for security

2.1.3.3.2. Accepted areas of concern for the security architect

2.1.3.3.3. Typical security architecture artifacts

2.1.3.4. 4. Using TOGAF to Define & Govern SOAs

2.1.3.4.1. A style of architecture that looks at all the functions of the system as services.

2.1.3.4.2. Services

2.1.3.4.3. Using TOGAF for SOA

2.1.3.5. 5. Architecture Principles

2.1.3.5.1. Principle Components

2.1.3.5.2. Qualities

2.1.3.5.3. Two key domains inform the development and utilization of architecture:

2.1.3.5.4. Example Set of Architecture Principles (BDAT)

2.1.3.6. 6. Architecture Stakeholder Management

2.1.3.6.1. Stakeholder

2.1.3.6.2. Technique

2.1.3.6.3. Approach to Stakeholder Management

2.1.3.7. 7. Architecture Patterns

2.1.3.7.1. A "pattern" has been defined as: "an idea that has been useful in one practical context and will probably be useful in other

2.1.3.7.2. In TOGAF, patterns are considered to be a way of putting building blocks into context; for example, to describe a re-usable solution to a problem.

2.1.3.7.3. Building blocks are what you use: patterns can tell you how you use them, when, why, and what trade-offs you have to make in doing so.

2.1.3.8. 8. Business Scenarios

2.1.3.8.1. Introduction

2.1.3.8.2. Benefits of Business Scenarios

2.1.3.8.3. Creating the Business Scenario

2.1.3.8.4. Contents of a Business Scenario

2.1.3.8.5. Contributions to the Business Scenario

2.1.3.8.6. Business Scenarios and the TOGAF ADM

2.1.3.8.7. Developing Business Scenarios

2.1.3.8.8. Business Scenario Documentation

2.1.3.8.9. Guidelines on Goals and Objectives

2.1.3.9. 9. Gap Analysis

2.1.3.9.1. Business domain gaps:

2.1.3.9.2. Data domain gaps:

2.1.3.9.3. Applications impacted, eliminated, or created

2.1.3.9.4. Technologies impacted, eliminated, or created

2.1.3.10. 10. Migration Planning Techniques

2.1.3.10.1. Matries

2.1.3.10.2. Tables

2.1.3.10.3. 5. Business Value Assessment Technique

2.1.3.11. 11. Interoperability Requirements

2.1.3.11.1. Definitions

2.1.3.11.2. Categories

2.1.3.11.3. Enterprise Operating Model

2.1.3.11.4. Refining Interoperability

2.1.3.11.5. Determining Interoperability Requirements

2.1.3.11.6. Reconciling Interoperability Requirements with Potential Solutions

2.1.3.11.7. Summary

2.1.3.12. 12. Business Transformation Readiness Assessment

2.1.3.12.1. Introduction

2.1.3.12.2. Recommended Activities

2.1.3.12.3. Business Transformation Enablement Program (BTEP)

2.1.3.12.4. Determine Readiness Factors

2.1.3.12.5. Present Readiness Factors

2.1.3.12.6. Assess Readiness Factors

2.1.3.12.7. Readiness and Migration Planning

2.1.3.12.8. Marketing the Implementation Plan

2.1.3.13. 13. Risk Management

2.1.3.13.1. Intro

2.1.3.13.2. Risk Classification

2.1.3.13.3. Risk Identification

2.1.3.13.4. Initial Risk Assessment

2.1.3.13.5. Risk Mitigation and Residual Risk Assessment

2.1.3.13.6. Conduct Residual Risk Assessment

2.1.3.13.7. Risk Monitoring and Governance (Phase G)

2.1.3.13.8. Initial Risk Assessment

2.1.3.14. 14. Capability-Based Planning

2.1.3.14.1. Overview

2.1.3.14.2. Capability-Based Planning Paradigm

2.1.3.14.3. Concept of Capability-Based Planning

2.1.3.14.4. Capabilities in an Enterprise Architecture Context

2.1.3.14.5. Summary

2.1.3.14.6. Old

2.1.3.14.7. Links

2.1.4. Part 4: Architecture Content Framework

2.1.4.1. Intro.

2.1.4.1.1. This part describes the TOGAF content framework, including a structured metamodel for architectural artifacts, the use of re-usable architecture building blocks, and an overview of typical architecture deliverables

2.1.4.1.2. Architects executing the Architecture Development Method (ADM) will produce a number of outputs as a result of their efforts, such as process flows, architectural requirements, project plans, project compliance assessments, etc.

2.1.4.1.3. The content framework provides a structural model for architectural content that allows the major work products that an architect creates to be consistently defined, structured, and presented

2.1.4.2. Content Metamodel

2.1.4.2.1. 1. Overview

2.1.4.2.2. 2. Content Metamodel Vision and Concepts

2.1.4.2.3. 3. Content Metamodel in Detail

2.1.4.2.4. 4. Content Metamodel Extensions

2.1.4.2.5. 5. Content Metamodel Entities

2.1.4.2.6. 6. Content Metamodel Attributes

2.1.4.2.7. 7. Metamodel Relationships

2.1.4.3. Architectural Artifacts

2.1.4.3.1. Classifications

2.1.4.3.2. Artifacts

2.1.4.4. Architecture Deliverables

2.1.4.4.1. 1. Architecture Building Blocks

2.1.4.4.2. 2. Architecture Contract

2.1.4.4.3. 3. Architecture Definition Document

2.1.4.4.4. 4. Architecture Principles

2.1.4.4.5. 5. Architecture Repository

2.1.4.4.6. 6. Architecture Requirements Specification

2.1.4.4.7. 7. Architecture Roadmap

2.1.4.4.8. 8. Architecture Vision

2.1.4.4.9. 9. Business Principles, Business Goals, and Business Drivers

2.1.4.4.10. 10. Capability Assessment

2.1.4.4.11. 11. Communications Plan

2.1.4.4.12. 12. Compliance Assessment

2.1.4.4.13. 13. Implementation and Migration Plan

2.1.4.4.14. 14. Implementation Governance Model

2.1.4.4.15. 15. Organizational Model for Enterprise Architecture

2.1.4.4.16. 16. Request for Architecture Work

2.1.4.4.17. 17. Change Request

2.1.4.4.18. 18. Requirements Impact Assessment

2.1.4.4.19. 19. Solution Building Blocks

2.1.4.4.20. 20. Statement of Architecture Work

2.1.4.4.21. 21. Tailored Architecture Framework

2.1.4.5. Building Blocks

2.1.4.5.1. Characteristics

2.1.4.5.2. A good building block has the following characteristics:

2.1.4.5.3. Architecture Building Blocks

2.1.4.5.4. Solution Building Blocks

2.1.4.5.5. Building Block Specification Process in the ADM

2.1.5. Part 5: Enterprise Continuum and Tools

2.1.5.1. Architecture Continuum

2.1.5.1.1. Foundation Architecture

2.1.5.1.2. Common Systems Architecture

2.1.5.1.3. Industry Architecture

2.1.5.1.4. Organization-Specific Architecture

2.1.5.2. Architecture Repository

2.1.5.2.1. Architecture

2.1.5.2.2. SIB

2.1.5.2.3. Reference Library

2.1.5.2.4. Governance Log

2.1.5.3. Solutions Continuum

2.1.5.3.1. Foundation Solutions

2.1.5.3.2. Common Systems Solutions

2.1.5.3.3. Industry Solutions

2.1.5.3.4. Organization-Specific Solutions

2.1.5.4. Architecture Partitioning

2.1.5.4.1. Reasons

2.1.5.4.2. Architectural Landscape:

2.1.5.4.3. Integration Risks:

2.1.5.4.4. What is needed:

2.1.5.4.5. Explanation

2.1.6. Part 6 TOGAF Reference Models

2.1.6.1. Foundation Architecture: TRM

2.1.6.1.1. Intro

2.1.6.1.2. TRM

2.1.6.1.3. SIB

2.1.6.2. Integrated Information Infrastructure Reference Model) III-RM

2.1.6.2.1. Boundaryless Information Flow

2.1.7. Part 7: Architecture Capability Framework

2.1.7.1. Overview

2.1.7.1.1. In order to successfully operate an architecture function within an enterprise, it is necessary to put in place appropriate organization structures, processes, roles, responsibilities, and skills to realize the Architecture Capability.

2.1.7.1.2. Part VII: Architecture Capability Framework provides a set of reference materials for how to establish such an architecture function.

2.1.7.2. Establishing an Architecture Capability

2.1.7.2.1. Can be supported by the TOGAF Architecture Development Method (ADM).

2.1.7.2.2. Require the design of the four domain architectures

2.1.7.3. Architecture Board

2.1.7.3.1. Responsibilities

2.1.7.3.2. Role

2.1.7.3.3. Setting Up the Architecture Board

2.1.7.4. Architecture Compliance

2.1.7.4.1. Terminology

2.1.7.4.2. Architecture Compliance Reviews

2.1.7.5. Architecture Contracts

2.1.7.5.1. Architecture Contracts are the joint agreements between development partners and sponsors on the:

2.1.7.5.2. Successful implementation of these agreements will be delivered through effective architecture governance

2.1.7.6. Architecture Governance

2.1.7.6.1. Hierarchy of Governance:

2.1.7.6.2. Characteristics of Governance

2.1.7.6.3. Architecture Governance Framework

2.1.7.7. Architecture Maturity Models

2.1.7.7.1. Capability Maturity Models (CMMs)

2.1.7.8. Architecture Skills Framework

2.1.7.8.1. Provide a view of the competency levels required for specific roles

2.1.7.8.2. Goals

2.1.7.8.3. Enterprise Architecture Role and Skill Categories

2.1.7.8.4. Enterprise Architecture Role and Skill Categories

2.2. TOGAF 9.2 (I/O, Artifacts, Approach)

2.2.1. ADM Input/Output & Steps

2.2.1.1. 0 : Preliminary

2.2.1.1.1. Inputs

2.2.1.1.2. Outputs

2.2.1.1.3. Steps

2.2.1.2. A: Architecture Vision

2.2.1.2.1. Inputs

2.2.1.2.2. Outputs

2.2.1.2.3. Steps

2.2.1.3. B C D: Business/Information Systems/Technology Architecture

2.2.1.3.1. Inputs

2.2.1.3.2. Outputs

2.2.1.3.3. Steps

2.2.1.4. E: Opportuneties and Solutions

2.2.1.4.1. Inputs

2.2.1.4.2. Outputs

2.2.1.4.3. Steps

2.2.1.5. F: Migration Planning

2.2.1.5.1. Inputs

2.2.1.5.2. Outputs

2.2.1.5.3. Steps

2.2.1.6. G: Implementation Governance

2.2.1.6.1. Inputs

2.2.1.6.2. Outputs

2.2.1.6.3. Steps

2.2.1.7. H: Architecture Change Management

2.2.1.7.1. Inputs

2.2.1.7.2. Outputs

2.2.1.7.3. Steps

2.2.2. ADM Objectives, Approach & Process

2.2.2.1. Preliminary

2.2.2.1.1. Objectives

2.2.2.1.2. Approach

2.2.2.1.3. steps

2.2.2.2. A Architecture vision

2.2.2.2.1. Objectives

2.2.2.2.2. Approach

2.2.2.2.3. Steps

2.2.2.3. B. Business architecture

2.2.2.3.1. Objectives

2.2.2.3.2. Approach

2.2.2.3.3. Steps

2.2.2.4. C. Information systems

2.2.2.4.1. Data

2.2.2.4.2. Applications

2.2.2.5. D. technology architecture

2.2.2.5.1. Objectives

2.2.2.5.2. Approach

2.2.2.5.3. Process

2.2.2.6. E. Opportunity/solutions

2.2.2.6.1. Objectives

2.2.2.6.2. Approach

2.2.2.6.3. Steps

2.2.2.7. F, Migration planning

2.2.2.7.1. Objectives

2.2.2.7.2. Steps

2.2.2.8. G. Implementation governance

2.2.2.8.1. Objectives

2.2.2.8.2. Approach

2.2.2.8.3. Steps

2.2.2.9. Architecture requirements mgmg

2.2.2.9.1. Objectives

2.2.2.9.2. Approach

2.2.2.10. H. Architecture change mgmt

2.2.2.10.1. Objectives

2.2.2.10.2. Approach

2.2.2.10.3. Steps

2.2.3. Artifacts

2.2.3.1. 0: Preliminary

2.2.3.1.1. Principles Catalog

2.2.3.2. A: Architecture Vision

2.2.3.2.1. Stakeholder Map Matrix

2.2.3.2.2. Value Chain Diagram

2.2.3.2.3. Solution Concept Diagram

2.2.3.3. B: Business Architecture

2.2.3.3.1. Organization/Actor Catalog

2.2.3.3.2. Driver/Goal/Objective Catalog

2.2.3.3.3. Role Catalog

2.2.3.3.4. Business Service/Function Catalog

2.2.3.3.5. Location Catalog

2.2.3.3.6. Process/Event/Control/Product Catalog

2.2.3.3.7. Contract/Measure Catalog

2.2.3.3.8. Business Interaction Matrix

2.2.3.3.9. Actor/Role Matrix

2.2.3.3.10. Business Footprint Diagram

2.2.3.3.11. Business Service/Information Diagram

2.2.3.3.12. Functional Decomposition Diagram

2.2.3.3.13. Product Lifecycle Diagram

2.2.3.3.14. Goal/Objective/Service Diagram

2.2.3.3.15. Business Use-Case Diagram

2.2.3.3.16. Organization Decomposition Diagram

2.2.3.3.17. Process Flow Diagram

2.2.3.3.18. Event Diagram

2.2.3.4. C: Information Systems Architecture

2.2.3.4.1. Data

2.2.3.4.2. Application

2.2.3.5. D: Technology Architecture

2.2.3.5.1. Technology Standards Catalog

2.2.3.5.2. Technology Portfolio Catalog

2.2.3.5.3. Application/Technology Matrix

2.2.3.5.4. Environments and Locations Diagram

2.2.3.5.5. Platform Decomposition Diagram

2.2.3.5.6. Processing Diagram

2.2.3.5.7. Networked Computing/Hardware Diagram

2.2.3.5.8. Communications Engineering Diagram

2.2.3.6. E: Opportunities and Solutions

2.2.3.6.1. Project Context Diagram

2.2.3.6.2. Benefits Diagram

2.2.4. Summary

2.2.4.1. Resources

2.2.4.1.1. ADM Steps Reference

2.2.4.1.2. Architectural Artifacts

2.2.4.1.3. TOGAF 9 certification preparation advices & exam tips

2.2.4.1.4. Togaf Modeling

2.2.4.2. Exams

2.2.4.2.1. Level 1

2.2.4.2.2. Level 2

2.2.4.3. TOGAF 9.2 brief

2.2.4.3.1. Move to Modular

2.2.4.3.2. Why

2.2.4.3.3. ADM Vision and Business Phases

2.2.4.3.4. Content Metamodel

2.2.4.3.5. Summary

2.2.5. EA Operating Model

2.3. Exams

2.3.1. Part 1

2.3.1.1. Part 1 Exam

2.3.1.2. Questions and Answers

2.3.1.3. Part 1 online Sample Tests

2.3.2. Part 2