Zachmanův rámec - Zachman Framework

Tento článek má několik problémů. Prosím pomozte zlepšit to nebo diskutovat o těchto otázkách na internetu diskusní stránka. (Zjistěte, jak a kdy tyto zprávy ze šablony odebrat) Zdá se, že hlavní přispěvatel do tohoto článku má úzké spojení s jeho předmětem. Může vyžadovat vyčištění, aby vyhovovalo zejména obsahovým zásadám Wikipedie neutrální hledisko. Diskutujte prosím dále o diskusní stránka. (Březen 2015) (Zjistěte, jak a kdy odstranit tuto zprávu šablony) tento článek může být pro většinu čtenářů příliš technická na to, aby tomu rozuměli. Prosím pomozte to vylepšit na aby to bylo srozumitelné pro neodborníky, aniž by byly odstraněny technické podrobnosti. (Únor 2012) (Zjistěte, jak a kdy odstranit tuto zprávu šablony) (Zjistěte, jak a kdy odstranit tuto zprávu šablony)

Zachmanův rámec podnikové architektury

The Zachmanův rámec je podnik ontologie a je základní strukturou pro Enterprise Architecture který poskytuje formální a strukturovaný způsob prohlížení a definování podniku. Ontologie je dvourozměrné klasifikační schéma, které odráží průnik mezi dvěma historickými klasifikacemi. První jsou primitivní výslechy: Co, Jak, Kdy, Kdo, Kde a Proč. Druhý je odvozen z filozofického konceptu reifikace, transformace abstraktní myšlenky na instanci. Reformační transformace Zachman Framework jsou: Identifikace, Definice, Zastoupení, Specifikace, Konfigurace a Instance.^[1]

Zachmanův rámec není metodologie v tom smyslu, že neznamená žádnou konkrétní metodu nebo postup pro shromažďování, správu nebo používání informací, které popisuje .;^[2] je to spíše ontologie, kdy a schéma pro organizaci architektonických artefaktů (jinými slovy, návrhové dokumenty, specifikace a modely) se používá k zohlednění jak toho, na koho se artefakt zaměřuje (například vlastník firmy a stavitel), a jaké konkrétní otázky (například data a funkce) jsou řešit.^[3]

Rámec je pojmenován po svém tvůrci John Zachman, který koncept poprvé vyvinul v 80. letech 20. století v IBM. Od té doby byl několikrát aktualizován.^[4]

Přehled

Název „Zachman Framework“ odkazuje na Zachman Framework pro Enterprise Architecture, přičemž nejnovější verze je nejnovější. Zachman Framework se ve své třicetileté historii vyvinul a zahrnoval:

• Počáteční rámec pojmenovaný Rámec pro architekturu informačních systémů, John Zachman publikoval v článku z roku 1987 v časopise IBM Systems.^[5]
• The Zachman Framework pro podnikovou architekturubyla rozšířena a přejmenována aktualizace originálu z roku 1987 v 90. letech.^[6]
• Jedna z novějších verzí Zachman Framework, kterou Zachman International nabízí jako průmyslový standard.

Koláž Zachman Frameworks, jak je uvedeno v několika knihách o Enterprise Architecture od roku 1997 do roku 2005.

V dalších zdrojích je Zachman Framework představen jako rámec, který vznikl a pojmenoval podle Johna Zachmana, reprezentovaný mnoha způsoby, viz obrázek. Tento rámec je vysvětlen jako například:

• A rámec organizovat a analyzovat data,^[7]
• rámec pro podnikovou architekturu.^[8]
• A klasifikace systém nebo klasifikační schéma^[9]
• matice, často ve formátu matice 6x6
• dvojrozměrný Modelka^[10] nebo analytický model.
• dvourozměrné schéma, které se používá k uspořádání podrobných reprezentací podniku.^[11]

Kromě rámců vyvinutých Johnem Zachmanem bylo vyvinuto mnoho rozšíření a / nebo aplikací, které se někdy také nazývají Zachmanské rámce, ale obecně mají tendenci být grafickými překryvy samotného samotného rámce.

Zachman Framework shrnuje sbírku perspektivy podílí se na podnikové architektuře. Tyto perspektivy jsou zastoupeny v dvourozměrné matici, která definuje podél řádků typ zúčastněné strany a se sloupy aspekty architektury. Rámec nedefinuje metodiku pro architekturu. Matice je spíše šablonou, kterou je třeba vyplnit cíli / pravidly, procesy, materiálem, rolemi, místy a událostmi konkrétně požadovanými organizací. Další modelování mapováním mezi sloupci v rámci identifikuje mezery v dokumentovaném stavu organizace.^[12]

Rámec je logická struktura pro klasifikaci a organizaci popisných reprezentace podniku. Je to významné pro oba řízení podniku a aktéry podílející se na vývoji podnikových systémů.^[13] I když pro sloupce Framework neexistuje žádné pořadí priorit, pořadí řádků shora dolů je významné pro sladění obchodních konceptů a skutečného fyzického podniku. Úroveň podrobností v rámci je funkcí každé buňky (a nikoli řádků). Pokud je to provedeno IT, je kladena nižší úroveň zaměření informační technologie Může se však vztahovat stejně na fyzický materiál (kulové ventily, potrubí, transformátory, pojistkové skříňky) a související fyzické procesy, role, umístění atd. související s těmito položkami.^{[Citace je zapotřebí ]}

Dějiny

V 80. letech John Zachman se v IBM podílel na vývoji plánování obchodního systému (BSP), metoda pro analýzu, definování a navrhování informační architektura organizací. V roce 1982 Zachman^[14] již dospěl k závěru, že tyto analýzy mohou dosáhnout mnohem dál než automatizace návrh systémů a správa dat do oblastí strategického obchodního plánování a vědy o řízení obecně. Může být použit v (v té době považovaných za více esoterických) oblastech podnikové architektury, návrhu systémů založených na datech, kritériích klasifikace dat a dalších.^[14]

Rámec „Architektura informačních systémů“

Původní 1987 „Architecture Systems Architecture Framework“.

Jednoduchý příklad rámce z roku 1992.

V článku z roku 1987 „Rámec pro architekturu informačních systémů“^[15] Zachman poznamenal, že termín „architektura“ byl volně používán odborníky na informační systémy a pro plánovače, designéry, programátory, komunikační specialisty a další znamenal různé věci.^[16] Při hledání objektivního a nezávislého základu pro vývoj rámce pro architekturu informačních systémů se Zachman podíval na pole klasiky architektura a celou řadu složitých inženýrských projektů v průmyslu. Viděl podobný přístup a dospěl k závěru, že architektury existují na mnoha úrovních a zahrnuje alespoň tři perspektivy: surovinu nebo data, funkce procesů a umístění nebo sítě.^[16]

Architektura informačních systémů je navržena tak, aby byla klasifikační schéma pro organizování modelů architektury. Poskytuje přehledný pohled na modely potřebné pro podnikovou architekturu. Architektura informačních systémů nedefinuje podrobně, co by modely měly obsahovat, nevynucuje modelovací jazyk používaný pro každý model a nenavrhuje metodu pro vytváření těchto modelů.^[17]

Rozšíření a formalizace

V článku z roku 1992 „Rozšíření a formalizace rámce pro architekturu informačních systémů“ John F. Sowa a John Zachman představují rámec a jeho nedávná rozšíření a ukazují, jak jej lze formalizovat v notaci konceptuálních grafů.^[18] Také v roce 1992:

Spoluautor Johna Zachmana John Sowa navrhl doplnění perspektivy Scope o „plánovače“ (omezující seznamy společné pro podnik a jeho prostředí) a perspektivu „detailní reprezentace“ „subdodavatele“ (který je mimo kontext dodavatele řešení komponenty). V článku byly uvedeny sloupce Kdo, kdy a proč, představa čtyř úrovní metaframeworks a zobrazení integračních asociací napříč perspektivami. Keri Anderson Healey pomohla s vytvořením modelu modelů (framework metamodel), který byl také zahrnut v článku.

— Stan Locke, Podniková konvergence v našem životě od NOVINY PODNIKU^[19]

Později v průběhu 90. let^[19]

• Metodologové mají rádi Clive Finkelstein znovu zaostřil na dva horní řádky rámce, které označil Enterprise Engineering a má jednu z nejúspěšnějších metod konvergence obchodních potřeb s implementací inženýrství informačních technologií a určování logické sekvence sestavení jednotlivých částí.

Rámec pro podnikovou architekturu

V článku z roku 1997 „Koncepty rámce pro podnikovou architekturu“ Zachman uvedl, že rámec by měl být označován jako „Rámec pro podnikovou architekturu“ a měl by mít od začátku. Na začátku 80. let však podle Zachmana „byl malý zájem o myšlenku Enterprise Reengineering nebo Podnikové modelování a použití formalismů a modelů bylo obecně omezeno na některé aspekty vývoje aplikací v komunitě informačních systémů “.^[20]

V roce 2008 představil Zachman Enterprise Zachman Framework: The Official Struise Definition jako nový standard Zachman Framework.

Rozšířené a upravené rámce

Od 90. let 20. století bylo navrženo několik rozšířených rámců, například:

• Matthew & McGee (1990)^[21] rozšířil tři počáteční perspektivy „co“, „jak“ a „kde“, na událost („kdy“), důvod („proč“) a organizaci („kdo“).^[16]
• Alternativu představil Evernden (1996) Informační FrameWork.
• The Integrovaný rámec architektury vyvinutý uživatelem Capgemini od roku 1996.^[22]
• Vladan Jovanovic et all (2006) představuje Zachmanovu kostku, rozšíření Zachmanova rámce do vícerozměrné Zachmanovy kostky.^[23]

Zachmanská rámcová témata

Pojem

Základní myšlenkou Zachmanského rámce je, že stejnou složitou věc nebo položku lze popsat pro různé účely různými způsoby pomocí různých typů popisů (např. Textových, grafických). Zachmanův rámec poskytuje třicet šest nezbytných kategorií k úplnému popisu čehokoli; zejména složité věci, jako jsou vyráběné zboží (např. spotřebiče), postavené konstrukce (např. budovy) a podniky (např. organizace a všechny její cíle, lidé a technologie). Rámec poskytuje šest různých transformací abstraktní myšlenky (nezvyšuje se podrobně, ale transformuje se) ze šesti různých perspektiv.^[24]

Umožňuje různým lidem dívat se na stejnou věc z různých úhlů pohledu. Tím se vytvoří ucelený pohled na životní prostředí, což je důležitá schopnost znázorněná na obrázku.^[25]

Pohledy na řádky

Každý řádek představuje celkový pohled na řešení z určité perspektivy. Horní řada nebo perspektiva nemusí nutně mít komplexnější chápání celku než dolní perspektiva. Každý řádek představuje odlišnou, jedinečnou perspektivu; výstupy z každé perspektivy však musí poskytnout dostatečné podrobnosti k definování řešení na úrovni perspektivy a musí se výslovně přeložit do další spodní řady.^[26]

Každá perspektiva musí brát v úvahu požadavky ostatních perspektiv a omezení, která tyto perspektivy kladou. Omezení každé perspektivy jsou aditivní. Například omezení vyšších řádků ovlivňují řádky níže. Omezení spodních řádků mohou, ale nemusí nutně ovlivnit vyšší řádky. Pochopení požadavků a omezení vyžaduje komunikaci znalostí a porozumění z perspektivy do perspektivy. Rámec ukazuje vertikální směr této komunikace mezi perspektivami.^[26]

Rámec Zachman pro záležitosti veteránů s vysvětlením jeho řádků.^[27][28]

Aktuální verze Zachman Framework (3) kategorizuje řádky následovně:

• Výkonná perspektiva (Obsah předmětu) - První architektonický náčrt je „bublinový graf „nebo Vennův diagram, který hrubým způsobem zobrazuje velikost, tvar, dílčí vztahy a základní účel konečné struktury. Odpovídá shrnutí pro plánovače nebo investory, kteří chtějí přehled nebo odhad rozsahu systému, co by to stálo a jak by to souviselo s obecným prostředím, ve kterém bude fungovat.
• Perspektiva řízení podniku (Business Concepts) - Další jsou výkresy architekta, které zobrazují finální budovu z pohledu majitele, který s ní bude muset žít v každodenních rutinách podnikání. Odpovídají podnikovým (obchodním) modelům, které tvoří design podnikání a ukazují obchodní subjekty a procesy a jejich vztah.
• Perspektiva architekta (Systémová logika) - Plány architekta spočívají v překladu výkresů do podrobných reprezentací požadavků z pohledu designéra. Odpovídají systémovému modelu navrženému systémovým analytikem, který musí určit datové prvky, toky logických procesů a funkce, které představují obchodní entity a procesy.
• Perspektiva inženýra (Technologie fyziky) - Dodavatel musí překreslit plány architekta tak, aby představovaly perspektivu stavitele, s dostatečnými podrobnostmi, aby pochopil omezení nástrojů, technologií a materiálů. Plány stavitele odpovídají technologickým modelům, které musí model informačních systémů přizpůsobit podrobnostem programovacích jazyků, vstupně-výstupních (I / O) zařízení nebo jiných požadovaných podpůrných technologií.
• Perspektiva technika (Součásti nástroje) - Subdodavatelé pracují z plánů obchodů, které určují podrobnosti dílů nebo podsekcí. Odpovídají podrobným specifikacím, které dostávají programátoři, kteří kódují jednotlivé moduly, aniž by se zabývali celkovým kontextem nebo strukturou systému. Alternativně mohou představovat podrobné požadavky na různé komerčně dostupné (COTS), vládní pokladna (GOTS), nebo součásti softwaru modulárních systémů, které jsou získávány a implementovány spíše než vytvářeny.
• Perspektiva podniku nebo (Provozní instance)

Zaměření sloupců

Stručně řečeno, každá perspektiva zaměřuje pozornost na stejné základní otázky, poté na tyto otázky odpovídá z tohoto hlediska a vytváří různé popisné reprezentace (tj. Modely), které se překládají z vyšší do nižší perspektivy. Základní model pro fokus (nebo abstrakci produktu) zůstává konstantní. Základní model každého sloupce je jednoznačně definován, přesto souvisí napříč a dolů maticí.^[26] Kromě toho šest kategorií komponent podnikové architektury a podkladové dotazy, na které odpovídají, tvoří sloupce Zachman Framework a jsou to:^[24]

1. Sady inventáře - co
2. Procesní toky - jak
3. Distribuční sítě - kde
4. Přiřazení odpovědnosti - kdo
5. Časové cykly - kdy
6. Motivační záměry - Proč

Podle Zachmana je jediným faktorem, který činí jeho rámec jedinečným, že každý prvek na kterékoli ose matice je výslovně odlišitelný od všech ostatních prvků na této ose. Reprezentace v každé buňce matice nejsou pouze postupnými úrovněmi rostoucího detailu, ale ve skutečnosti jsou odlišnými reprezentacemi - odlišnými v kontextu, smyslu, motivaci a použití. Protože každý z prvků na obou osách se výslovně liší od ostatních, je možné přesně definovat, co do každé buňky patří.^[24]

Modely buněk

Zachmanův rámec je obvykle zobrazen jako ohraničená „matice“ 6 x 6 s komunikačními dotazníky jako sloupy a transformacemi reifikace jako řádky. Klasifikace rámce jsou potlačeny buňkami, tj. Průnikem mezi Interrogatives a Transformations.^[29]

Popisy buněk jsou převzaty přímo z verze 3.0 Zachman Framework.

Výkonná perspektiva

1. (Co) Identifikace inventáře
2. (Jak) Identifikace procesu
3. (Kde) Identifikace distribuce
4. (Kdo) Identifikace odpovědnosti
5. (Kdy) Načasování Identifikace
6. (Proč) Identifikace motivace

Perspektiva řízení podniku

1. (Co) Definice inventáře
2. (Jak) Definice procesu
3. (Kde) Definice distribuce
4. (Kdo) Definice odpovědnosti
5. (Kdy) Definice časování
6. (Proč) Definice motivace

Perspektiva architekta

1. (Co) Inventární vyjádření
2. (Jak) Zastoupení procesu
3. (Kde) Distribuční prohlášení
4. Zastoupení odpovědnosti (kdo)
5. (Kdy) Načasování Zastoupení
6. (Proč) Zastoupení motivace

Perspektiva inženýra

1. (Co) Specifikace inventáře
2. (Jak) Specifikace procesu
3. (Kde) Specifikace distribuce
4. (Kdo) Specifikace odpovědnosti
5. (Kdy) Specifikace časování
6. (Proč) Specifikace motivace

Perspektiva technika

1. (Co) Konfigurace inventáře
2. (Jak) Konfigurace procesu
3. (Kde) Konfigurace distribuce
4. Konfigurace odpovědnosti (kdo)
5. (Kdy) Konfigurace časování
6. (Proč) Konfigurace motivace

Perspektiva podniku

1. (Jaké) instance inventáře
2. (Jak) Instance procesu
3. (Kde) Distribuční instance
4. (Who) odpovědnosti instance
5. (Kdy) Načasování instance
6. (Proč) Instalace motivace

Vzhledem k tomu, že vývoj produktu (tj. Architektonický artefakt) v každé buňce nebo řešení problému ztělesněné buňkou je odpovědí na otázku z pohledu, obvykle jsou modely nebo popisy vyobrazení na vyšší úrovni nebo povrchové odpovědi buňky. Vylepšené modely nebo návrhy podporující tuto odpověď jsou podrobné popisy v buňce. V každé buňce dochází k rozkladu (tj. Procházení podrobnějšími podrobnostmi). Pokud buňka není explicitně definována (definována), je implicitní (nedefinováno). Pokud je to implicitní, existuje riziko vytváření předpokladů o těchto buňkách. Pokud jsou předpoklady platné, ušetří se čas a peníze. Pokud jsou však předpoklady neplatné, je pravděpodobné, že to zvýší náklady a překročí plán implementace.^[26]

Rámcová sada pravidel

Příklad pravidel Zachman Framework.

Rámec přichází se sadou pravidel:^[30]

• Pravidlo 1 Sloupce nemají pořadí : Sloupce jsou zaměnitelné, ale nelze je zmenšit ani vytvořit
• Pravidlo 2 Každý sloupec má jednoduchý obecný model : Každý sloupec může mít svůj vlastní meta-model
• Pravidlo 3 Základní model každého sloupce musí být jedinečný : Základní model každého sloupce, relační objekty a jeho struktura jsou jedinečné. Každý objekt vztahu je vzájemně závislý, ale cíl reprezentace je jedinečný.
• Pravidlo 4 Každý řádek popisuje odlišnou, jedinečnou perspektivu : Každý řádek popisuje pohled na konkrétní obchodní skupinu a je pro ni jedinečný. Všechny řádky jsou obvykle přítomny ve většině hierarchických organizací.
• Pravidlo 5 Každá buňka je jedinečná : Kombinace 2,3 a 4 musí vytvářet jedinečné buňky, kde každá buňka představuje konkrétní případ. Příklad: A2 představuje obchodní výstupy, protože představují to, co má být nakonec vytvořeno.
• Pravidlo 6 Složené nebo integrace všech modelů buněk v jednom řádku představuje z pohledu daného řádku úplný model : Ze stejného důvodu jako pro nepřidávání řádků a sloupců může změna názvů změnit základní logickou strukturu rozhraní.
• Pravidlo 7 Logika je rekurzivní : Logika je relační mezi dvěma instancemi stejné entity.

Rámec je obecný v tom, že jej lze použít ke klasifikaci popisných reprezentací jakýchkoli fyzických objektů koncepční objekty například podniky. Rekurzivní je také v tom, že jej lze použít k analýze jeho architektonické kompozice. I když rámec bude nést vztah z jednoho sloupce do druhého, stále jde o zásadně strukturální reprezentaci podniku, nikoli o tokovou reprezentaci.

Flexibilita na úrovni detailů

Jednou ze silných stránek Zachmanova rámce je to, že výslovně ukazuje komplexní soubor pohledy které lze řešit pomocí podnikové architektury.^[12] Někteří mají pocit, že úplné provedení tohoto modelu může vést k přílišnému důrazu na dokumentaci, protože artefakty by byly potřebné pro každou z třiceti buněk v rámci. Zachman však naznačuje, že je třeba vyplnit pouze fakta potřebná k vyřešení analyzovaného problému.

John Zachman ve své dokumentaci, prezentacích a seminářích jasně uvádí, že jako rámec existuje flexibilita v tom, jaká hloubka a rozsah podrobností je vyžadována pro každou buňku matice na základě důležitosti pro danou organizaci. Automobilka, jejíž obchodní cíle mohou vyžadovat zaměření na řízení zásob a procesů, by mohla považovat za výhodné zaměřit své dokumentační úsilí Co a Jak sloupce. Naproti tomu společnost poskytující cestovní kanceláře, jejímž předmětem podnikání je více lidí a načasování událostí, by mohla považovat za přínosné zaměřit své dokumentační úsilí na SZO, Když, a Kde sloupce. Nelze však uniknout Proč důležitost sloupce, protože poskytuje obchodní ovladače pro všechny ostatní sloupce.

Aplikace a vlivy

Od 90. let se Zachmanův rámec široce používá jako prostředek k zajištění struktury pro inženýrství informačních technologií -styl podnikové modelování.^[31] Zachman Framework lze použít jak v obchodních společnostech, tak ve vládních agenturách. V rámci vládní organizace může být rámec aplikován na celou agenturu na abstraktní úrovni, nebo může být aplikován na různá oddělení, kanceláře, programy, podjednotky a dokonce i na základní provozní subjekty.^[32]

Přizpůsobení

Zachman Framework se používá v přizpůsobených rámcích, jako je TEAF, postavený na podobných rámcích, TEAF matice.

• 

  TEAF Matice pohledů a perspektiv.

• 

  Rámec pro EA Směr, popis a přehled o úspěchu.

• 

  Výrobky TEAF.

• 

  Pracovní produkty TEAF pro směr, popis a úspěch EA.

Další zdroje:

• Matice TEAF se nazývá ukázka přizpůsobení, viz tady, str. 22

Standardy založené na Zachmanově rámci

Zachman Framework se také používá jako rámec k popisu standardů, například standardů pro zdravotnictví a zdravotnického informačního systému. Každá buňka rámce obsahuje takovou řadu standardů pro zdravotnictví a zdravotnický informační systém.^[33]

Mapování dalších rámců

Další aplikace Zachman Framework je jako referenční model pro jiné podnikové architektury, viz například tyto čtyři:

• 

  EAP mapovaný na Zachman Framework, 1999

• 

  Mapování C4ISR, 1999

• 

  Mapa produktů DoD na buňky Zachman Framework, 2003.

• 

  Mapování části DoDAF, 2007.

Další příklady:

• Analýza Racionální jednotný proces jako proces,^[34]
• Jak Architektura řízená modelem (MDA) modely používané při vývoji softwaru mapují na Zachman Framework.^[35]
• Mapování modelů IEC 62264 na rámec Zachman pro analýzu sledovatelnosti informací o produktech.^[36]
• Mapování TOGAF Metoda vývoje architektury (např. Metodologie) k Zachmanovmu rámci.^[6]

Základ pro další architektury podnikové architektury

Méně zřejmé jsou způsoby, jakými původní Zachmanova struktura stimulovala vývoj dalších rámce podnikové architektury, například v Model architektury Enterprise NIST, C4ISR AE, DOE AE a DoDAF:

• 

  Model architektury Enterprise NIST.^[26]

• 

  C4ISR AE, 1997.

• 

  DOE AE, 1998.

• 

  DODAF, 2003.

• The Federální rámec podnikové architektury (FEAF) je založen na Zachmanově rámci, ale řeší pouze první tři sloupce Zachmana, používá mírně odlišné názvy, a zaměřuje se na horní část tří řádků.^[37] (vidět tady )

Příklad: One-VA Enterprise Architecture

Metodiku Zachmanského rámce například použila Ministerstvo pro záležitosti veteránů Spojených států (VA) vyvinout a udržovat svou One-VA Enterprise Architecture v roce 2001. Tato metodika vyžadovala definování všech aspektů podniku VA z hlediska obchodního procesu, dat, technických, lokalizačních, personálních a požadavků. Dalším krokem při implementaci metodiky bylo definování všech funkcí souvisejících s každým obchodním procesem a identifikace souvisejících datových prvků. Po identifikaci lze identifikovat a vyřešit duplicitu funkce a nekonzistenci v definici údajů,.^[38]

• 

  Integrovaný procesní tok pro VA IT projekty (2001)

• 

  Rámcový portál VA Zachman

• 

  Úvod do úložiště VA EA (2008)

• 

  Výukový program pro Zachman Architecture Framework

Oddělení pro záležitosti veteránů na počátku 21. století^{[když? ]} plánoval implementovat podnikovou architekturu plně založenou na Zachman Framework.

• Zachman Framework byl použit jako referenční model k zahájení plánování podnikové architektury v roce 2001.
• Někde mezi tím byl postaven portál VA Zachman Framework.
• Tento portál VA Zachman Framework se stále používá jako referenční model, například při určování informací EA shromážděných z různých obchodních a projektových zdrojových dokumentů.

Úložiště podnikové architektury bylo nakonec vytvořeno na úrovni maker Zachman frameworkem a na úrovni buňky pomocí meta-modelu popsaného níže.^[39]

Detaily buňky VA EA Meta-Model Enlarged.

Tento diagram^[40] byla začleněna do VA-EA, aby poskytla symbolické znázornění metamodel používá se k popisu podnikové architektury One-VA a k vybudování úložiště EA bez použití komerčního softwaru EA Repository. Byl vyvinut pomocí objektově orientovaná databáze v rámci softwarového produktu Caliber-RM. Caliber-RM je určen k použití jako správa konfigurace softwaru nářadí; ne jako úložiště EA.

Tento nástroj však umožňoval definování entit a vztahů a definování vlastností jak entit, tak vztahů, což vzhledem k technologii dostupné na začátku roku 2003 postačovalo pro vybudování úložiště EA. Osobní motivací při výběru tohoto nástroje bylo, že žádný z komerčních tehdy dostupné nástroje úložiště poskytovaly skutečnou reprezentaci Zachman Framework a byly vysoce proprietární, takže bylo obtížné začlenit komponenty od jiných dodavatelů nebo z otevřeného zdroje.

Tento diagram zdůrazňuje několik důležitých interpretací Zachmanova rámce a jeho přizpůsobení informačním technologiím investiční management.

1. Postupováním řádky shora dolů lze vysledovat Životní cyklus vývoje systémů (SDLC), což je de facto standard v celém informačním průmyslu;
2. Diagram zdůrazňuje důležitost často zanedbávaného Zachman Row-Six (integrovaný, provozní podnikový pohled). Zastoupení v interpretaci Zachmanovy řady šest Zachmana spočívá převážně v měřitelných vylepšeních služeb a úsporách / vyhýbání se nákladům, které jsou výsledkem obchodních procesů a technologických inovací, které byly vyvinuty napříč řádky dva až pět.

Řádek šest poskytuje měřené návratnost investic pro jednotlivé projekty a případně pro celé investiční portfolio. Bez šestého řádku Framework identifikuje pouze zaplacené náklady, ale ROI šestého řádku mu umožňuje měřit výhody a být používán v procesu neustálého zlepšování, zachycovat osvědčené postupy a aplikovat je zpět přes druhý řádek.

Kritika

Zatímco Zachman Framework je široce diskutován, jeho praktická hodnota byla zpochybněna:

• Rámec je čistě spekulativní, neempirický a je založen pouze na koncepčním argumentu, že „ekvivalence [mezi architektonickými reprezentacemi výrobního a stavebního průmyslu] by posílila argument, že analogický soubor architektonických reprezentací je pravděpodobně které mají být vyrobeny během procesu výroby jakéhokoli složitého strojírenského produktu, včetně informačního systému "^[5]
• Praktická zpětná vazba ukazuje, že obecná myšlenka vytváření komplexních popisů podniků, jak je navrhuje Zachmanův rámec, je nereálná^[41]
• V roce 2004 John Zachman připustil, že rámec je teoretický a nikdy nebyl plně implementován: „Pokud se zeptáte, kdo úspěšně implementuje celý rámec, odpovědí je nikdo, o kom dosud víme.“^[42]
• Neexistují žádné podrobné příklady prokazující úspěšné praktické použití rámce^[43]
• Praktik EA Stanley Gaver tvrdí, že „analogie ke klasické architektuře, kterou poprvé vytvořil John Zachman, je chybná a neúplná“^[44]
• Jason Bloomberg tvrdí, že „podnik není obyčejný systém, jako je stroj nebo budova, a nelze jej jako takový projektovat ani navrhovat“^[45]
• Podrobná kontrola ukazuje, že Zachmanův rámec je ve skutečnosti založen pouze na čistě spekulativních argumentech podporovaných fiktivními sliby, nemá žádné praktické případy použití a z historického hlediska nezavádí žádné inovativní nápady, které by dříve chyběly^[46][47]

Tato kritika naznačuje, že Zachmanův rámec může jen těžko odrážet skutečné osvědčené postupy v EA.

Viz také

• Koncepční schéma
• Datový model
• Rámec Enterprise Architecture
• Plánování podnikové architektury
• FDIC Enterprise Architecture Framework
• Pět Ws
• Zobrazit model

Reference

externí odkazy

• The Zachman Framework: The Official Concise Definition by John A. Zachman at Zachman International, 2009.
• The Zachman Framework Evolution: overview of the evolution of the Zachman Framework by John P. Zachman at Zachman International, April 2009.
• UML, RUP, and the Zachman Framework: Better together, by Vitalie Temnenco, IBM, 15 Nov 2006.