Togaf 9.2 Level 1  (Part 1)

Togaf 9.2 Level 1 (Part 1)


efore we go in details , we have to know how can we read the open group standards document, you should download the following two document from open group website:

1- TOGAF 9.2 Conformance Requirements

No alt text provided for this image

2- TOGAF Standard 9.2

No alt text provided for this image

in the TOGAF9.2 Conformance Requirements go to

No alt text provided for this image

this is what you should know for Level 1 , look at KLP reference , for example : Describe what an enterprise is (KLP 1.3-1) , then open the (TOGAF Standard 9.2) document and go to section 1.3 as follow :

No alt text provided for this image

now you have the capability to read open group document for the exams (level 1 and 2), so let's start our course :)

What is an Enterprise?

A collection of organizations that share a common set of goals :

  • Government agency
  • Part of a corporation
  • Corporation

Large corporations may comprise multiple enterprises May be an “extended enterprise” including partners, suppliers and customers

What is an Architecture??

An Architecture is the fundamental concepts or properties of a system in its environment embodied in:

  • its elements,
  • their relationships to each other and the environment,
  • and the principles governing its design and evolution.

What is Enterprise Architecture??

Enterprise Architecture is:

  1. The organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm’s operating model.
  2. A conceptual blueprint that defines the structure and operation of an organization. The intent of an Enterprise Architecture is to determine how an organization can most effectively achieve its current and future objectives.

What is The Architecture Types??

No alt text provided for this image

Why Enterprise Architecture?

Two key reasons why you need an Enterprise Architecture:

  • A means to achieve competitive advantage
  • Enables managed innovation within the enterprise

What Are The Business Benefits of Enterprise Architecture?

  • Achieve business strategy
  • Faster time to market
  • More consistent business processes and information
  • More reliability and security, less risk
  • More efficient business operation
  • More efficient IT operation
  • Better ROI
  • Reduced risk
  • Faster, simpler, and cheaper procurement

What do we mean by Governance?

The way in which decisions are made

  • Who is responsible?
  • Who is involved?
  • Who is accountable?

What is an Architecture Framework?

A conceptual structure used to develop, implement, govern, and sustain an architecture

The framework has:

  • A method to design EA in terms of BBs
  • A set of tools
  • A common vocabulary
  • A list of recommended standards
  • A list of recommended products to implement the BBs

TOGAF Framework Components

No alt text provided for this image

  • Architecture Development Method (ADM)
  • ADM Guidelines and Techniques
  • Architecture Content Framework
  • The Enterprise Continuum
  • The Architecture Capability Framework
  • The TOGAF Library


Architecture Development Method?

No alt text provided for this image

Core of TOGAF

The ADM is an iterative process:

  • Over the whole process
  • Between phases
  • Within phases

For each iteration, re-consider:

  • Scope
  • Detail
  • Schedules, milestones

Each phase includes objectives, approach, inputs, steps and output deliverables :

  • These are suggestions and need not be followed exactly
  • Output of an early phase may be modified in a later phase
  • Version numbers are used to manage the output
  • A convention is used to illustrate the evolution of deliverables ( 0.1 is a high level outline deliverable and 1.0 is a formally reviewed detailed deliverable )?

The result of contributions from many architecture practitioners

A process for developing an EA

Integrates all the elements within TOGAF

Generic methodology intended for variable (Geographies ,Vertical sectors ,Industry types )

Usable with deliverables of other frameworks such as Zachman, DODAF, …

Designed to address enterprise’s business and IT needs by providing:

? A set of views (business, data, application, technology)

? A set of recommended deliverables

? A method for managing requirements

? Guidelines on tools for EA development?

The ADM itself must be managed and governed

The Architecture Board is responsible for ADM governance

Governance needs a controlled environment

Scoping the Architecture Activity

No alt text provided for this image


There are four dimensions in which scope may be limited:

  • Breadth
  • Depth
  • Time Period
  • Architecture Domains

Preliminary Phase?

No alt text provided for this image

Phase A: Architecture Vision

No alt text provided for this image

Approach

The architecture vision is an important selling tool

? Clarifying the purpose of the architecture

? Showing how it will be achieved

? High level view of the baseline and target architectures

? What is in and what is out the architecture effort

Emerging technologies help to catch opportunities

If business goals, drivers, constraints and principles are defined understand them, otherwise establish them?

Phase B: Business Architecture

No alt text provided for this image

Approach

? Knowledge of the Business Architecture is a prerequisite for Data, Applications and Technology architectures

? Business Strategy defines what to achieve

? Business Architecture describes how to achieve it

? Check if some of the Business Architecture work is already done under another discipline (e.g. business planning or enterprise planning)

? Scope depends on existing strategy and planning

? If there is no existing strategy or planning, identify any existing architecture definitions, then verify and update

? In both cases, use business scenarios to identify key business objectives and processes

?

Phase C: Information Systems Architectures?

The Information Systems Architecture including development Data and Application:

  • The IS elements (e.g. data and applications)
  • Their relationships
  • The governing principles

Data or Applications first?

May be developed in either order, or in parallel

  • Theory suggests Data first
  • Practical considerations lead to Application first

There will need to be some iteration to ensure consistency

Phase D: Technology Architecture?

No alt text provided for this image


Approach

Consider Emerging Technologies

? Evolution of new technologies is a major driver for Review the Technology Architecture Resources available in the Architecture Repository

? Existing IT Services in the IT Repository or IT Service Catalog

? The adopted technical reference model, if applicable

? Technology models relevant to the organization (e.g. TM Forum models for telecommunication and the open group TRM and III-RM)

Phase E: Opportunities and Solutions?

No alt text provided for this image

Approach

Key concepts for transitioning from developing to delivering a Target Architecture:

? Architecture Roadmap:lists individual work packages in a timeline that will realize the Target Architecture

? Work Packages: logical group of changes necessary to realize the Target Architecture

? Transition Architectures: describes the enterprise at an architecturally significant state between the Baseline and Target Architectures

? Implementation and Migration Plan: provides a schedule of the projects that will realize the Target Architecture

Phase F: Migration Planning?

No alt text provided for this image

Approach

The focus is finalization of the Implementation and Migration plan initially prepared in Phase E

Activities include the dependencies, costs, and benefits of the various migration projects?

Phase G: Implementation Governance?

No alt text provided for this image

Approach

Establish Architecture Contract

The development happens in parallel with Phase G

Adopt a phased deployment schedule that reflects the business priorities embodied in the Architecture Roadmap

Follow the organization's standard for governance

Use the organization's established portfolio / program management approach, where this exists

Define an operations framework to ensure the effective long life of the deployed solution

Phase H: Architecture Change Management?

  • Provide change management process
  • Ensure flexibility and responsive to changes in technology or business environment
  • Monitors the business and capacity management?

The TOGAF 9.2 Library?

A portfolio of guidance material to support practical application of the TOGAF standard

It contains guidelines, templates, patterns and other forms of reference material

Over 160 documents (as of January 2021)

TOGAF Library – Structure

Section 1: Foundation Documents

Section 2: Generic Guidance and Techniques

Section 3: Industry-Specific Guidance and Techniques

Section 4: Organization-Specific Guidance and Techniques?



ADM Guidelines and Techniques

A set of guidelines and techniques to support the application of the ADM

The guidelines help to adapt the ADM to deal with different scenarios, including different process styles (e.g. the use of iteration) and also specific requirements (e.g. security).

The techniques support specific tasks within the ADM (e.g. defining principles, business scenarios, gap analysis, migration planning, risk management, etc).

Architecture Content Framework?

No alt text provided for this image

Models architectural Deliverables, Artifacts and the ABBs

  • Ensures consistency, completeness and integration of ADM outputs
  • It provides an open standard for architecture description
  • Has a detailed metamodel

Deliverables, Artifacts and Building Blocks

No alt text provided for this image


TOGAF Standard, Version 9.2 Artifacts

No alt text provided for this image

Building Blocks

A package of functionality defined to meet the business needs across an organization

A building block has a type that corresponds to the metamodel (e.g. actor, application, data entity …)

A building block has published interfaces to access functionality

A building block may interoperate with other, inter-dependent building blocks?

A Good Building Block Is :

  • Considers implementation and usage and evolves to exploit technology and standards
  • May be assembled from or a subassembly of other building blocks
  • Is reusable and replaceable

Systems are built from collections of building blocks

ABBs group functionality

SBBs group real products

No alt text provided for this image

An architecture need only contain building blocks

Building blocks may implement one, more than one, or only part of a service identified in the architecture

Building blocks should conform to standards

Consider the integration between BBs

BBs could be developed, purchased or reused




Full Content Metamodel with Relationships

No alt text provided for this image

The Enterprise Continuum?

Noun: a continuous extent of something, no part of which is different from any other

A model for structuring a virtual repository and methods for classifying architecture and solution artifacts.

The practical implementation of the Enterprise Continuum takes the form of an Architecture Repository?

Combination of Architecture Continuum and Solutions Continuum

Enables effective use of COTS (A?COTS?(commercial off-the-shelf) product is one that is used "as-is." COTS products are designed to be easily installed and to interoperate with existing system components)

Improves engineering efficiency

Organizes reusable assets

It provides a common language:

  • Within enterprises
  • Between customer enterprises and vendors

The Enterprise Continuum consists of all architecture assets: models, patterns, architecture descriptions, etc. External assets include:

  • Generic reference models (eg TOGAF’s TRM, Zachmann…)
  • IT-specific models (eg a web services architecture)
  • Information Processing-specific models (eg e-Commerce, supply chain management …)
  • Vertical-Industry-specific models (eg TMF, ARTS, POSC…)

The architecture governance function decides which assets an enterprise considers part of its own Enterprise Continuum?

Contains complete and work-in-progress solutions

It is a "framework-within-a-framework” Has few internal assets, at first Grows by adding reusable building blocks?

The Enterprise Continuum improves productivity through leverage

The Enterprise Continuum does not represent strictly chained relationships :

  • enterprise architectures may have components from a Common Systems Architecture
  • enterprise solutions may contain a product or service

No alt text provided for this image

Tools are needed to manage and control the artifacts within the Enterprise Continuum :

  • To promote re-use
  • To enable sharing of architecture information
  • To facilitate easier maintenance of the architecture
  • To ensure common terminology is used
  • To provide stakeholders with relevant models?

The Architecture and Solutions Continuum are related by guidance, direction, and support.

The Open Group Technical Reference model (TRM) is a Foundation Architecture

The Open Group III-RM is a Common Systems Architecture

The Architecture Continuum?

No alt text provided for this image

The Solutions Continuum?

No alt text provided for this image

Represents the implementations of the architectures at the corresponding levels of the Architecture Continuum

It is a population of the architecture with SBBs, either purchased products or built components

It forms a Solutions Inventory or Reuse Library

Architecture Repository

A formal taxonomy for different types of architectural assets

This is one part of a wider Enterprise Repository?

No alt text provided for this image

Architecture Landscape

  1. Strategic Architectures:

  • Long-term summary view of the entire enterprise.
  • High level description oriented for executive level

2. Segment Architectures:

  • Focus on areas within the enterprise (e.g. sectors or departments) in more details
  • Related to portfolio or program

3. Capability Architectures:

  • Focus on specific capability in more details
  • Related to work packages or projects

Reference Library

Holds models (e.g. TOGAF, CMMI, ITIL …), best practice, viewpoint library, templates …

The architecture may not conform to its contents

Compliance with the standards is not assessed during governance

Sources come from:

  • Standards bodies (if not used as standards)
  • Product and service vendors
  • Industry communities or forums
  • Corporately defined templates (may come from CMMI, ISO, ITIL …)
  • Best practice resulting from this project or other projects


Standards Information Base

Holds a set of specifications, to which architectures must conform.

Compliance with the standards is assessed during governance

Standards should be:

  • Easily accessible
  • Clear and unambiguous manner

Types of Standard

  • Legal and Regulatory
  • Industry
  • Organizational

Standards Lifecycle

  • Trial
  • Active
  • Deprecated
  • Obsolete

Standards Classification?

  1. Business Standards:

  • ? Shared business functions
  • ? Role and actor definitions (e.g. NCF)
  • ? Security and governance

2. Data Standards:

  • ? Coding and values for data
  • ? Structures and formats for data
  • ? Origin and ownership of data (e.g. IT4IT)
  • ? Replication and access

3. Applications Standards:

  • ? Application sharing
  • ? Application communication and interoperation
  • ? Access, presentation, and style

4. Technology Standards:

  • ? Hardware products
  • ? Software products
  • ? Software development

Governance Log?

  1. Decision Log:

  • Product selections
  • Justification for major architectural features of projects
  • Standards deviations
  • Standards lifecycle changes
  • Change Request evaluations and approvals
  • Re-use assessments

2. Compliance Assessments:

  • Project overview
  • Progress overview (timeline, status, issues, risks, dependencies, etc.)
  • Completed architecture checklists
  • Standards compliance assessment
  • Recommended actions

3. Capability Assessments:

  • Templates and reference models for Capability Assessments
  • Business Capability Assessments
  • IT capability, maturity, and impact assessments
  • Architecture maturity assessments

4. Calendar (Schedule)

5. Project Portfolio

  • Name and Description
  • Scope
  • Roles and responsibilities

6. Performance Measurement

Architecture Requirements Repository

Holds the architecture requirements on different levels Used by all phases of the ADM

Managed by the Architecture Requirements phase of the ADM

Solutions Landscape

A repository area used to hold architectural representations of all Solution Building Blocks (SBBs) supporting Architecture Building Blocks (ABBs) specified, developed, or deployed


The TOGAF ADM has reminders when to use assets from the Architecture Repository

The Architecture Repository is a model for a physical instance of the Enterprise Continuum

Capability Framework

No alt text provided for this image

TOGAF Reference Models

There are two Reference Models provided in the TOGAF Library

  1. The TOGAF Technical Reference Model (TRM)

? A Foundation Architecture

? A model and a taxonomy of generic platform services

2. The Integrated Information Infrastructure Model (III-RM).

? A model for business applications and infrastructure applications

? Supports the Boundaryless Information Flow? vision?

Boundaryless Information Flow?

A trademark of The Open Group

Access to integrated information to support business

Combines multiple sources of information

Securely delivers the information

Architecture Principles

An initial output of the Preliminary Phase

A set of general rules and guidelines for the architecture being developed

The TOGAF standard contains guidelines for developing principles and a detailed set of generic principles Principles are generally established in two key domains:

  • Enterprise principles provide a basis for decision-making throughout an enterprise and dictate how the organization fulfills its mission
  • Architecture principles are a set of principles that relate to architecture work.

They inform and support the way in which an organization sets about fulfilling its mission

Often they are one element in a structured set of ideas that collectively define and guide the organization, from values through to actions and results

Represents the essence of the rule

Easy to remember

Should not mention specific technology platforms

Should avoid ambiguous words (e.g. support, open, consider, avoid …) Statement

Must be clear

Must be unambiguous

Highlights the business benefits of adhering to the principle

Describes the relationship to other principles (e.g. precedence, weight …)

Business and IT requirements for the principle

The impact and consequences of the principle on the business

Five Qualities of Principles

1.Understandable: they can be quickly grasped. Intent is clear and unambiguous

2.Robust: precise to enable decisions and enable policies and standards to be created

3.Complete: cover every situation perceived

4.Consistent: not contradicting

5.Stable: principles should not change frequently, although they can change


Principles should be few in number ,Recommended number of principles is 10 to 15

Architecture Governance

Governance includes:

? controlling the activities

? ensuring compliance with standards and regulatory obligations

? supporting management

? ensuring accountability to stakeholders

Governance should be established in the Preliminary Phase

? Usually an adaptation of existing governance and support models

The Architecture Board governs the ADM Governance plays a key role in Phases G and H

Governance ensures business is conducted properly

It is less about overt control and strict adherence to rules

It is about effective and equitable usage of resources to ensure sustainability of strategic objectives

The hierarchy of governance domains includes:

? Corporate Governance (outside of TOGAF scope)

? Technology Governance

? IT Governance

? Architecture Governance

Each domain may exist at multiple geographic levels: ( Global - Regional - Local?)

Phase G of the TOGAF ADM is about Implementation Governance - the realization of architecture through change projects

? Implementation governance is just one aspect of Architecture Governance

The Architecture Governance Framework is generic and can be adapted to an existing governance environment?

Architecture Board

The Board oversees implementation of the governance strategy Board comprises of representative stakeholders at 2 levels:

? Local (domain experts, line responsibility)

? Global (organization-wide responsibility)

? Board has identifiable and articulated:

? Responsibilities and decision-making capabilities

? Remit and authority limits

Architecture Contracts

Joint agreements between development partners and sponsors on the deliverables, qualify and fitness-for-purpose of an architecture?

The Statement of Architecture Work created in Phase A

Architectures Domains (Business, Data, Application, Technology)

Phase G Implementation projects

No alt text provided for this image

Architecture Compliance

Two processes are defined to ensure compliance of projects with the Enterprise Architecture: ? Prepare Project Impact Assessments - project-specific views that illustrate how the Enterprise Architecture impact a project

? Perform an Architecture Compliance Review

No alt text provided for this image

Architecture Capability

TOGAF provides guidelines to establish an EA capability

? Use of the ADM

? Treat is as an ongoing practice

? Address the four domain architectures

? Business Architecture: the architecture governance, architecture processes, architecture organizational structure, architecture information requirements, architecture products, etc.

? Data Architecture: the structure of the organization's Enterprise Continuum and Architecture Repository

? Application Architecture: the functionality and / or applications services required to enable the architecture practice

? Technology Architecture: infrastructure requirements and deployment in support of the architecture applications and Enterprise Continuum

Architecture Views and Viewpoints

system is a combination of interacting elements organized to achieve one or more stated purposes.

Stakeholders are individuals, teams, organizations, or classes thereof, having an interest in a system. They are people who have key roles in, or concerns about, the system; for example, users, developers, etc

Concerns are interests in a system relevant to one or more of its stakeholders. Concerns may pertain to any aspect of the system’s functioning, development, or operation, including performance, reliability, security, distribution, and evolvability, and may determine the acceptability of the system?

Architecture View is a representation of a system from the perspective of a related set of concerns.

A representation of an overall architecture with meaning to one or more stakeholders in the system

For example: a building architect might create wiring diagrams, floor plans, and elevations to describe different facets of a building to its different stakeholders (electricians, owners, planning officials etc.)

An enterprise architect might create physical and security views of an IT system?

Architecture Viewpoint defines the perspective from which an architecture view is taken. ? It defines how to construct and use an architecture view

Architecture Views and Viewpoints Used in phases A to D :

? An architecture view is what you see

? An architecture viewpoint is where you are looking from

? Every architecture view has an associated architecture viewpoint that describes it, at least implicitly.

? Architecture viewpoints are generic, and can be stored in libraries for reuse.

? An architecture view is always specific to the architecture for which it is created.?

Developing Architecture Views in the ADM

The architect has a responsibility for ensuring:

? the completeness of the architecture

? does it address all the concerns of its stakeholders?

? the integrity of the architecture

? can the architecture views be connected to each other?

? can the conflicting concerns be reconciled?

? what trade-offs have been made (e.g. between security and performance)?

The Architecture View Creation Process

1. Refer to any existing libraries of viewpoints

2. Select key stakeholders

3. Analyze their concerns

4. Select appropriate architecture viewpoints

5. Generate views

If no libraries of architecture viewpoints exist then:

1. Select key stakeholders

2. Analyze their concerns

3. Develop new architecture viewpoints

4. Generate views

Alternatively create an ad hoc architecture view and then consider whether a generalized form of the implicit viewpoint should be defined explicitly and saved.

Business Transformation Readiness Assessment – Overview (technique)

EA involves considerable change

The readiness of an organization to accept change must be assessed and understood

This assessment is a key success factor in phases E and F

Initial assessment is done in phase A

This is a joint effort between corporate staff, lines of business and IT planners.

Business Transformation Readiness Assessment Steps

1. Determine the readiness factors

2. Present the readiness factors using maturity models (current, intermediate and target)

3. Assess the readiness factors (urgency, readiness and difficulty)

4. Assess the risks for each readiness factor and identify mitigating actions

5. Work these actions into Phase E and F Implementation and Migration Plan

Assess the Readiness Factors?

No alt text provided for this image

Risk Management – Overview (technique)

There are two levels of risk that should be considered:

? Initial Level of Risk: Risk categorization prior to determining and implementing mitigating actions.

? Residual Level of Risk: Risk categorization after implementation of mitigating actions

The process for risk management is:

? Risk classification

? Risk identification

? Initial risk assessment

? Risk mitigation and residual risk assessment

? Risk monitoring

Risks are identified in Phase A as part of the initial Business Transformation Readiness Assessment

Risks are maintained and monitored as governance artifacts in Phase G

New risks may be identified in Phase G (or at any other phase actually)

Another full or partial ADM cycle may be required to mitigate some risks

Risk Classification Scheme?

No alt text provided for this image

Risk Identification and Mitigation??

No alt text provided for this image

Business Scenarios – Overview (technique)

No alt text provided for this image


A business scenario describes:

? a business process, application or set of applications that can be enabled by the architecture

? the business and technology environment;

? the people and computing components (the “actors”) who execute it;

? the desired outcome of proper execution.


Used prominently in Phase A (Architecture Vision) and iteratively in Phase B (Business Architecture)

Business Requirements are referred to throughout all phases of the ADM


A good business scenario:

? Is representative of a significant business need or problem

? Enables vendors to understand the value of a developed solution to a customer.

? Is “SMART”

Specific defines what needs to be done to done in the business;

Measurable has clear metrics for success;

Actionable clearly segments the problem, and provides the basis for finding a solution;

Realistic defines the bounds of technology capability and cost constraints;

Time-bound gives a clear understanding of when a solution expires

Sir yeh PIA ka TOGAF kesy bane ga

回复

要查看或添加评论,请登录

社区洞察

其他会员也浏览了