TOGAF Architecture Development Method (ADM)

ADM, de TOGAF Architecture Development Method is een iteratieve cyclus van de onderstaande fasen. Requirements Management staat centraal in de cyclus en is daarmee aan de orde in elk van de overige fasen m.u.v. de Preliminary fase. De centrale Requirements Management fase is dus niet zozeer een fase maar een continue proces voor het organiseren en beheren van de requirements en de veranderingen daarop. De requirements inhoudelijk worden opgesteld binnen verschillende andere fasen.

  1. Preliminary: de voorbereiding en opstart (initiatie) activiteiten voor het opzetten van de Architectuur organisatie (de “Architecture Capability”) zoals architectuurteam(s), de Governance inrichting (o.a. architectuurboard), het vaststellen van de Enterprise scope met de betrokken organisatie onderdelen, het vaststellen van de architectuurmethode met eventueel het op maat snijden van TOGAF (ook qua integratie met eventueel andere methodes), en het definiëren van de Architectuur Principes. Deze fase kan eventueel met een “Request for Architecture Work” de vervolgfase A opstarten.
  2. A: Architectuur Visie scope bepaling van het architectuur initiatief, identificatie van de stakeholders en hun concerns, vaststellen van de business requirements voor alle concerns, beschrijven van de Architectuur Visie met een voorgestelde schets van een oplossing (solution), het organiseren en plannen van de architectuurwerkzaamheden met een “Statement of Architecture Work” en het verkrijgen van goedkeuring hiervoor en daarmee starten van de volgende fasen.
  3. B: Business Architectuur : opstellen van de Business Architectuur in het “Architecture Definition Document” en de business architecture requirements daarvoor in de “Architecture Requirements Specification”.
  4. C: Informatie Systeem Architecturen : opstellen van de Informatie Systeem  Architecturen: Applicatie Architectuur en Data Architectuur in het “Architecture Definition Document” en de application en data architecture requirements daarvoor in de “Architecture Requirements Specification”.
  5. D: Technologie Architectuur : opstellen van de Technologie Architectuur in het “Architecture Definition Document” en de technology architecture requirements daarvoor in de “Architecture Requirements Specification”.
  6. E: Opportunities & Solutions : Initiële opzet van de Architecture Roadmap en de implementatieplannen.
  7. F: Migratie Planning : detail implementatie en migratieplan voor transitie van de huidige Baseline naar de Target Architecturen. Consolidatie van de tot dan toe opgestelde documenten vanaf fase A.
  8. G: Implementatie Governance : Architecture Contracts worden opgesteld als architectuuropdracht voor de implementatieprojecten. De projectresultaten, de opgeleverde SBB’s en capability increments worden beoordeeld middels compliance assessments. Voor eventuele benodigde aanpassingen in de architectuur die worden onderkend tijdens de implementatie worden Change Requests opgesteld en eventueel uitgevoerd voor de architectuurproducten.
  9. H: Architectuur Change Management :D it is feitelijk een continue proces waarin monitoring plaatsvindt op de prestaties van operationele geïmplementeerde architectuur.  Het heeft qua volgorde wel een logische positie tussen fase G waarin de laatste target architectuur is geimplementeerd (en baseline is geworden) en fase A waarin nieuwe cycli worden gestart. Er wordt beoordeeld en vastgesteld in hoeverre de enterprise (en de architectuur) voldoet aan de beoogde business value. Veranderingen in business en technologie veroorzaken benodigde veranderingen in de enterprise en daarmee in de enterprise architectuur.  In dit proces worden daarvoor met nieuwe “Requests for Architecture Work” nieuwe cycli van de ADM cyclus gestart. Dit proces is tevens verantwoordelijk voor het managen van het governance proces zoals het organiseren van architectuurboard bijeenkomsten waarin changes worden behandeld.
  10. Requirements Management :  het proces voor  het organiseren en managen van de architectuur requirements gedurende de ADM cyclus.

Verschillende deliverables worden incrementeel ontwikkeld:

  • Architecture Definition Document : Bevat de architecturen per domein “Business”, “Application”, “Data” , “Technology” die initieel in fase A high level worden opgesteld en vervolgens successievelijk in de fases B, C en D nader worden uitgewerkt. In dit document wordt de huidige situatie, de baseline architectuur, en de nieuwe situatie, de target architectuur beschreven. Het bevat een GAP analyse waarin de verschillen tussen huidig/baseline en nieuw/target in kaart worden gebracht. Dit document vormt een basis voor het opstellen van de Transition Architecture en Architecture Roadmap. In fase E en F wordt dit document verder aangevuld en uiteindelijk in fase F geconsolideerd.
  • Architecture Requirements Specification: Bevat de verzamelde requirements die in de verschillende fasen worden gespecificeerd. Het gaat in fase A om de Business Requirements van de onderkende stakeholders. Het gaat in de fasen B t/m D om Architectuur requirements voor de verschillende architectuurdomeinen. Een bijzondere categorie vormen de “Interoperability Requirements”, gericht op het delen van processen, services en informatie. In fase E en F wordt dit document verder aangevuld en uiteindelijk in fase F geconsolideerd.
  • Transition Architecture : De Transition Architecture definieert in de tijd één of meer mijlpalen met bijbehorende Transition States. Elke Transition State definieert per architectuurdomein de toestand van de architectuur voor de betreffende mijlpaal. De Transition Architecture bevat ook een definitie van de work packages die de verandering van de huidige baseline architectuur naar de nieuwe target architectuur tot stand moeten brengen. Voor elk Work Package worden Functional Requirements gespecificeerd, en worden onderlinge afhankelijkheden benoemd.
    Ten slotte worden voor de onderkende GAP’s potentiele Solutions benoemd waarmee de GAPs kunnen worden opgelost. Deze solutions zullen een verandering in de capabilities van de organisatie opleveren, aangeduid als “Capability Increments” waarvoor in dit onderdeel een overzicht wordt gegeven.
    Dit onderdeel wordt in de fasen B,C en D initieel opgesteld door resp. per architectuurdomein de Roadmap componenten te onderkennen die hun plek in de Transition Architecture States moeten gaan krijgen.
    De Transition Architecture vormt de basis voor de Architecture Roadmap.
    Dit onderdeel is helaas niet al te duidelijk binnen Togaf. Het is feitelijk geen deliverable, maar is gedefinieerd als onderdeel van zowel de Architecture Roadmap als Architecture Definition Document deliverables. De Togaf templates voor deze deliverables bevatten dit onderdeel echter niet , maar bieden een apart Transition Architecture template voor fase E.
  • Architecture Roadmap : Clustert de workpackages uit de Transition Architecture tot een lijst van projecten die de verandering van de huidige baseline architectuur naar de nieuwe target architectuur tot stand moeten brengen.  Het definieert hiervoor de onderlinge afhankelijkheden en plaatst deze op een tijdlijn.
    Dit document specificeert ook een lijst Solution Building Blocks (SBB’s), de feitelijke fysieke implementatie output van de projecten. In de Transition Architecture werd de basis voor de SBB’s gelegd met de voorgestelde solutions per GAP.  In fase E wordt dit document opgesteld en in fase F eventueel bijgewerkt en geconsolideerd.
  • Implementation & Migration Plan : bevat de hooflijnen in het onderdeel “Implementation & Migration Strategy” welke in fase E wordt opgesteld.  In fase F wordt de overall planning voor de projecten uit de Roadmap uitgewerkt in het onderdeel “Project & Portfolio Breakdown”.  Het geheel wordt vervolgens afgestemd met de verschillende verantwoordelijken voor de implementatieprojecten. Daarmee is de basis gelegd voor de opstart van de implementatie projecten. In fase F wordt dit document geconsolideerd.
This entry was posted in TOGAF and tagged , . Bookmark the permalink.

Geef een reactie

Je e-mailadres wordt niet gepubliceerd.

De volgende HTML tags en attributen zijn toegestaan: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>