Model architektury Enterprise NIST - NIST Enterprise Architecture Model

Model architektury Enterprise NIST.

NIST Enterprise Architecture Model ( NIST EA Model ) je pozdně 1980 referenční model pro podnikové architektury . Definuje podnikovou architekturu vzájemným vztahem mezi podnikovým, informačním a technologickým prostředím.

Federální vláda Spojených států, vyvinutá koncem 80. let Národním institutem pro standardy a technologie (NIST) a dalšími, propagovala tento referenční model v 90. letech jako základ pro podnikové architektury jednotlivých vládních agentur USA a v celkové federální podnikové architektuře. .

Intro

Model architektury NIST Enterprise je pětivrstvý model podnikové architektury určený k organizaci, plánování a budování integrované sady architektur informačních a informačních technologií. Těchto pět vrstev je definováno samostatně, ale jsou vzájemně propojené a protkané. Model definoval vzájemný vztah následovně:

  • Obchodní architektura řídí informační architekturu
  • Informační architektura předepisuje architekturu informačních systémů
  • Architektura informačních systémů identifikuje architekturu dat
  • Data Architecture navrhuje specifické systémy pro doručování dat a
  • Systémy pro dodávání dat (software, hardware, komunikace) podporují datovou architekturu.

Hierarchie v modelu je založena na představě, že organizace provozuje řadu obchodních funkcí, každá funkce vyžaduje informace z řady zdrojů a každý z těchto zdrojů může provozovat jeden nebo více operačních systémů, které zase obsahují data organizovaná a uloženy v libovolném počtu datových systémů.

Dějiny

Model architektury NIST Enterprise Architecture Model byl zahájen v roce 1988 v rámci pátého semináře o pokynech pro správu informací sponzorovaného NIST ve spolupráci s Asociací pro výpočetní techniku (ACM), IEEE Computer Society a Federální skupinou uživatelů pro správu dat (FEDMUG). Výsledky tohoto výzkumného projektu byly publikovány jako NIST Special Publication 500-167, Information Management Directions: The Integration Challenge .

Rozvíjející se oblast správy informací

S rozmnožováním informačních technologií počínaje sedmdesátými léty nabrala práce v oblasti správy informací nové světlo a začala zahrnovat i oblast údržby dat . Správa informací již nebyla jednoduchou prací, kterou mohl provádět téměř kdokoli. Bylo nutné porozumět zapojené technologii a teorii za ní. Jak se úložiště informací přesunulo do elektronických prostředků, bylo to stále obtížnější.

Pojem modelu se třemi schématy byl poprvé představen v roce 1975 tříúrovňovou architekturou ANSI / X3 / SPARC , která určovala tři úrovně pro modelování dat.

Jedním z prvních celkových přístupů k budování informačních systémů a správy systémových informací ze 70. let byl přístup založený na třech schématech . Navrhuje použít tři různé pohledy na vývoj systémů, ve kterých je koncepční modelování považováno za klíč k dosažení integrace dat :

  • Externí schéma pro zobrazení uživatelů
  • Koncepční schéma integruje externí schémata
  • Interní schéma, které definuje fyzické úložné struktury

Ve středu je koncepční schéma definuje ontologii těchto pojmů jako uživatelé uvažovat o nich a mluvit o nich. Fyzické schéma podle Sowa (2004) „popisuje interní formáty dat uložených v databázi a externí schéma definuje pohled na data prezentovaná aplikačním programům “.

Od sedmdesátých let uspořádal NIST sérii čtyř workshopů o pokynech pro správu databáze a informací. Každý z workshopů se zaměřuje na konkrétní téma:

  • „Jaké informace o databázové technologii potřebuje manažer, aby mohl uvážlivě rozhodovat o používání nové technologie“, v roce 1975.
  • „Jaké informace mohou manažerovi pomoci posoudit dopad na databázový systém?“ v roce 1977.
  • „ Nástroje pro správu informací z hlediska: použití; zásady a kontroly; logický a fyzický návrh databáze“ v roce 1980; a
  • „Povaha praxe a problémů při řízení informačních zdrojů “ v roce 1985.

Pátý workshop v roce 1989 uspořádala Národní laboratoř počítačových systémů (NCSL) NIST. Do té doby to byl jeden ze čtyř ústavů, které prováděly technické práce NIST. Specifickým cílem NCSL bylo provádět výzkum a poskytovat vědecké a technické služby na pomoc federálním agenturám při výběru, pořizování, používání a používání výpočetní techniky.

Workshop NIST o pokynech pro správu informací

Pátý seminář Direction Information Management Directions v roce 1989 se zaměřil na integraci a produktivitu ve správě informací . Pět pracovních skupin zvažovalo konkrétní aspekty integrace znalostí, správy dat , plánování systémů, vývoje a údržby, výpočetních prostředí, architektur a standardů. Účastníci pocházeli z akademické obce, průmyslu, vlády a poradenských firem. Mezi 72 účastníky byli Tom DeMarco , Ahmed K. Elmagarmid , Elizabeth N. Fong, Andrew U. Frank , Robert E. Fulton, Alan H. Goldfine, Dale L. Goodhue , Richard J. Mayer , Shamkant Navathe , T. William Olle , W. Bradford Rigdon , Judith A. Quillard, Stanley YW Su a John Zachman .

Hlavní projev přednesl Tom DeMarco, který tvrdil, že standardy způsobují více škody než užitku, když působí proti převládající kultuře, a že podstatou standardizace je objev, nikoli inovace. Pět pracovních skupin se sešlo, aby diskutovali o různých aspektech integrace:

  • integrace znalostí a správy dat
  • integrace správy technických a obchodních dat
  • integrace nástrojů a metod pro plánování, vývoj a údržbu systémů
  • - integrace distribuovaných, heterogenních výpočetních prostředí a -
  • architektury a standardy.

Ve třetí pracovní skupině pro plánování systémů předsedal John Zachman a jako základ pro diskusi přijal Zachmanův rámec .

Model podnikové architektury, 1989

Páté pracovní skupině pro architektury a standardy předsedal W. Bradford Rigdon ze společnosti McDonnell Douglas Information Systems Company (MDISC), divize společnosti McDonnell Douglas . Rigdon a kol. (1989) vysvětlili, že diskuse o architektuře se v té době většinou zaměřují na technologické problémy. Jejich cílem bylo „zaujmout širší pohled a popsat potřebu podnikové architektury, která zahrnuje důraz na obchodní a informační požadavky. Tyto problémy vyšší úrovně ovlivňují architektury a rozhodnutí v oblasti dat a technologií.“ Za tímto účelem se pracovní skupina zabývala třemi problémy:

  • Úrovně architektury v podniku
  • Problémy řešené architekturou
  • Výhody a rizika spojené s architekturou

Pro ilustraci úrovní architektury bylo představeno to, co se stalo známým jako NIST Enterprise Architecture Model (viz obrázek). V tomto konceptu jsou tři vrstvy přístupu se třemi schématy rozděleny do pěti vrstev.

Aplikace v 90. letech

Svým způsobem NIST Enterprise Architecture Model předběhl svou dobu. Podle Zachmana (1993) v 80. letech byla „architektura“ uznána jako téma zájmu, ale stále existovala jen málo konsolidovaná teorie týkající se tohoto konceptu. Například softwarová architektura . důležitým tématem se staly až ve druhé polovině devadesátých let.

Na podporu modelu NIST Enterprise Architecture v 90. letech byl ve federální vládě USA široce propagován jako nástroj pro správu Enterprise Architecture. Model NIST Enterprise Architecture se používá jako základ v několika rámcích Enterprise Architecture amerických federálních vládních agentur a v celkovém Federal Enterprise Architecture Framework . Při koordinaci tohoto úsilí byl model NIST dále vysvětlen a rozšířen v dokumentu „Memoranda 97-16 (Information Technology Architectures)“ vydaném Úřadem pro správu a rozpočet USA z roku 1997, viz další architektura informačních technologií .

Témata modelu NIST Enterprise Architecture

Nadace

Podle Rigdona a kol. (1989) je architektura „jasnou reprezentací koncepčního rámce komponent a jejich vzájemného vztahu v určitém okamžiku“. Může to například představovat „pohled na současnou situaci s ostrovy automatizace, nadbytečnými procesy a nekonzistencí dat“ nebo „budoucí integrovanou informační strukturu automatizace, ke které se podnik bude pohybovat v předepsaném počtu let.“ Úlohou standardů v architektuře je „umožnit nebo omezit architekturu a sloužit jako její základ“.

Za účelem rozvoje podnikové architektury Rigdon potvrzuje:

  • Existuje několik způsobů, jak rozvíjet architekturu
  • Existuje několik způsobů, jak implementovat standardy
  • Vývoj a implementace by měly být přizpůsobeny prostředí
  • Každá architektura sama o sobě může být rozdělena do různých úrovní.

Různé úrovně podnikové architektury lze vizualizovat jako pyramidu: Nahoře nad obchodní jednotkou podniku a dole na doručovacím systému v rámci podniku. Podnik se může skládat z jedné nebo více obchodních jednotek pracujících v konkrétní oblasti podnikání. Pět úrovní architektury je definováno jako: Business Unit, Information, Information System, Data and Delivery System.

Jednotlivé úrovně podnikové architektury jsou vzájemně propojeny zvláštním způsobem. Na každé úrovni architektury předpokládají nebo diktují architektury na vyšší úrovni. Ilustrace vpravo poskytuje příklad, které prvky mohou tvořit Enterprise Architecture.

Ukázkové prvky podnikové architektury (1989).

Úrovně architektury

Každá vrstva architektury v modelu má konkrétní záměr:

  • Úroveň obchodní architektury: Na této úrovni lze zobrazit celkovou částku nebo podjednotku jakékoli společnosti, která je v kontaktu s externími organizacemi.
  • Úroveň informační architektury: Tato úroveň určuje typy obsahu, formy prezentace a formát požadovaných informací.
  • Úroveň architektury informačních systémů: Specifikace pro automatizované a procedurálně orientované informační systémy.
  • Úroveň datové architektury: Rámec pro údržbu, přístup a použití dat s datovým slovníkem a jinými konvencemi pojmenování.
  • Úroveň systémů pro doručování dat: Úroveň technické implementace softwaru, hardwaru a komunikace, která podporuje datovou architekturu.

Některé ukázkové prvky toho, jak lze Enterprise Architecture popsat podrobněji, jsou zobrazeny na obrázku.

Architektura informačních technologií

„Memoranda 97-16 (Information Technology Architectures)“ dala následující definici podnikové architektury:

Enterprise Architecture je explicitní popis současných a požadovaných vztahů mezi obchodním a řídícím procesem a informačními technologiemi. Popisuje „cílovou“ situaci, kterou chce agentura vytvořit a udržovat správou svého portfolia IT.
Dokumentace Enterprise Architecture by měla zahrnovat diskusi o principech a cílech. Například při vývoji Enterprise Architecture by mělo být jasně pochopeno celkové prostředí pro správu agentury, včetně rovnováhy mezi centralizací a decentralizací a tempem změn v agentuře. V tomto prostředí určují principy a cíle směr v takových otázkách, jako je podpora interoperability, otevřených systémů, veřejného přístupu, spokojenosti koncových uživatelů a bezpečnosti.

V tomto pokynu byl přijat a dále vysvětlen pětičlenný model NIST. Agenturám bylo povoleno identifikovat různé komponenty podle potřeby a specifikovat organizační úroveň, na které budou konkrétní aspekty komponent implementovány. Ačkoli podstata těchto komponent, někdy nazývaná „architektury“ nebo „subarchitektury“, musí být uvedena v úplné agenturní architektuře Enterprise Agency, agentury mají velkou flexibilitu v popisu, kombinování a přejmenování komponent, které se skládají z:

  • Obchodní procesy : Tato součást Enterprise Architecture popisuje hlavní obchodní procesy, které podporují poslání organizace. Součástí obchodních procesů je analýza práce na vysoké úrovni, kterou agentura provádí na podporu poslání, vize a cílů organizací, a je základem ITA. Analýza obchodních procesů určuje informace, které agentura potřebuje a zpracovává. Tento aspekt ITA musí vyvinout vedoucí programoví manažeři ve spolupráci s IT manažery. Bez důkladného pochopení jejích obchodních procesů a jejich vztahu k misím agentury nebude agentura schopna efektivně využívat svůj ITA.
    Obchodní procesy lze popsat rozložením procesů na odvozené obchodní činnosti. K dispozici je řada metodik a souvisejících nástrojů, které agenturám pomáhají rozkládat procesy. Bez ohledu na použitý nástroj by model měl zůstat na dostatečně vysoké úrovni, aby umožnil široké zaměření agentury, přesto dostatečně podrobné, aby bylo užitečné při rozhodování, protože agentura identifikuje své informační potřeby. Agentury by se měly vyvarovat nadměrného důrazu na modelování obchodních procesů, což může vést ke ztrátě zdrojů agentur.
  • Informační toky a vztahy : Tato součást analyzuje informace, které organizace využívá ve svých obchodních procesech, identifikuje použité informace a pohyb informací v agentuře. V této komponentě jsou popsány vztahy mezi různými toky informací. Tyto informační toky naznačují, kde jsou informace potřebné a jak jsou tyto informace sdíleny pro podporu funkcí mise.
  • Aplikace : Komponenta Aplikace identifikuje, definuje a organizuje aktivity, které zachycují, manipulují a spravují obchodní informace na podporu operací mise. Také popisuje logické závislosti a vztahy mezi obchodními aktivitami.
  • Popisy dat : Tato součást Enterprise Architecture identifikuje, jak jsou data udržována, přistupována a používána. Na vysoké úrovni agentury definují data a popisují vztahy mezi datovými prvky používanými v informačních systémech agentury. Součást Popisy dat a vztahy může zahrnovat datové modely, které popisují data, která jsou základem obchodních a informačních potřeb agentury. Jasné znázornění dat a datových vztahů je důležité pro identifikaci dat, která lze korporátně sdílet, pro minimalizaci redundance a pro podporu nových aplikací
  • Technologická infrastruktura : Komponenta Technologická infrastruktura popisuje a identifikuje fyzickou vrstvu včetně funkčních charakteristik, schopností a propojení hardwaru, softwaru a komunikace, včetně sítí, protokolů a uzlů. Jedná se o „schéma zapojení“ fyzické IT infrastruktury .

S výjimkou komponenty Obchodní procesy nejsou těmito pokyny předepsány vzájemné vztahy a priority těchto složek; neexistuje žádná implicitní hierarchie vztahů. Agentury by dále měly dokumentovat nejen své aktuální prostředí pro každou z těchto složek, ale také požadované cílové prostředí.

Aplikace

Rámec FDIC EA.

Rámec NIST byl převzat několika federálními agenturami USA a byl použit jako základ pro jejich informační strategii. V referenčním modelu jsou použity následující rámce:

Viz také

Poznámky

Reference

 Tento článek obsahuje  public domain materiál z webu Národního institutu pro standardy a technologie https://www.nist.gov .

externí odkazy