Model architektury korporacyjnej NIST

Model architektury korporacyjnej NIST.

NIST Enterprise Architecture Model ( NIST EA Model ) to referencyjny model architektury korporacyjnej z końca lat 80 . Definiuje architekturę przedsiębiorstwa na podstawie wzajemnych powiązań między środowiskiem biznesowym, informacyjnym i technologicznym przedsiębiorstwa.

Opracowany pod koniec lat 80. przez National Institute of Standards and Technology (NIST) i innych, rząd federalny Stanów Zjednoczonych promował ten model referencyjny w latach 90. jako podstawę architektur korporacyjnych poszczególnych agencji rządowych USA oraz w całej federalnej architekturze korporacyjnej .

Wprowadzenie

NIST Enterprise Architecture Model to pięciowarstwowy model architektury korporacyjnej , przeznaczony do organizowania, planowania i budowania zintegrowanego zestawu architektur informacji i technologii informatycznych. Pięć warstw jest zdefiniowanych oddzielnie, ale są ze sobą powiązane i przeplatają się. Model zdefiniował zależność w następujący sposób:

  • Architektura biznesowa napędza architekturę informacji
  • Architektura informacji określa architekturę systemów informatycznych
  • Architektura systemów informatycznych identyfikuje architekturę danych
  • Architektura danych sugeruje określone systemy dostarczania danych i
  • Systemy dostarczania danych (oprogramowanie, sprzęt, komunikacja) obsługują architekturę danych.

Hierarchia w modelu opiera się na założeniu, że organizacja pełni wiele funkcji biznesowych, każda funkcja wymaga informacji z wielu źródeł, a każde z tych źródeł może obsługiwać jeden lub więcej systemów operacyjnych, które z kolei zawierają uporządkowane i przechowywane w dowolnej liczbie systemów danych.

Historia

Model architektury korporacyjnej NIST został zainicjowany w 1988 roku podczas piątych warsztatów na temat kierunków zarządzania informacjami, sponsorowanych przez NIST we współpracy ze Stowarzyszeniem Maszyn Komputerowych (ACM), Towarzystwem Komputerowym IEEE i Federalną Grupą Użytkowników Zarządzania Danymi (FEDMUG). Wyniki tego projektu badawczego zostały opublikowane jako Specjalna Publikacja NIST 500-167, Information Management Directions: The Integration Challenge .

Rozwijająca się dziedzina zarządzania informacją

Wraz z rozprzestrzenianiem się technologii informatycznych , które rozpoczęło się w latach 70. XX wieku, zadanie zarządzania informacją nabrało nowego światła i zaczęło obejmować również dziedzinę konserwacji danych . Zarządzanie informacją nie było już prostą pracą, którą mógł wykonać prawie każdy. Zrozumienie zastosowanej technologii i teorii, która za nią stoi, stało się konieczne. W miarę jak przechowywanie informacji przestawiało się na środki elektroniczne, stawało się to coraz trudniejsze.

Pojęcie modelu trójschematowego zostało po raz pierwszy wprowadzone w 1975 roku przez architekturę trójpoziomową ANSI/X3/SPARC , która określała trzy poziomy modelowania danych.

Jednym z pierwszych ogólnych podejść do budowania systemów informatycznych i zarządzania informacją systemową z lat 70. było podejście oparte na trzech schematach . Proponuje wykorzystanie trzech różnych perspektyw w rozwoju systemów, w których modelowanie koncepcyjne jest uważane za klucz do osiągnięcia integracji danych :

  • Schemat zewnętrzny dla widoków użytkownika
  • Schemat pojęciowy integruje schematy zewnętrzne
  • Schemat wewnętrzny definiujący fizyczne struktury pamięci masowej

W centrum schemat pojęciowy definiuje ontologię pojęć , gdy użytkownicy myślą o nich i rozmawiają o nich. Schemat fizyczny według Sowy (2004) „opisuje wewnętrzne formaty danych przechowywanych w bazie danych , a schemat zewnętrzny określa widok danych prezentowanych programom użytkowym ”.

Od lat siedemdziesiątych NIST zorganizował serię czterech warsztatów na temat kierunków zarządzania bazami danych i informacjami. Każdy z warsztatów dotyczy określonego tematu:

  • „Jakich informacji o technologii baz danych potrzebuje menedżer, aby podejmować rozważne decyzje dotyczące korzystania z nowej technologii”, w 1975 r.
  • „Jakie informacje mogą pomóc menedżerowi ocenić wpływ na system bazy danych?” w 1977 r.
  • „ Narzędzia do zarządzania informacją z punktu widzenia: zastosowań; polityk i kontroli; logicznego i fizycznego projektowania baz danych” w 1980 r.; I
  • „Charakter praktyk i problemów zarządzania zasobami informacyjnymi ” w 1985 r.

Piąte warsztaty w 1989 roku zostały zorganizowane przez Narodowe Laboratorium Systemów Komputerowych (NCSL) NIST. Do tego czasu był to jeden z czterech instytutów, które wykonywały prace techniczne NIST. Konkretnym celem NCSL było prowadzenie badań i świadczenie usług naukowych i technicznych w celu pomocy agencjom federalnym w wyborze, nabywaniu, stosowaniu i korzystaniu z technologii komputerowej.

Warsztaty NIST dotyczące kierunków zarządzania informacjami

Piąty warsztat Information Management Directions, który odbył się w 1989 roku, koncentrował się na integracji i produktywności w zarządzaniu informacją . Pięć grup roboczych rozważyło konkretne aspekty integracji wiedzy, zarządzania danymi , planowania, rozwoju i utrzymania systemów, środowisk obliczeniowych, architektur i standardów. Uczestnicy pochodzili ze środowisk akademickich, przemysłu, instytucji rządowych i firm konsultingowych. Wśród 72 uczestników 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 i John Zachman .

Tom DeMarco wygłosił przemówienie programowe, twierdząc, że standardy wyrządzają więcej szkody niż pożytku, gdy działają wbrew dominującej kulturze, oraz że istotą standaryzacji jest odkrycie, a nie innowacja. Pięć grup roboczych spotkało się, aby omówić różne aspekty integracji:

  • integracja zarządzania wiedzą i danymi
  • integracja zarządzania danymi technicznymi i biznesowymi
  • integracja narzędzi i metod planowania, rozwoju i konserwacji systemów
  • integracja rozproszonych, heterogenicznych środowisk obliczeniowych oraz
  • architektury i standardy.

W trzeciej grupie roboczej ds. planowania systemów przewodniczył John Zachman i przyjęła Zachman Framework jako podstawę do dyskusji.

Model architektury korporacyjnej, 1989

Piątej grupie roboczej ds. architektur i standardów przewodniczył W. Bradford Rigdon z McDonnell Douglas Information Systems Company (MDISC), oddziału McDonnell Douglas . Rigdona i in. (1989) wyjaśnił, że dyskusje o architekturze w tamtym czasie skupiały się głównie na kwestiach technologicznych. Ich celem było „przyjęcie szerszego spojrzenia i opisanie potrzeby architektury korporacyjnej , która obejmuje nacisk na wymagania biznesowe i informacyjne. Te kwestie wyższego poziomu wpływają na architekturę danych i technologię oraz decyzje”. W tym celu grupa robocza zajęła się trzema kwestiami:

  • Poziomy architektury w przedsiębiorstwie
  • Problemy rozwiązywane przez architekturę
  • Korzyści i zagrożenia związane z posiadaniem architektury

Aby zilustrować poziomy architektury, przedstawiono to, co stało się znane jako model architektury korporacyjnej NIST (patrz ilustracja). W tej koncepcji trzy warstwy podejścia opartego na trzech schematach są podzielone na pięć warstw.

Zastosowanie w latach 90

W pewnym sensie NIST Enterprise Architecture Model wyprzedzał swoje czasy. Według Zachmana (1993) w latach 80. „architektura” była uznawana za przedmiot zainteresowania, ale nadal istniało niewiele skonsolidowanej teorii dotyczącej tej koncepcji. Architektura oprogramowania , np. stały się ważnym tematem dopiero w drugiej połowie lat dziewięćdziesiątych.

Aby wspierać model architektury korporacyjnej NIST w latach 90., był szeroko promowany w rządzie federalnym Stanów Zjednoczonych jako narzędzie do zarządzania architekturą korporacyjną. Model architektury korporacyjnej NIST jest stosowany jako podstawa w wielu strukturach architektury korporacyjnej agencji rządu federalnego Stanów Zjednoczonych oraz w ogólnych ramach federalnej architektury korporacyjnej . Koordynując te wysiłki, model NIST został dalej wyjaśniony i rozszerzony w „Memoranda 97-16 (Information Technology Architectures)” z 1997 r., wydanym przez Biuro Zarządzania i Budżetu Stanów Zjednoczonych, patrz dalej Architektura technologii informacyjnej .

Tematy modelu architektury korporacyjnej NIST

Podwaliny

Według Rigdona i in. (1989) architektura jest „wyraźną reprezentacją ram koncepcyjnych komponentów i ich relacji w określonym momencie”. Może to na przykład przedstawiać „obecną sytuację z wyspami automatyzacji, nadmiarowymi procesami i niespójnościami danych” lub „przyszłą zintegrowaną strukturę informacyjną automatyzacji, do której przedsiębiorstwo będzie się zbliżać w określonej liczbie lat”. Rolą standardów w architekturze jest „umożliwianie lub ograniczanie architektury i służenie jako jej podstawa”.

W celu opracowania architektury korporacyjnej Rigdon uznaje:

  • Istnieje wiele sposobów tworzenia architektury
  • Istnieje wiele sposobów wdrażania standardów
  • Rozwój i wdrożenie powinny być dostosowane do otoczenia
  • Jednak samą architekturę można podzielić na różne poziomy.

Różne poziomy architektury korporacyjnej można zwizualizować jako piramidę: na górze jednostka biznesowa przedsiębiorstwa, a na dole system dostarczania w przedsiębiorstwie. Przedsiębiorstwo może składać się z jednej lub kilku jednostek biznesowych, działających w określonym obszarze biznesowym. Pięć poziomów architektury definiuje się jako: jednostka biznesowa, informacja, system informacyjny, system danych i dostarczania.

Poszczególne poziomy architektury korporacyjnej są ze sobą powiązane w szczególny sposób. Na każdym poziomie architektura zakłada lub dyktuje architekturę na wyższym poziomie. Ilustracja po prawej pokazuje przykład, które elementy mogą stanowić architekturę korporacyjną.

Przykładowe elementy architektury korporacyjnej (1989).

Poziomy architektury

Każda warstwa architektury w modelu ma określony cel:

  • Poziom architektury biznesowej: Ten poziom może przedstawiać całość lub podjednostkę dowolnej korporacji, która ma kontakt z organizacjami zewnętrznymi.
  • Poziom architektury informacji: Ten poziom określa rodzaje treści, formy prezentacji i format wymaganych informacji.
  • Poziom architektury systemów informatycznych: Specyfikacje zautomatyzowanych i zorientowanych na procedury systemów informatycznych.
  • Poziom architektury danych: Struktura obsługi, dostępu i korzystania z danych, ze słownikiem danych i innymi konwencjami nazewnictwa.
  • Poziom systemów dostarczania danych: poziom technicznej implementacji oprogramowania, sprzętu i komunikacji, które obsługują architekturę danych.

Niektóre przykładowe elementy bardziej szczegółowego opisu architektury korporacyjnej pokazano na ilustracji.

Architektura technologii informatycznych

„Memoranda 97-16 (Information Technology Architectures)” podały następującą definicję architektury korporacyjnej:

Architektura korporacyjna to wyraźny opis aktualnych i pożądanych relacji między biznesem i procesem zarządzania a technologią informacyjną. Opisuje „docelową” sytuację, którą agencja chce stworzyć i utrzymać, zarządzając swoim portfolio IT.
Dokumentacja architektury korporacyjnej powinna zawierać omówienie zasad i celów. Na przykład ogólne środowisko zarządzania agencji, w tym równowaga między centralizacją a decentralizacją oraz tempo zmian w agencji, powinno być jasno zrozumiane podczas opracowywania architektury korporacyjnej. W tym środowisku zasady i cele wyznaczają kierunek w takich kwestiach, jak promowanie interoperacyjności, otwartych systemów, publicznego dostępu, satysfakcji użytkowników końcowych i bezpieczeństwa.

W tym poradniku przyjęto i dokładniej wyjaśniono pięcioskładnikowy model NIST. Agencje mogły odpowiednio identyfikować różne komponenty i określać poziom organizacyjny, na którym zostaną wdrożone określone aspekty komponentów. Chociaż treść tych komponentów, czasami nazywanych „architekturami” lub „architekturami podrzędnymi”, musi zostać uwzględniona w kompletnej architekturze korporacyjnej każdej agencji, agencje mają dużą elastyczność w opisywaniu, łączeniu i zmienianiu nazw komponentów, na które składają się:

  • Procesy biznesowe : Ten składnik architektury korporacyjnej opisuje podstawowe procesy biznesowe, które wspierają misję organizacji. Komponent Procesy biznesowe to wysokopoziomowa analiza pracy wykonywanej przez agencję w celu wspierania misji, wizji i celów organizacji i jest podstawą ITA. Analiza procesów biznesowych określa, jakie informacje są potrzebne i przetwarzane przez agencję. Ten aspekt ITA musi zostać opracowany przez starszych kierowników programów we współpracy z kierownikami IT. Bez dogłębnego zrozumienia swoich procesów biznesowych i ich związku z misją agencji, agencja nie będzie w stanie efektywnie wykorzystać swojego ITA.
    Procesy biznesowe można opisać, rozkładając je na pochodne działania biznesowe. Dostępnych jest wiele metodologii i powiązanych narzędzi, które pomagają agencjom rozkładać procesy. Niezależnie od zastosowanego narzędzia, model powinien pozostać na wystarczająco wysokim poziomie, aby umożliwić szerokie skupienie agencji, a jednocześnie wystarczająco szczegółowy, aby był przydatny w podejmowaniu decyzji, gdy agencja identyfikuje swoje potrzeby informacyjne. Agencje powinny unikać nadmiernego nacisku na modelowanie procesów biznesowych, co może skutkować marnotrawstwem zasobów agencji.
  • Przepływy informacji i relacje : ten komponent analizuje informacje wykorzystywane przez organizację w jej procesach biznesowych, identyfikując wykorzystywane informacje i przepływ informacji w agencji. W tym komponencie opisano zależności między różnymi przepływami informacji. Te przepływy informacji wskazują, gdzie informacje są potrzebne i jak informacje są udostępniane w celu wspierania funkcji misji.
  • Aplikacje : Komponent Aplikacje identyfikuje, definiuje i organizuje działania, które przechwytują, przetwarzają i zarządzają informacjami biznesowymi w celu wspierania operacji misji. Opisuje również logiczne zależności i relacje między działaniami biznesowymi.
  • Opisy danych : ten składnik architektury korporacyjnej identyfikuje, w jaki sposób dane są utrzymywane, dostępne i używane. Na wysokim poziomie agencje definiują dane i opisują relacje między elementami danych wykorzystywanymi w systemach informacyjnych agencji. Komponent Opisy i relacje danych może zawierać modele danych, które opisują dane leżące u podstaw potrzeb biznesowych i informacyjnych agencji. Jasna reprezentacja danych i relacji między danymi jest ważna dla identyfikowania danych, które mogą być udostępniane w firmie, minimalizowania redundancji i obsługi nowych aplikacji
  • Infrastruktura technologiczna : Komponent Infrastruktura technologiczna opisuje i identyfikuje warstwę fizyczną, w tym cechy funkcjonalne, możliwości i wzajemne połączenia sprzętu, oprogramowania i komunikacji, w tym sieci, protokoły i węzły. Jest to „schemat okablowania” fizycznej infrastruktury IT .

Z wyjątkiem komponentu Procesy biznesowe, niniejsze wytyczne nie określają wzajemnych powiązań i priorytetów tych komponentów; nie ma implikowanej hierarchii relacji. Ponadto agencje powinny dokumentować nie tylko swoje obecne środowisko dla każdego z tych komponentów, ale także docelowe środowisko, które jest pożądane.

Aplikacje

Ramy FDIC EA.

Ramy NIST zostały przechwycone przez kilka amerykańskich agencji federalnych i wykorzystane jako podstawa ich strategii informacyjnej. W modelu referencyjnym zastosowano następujące ramy:

Zobacz też

Notatki

Public Domain Ten artykuł zawiera materiały należące do domeny publicznej z Narodowego Instytutu Standardów i Technologii .

Linki zewnętrzne

Pobrano z „ https://en.wikipedia.org/w/index.php?title=NIST_Enterprise_Architecture_Model&oldid=1010074706 ”