Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

TOGAF Classroom Series - M3 intro-adm


Published on

The TOGAF Course Material Taught @Gebze Technical University

Published in: Technology
  • Be the first to comment

TOGAF Classroom Series - M3 intro-adm

  1. 1. Introduc)on to the Architecture Development Method Module 3
  2. 2. Module Objec)ves • The TOGAF ADM • Its rela1onship to other parts of TOGAF • The phases of the ADM • How and why to adapt the ADM • How to scope an architecture ac1vity • The need for an integra1on framework
  3. 3. What is TOGAF ADM? • The ADM forms the core part of TOGAF • The result of contribu1ons from architecture prac11oners • A process for developing an EA • Integrates all the elements within TOGAF • Designed to address business and IT needs through • A set of architecture views • A set of recommended deliverables • A method for managing requirements • Guidelines on tools for architecture development
  4. 4. ADM - Process • The ADM is an itera1ve process • over the whole process • between phases • within phases • For each itera1on, re-consider • Scope • Detail • Schedules, milestones
  5. 5. ADM - Process • Consider assets from: • Previous itera1ons • Marketplace, according to availability, competence and value • Other frameworks • Systems models • Ver1cal Industry models
  6. 6. Rela)onship to other parts of TOGAF
  7. 7. ADM Key Points
  8. 8. ADM Phases
  9. 9. ADM Phase Steps Example
  10. 10. ADM Inputs and Outputs • TOGAF defines a number of inputs and outputs for each phase • These are sugges1ons, therefore not mandatory • Output of an early phase may be modified in a later phase • Version numbers are used to manage the output • A conven1on is used to illustrate the evolu1on of deliverables • 0.1 – a high level outline deliverable • 1.0 – a formally reviewed detailed deliverable
  11. 11. Adap)ng the ADM • Generic methodology intended for various enterprises • Usable with deliverables of other frameworks such as Zachman, DODAF, … • It is usual to modify or extend the ADM to suit specific needs
  12. 12. Governing the ADM • ADM is a key process to be managed and governed • The Architecture Board should be sa1sfied that the method is being applied correctly • The management of all architectural ar1facts, governance and related process should be supported by a controlled environment such as a repository, Architecture Repository
  13. 13. Governance Repository • Reference Data •  Used for guidance and instruc1on during project implementa1on. • Process Status •  All informa1on regarding the state of any governance processes will be managed • Audit Informa1on •  All completed governance process ac1ons
  14. 14. Reasons to constrain the Scope of Architectural Ac)vity • The organiza1onal authority of the team producing the architecture • The objec1ves and stakeholder concerns to be addressed within the architecture • The availability of people, finance, and other resources
  15. 15. Scoping the Architecture Ac)vity • There are four dimensions in which scope may be limited • Breadth • Depth (Level) • Time Period • Architecture Domains
  16. 16. Architecture Integra)on across the Landscape
  17. 17. Summary • The ADM is comprehensive, general method • ADM recommends a sequence for various phases and steps involved in developing an architecture • ADM is an itera1ve method • ADM draws on the other parts of TOGAF for assets and processes • ADM can be used with other deliverables from other frameworks