Come rappresentare e applicazione e database nel meta modello completo TOGAF?

Sebbene le risposte di cui sopra siano premurose, non rispondono a una domanda molto semplice, che è l'entità nel metamodello TOGAF che si vorrebbe utilizzare per rappresentare un database.

La risposta, molto semplicemente, è che se si tratta di un database fisico (ad esempio, si sta creando un modello di architettura fisica), si utilizzerà la componente dei dati fisici; se si tratta di un database logico (ad esempio, stai creando un modello di architettura logico), utilizzerai una componente dati logici.

Non esiste un modello magico per TOGAF - TOGAF è una metodologia per descrivere architetture esistenti, stati futuri dell'architettura e le mappe stradali per passare da una all'altra. Questa domanda ha molto senso per l'individuo certificato TOGAF come la domanda "Come rappresentare e applicazione e database in PRINCE2" a un individuo qualificato PRINCE2.

Utilizza la rappresentazione più appropriata che funziona per il tuo pubblico . TOGAF sostiene di avere una serie di "punti di vista" dell'architettura che riguardano le preoccupazioni dei diversi gruppi di stakeholder e diversi livelli di dettaglio. Decidi quali punti di vista hai bisogno di creare e assicurati che ogni punto di vista abbia un diagramma mirato chiaro che comunichi ai tuoi stakeholder cosa devono sapere.

Nell'esempio sopra, vorresti includere o nascondere i dettagli tecnici per determinati segmenti di pubblico, ma entrambi i diagrammi sarebbero appropriati per un livello di dettaglio, quindi non insistere sul colore o sulla forma delle caselle finché le informazioni è accessibile e comprensibile.

Modifica seguendo le modifiche alla domanda

Quando ho fatto un corso TOGAF prima dei miei esami di certificazione, il formatore ha spiegato che i Modelli forniti con i materiali TOGAF erano un compromesso tra tutti i partecipanti (Guarda l'elenco dei membri dalle pagine xxv - xxx nell'edizione 9.1 di il libro e immagina che tutti siano d'accordo su qualsiasi cosa - CA, CSC, HP, IBM ...) e in quanto tali sono praticamente inutili.

Ha fornito esempi del mondo reale (con nomi redatti ma altrimenti completi) delle garanzie prodotte dalla sua azienda a condizione che noi, in quanto studenti, non potessimo prendere delle copie ma potessero apparire. Questa è stata un'esperienza liberatoria in quanto ci ha liberato dai "Modelli" estremamente limitati forniti dallo stesso TOGAF e ci ha mostrato come creare materiali di alta qualità usando niente di più sofisticato di Visio.

Quindi, quello che sto dicendo è - guarda gli esempi forniti ma NON USARLI RELIGIOSAMENTE perché sono troppo compromessi per essere qualcosa di più di una guida. Sto guardando il TRM (capitolo 43) per la prima volta da quando ho superato gli esami (che dovrebbe essere un indizio) ed è ancora più inutile di quanto ricordassi :). I numeri arretrati di "The Journal of Enterprise Architecture" (disponibili per i membri) spesso includono esempi e questi sono solitamente migliori di qualsiasi altro fornito ufficialmente da The Open Group.

Crea la tua architettura basata su ciò che è necessario documentare e spiegare ai tuoi stakeholder. Un pubblico tecnico si aspetta un modello di dati completo, un utente tecnico aziendale può desiderare un modello di dati concettuali, i dirigenti di livello C saranno felici con una scatola che rappresenta il database. Usa il colore per indicare le aree che richiedono attenzione.

Sulla base della tua descrizione di voler catturare le connessioni tra un'applicazione e un database, sarei d'accordo che sia l'estensione dei dati (definita nel capitolo 34.4.4) che l'estensione del consolidamento dell'infrastruttura (definita nel capitolo 34.4.5) sono appropriate . Nello specifico, due degli scopi delle estensioni di dati sono di acquisire la "creazione di componenti di dati fisici che implementano componenti di dati logici e sono analoghi a database, registri, archivi, schemi e altre tecniche di segmentazione dei dati" e la "creazione di dati" diagrammi di migrazione del ciclo di vita, sicurezza dei dati e migrazione dei dati dell'architettura per mostrare i problemi dei dati in modo più dettagliato ". Alcuni degli scopi di Infrastructure Consolidation Extensions sono di acquisire "la creazione di componenti di applicazioni logiche e fisiche per astrarre la capacità di un'applicazione lontano dalle applicazioni reali esistenti" e "la creazione di componenti di applicazioni logiche e fisiche per il tipo di prodotto astratto dal prodotti tecnologici reali esistenti ".

Se dovessi creare completamente entrambe queste estensioni, dovresti creare i seguenti diagrammi:

• Diagramma di sicurezza dei dati
• Diagramma di migrazione dei dati
• Diagramma del ciclo di vita dei dati
• Diagramma di realizzazione processo / applicazione
• Diagramma di ingegneria del software
• Diagramma di migrazione dell'applicazione
• Diagramma di distribuzione del software
• Diagramma di elaborazione
• Elaborazione in rete / Diagramma hardware
• Diagramma di ingegneria delle comunicazioni

Tutti questi diagrammi sono definiti in Artefatti architettonici (capitolo 35) .

In base al disegno nella tua domanda, il diagramma di distribuzione del software e il diagramma di rete / hardware si avvicinano molto a questo. Il diagramma di distribuzione del software mostra la struttura dell'applicazione e la distribuzione fisica tra pezzi fisici di tecnologia e posizione geografica. Il diagramma Networked Computing / Hardware mostra le connessioni logiche tra i componenti dell'applicazione. Poiché si menzionano anche aggiornamenti a applicazioni e database (sto interpretando che si tratta di una distribuzione di una nuova versione o di un aggiornamento tecnologico a un nuovo fornitore), il diagramma di migrazione dell'applicazione sembra appropriato e mostra come si intende passare da le versioni di base dei componenti alla versione di destinazione in tutti gli ambienti. Va notato che tutti questi elementi rientrano nelle estensioni del consolidamento dell'infrastruttura.

Osservando le definizioni complete di questi diagrammi (e dando uno sguardo alle definizioni degli altri diagrammi), TOGAF non specifica mai una particolare notazione o tecnica di modellazione. Ciascuna delle estensioni TOGAF descrive un particolare aspetto dell'architettura, un insieme di modelli che aiutano a catturare le informazioni rilevanti per quel particolare aspetto dell'architettura e fornisce nomi specifici ai diagrammi che servono a scopi specifici.

Se devi rispettare gli standard TOGAF, la cosa migliore da fare sarebbe scegliere le tue estensioni (sembra che tu abbia), assicurati che lo scopo sia allineato con quello che stai cercando di comunicare, guarda gli schemi delle liste che supportano quell'estensione, quindi guarda l'intento e lo scopo di quei diagrammi. Quindi, collabora con le parti interessate che utilizzeranno la documentazione (non si tratta solo dei diagrammi - è probabile che siano presenti testo, tabelle e altre informazioni) associati a tale estensione.

Un'altra raccomandazione proviene da IEEE Standard per Information Technology - Systems Design - Descrizioni di progettazione del software (1016) : l'uso di linguaggi di progettazione standardizzati è preferibile ad altri linguaggi di progettazione. L'idea di utilizzare un linguaggio di progettazione standardizzato (e di usarlo correttamente), non è necessario spiegare cosa significa la tua notazione ai lettori. Se non si utilizza un linguaggio di progettazione standardizzato o si utilizzano simboli da un linguaggio di progettazione standardizzato in un modo non standard, è necessario contenuto aggiuntivo per spiegare ai lettori come interpretare i diagrammi e le notazioni di progettazione, il che porta a un progetto o architettura più dettagliato descrizione.

In breve: in primo luogo, consultare le parti interessate. Scopri quali schemi e modelli sarebbero più facili da comprendere e utilizzare. Ci possono essere standard o convenzioni organizzative già in vigore. Se non ci sono standard, convenzioni, preferenze o consenso, cerca una notazione standardizzata che possa essere usata per comunicare le informazioni che il diagramma intende comunicare. Se non c'è una notazione standardizzata, puoi scegliere di usare una notazione della tua ideazione a patto che sia chiaro anche a un lettore come capire quella notazione.