Enterprise Architecture

L’impatto delle tecnologie digitali
sulla catena del valore dell’impresa
La definizione di un’architettura di impresa
Outline
  Introduzione
  The Zachman Framework for Enterprise Architecture
  Perspectives
  Abstractions
  The Open Group Architecture Framework
  Architecture domain
  Architecture Development Method
Introduzione
  Nel 1987 John A. Zachman pubblica su IBM Systems Journal “Framework for
Information Systems Architecture”, un articolo seminale nel quale introduce
alcuni dei concetti che saranno fondamentali in ambito di Enterprise
Architecture. Nel 1992 questi concetti sono approfonditi e raffinati, e le
problematiche affrontate iniziano ad essere riconosciute dalla comunità:
  Complessità dei sistemi aziendali: le organizzazioni spendevano sempre
più denaro per sviluppare sistemi IT;
  Scarso allineamento con il business: le organizzazioni avevano sempre più
difficoltà a mantenere tali sistemi IT allineati con le necessità del business.
  Questi problemi, posti già venti ani fa, hanno raggiunto oggi un punto critico. Il
costo e la complessità dei sistemi IT sono cresciuti esponenzialmente, mentre
le possibilità di trarne un valore reale e immediato hanno subito un crollo.
  Le organizzazioni di grandi dimensioni non possono ignorare questi problemi.
Le idee fondanti dell’Enterprise Architecture, che venti anni fa sembravano
visionarie, oggi risultano profetiche e attuali.
Introduzione
Una visione olistica
  L’Enterprise Architecture (EA) rappresenta un’impresa
nella sua interezza, agendo come mezzo di
coordinamento fra:
  aspetti di business planning come obiettivi, vision,
strategie e principi di governance;
  aspetti operativi come vocabolari di business, struttura
organizzativa, processi e dati;
  asetti di automazione come sistemi informativi e
database;
  e infrastrutture tecnologiche di supporto come
computer, sistemi operativi e network.
  In un’azienda di grandi dimensioni, è necessario un
framework rigoroso per poter scattare una fotografia
dell’intera organizzazione in tutte le sue dimensioni e in
tutta la sua complessità.
  L’Enterprise Architecture è in grado di coordinare in
modo olistico le molteplici sfaccettature che
costituiscono l’essenza fondamentale di un’impresa.
Enterprise Strategic
Alignment
Business
Strategy
Business
Concepts
Operational
Capabilities
Technology
Strategy
Enabling
Technologies
Technology
Capabilities
Enterprise Business
Improvement
Introduzione
Fattori critici di successo per una EA
Un approccio efficace all’Enterprise Architecture è in grado di:
  creare e mantenere una visione condivisa del presente e del futuro che guidi
l’allineamento continuo fra business e IT;
  creare processi di business che riflettono la strategia dell’impresa
  favorire l’agilità riducendo la complessità, forte inibitore del cambiamento;
  aumentare la flessibilità dell’impresa nel relazionarsi con partner esterni;
  sviluppare un’organizzazione proattiva capace di venire incontro alla domanda del cliente;
  ridurre i rischi e preparare l’impresa per cambiamenti rapidi e inaspettati;
  evitare la duplicazione di team IT che operano ciascuno allo scuro dell’altro;
  creare, unire e integrare i processi di business attraverso tutta l’impresa;
  sbloccare i flussi informativi, unendo gli “information silos” che intralciano le iniziative a
livello corporate;
  eliminare tecnologie duplicate e sovrapposte, diminuendo i costi di supporto e
migliorando l’integrazione fra i sistemi;
  ridurre il delivery time e i costi di sviluppo massimizzando il riuso di tecnologie,
informazioni e applicazioni di business.
Introduzione
Alcune definizioni
  “L’Architettura di Impresa ci permette di determinare gli elementi che
costituiscono l'impresa e come questi sono posti in relazione tra loro.”
The Open Group
  “L’Enterprise Architecture è un asset strategico - informativo di base che
definisce la business mission, le informazioni utili, le tecnologie di
supporto e il processo di perfezionamento delle tecnologie in risposta alle
necessità di cambiamento.”
USA Federal CIO Council
  “L’Enterprise Architecture è l’espressione olistica di tutti i fattori chiave
di business di un’organizzazione, delle informazioni, delle applicazione e
delle tecnologie e del loro impatto sulle funzioni e sui processi di
business. L'approccio guarda ai processi di business, alla struttura
dell'organizzazione e al tipo di tecnologia usata per guidare i processi.”
Meta Group, Inc.
Introduzione
Prospettiva storica
  La maggior parte dei framework ha una storia comune ed è frutto di raffinamenti di altri framework;
  Il framework di Zachman ha avuto il merito di aprire il filone e rimane tuttora il punto di riferimento per
ogni altro framework.
references
DoD AF
2003
JTA
ISO/IEC
14252
DoD TRM
supported by
TAFIM
influenced
references
influenced
influenced
influenced
influenced
TASIF
1997
IAF v1
influenced 1996
1985
1990
1995
FEA
2002
supported by
influenced
UVA Model
1994
Zachman
2008
FEAF
1999
influenced
TOGAF
2009
TEAF
2000
influenced
influenced
TOGAF
2002
influenced
Zachman
1992
EAP
1992
supported by
C4ISR
1999
references
TOGAF
1995
adopted by
Zachman
1987
DoD AF
2007
influenced
influenced
influenced
influenced
IAF v3
2001
2000
FEA
2007
E2AF
2003
XAF
2003
2005
E2AF
2006
XAF
2008
2010
Adapted from: Jaap Schekkerman, How to survive the jungle of Enterprise Architecture Frameworks, Trafford 2004
The Zachman Framework for Enterprise
Architecture
The Zachman Framework
  Secondo l’idea originaria di Zachman, l’Enterprise Arhitecture deve
adottare un’approccio ingegneristico alla gestione di prodotti complessi.
La creazione e gestione di un’impresa risulta, da questo punto di vista,
qualcosa di molto simile a quella di un aeroplano. Essi sono
semplicemente due istanze diverse di un generico “oggetto complesso”
  Il concetto di architettura è inteso come il mezzo per colmare il gap fra
strategia e implementazione, cioè fra aspettative del committente e
prodotto finale. L’architettura è centrale nella produzione di risultati di
qualità e nei tempi stabiliti e nella gestione del cambiamento di prodotti
complessi
The Zachman Framework
  Dato un sistema/prodotto complesso, tuttavia, non ne esiste una singola
rappresentazione che possa modellarne tutti gli aspetti.
  Esistono rappresentazioni da diverse prospettive e ruoli che entrano in gioco nel
processo di produzione del prodotto. Come vedremo nel seguito è necessario tenere
conto di punti di vista che vanno da quello del committente a quello del designer, dal
quello dello sviluppatore, a quello del sub-contractor.
  La seguente tabella fornisce un esempio delle prospettive previste da Zachman per tre
tipi di oggetti complessi: buildings, airplanes, information system:
Generic
Buildings
Airplanes
Ballpark
Bubble charts
Concepts
Scope/Objectives
Owner’s
representation
Architect’s
drawings
Work breakdown structure
Model of the business
(or business description)
Designer’s
representation
Architect’s
plans
Engineering design
/bill of materials
Model of the information system
(or information system description)
Builder’s
representation
Contractor’s
plans
Manufacturing Engineering
design / bill of materials
Technology model
(or technology-constrained description)
Out-of-context
representation
Shop plans
Assembly / fabrication
drawings
Detailed description
Numerical code programs
Machine language description
(or object code)
Airplane
Information System
Machine language
representation
Product
Building
Information Systems
The Zachman Framework
  E’ possibile individuare, inoltre, rappresentazioni relative a diverse
caratteristiche del prodotto (materiale, funzionale, geometrica, …)
  Tali caratteristiche (abstraction) rispondono alle domande:
  di cosa è fatto il prodotto (WHAT)?
  come funziona il prodotto (HOW)?
  come sono collocate reciprocamente le componenti (WHERE)?
  chi fa che cosa relativamente al prodotto (WHO)?
  quando accadono gli eventi rilevanti per il prodotto (WHEN)?
  con quale criterio sono prese le varie decisioni in merito al prodotto (WHY)?
The Zachman Framework
Zachman identifica una struttura logica generica che ci permette di organizzare e
classificare le diverse rappresentazioni possibili di un oggetto complesso. Inoltre definisce il
concetto di generico architettura.
Architecture: set of design artefacts, or descriptive representations, that are relevant for
describing an object such that it can be produced to requirements (quality) as well as
maintained over the period of its useful life (change).
The Zachman Framework
Zachman, poi, specializza la definizione di architettura nell’ottica di architettura di impresa e
contestualizza il framework logico in tale ambito
Architecture: set of descriptive representations (i.e. models), that are relevant for
describing an Enterprise such that it can be produced to management s requirements
(quality) and maintained over the period of its useful life (change)
there are different perspectives (and actually different representations)
for each of the
different
participants
The Zachman framework for Enterprise Architecture
Perspectives
The Zachman Framework
Perspectives - Scope
  Role: planner
  Vicoli: Finanziari, enti esterni
  Ingegneria Edile: il primo diagramma
è un semplice schizzo che delinea
grossolanamente la dimensione, la
forma, le relazioni spaziali e le finalità
essenziali della struttura finale.
  Zachman Framework: sommario
essenziale per chi voglia pianificare un
investimento in un sistema informativo
aziendale, delineandone lo scopo e
stimandone i costi e le performance.
The Zachman Framework
Perspectives - Business model
  Role: owner
  Vicoli: uso, policy
  Ingegneria Edile:Un secondo
diagramma che raffiguri il prodotto
finale, disegni composti da sezioni
orizzontali, verticali, ecc.. Serve
committente per capire se “Questo è
esattamente ciò che avevo in mente! “
  Zachman Framework: obiettivi,
strategie e processi che sono usati per
supportare la mission del progetto in atto
The Zachman Framework
Perspectives - System model
  Role: designer
  Vicoli: strutturali, operazionali
  Ingegneria Edile: Progettazione
archetettonica, strutturale, sicurezza ecc
  Zachman Framework: È la prospettiva
dell'ingegnere, l'architetto del software,
l'intermediario tra quello che è
desiderabile (Riga 2) e quello che è
fisicamente e tecnicamente possibile
(Riga 4), cioè colui che si occupa del
disegno logico del nuovo sistema.
Queste rappresentazioni contengono i
requisiti del sistema, gli oggetti, le
attività e le funzioni che implementano il
modello di business.
The Zachman Framework
Perspectives - Technology
  Role: builder
  Vicoli: tecnologici, fisici
  Ingegneria Edile: il costruttore deve
adattare i progetti dell’architetto in modo da
considerare vincoli dovuti agli strumenti, alla
tecnologia e ai materiali disponibili.
  Zachman Framework: modello che adatta
il progetto di sistema ai vincoli posti dai
linguaggi di programmazione, dai dispositivi
hardware e, in generale, dalle tecnologie
esistenti.
The Zachman Framework
Perspectives - Detailed representations
  Role: subcontractor
  Vicoli: implementativi
  Ingegneria Edile: i sub-contractors lavorano
sulla base di disegni e progetti che dettagliano le
modalità di realizzazione di parti o componenti
(e.g. finestre e porte su misura)
  Zachman Framework: specifica dettagliata
fornita ai programmatori che hanno il compito di
sviluppare moduli individuali senza la necessità di
preoccuparsi del contesto, cioè della struttura
generale del sistema.
The Zachman Framework
Perspectives - Proprietà
  Additività dei vincoli: i vincoli di ciascun livello sono aggiunti/applicati al
modello del livello superiore, ottenendo così un nuovo tipo di modello
rispondente ad una nuova prospettiva.
  Reverse Engineering: in linea di principio fra i modelli di due livelli
adiacenti non ci dovrebbe essere una differenza tale da rendere impossibile la
derivazione di quello del livello superiore a partire da quello del livello
inferiore. Questo assicura che, a valle del processo di trasformazione che
porta al modello dell’ultimo livello (sub-contractor), non accada che i requisiti
di business iniziali non siano riconoscibili nel prodotto finale.
Abstractions
The Zachman Framework
Abstractions
  Le colonne del framework rappresentano diverse astrazioni o diversi modi di
descrivere la realtà.
  Isolare (astrarre) un aspetto, nascondendo gli altri, è un modo per ridurre la
complessità del problema di design.
  Tuttavia le astrazioni si riferiscono tutte allo stesso oggetto complesso, quindi
rimane il problema di mantenere la consistenza e l’integrità fra le differenti
rappresentazioni.
The Zachman Framework
Abstractions
  Ogni colonna rappresenta un’astrazione del mondo reale e corrisponde ad
una delle domande: what, how, where, who, when, why.
  Le risposte a queste sei domade sono le entità base o variabili di colonna:
entities, functions, locations, people, times, motivations.
  In aggiunta a queste variabili, si definiscono le connessioni che ne legano le
istanze.
  Per ogni colonna quindi esiste un basic model costituito da una variabile e
una connessione.
The Zachman Framework
Abstractions - What
  La colonna “what” descrive, in
linea generale, i materiali e gli
oggetti di cui il prodotto finale sarà
composto; in un sistema
informativo questa colonna
contiene i modelli dei dati. Questi
sono quindi simili al concetti di
“distinta base” (bill of materials) di
un prodotto manifatturiero.
  Basic Model:
entity - relationship - entity
The Zachman Framework
Abstractions - How
  La colonna “how” descrive le caratteristiche funzionali
del prodotto finale. Per un sistema informativo una
simile descrizione può essere chiamata modello di
processo.
  Basic model: input - process - output
(input argument - function - output argument)
The Zachman Framework
Abstractions - Where
  La colonna “where ” descrive il prodotto dal
punto di vista dello spazio fisico,
evidenziandone la dislocazione e connessione
dei componenti. Un modello di questo tipo è
detto “network model”.
  Basic model: site-link-site (node-line-node)
The Zachman Framework
Abstractions - Who
  La progettazione dell’organizzazione riguarda l’allocazione
del lavoro e la strutturazione delle responsabilità e
dell’autorità.
  Basic Model: people - work - people
  People: entità che allocano o a cui è allocato il
lavoro
  Work:
  Control work: specifica formale dei rapporti
lavorativi fra agenti in termini di
schedulazione, costi e prodotto;
  Coordination work: le relazioni lavorative
variano a seconda del contesto e in base alle
necessità;
  Operational work: collaborazione fra agenti;
The Zachman Framework
Abstractions - When
  La colonna “when” descrive gli
eventi e le relazioni fra essi (durata)
che determinano i criteri per
misurare le performance e l’utilizzo
di risorse. In generale, a parità di
obiettivo, ad una breve durata
corrisponde un’alta quantità di
risorse, mentre ad una durata
prolungata corrisponde una limitata
quantità di risorse.
  Basic Model
event - duration - event
The Zachman Framework
Abstractions - Why
  La colonna “why” descrive
quali siano le motivazioni
che guidano le scelte
relative al prodotto/sistema.
  Basic Model: ends means - ends
  Ends: obiettivi o goal
  Means:strategie o mezzi
per realizzare gli obiettivi
The Zachman Framework
Le regole
 
 
 
 
Le colonne non sono ordinate. Nessuna è più importante di un'altra ma
concentrandosi su una si possono avere implicazioni pratiche e significative.
Ogni colonna ha un semplice modello di base. Ogni colonna
rappresenta una astrazione dell'impresa nel mondo reale, che corrisponde
ad uno schema di classificazione basato sulle interrogazioni: che cosa,
come, dove, chi, quando e perchè. Le risposte a queste sei domande sono
le entità di base o le variabili delle colonne: entità, funzioni, localizzazioni,
persone, tempi e motivazioni
Il modello di base è unico per ogni colonna. L'unicità è essenziale.
Perciò, nessuna variabile o connettore nel modello della colonna di base è
ripetuto, o nel nome o nel concetto. Per esempio, “entità” e “relazione”
sono unici per la colonna Data. I termini “funzione” ed “argomento” sono
unici per la colonna Function. Entità non è equivalente a funzione e
relazione non è equivalente ad argomento.
Ogni riga rappresenta una distinta e unica prospettiva. Ogni
prospettiva è diversa perché basata su un set specifico di vincoli. Questo
implica, fra l’altro, che in una data colonna il significato del basic model
cambia di riga in riga.
The Zachman Framework
 
Le regole
Ogni cella è unica. Ciò discende dalle regole 3 e 4. Si noti che una conseguenza
di questa regola è che esiste un linguaggio di modellazione per ciascuna cella.
Questo spiegherebbe la pletora di linguaggi attualmente esistenti che possono
essere mappati più o meno precisamente ad alcune aree del framework.
 
La composizione o integrazione dei modelli delle celle di una riga costituisce un
modello completo per la corrispondente prospettiva.
 
La logica del framework è ricorsiva. Il
framework, nel corso degli anni, è stato
applicato a diversi oggetti complessi. Fra
questi evidenziamo i seguenti: edifici,
aeroplani, aziende, sistemi informativi. Tali
esempi non sono casuali, si noti infatti che
esiste un rapporto ben preciso fra essi.
 
 
Il responsabile del prodotto
(edificio, aeroplano) gioca il ruolo
di owner (cliente) per l’azienda
Il responsabile dell’azienda gioca il
ruolo di owner (cliente) per il
sistema informativo
The Open Group Architecture Framework
TOGAF
architecture domain
  Framework architetturale sviluppato dal Consorzio The Open Group. Costituisce un
quadro di riferimento (framework + metodi) per consentire la progettazione e la
realizzazione di una corretta Architettura di Impresa tenendo conto della specifica
realtà di business.
  TOGAF definisce quattro architecture domain:
  Architettura di business definisce la strategia di business, la governance,
l’organizzazione e i processi chiave;
  Architettura applicativa definisce l’architettura dei sistemi applicativi e le loro
interazioni e relazioni con i processi core;
  Architettura dei dati definisce l’architettura logica e fisica dei dati di
un'organizzazione e le risorse di gestione a loro dedicate;
  Architettura infrastrutturale definisce l’infrastruttura hardware, software e di rete
necessaria a supportare le applicazioni di business.
TOGAF
ADM
L’ A r c h i t e c t u r e D e v e l o p m e n t M e t h o d
rappresenta il nucleo del TOGAF. Dettaglia fase
per fase come realizzare l’architettura in funzione
dell’organizzazione e dei requisiti di business
specifici .
Costituisce un riferimento per
l’architetto per permettergli di soddisfare un set
complesso di requisiti, comunicare il concept,
orientarsi su tool di sviluppo e, inoltre, fornisce un
collegamento con casi studio pratici."
ADM è un metodo iterativo
 
lungo l’intero processo
 
tra fase e fase
 
all’interno di ogni fase
Per ogni iterazione bisogna riconsiderare
 
l’ambito di intervento
 
il livello di dettaglio
 
la pianificazione.
TOGAF
ADM - Framework and Principles
Prima di iniziare un progetto di EA, c’è bisogno di
rispondere ad alcune domande di base come:
“Quanto tempo possiamo dedicare al progetto?”,
“A che livello di dettaglio vogliamo arrivare?”,
“Quali sono gli obiettivi di business?”. In sostanza
è necessario determinare i principi che
governeranno il resto del lavoro.
TOGAF
ADM - Architecture Vision
  Determinare l’ambito di intervento, i vincoli e le
aspettative per il progetto;
  Creare una vision architetturale e validarla con
il top management, assicurandosi il suo
appoggio e il suo commitment;
  Determinare tutti gli stakeholder coinvolti nel
processo;
TOGAF
ADM - Business Architecture
Documentare l’architettura corrente di business
(AS IS), analizzando in particolare i processi, le
relazioni, i principi, le strutture organizzative, le
funzioni e i mezzi che l’impresa utilizza per
raggiungere i suoi obiettivi.
Definire l’architettura target di business (TO BE)
Analizzare il gap fra as is e to be
TOGAF
ADM - Information System Architecture
  Viene analizzata in dettaglio l’architettura dei
sistemi informativi (AS IS), in particolar modo i
flussi dati e le architetture applicative.
  E’ necessario documentare la situazione
attuale e ipotizzare le informazioni e le
applicazioni che possano essere di supporto
agli obiettivi di business (TO BE), suddividendo
il sistema informativo desiderato in blocchi
(siano essi esistenti o meno)
  Analizzare il gap fra as is e to be
TOGAF
ADM - Technology Architecture
  In questa fase si sviluppa l’architettura
tecnologica che implementa il business e
l’architettura informativa definite
precedentemente.
  Creare un riferimento dell’esistente (AS IS),
suddividere il sistema IT in blocchi e descriverli
singolarmente.
  Creare un modello TO BE combinando più
blocchi insieme (esistenti e da sviluppare)
  Analizzare il gap fra as is e to be.
TOGAF
ADM - Opportunities and Solutions
  Nelle fase precedenti sono state fotografate la
situazione iniziale e il target di riferimento e si è
divisa l’architettura esistente in parti (building blocks).
  In questa fase si considerano tutti i blocchi presenti,
si determina quali riutilizzare, quali sostituire, quali
acquistare o costruire in funzione delle priorità e delle
dipendenze.
  Concentrarsi su progetti a breve termine che
garantiscono risultati immediati, in grado di creare un
clima di entusiasmo per favorire successivi progetti
di maggiori dimensioni.
TOGAF
ADM - Migration Planning
In questa fase viene effettuata un’analisi dei rischi e
un’analisi Costi-Benefici per ogni opportunità identificata
nella fase precedente.
Successivamente si passa alla creazione di una roadmap che permette di pianificare lo sviluppo secondo le
priorità individuate.
TOGAF
ADM - Implementation Governance
  Il processo di sviluppo vero e proprio è fuori
dall’ambito di TOGAF, ma in questa fase si assicura
un controllo continuo affinchè lo sviluppo risulti
conforme agli obiettivi architetturali.
  In questa fase si produce un contratto di architettura
che formalizza i parametri sui quali basare la
valutazione della conformità dei risultati."
TOGAF
ADM - Architecture Change Management
  Una architettura di impresa, una volta terminata, è
raramente un sistema statico. Questa fase ha il
compito di monitorare di continuo le richieste di
cambiamento decidendo se e come procedere per
soddisfarle.
  Alcuni cambiamenti, come la semplificazione di un
processo, possono essere gestiti da una buona
politica di change management
e non
necessiteranno di spostarsi da questa fase.
  Altri tipi di cambiamento, come nuove iniziative di
standardizzazione o l’introduzione di nuove
tecnologie, richiedono solo una ridefinizione parziale
dell’architettura, partendo magari dalla fase D.
  In altri casi, come quelli che impattano pesantemente
sui processi di business, richiedono di ricominciare il
ciclo dalla fase A, considerando l’attuale architettura
come AS IS (o baseline)
Grazie dell’attenzione