TOGAF, Architecture Framework

...vi spiego di che cosa si tratta

TOGAF® è un Architectural Framework, il quale fornisce i metodi e gli strumenti per supportare l'accettazione, produzione, utilizzo e manutenzione di una architettura aziendale, basandosi su un modello di processo iterativo supportato da best practices e un riutilizzabile insieme di asset architetturali esistenti. 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.

TOGAF® abbraccia anche se non aderisce strettamente alla terminologia della ISO/IEC 42010:2007, dove per TOGAF® il concetto di "Architettura" ha due significati in base al contesto:

• Una formale descrizione di un sistema, o un piano dettagliato di un sistema a livello componente per guidarlo alla sua implementazione;
• La struttura dei componenti, le loro interrelazioni ed i principi e le linee guida che governano il loro progetto ed evoluzione nel tempo.

Obiettivi

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. 

I principali vantaggi del TOGAF® framework sono:

• 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.

Framework

TOGAF® framework è composto dalle seguenti parti principali:

• Architecture Capability Framework - Who | Chi deve essere coinvolto
• Architecture Development Method (ADM) – Metodo di sviluppo architettonico - What | Che cosa fare
• ADM Guidelines & Techniques - How | Come farlo
• 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 questo 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 del ciclo ADM. 

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.