Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Togaf Foundation Study

No description
by

Patrice Kerremans

on 10 November 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Togaf Foundation Study

What is Togaf? Togaf Foundation Study TOGAF is an architecture framework

It is a tool for assisting in
acceptance
production
use
maintenance
of enterprise architectures

It is based on an iterative process model supported by best practices and a re-usable set of existing architectural assets The key to TOGAF is the process the Architecture Development Method (ADM) Structure of the TOGAF document Part I: Introduction
Part II: Architecture Development Method (ADM)
Part III: ADM Guidelines and Techniques
Part IV: Architecture Content Framework
Part V: Enterprise Continuum
Part VI: TOGAF Reference Models
Part VII: Architecture Capability Framework Section II ADM: describes the step-by-step approach to developing an enterprise architecture Section III ADM Guidelines and Techniques: This part contains a set of guidelines and techniques available for use in applying the ADM. Part IV Architecture Content Framework:
Describes the ACF. Includes:
a structured meta model for architectural artifacts,
Architecture Building Blocks (ABBs)
Overview of typical architecture deliverables Part V Enterprise Continuum and tools:
Taxonomies and tools to categorize and store the outputs of architecture activity within the enterprise Part VI TOGAF reference models:
Two reference models: 1) TRM, 2) III-RM
Technical Reference Model
Integrated Information Infrastructure Reference Model Part VII Architecture Capability Framework:
Discusses:
roles
organization
responsibilities
processes
skills
Required to establish and operate an architecture practice within the enterprise RORPS Intro
ADM
ADM GT
AConF

EC
RM
ACapF I AAA ETA AcPrUsMa "I triple-A eta" What is an enterprise? TOGAF defines an enterprise as any collection of organizations that has a common set of goals Examples:
Government agency
Whole corporation
Division of a corporation
Single department
Chain of geographically distant organizations linked together by common ownership Section I Introduction: describes the basic TOGAF concepts What is an architecture? ISO/IEC defines an architecture as: the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution Enterprise Architecture (according to MIT):
The organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm's operating model. Enterprise Architecture (according to SearchCIO.com):
A conceptual blueprint that defines the structure and operation of an organization Purpose of Enterprise Architecture:
to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy. Using an architecture framework will speed up and simplify architecture development, ensure more complete coverage of the designed solution and make certain that the architecture selected allows for future growth in response to the needs of the business. TOGAF is a suitable framework, since it's been developed by 300 Architecture forum member companies More on the purpose of Enterprise Architecture:
Enterprise architecture development is a technically complex process, and the design of heterogeneous, multi-vendor architectures is particularly complex. TOGAF plays an important role in helping to "de-mystify" and "de-risk" the architecture development process. It also provides a platform for adding value, and enables users to build genuinely open systems-based solutions to address their business issues and needs. TOGAF supports four different architecture domains: Business Architecture Technology Architecture Application
Architecture Data
Architecture Business Architecture: the business strategy, governance, organization, and key business processes.
Data architecture: the structure of an organization's logical and physical data assets and data management resources.
Application architecture: a blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization
Technology Architecture: The software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, and standards. Meta Model content framework by ADM phase Detailed
Meta Model content framework by ADM phase Architects executing the 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. The TOGAF Architecture Content Framework (see Part IV, Chapter 33) provides a structural model for architectural content that allows major work products to be consistently defined, structured, and presented.Architects executing the 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. The TOGAF Architecture Content Framework (see Part IV, Chapter 33) provides a structural model for architectural content that allows major work products to be consistently defined, structured, and presented.The Preliminary Phase describes the preparation and initiation activities required to create an Architecture Capability including customization of TOGAF and definition of Architecture Principles.rchitecture Visionrchitecture Visionrchitecture Vision Deliverables
Artifacts
Architecture Building Blocks (ABBs) a deliverable is a work product that is contractually specified and in turn formally reviewed, agreed, and signed off by the stakeholders. Deliverables represent the output of projects An artifact is an architectural work product that describes an aspect of the architecture. Artifacts are generally classified as catalogs (lists of things), matrices (showing relationships between things), and diagrams (pictures of things). A building block represents a (potentially re-usable) component of business, IT, or architectural capability that can be combined with other building blocks to deliver architectures and solutions. Architecture Building Blocks (ABBs) typically describe required capability and shape the specification of Solution Building Blocks (SBBs). For example, a customer services capability may be required within an enterprise, supported by many SBBs, such as processes, data, and application software.
Solution Building Blocks (SBBs) represent components that will be used to implement the required capability. For example, a network is a building block that can be described through complementary artifacts and then put to use to realize solutions for the enterprise. Relationships between Deliverables, Artifacts, and Building Blocks The Enterprise Continuum The Architecture Repository The major components within an Architecture Repository are as follows:
1. The Architecture Metamodel describes the organizationally tailored
application of an architecture framework, including a metamodel for architecture content.
2. The Architecture Capability defines the parameters, structures, and
processes that support governance of the Architecture Repository.
3. The Architecture Landscape is the architectural representation of assets
deployed within the operating enterprise at a particular point in time. The landscape is likely to exist at multiple levels of abstraction to suit different architecture objectives.
4. The Standards Information Base (SIB) captures the standards with
which new architectures must comply, which may include industry standards, selected products and services from suppliers, or shared services already deployed within the organization.
5. The Reference Library provides guidelines, templates, patterns, and
other forms of reference material that can be leveraged in order to accelerate the creation of new architectures for the enterprise.
6. The Governance Log provides a record of governance activity across the
enterprise. The Preliminary Phase describes the preparation and initiation activities required to create an Architecture Capability including customization of TOGAF and definition of Architecture Principles. Phase A: Architecture Vision describes the initial phase of an architecture development cycle. It includes information about defining the scope of the architecture development initiative, identifying the stakeholders, creating the Architecture Vision, and obtaining approval to proceed with the architecture development. Phase B: Business Architecture describes the development of a Business Architecture to support the agreed Architecture Vision. Phase C: Information Systems Architectures describes the development of Information Systems Architectures to support the agreed Architecture Vision. Phase D: Technology Architecture describes the development of the Technology Architecture to support the agreed Architecture Vision. Phase E: Opportunities & Solutions conducts initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases. Phase F: Migration Planning addresses how to move from the Baseline to the Target Architectures by finalizing a detailed Implementation and Migration Plan. Phase G: Implementation Governance provides an architectural oversight of the implementation. Phase H: Architecture Change Management establishes procedures for managing change to the new architecture. Requirements Management examines the process of managing architecture requirements throughout the ADM. A BIT O' MIA rchitecture Vision usiness Architecture nformations Systems Architecture echnology Architecture pportunities & Solutions igration Planning mplementation Governance rchitecture Change Management Chapters

Establishing an Architecture Capability
Architecture Board
Architecture Compliance
Architecture Contracts
Architecture Governance
Architecture Maturity Description

Guidelines for establishing an Architecture Capability within an organization
Guidelines for establishing and operating an enterprise Architecture Board
Guidelines for ensuring project compliance to architecture
Guidelines for defining and using Architecture Contracts
Framework and guidelines for Architecture Governance
Models Techniques for evaluating and quantifying an orgnaization's maturity in
enterprise architecture TOGAF and other frameworks TOGAF defines:
1. a set of deliverables that an architect should produce
2. a method for producing these deliverables TOGAF allows for replacing or extending the deliverables. It also allows for adoption and integration of other standard frameworks like ITIL, Prince2... Document Categorization Model Model to assist with the release management of specification content. It defines 4 categories of content:
1. Core
2. Mandated
3. Recommended
4. Supporting CorManRecSup TOGAF Core: The fundamental concepts that form the essence of TOGAF. E.g. Core concepts

TOGAF Mandated: The normative parts of the TOGAF specification. These elements are central to its usage and without them the framework would not be recognizable TOGAF. E.g. for each ADM phase: objectives, inputs, steps, outputs

TOGAF Recommended: A pool of resources that are specifically referenced in TOGAF as ways in which TOGAF core and TOGAF Mandated processes can be accomplished. E.g. Business Scenarios, Gap Analisys, The SEI Architecture Trade-off Analysis Method.

TOGAF Supporting: Additional resources not referenced in the othe TOGAF categories. E.g. Release Notes, Evaluation Criteria for Tools. Key TOGAF Terminology Activity: A task or collection of tasks that support the functions of an organization; for example, a user entering data into an IT system or travelling to visit customers Application: A deployed and operational IT system that supports business functions and services; for examples, a payroll. Applications use data and are supported by multiple technology components but are distinct from the technology components that support the application. Application Architecture: A description of the major logical grouping of capabilities that manage the data objects necessary to proces the data and support the business. Architecture:
1. either, A formal description of a system, or a detailed plan of the system at component level to guide its implementation.
2. or, The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time. Architecture Continuum: part of the enterprise continuum. A repository of architectural elements with increasing detail and specialization.
Foundational Architectures
Industry Architectures
Organization specific architectures Architecture Building Block (ABB): describes a single aspect of the overall model. Architecture Development Method (ADM): The core of TOGAF, a step-by-step, iterative approach to develop and use an enterprise architecture. Architecture Domain: the architectural area being considered: Business, Data, Application, and Technology. In short: BDAT Architecture Framework: A foundational structure, or set of structures, which can be used for developing a broad range of different architectures. Architecture Principles: A qualitative statement of intent that should be met by the architecture. Has at least a supporting rationale and a measure of importance Architecture View: View Architecture Vision:
High-level, aspirational view of the target architecture
Phase in the ADM
Deliverable describing the Architecture Vision Baseline: A specification that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development or change and that can be changed only through formal change control procedures or a type of procedure such as configuration management. Building block: represents a potentially re-usable component of business, IT, or architectural capability that can be combined with other building blocks to deliver architectures and solutions. Business Architecture:
business strategy
governance
organization
key business process information
the interaction between the above Business Governance: ensuring that the business processes and policies deliver the business outcomes and adhere to relevant business regulation. Capability: An ability that an organization, person, or system possesses Concerns: the key interests that are crucially important to the stakeholders in a system, and determine the acceptability of the system. Constraint: an external factor that prevents an organization from pursuing particular approaches to meet its goals. Data Architecture: the structure of an organization's logical and physical data assets and the data management resources. Deliverable: contractually specified architectural work product; formally reviewed, agreed, and signed off by stakeholders. Enterprise: the highest level of description of an organization and typically covers all missions and functions Enterprise Continuum: A categorization mechanism usefull for classifying architecture and solution articfacts. Foundation Architecture: An architecture of generis services and functions that provides a foundation on whic more specific architectures an architectural components can be built. Gap: a statement of difference between two states, typically meant between baseline and target architectures. Governance: the discipline of monitoring, managing, and steering a business (or IS/IT landscape) to deliver the business outcome required Information: any communication or representation of facts, data, or opinions, in any memium or form. Information Technology (IT):
1. the lifecycle management of information and related technology used by an organization
2. the wider umbrella term as we know and use it
3. also short for the IT department Logical (Architecture): an implementation independent definition of the architecture. Metadata: data about data. Metamodel: a model that describes how and with what the architecture will be described in a structured way Method or Methodology: a defined, repeatable approach to address a particular type of problem Model: a representation of a subject of interest. Provides a smaller scale, simplified, and/or abstract representation of the subject matter.
Full transcript