TOGAF® framework è un metodo step-by-step per lo sviluppo di un’architettura aziendale, attraverso l’utilizzo di un set di strumenti, ed è liberamente disponibile sul sito web Open Group per l’utilizzo da parte delle organizzazioni che desiderano implementare un’architettura aziendale.
Quando è nato TOGAF?
La prima versione rilasciata nel 1995 era basata sul Technical Architecture Framework for Information Management (TAFIM), sviluppato dal Dipartimento della Difesa degli Stati Uniti d’America.
Quali sono gli obiettivi del framework TOGAF?
TOGAF framework cerca di essere un approccio ad un “rapido” sviluppo architettonico e ad una governance efficace. Non prescrive i modelli che dovrebbero essere usati per rappresentare l’architettura, ma guida il processo quando si crea un’architettura. Grazie alla sua scalabilità, può essere utilizzato per organizzazioni governative, grandi imprese e anche piccole e medie imprese. Guardando i diversi livelli di architettura che un framework può supportare, TOGAF framework cerca di supportare tutti i livelli, che vanno dalla business, data, application fino alla technology architecture.
Quali sono i principali vantaggi del TOGAF framework?
- Un metodo collaudato ed applicato da migliaia di architetti digitali;
- Un dizionario comune, in modo che tutti possano comprendere le informazioni fornite dall’architettura risultante.
TOGAF framework è composto dalle seguenti parti principali:
- Architecture Capability Framework
- Who | Chi deve essere coinvolto
- Architecture Development Method (ADM) – Metodo di sviluppo architettonico
- ADM Guidelines & Techniques
- Architecture Content Framework
- Which | Quale documentazione produrre
- Enterprise Continuum & Tools
- Where | Dove archiviare la documentazione
ADM: Il metodo di sviluppo architettonico
Il metodo di sviluppo architettonico è un approccio dettagliato, suddiviso in fasi, su come gestire l’intero ciclo di vita di una architettura.
Fase. Preliminary
In questa fase viene definita ed istituito l’Enterprise Architecture Team, i principi architetturali ed il framework da utilizzare.
Fase A. Architecture Vision
Durante la fase A, vengono identificati i principali soggetti interessati e le loro preoccupazioni/obiettivi e vengono identificati i principali requisiti che dovranno essere affrontati dall’architettura. Sulla base di queste informazioni vengono creati gli scenari di business utilizzati per rispondere a tali requisiti.
Fase B. Business Architecture
L’output di questa fase sono le descrizioni della Business Architetture sia Baseline che Target. Queste possono essere definite utilizzando, ad esempio, UML o IDEF-0. La scelta del metodo di modellazione utilizzato è basata sulle viste (view) richieste, i cui punti di vista (viewpoint) sono identificati in questa fase.
Fase C. Information System Architecture
L’obiettivo di questa fase è descrivere la Data Architecture e l’Application Architecture. Le viste create in questa fase sono nuovamente modellate nella modellazione scelta. Per i database, ad esempio, può essere la modellazione dei dati relazionali.
Fase D. Technology Architecture
L’obiettivo di questa fase è descrivere la Technology Architecture che formerà la base del successivo lavoro di implementazione.
Fase E. Opportunity and Solutions
Questa fase identifica le caratteristiche del cambiamento, determina i vincoli per l’implementazione, valida le dipendenze ed identifica eventuali Transition Architecture. L’output di questa fase costituirà la base del piano di attuazione richiesto per passare all’architettura Target.
Fase F. Pianificazione della migrazione
Questa fase si concentra sulla prioritizzazione dei progetti e vengono stimati i costi per la migrazione dei vari progetti. Il risultato finale è una roadmap dettagliata, inclusa la sequenza temporale nel piano di migrazione.
Fase G. Implementation Governance
Per ciascuno dei progetti di implementazione, viene assegnata una corrispondente organizzazione che si incaricherà della relativa realizzazione. In parallelo verranno effettuate delle Compliance Review per assicurare che alla fine di questa fase il sistema sia completamente realizzato ed implementato conforme alle specifiche.
Fase H. Architecture Change Management
Dopo l’implementazione del sistema, il ciclo di vita dell’architettura non termina. L’obiettivo di questa fase è quello di gestire le modifiche all’architettura in modo coerente. Al fine di mantenere l’architettura flessibile e dinamica, eventuali modifiche tecnologiche o ambientali dovrebbero essere rapidamente integrate nell’architettura. Durante questa fase, per ogni richiesta di modifica, viene presa la decisione se è necessario iniziare il ciclo ADM di nuovo, al fine di ridisegnare l’architettura. Questa decisione dovrebbe essere presa sulla base di criteri predefiniti, che determineranno se una richiesta di modifica richiede solo un aggiornamento dell’architettura attuale, o il riavvio del ciclo. Questi criteri non sono predefiniti da TOGAF® framework, dal momento che le organizzazioni differiscono troppo in merito alla loro accettazione del rischio.
Fase. Requirement Management
Il cerchio centrale all’interno del ciclo ADM ci mostra che le diverse fasi dell’ADM sono alimentate dai requisiti. TOGAF® framework non prescrive un modo specifico di raccolta e gestione di questi requisiti, specifica solo quale dovrebbe essere un efficace processo di gestione dei requisiti.
Gli input per il processo di gestione dei requisiti vengono forniti dalle diverse fasi dell’ADM ciclo.
Risultati finali
Quando si applica The TOGAF® standard per creare un’architettura, ancora molte Organizzazioni non ne traggono il beneficio programmato. Ciò è tipicamente dovuto al fatto che un’architettura è spesso implementata dal basso verso l’alto, dove l’Alta Direzione non si impegna a sufficienza per raggiungere gli obiettivi aziendali con obiettivi architettonici, rendendo impossibile raggiungere l’obiettivo aziendale previsto attraverso la leva dell’architettura. Questo problema si verifica tuttavia, all’interno di ogni framework utilizzato per creare un’architettura. È quindi fondamentale che il piano strategico, utilizzato nella fase A, sia condiviso e concordato in tutta l’organizzazione.
Vuoi approfondire? Guarda la registrazione del nostro webinar Introduzione a TOGAF per saperne di più!
Vuoi approfondire i concetti di Architecture View & Viewpoint? Leggi la seconda parte dell’articolo!
Claudio Restaino
Claudio è TOGAF® Accredited Trainer e Consulente sui Sistemi di Gestione dei Servizi IT con oltre 17 anni di esperienza. Responsabile del gruppo di lavoro per la versione italiana del glossario TOGAF® Standard. In qualità di trainer il suo principale obiettivo è di combinare la sua personale esperienza con la sua rigorosa conoscenza dei framework ITIL, TOGAF®, COBIT, DevOps, Lean Six Sigma, ISO 27001, al fine di offrire ai partecipanti un’esperienza su come mettere in pratica le metodologie nella quotidianità dei propri servizi.
TRADEMARKS AND STATEMENTS
TOGAF® is a registered trade mark of The Open Group in United States and other countries.
