Zachman Framework - Zachman Framework

Zachman Framework architektury korporacyjnej

Ramowa Zachman jest przedsiębiorstwem ontologia i jest podstawową strukturę Enterprise Architecture , która zapewnia formalny i zorganizowany sposób oglądania i definiowania przedsiębiorstwa. Ontologia to dwuwymiarowy schemat klasyfikacji, który odzwierciedla przecięcie się dwóch historycznych klasyfikacji. Pierwsze to prymitywne pytania: co, jak, kiedy, kto, gdzie i dlaczego. Drugi wywodzi się z filozoficznej koncepcji reifikacji, przekształcenia abstrakcyjnej idei w konkretyzację. Transformacje reifikacji Zachmana Framework to: Identyfikacja, Definicja, Reprezentacja, Specyfikacja, Konfiguracja i Instancja.

Ramy Zachmana nie są metodologią , ponieważ nie implikują żadnej konkretnej metody ani procesu zbierania, zarządzania lub wykorzystywania informacji, które opisują .; jest to raczej ontologia, w której schemat organizowania artefaktów architektonicznych (innymi słowy, dokumenty projektowe, specyfikacje i modele) jest używany do uwzględnienia zarówno tego, do kogo skierowany jest artefakt (na przykład właściciel firmy i konstruktor), jak i jaki konkretny problem (na przykład dane i funkcjonalność).

Framework został nazwany na cześć jego twórcy, Johna Zachmana , który jako pierwszy opracował koncepcję w latach 80-tych w IBM . Od tego czasu był kilkakrotnie aktualizowany.

Przegląd

Tytuł „Zachman Framework” odnosi się do The Zachman Framework for Enterprise Architecture z wersją 3.0 będącą najbardziej aktualną. Ramy Zachmana ewoluowały w swojej trzydziestoletniej historii i obejmują:

  • Początkowy framework, nazwany A Framework for Information Systems Architecture , autorstwa Johna Zachmana, opublikowany w 1987 roku w artykule w czasopiśmie IBM Systems.
  • Ramowa Zachman for Enterprise Architecture , aktualizacja z 1987 oryginale w 1990 przedłużony i przemianowany.
  • Jedna z późniejszych wersji Zachman Framework, oferowana przez Zachman International jako standard branżowy.
Collage of Zachman Frameworks, jak przedstawiono w kilku książkach na temat architektury korporacyjnej w latach 1997-2005.

W innych źródłach Zachman Framework jest wprowadzany jako framework, zapoczątkowany i nazwany na cześć Johna Zachmana, reprezentowany na wiele sposobów, patrz ilustracja. Ramy te są wyjaśnione, na przykład:

  • ramy organizować i analizować dane ,
  • ramy dla architektury korporacyjnej.
  • klasyfikacja systemu lub schemat klasyfikacji
  • matryca, często w formacie matrycy 6x6
  • model dwuwymiarowy lub model analityczny.
  • dwuwymiarowy schemat używany do organizowania szczegółowych reprezentacji przedsiębiorstwa.

Oprócz frameworków opracowanych przez Johna Zachmana, opracowano wiele rozszerzeń i / lub aplikacji, które są czasami nazywane Zachman Frameworks, jednak na ogół są one graficznymi nakładkami samej struktury.

Zachman Framework podsumowuje zbiór perspektyw związanych z architekturą korporacyjną. Perspektywy te są reprezentowane w dwuwymiarowej macierzy, która definiuje wzdłuż rzędów typ interesariuszy, a kolumnami aspekty architektury. Ramy nie definiują metodologii architektury. Macierz jest raczej szablonem, który należy wypełnić celami / zasadami, procesami, materiałami, rolami, lokalizacjami i wydarzeniami, które są szczególnie wymagane przez organizację. Dalsze modelowanie poprzez mapowanie między kolumnami w ramach identyfikuje luki w udokumentowanym stanie organizacji.

Ramy to logiczna struktura służąca do klasyfikowania i organizowania opisowych reprezentacji przedsiębiorstwa. Jest to istotne zarówno dla kierownictwa przedsiębiorstwa, jak i dla podmiotów zaangażowanych w rozwój systemów przedsiębiorstwa. Chociaż nie ma kolejności priorytetów w kolumnach Framework, kolejność od góry do dołu ma znaczenie dla dostosowania koncepcji biznesowych i rzeczywistego fizycznego przedsiębiorstwa. Poziom szczegółowości struktury jest funkcją każdej komórki (a nie wierszy). W przypadku działań IT niższy poziom skupienia się na technologii informacyjnej , jednak może on odnosić się w równym stopniu do materiału fizycznego (na przykład zaworów kulowych, rurociągów, transformatorów, skrzynek bezpiecznikowych) oraz powiązanych procesów fizycznych, ról, lokalizacji itp. Związanych z tymi elementami. .

Historia

W latach 80-tych John Zachman był zaangażowany w IBM przy opracowywaniu planowania systemów biznesowych (BSP), metody analizy, definiowania i projektowania architektury informacyjnej organizacji. Już w 1982 roku Zachman doszedł do wniosku, że analizy te mogą wykraczać daleko poza automatyzację projektowania systemów i zarządzanie danymi w sferę strategicznego planowania biznesowego i ogólnie nauk o zarządzaniu. Może być stosowany w (w tamtych czasach uważanych za bardziej ezoteryczne) obszarach architektury korporacyjnej, projektowania systemów opartych na danych, kryteriach klasyfikacji danych i nie tylko.

Ramy architektury systemów informatycznych

Oryginalna „Struktura architektury systemów informacyjnych” z 1987 r.
Prosty przykład Framework z 1992 roku.

W artykule z 1987 r. „Framework for Information Systems Architecture” Zachman zauważył, że termin „architektura” był luźno używany przez specjalistów ds. Systemów informacyjnych i oznaczał różne rzeczy dla planistów, projektantów, programistów, specjalistów ds. Komunikacji i innych. Szukając obiektywnej, niezależnej podstawy, na której można by opracować ramy architektury systemów informatycznych, Zachman przyjrzał się architekturze klasycznej i różnorodnym skomplikowanym projektom inżynieryjnym w przemyśle. Widział podobne podejście i doszedł do wniosku, że architektury istnieją na wielu poziomach i obejmują co najmniej trzy perspektywy: surowiec lub dane , funkcję procesów oraz lokalizację lub sieci.

Architektura systemów informacyjnych została zaprojektowana jako schemat klasyfikacji służący do organizowania modeli architektury. Zapewnia synoptyczny widok modeli potrzebnych w architekturze korporacyjnej. Architektura systemów informatycznych nie definiuje szczegółowo, co powinny zawierać modele, nie narzuca języka modelowania używanego dla każdego modelu, ani nie proponuje metody tworzenia tych modeli.

Rozszerzenie i formalizacja

W artykule z 1992 r. „Rozszerzanie i formalizowanie ram architektury systemów informacyjnych” John F. Sowa i John Zachman przedstawiają ramy i ich ostatnie rozszerzenia oraz pokazują, jak można je sformalizować w notacji grafów pojęciowych. Również w 1992 roku:

Współautor Johna Zachmana, John Sowa, zaproponował dodanie perspektywy zakresu `` planisty '' (listy ograniczające wspólne dla przedsiębiorstwa i jego otoczenia) oraz perspektywy szczegółowej reprezentacji `` podwykonawcy '' (będącego rozwiązaniem dostawcy poza kontekstem) składniki). Kolumny „Kto, kiedy i dlaczego” zostały udostępnione publicznie, w artykule nakreślono pojęcie czterech poziomów metaframe oraz przedstawienie powiązań integracyjnych w różnych perspektywach. Keri Anderson Healey pomogła w stworzeniu modelu modeli (metamodelu frameworkowego), który również został zawarty w artykule.

-  Stan Locke, Enterprise Convergence in Our Lifetime, z THE ENTERPRISE NEWSLETTER

Później w latach 90

  • Metodolodzy, tacy jak Clive Finkelstein, skupili się ponownie na dwóch najwyższych rzędach frameworka, które nazwał Inżynierią Korporacyjną i mają jedną z najbardziej skutecznych metod łączenia potrzeb biznesowych z implementacją technologii informatycznych oraz określania logicznej kolejności budowania elementów.

Ramy architektury korporacyjnej

W artykule z 1997 r. „Concepts of the Framework for Enterprise Architecture” Zachman powiedział, że ramy powinny być określane jako „Framework for Enterprise Architecture” i powinny istnieć od samego początku. Jednak we wczesnych latach 80-tych XX wieku, według Zachmana, „zainteresowanie ideą Enterprise Reengineering lub Enterprise Modeling było niewielkie, a użycie formalizmów i modeli było ogólnie ograniczone do niektórych aspektów rozwoju aplikacji w społeczności systemów informatycznych”.

W 2008 Zachman Enterprise przedstawił Zachman Framework: The Official Concise Definition jako nowy standard Zachman Framework.

Rozszerzone i zmodyfikowane frameworki

Od lat 90. zaproponowano kilka rozszerzonych ram, takich jak:

  • Matthew i McGee (1990) rozszerzyli trzy początkowe perspektywy „co”, „jak” i „gdzie”, na zdarzenie („kiedy”), powód („dlaczego”) i organizację („kto”).
  • Evernden (1996) przedstawił alternatywne ramy informacyjne .
  • Integrated Framework Architecture opracowany przez Capgemini od 1996 roku.
  • Vladan Jovanovic et all (2006) przedstawia Zachman Cube, rozszerzenie Zachman Framework do wielowymiarowej Zachman's Cube.

Tematy Zachman Framework

Pojęcie

Podstawową ideą stojącą za Zachman Framework jest to, że ta sama złożona rzecz lub element może być opisana dla różnych celów na różne sposoby, przy użyciu różnych typów opisów (np. Tekstowych, graficznych). Ramy Zachmana zapewniają trzydzieści sześć kategorii niezbędnych do pełnego opisania czegokolwiek; szczególnie złożone rzeczy, takie jak wyroby przemysłowe (np. urządzenia), konstrukcje zbudowane (np. budynki) i przedsiębiorstwa (np. organizacja i wszystkie jej cele, ludzie i technologie). Ramy zapewniają sześć różnych transformacji abstrakcyjnej idei (nie zwiększając ich w szczegółach, ale przekształcając) z sześciu różnych perspektyw.

Pozwala różnym ludziom spojrzeć na to samo z różnych perspektyw. Tworzy to holistyczny obraz środowiska, co jest ważną zdolnością zilustrowaną na rysunku.

Widoki rzędów

Każdy wiersz przedstawia całościowy widok rozwiązania z określonej perspektywy. Wyższy rząd lub perspektywa niekoniecznie mają bardziej kompleksowe zrozumienie całości niż niższa perspektywa. Każdy rząd przedstawia odrębną, niepowtarzalną perspektywę; jednak wyniki z każdej perspektywy muszą zapewniać dostateczną szczegółowość, aby zdefiniować rozwiązanie na poziomie perspektywy i muszą być wyraźnie przekładane na następny niższy wiersz.

Każda perspektywa musi uwzględniać wymagania innych perspektyw oraz ograniczenia narzucane przez te perspektywy. Ograniczenia każdej perspektywy są addytywne. Na przykład ograniczenia wyższych wierszy wpływają na wiersze poniżej. Ograniczenia niższych rzędów mogą, ale nie muszą mieć wpływu na wyższe wiersze. Zrozumienie wymagań i ograniczeń wymaga przekazywania wiedzy i zrozumienia z perspektywy na perspektywę. Ramy wskazują pionowy kierunek komunikacji między perspektywami.

The Veterans Affairs Zachman Framework z wyjaśnieniem jego wierszy.

Bieżąca wersja (3) Zachman Framework kategoryzuje wiersze w następujący sposób:

  • Perspektywa wykonawcza (zawartość zakresu) - pierwszy szkic architektoniczny to „ wykres bąbelkowy ” lub diagram Venna , który przedstawia w kategoriach ogólnych rozmiar, kształt, częściowe zależności i podstawowy cel ostatecznej konstrukcji. Odpowiada podsumowaniu wykonawczemu dla planisty lub inwestora, który chce przeglądu lub oszacowania zakresu systemu, jego kosztów i tego, jak odnosi się do ogólnego środowiska, w którym będzie działał.
  • Perspektywa zarządzania biznesowego (koncepcje biznesowe) - następnie rysunki architekta przedstawiające ostateczny budynek z perspektywy właściciela, który będzie musiał z nim żyć w codziennych czynnościach biznesowych. Odpowiadają one modelom przedsiębiorstwa (biznesowym), które stanowią projekty przedsiębiorstwa i pokazują podmioty gospodarcze i procesy oraz ich powiązania.
  • Perspektywa architekta (logika systemu) - plany architekta są tłumaczeniem rysunków na reprezentacje wymagań szczegółowych z perspektywy projektanta. Odpowiadają one modelowi systemu zaprojektowanemu przez analityka systemowego, który musi określić elementy danych, logiczne przepływy procesów oraz funkcje reprezentujące podmioty i procesy biznesowe.
  • Perspektywa inżyniera (fizyka technologii) - wykonawca musi przerysować plany architekta, aby przedstawić perspektywę konstruktora, z dostateczną szczegółowością, aby zrozumieć ograniczenia narzędzi, technologii i materiałów. Plany konstruktora odpowiadają modelom technologicznym, które muszą dostosować model systemów informatycznych do szczegółów dotyczących języków programowania, urządzeń wejścia / wyjścia (I / O) lub innych wymaganych technologii pomocniczych.
  • Perspektywa techniczna (komponenty narzędzi) - podwykonawcy pracują na podstawie planów warsztatu, które określają szczegóły części lub podsekcji. Odpowiadają one szczegółowym specyfikacjom przekazywanym programistom, którzy kodują poszczególne moduły bez przejmowania się ogólnym kontekstem lub strukturą systemu. Alternatywnie, mogą one przedstawiać szczegółowe wymagania dla różnych gotowych, komercyjnych (COTS) , rządowych gotowych elementów (GOTS) lub komponentów oprogramowania systemów modułowych, które są zamawiane i wdrażane, a nie budowane.
  • Enterprise Perspective lub (Operations Instances)

Skupienie kolumn

Podsumowując, każda perspektywa skupia uwagę na tych samych fundamentalnych pytaniach, a następnie odpowiada na te pytania z tego punktu widzenia, tworząc różne reprezentacje opisowe (tj. Modele), które przekładają się z perspektywy wyższej na niższą. Podstawowy model celu (lub abstrakcji produktu) pozostaje niezmienny. Podstawowy model każdej kolumny jest jednoznacznie zdefiniowany, ale powiązany w całej macierzy i w dół. Ponadto sześć kategorii komponentów architektury korporacyjnej i podstawowe pytania, na które odpowiadają, tworzą kolumny Zachman Framework i są to:

  1. Zestawy ekwipunku - co
  2. Przepływy procesów - jak
  3. Sieci dystrybucyjne - gdzie
  4. Przypisania odpowiedzialności - kto
  5. Cykle czasowe - kiedy
  6. Intencje motywacyjne - dlaczego

Zdaniem Zachmana jedynym czynnikiem, który sprawia, że ​​jego struktura jest wyjątkowa, jest to, że każdy element na każdej osi macierzy jest wyraźnie odróżnialny od wszystkich innych elementów na tej osi. Reprezentacje w każdej komórce macierzy to nie tylko kolejne poziomy o coraz większej szczegółowości, ale w rzeczywistości są to różne reprezentacje - różniące się kontekstem, znaczeniem, motywacją i zastosowaniem. Ponieważ każdy z elementów na każdej osi wyraźnie różni się od pozostałych, możliwe jest dokładne zdefiniowanie tego, co należy do każdej komórki.

Modele komórek

Ramy Zachmana są zazwyczaj przedstawiane jako ograniczona "macierz" 6 x 6 z pytaniami komunikacyjnymi jako kolumnami i transformacjami reifikacji jako wierszami. Klasyfikacje ramowe są wypierane przez komórki, czyli przecięcie między pytaniami a transformacjami.

Opisy komórek są pobierane bezpośrednio z wersji 3.0 Zachman Framework.

Perspektywa wykonawcza
  1. (Co) Identyfikacja zapasów
  2. (Jak) Identyfikacja procesu
  3. (Gdzie) Identyfikacja dystrybucji
  4. (Kto) Identyfikacja odpowiedzialności
  5. (Kiedy) Identyfikacja czasu
  6. (Dlaczego) Identyfikacja motywacji
Perspektywa zarządzania biznesem
  1. (Co) Definicja zapasów
  2. (Jak) Definicja procesu
  3. (Gdzie) Definicja dystrybucji
  4. (Kto) Definicja odpowiedzialności
  5. (Kiedy) Definicja czasu
  6. (Dlaczego) Definicja motywacji
Perspektywa architekta
  1. (Co) Reprezentacja zapasów
  2. (Jak) Reprezentacja procesu
  3. (Gdzie) Reprezentacja dystrybucji
  4. (Kto) Oświadczenie o odpowiedzialności
  5. (Kiedy) Reprezentacja w czasie
  6. (Dlaczego) Reprezentacja motywacji
Perspektywa inżyniera
  1. (Co) Specyfikacja zapasów
  2. (Jak) Specyfikacja procesu
  3. (Gdzie) Specyfikacja dystrybucji
  4. (Kto) Specyfikacja odpowiedzialności
  5. (Kiedy) Specyfikacja czasowa
  6. (Dlaczego) Specyfikacja motywacji
Perspektywa technika
  1. (Co) Konfiguracja zapasów
  2. (Jak) Konfiguracja procesu
  3. (Gdzie) Konfiguracja dystrybucji
  4. (Kto) Konfiguracja odpowiedzialności
  5. (Kiedy) Konfiguracja czasu
  6. (Dlaczego) Konfiguracja motywacji
Perspektywa przedsiębiorstwa
  1. (Co) Wystąpienia zasobów
  2. (Jak) Przetwarzaj wystąpienia
  3. (Gdzie) Instancje dystrybucji
  4. (Kto) Instancje odpowiedzialności
  5. (Kiedy) wystąpienia czasowe
  6. (Dlaczego) Instancje motywacyjne

Ponieważ rozwój produktu (tj. Artefakt architektoniczny) w każdej komórce lub rozwiązanie problemu zawarte w komórce jest odpowiedzią na pytanie z perspektywy, zazwyczaj modele lub opisy są przedstawieniami wyższego poziomu lub odpowiedziami powierzchni komórki. Udoskonalone modele lub projekty wspierające tę odpowiedź są szczegółowymi opisami w komórce. W każdej komórce zachodzi dekompozycja (tj. Drążenie w dół do wyższych poziomów szczegółowości). Jeśli komórka nie jest jawna (zdefiniowana), jest niejawna (niezdefiniowana). Jeśli jest to dorozumiane, istnieje ryzyko przyjmowania założeń dotyczących tych komórek. Jeśli założenia są słuszne, oszczędza się czas i pieniądze. Jeżeli jednak założenia okażą się nieważne, prawdopodobnie zwiększy to koszty i przekroczy harmonogram realizacji.

Ramowy zbiór zasad

Przykład zasad ramowych Zachmana.

Framework zawiera zestaw reguł:

  • Zasada 1 Kolumny nie mają porządku  : kolumny są wymienne, ale nie można ich redukować ani tworzyć
  • Zasada 2 Każda kolumna ma prosty model ogólny  : każda kolumna może mieć swój własny metamodel
  • Zasada 3 Podstawowy model każdej kolumny musi być niepowtarzalny  : Podstawowy model każdej kolumny, obiekty relacji i ich struktura są niepowtarzalne. Każdy obiekt relacji jest współzależny, ale cel reprezentacji jest unikalny.
  • Zasada 4 Każdy wiersz opisuje odrębną, niepowtarzalną perspektywę  : każdy wiersz opisuje widok określonej grupy biznesowej i jest dla niej unikalny. Wszystkie wiersze są zwykle obecne w większości organizacji hierarchicznych.
  • Zasada 5 Każda komórka jest niepowtarzalna  : kombinacja 2, 3 i 4 musi dawać unikalne komórki, gdzie każda komórka reprezentuje określony przypadek. Przykład: A2 przedstawia wyniki biznesowe, ponieważ reprezentują to, co ma zostać ostatecznie zbudowane.
  • Zasada 6 Złożenie lub integracja wszystkich modeli komórek w jednym wierszu stanowi kompletny model z perspektywy tego wiersza  : Z tego samego powodu, co w przypadku nie dodawania wierszy i kolumn, zmiana nazw może zmienić podstawową strukturę logiczną Framework.
  • Zasada 7 Logika jest rekurencyjna  : logika jest relacyjna między dwoma instancjami tej samej jednostki.

Ramy są ogólne, ponieważ mogą być używane do klasyfikowania opisowych reprezentacji dowolnego obiektu fizycznego, jak również obiektów pojęciowych, takich jak przedsiębiorstwa. Jest również rekurencyjny, ponieważ można go użyć do analizy samej kompozycji architektonicznej. Chociaż ramy będą przenosić relację z jednej kolumny do drugiej, nadal jest to zasadniczo strukturalna reprezentacja przedsiębiorstwa, a nie reprezentacja przepływu.

Elastyczność w poziomie szczegółowości

Jedną z mocnych stron Zachman Framework jest to, że wyraźnie pokazuje kompleksowy zestaw poglądów, które mogą być uwzględnione w architekturze korporacyjnej. Niektórzy uważają, że całkowite podążanie za tym modelem może prowadzić do zbytniego nacisku na dokumentację, ponieważ dla każdej z trzydziestu komórek w strukturze potrzebne byłyby artefakty. Zachman wskazuje jednak, że należy podać tylko fakty potrzebne do rozwiązania analizowanego problemu.

John Zachman jasno stwierdza w swojej dokumentacji, prezentacjach i seminariach, że jako ramy istnieje elastyczność co do głębokości i zakresu szczegółów wymaganych dla każdej komórki macierzy w oparciu o znaczenie dla danej organizacji. Producent samochodów, którego cele biznesowe mogą wymagać inwentaryzacji i skupienia się na procesach, może uznać za korzystne skoncentrowanie wysiłków związanych z dokumentacją na kolumnach Co i jak . Z drugiej strony biuro podróży, którego działalność jest bardziej skoncentrowana na ludziach i czasie wydarzeń, może uznać za korzystne skoncentrowanie wysiłków związanych z dokumentacją na kolumnach Kto , kiedy i gdzie . Nie ma jednak ucieczki przed ważnością kolumny Dlaczego , ponieważ zapewnia ona czynniki biznesowe dla wszystkich innych kolumn.

Zastosowania i wpływy

Od lat dziewięćdziesiątych Zachman Framework jest szeroko stosowany jako środek zapewniający strukturę modelowania korporacyjnego w stylu inżynierii informatycznej . Ramę Zachmana można stosować zarówno w firmach komercyjnych, jak iw agencjach rządowych. W ramach organizacji rządowej ramy można zastosować do całej agencji na poziomie abstrakcyjnym lub do różnych działów, urzędów, programów, pododdziałów, a nawet do podstawowych jednostek operacyjnych.

Dostosowywanie

Zachman Framework jest stosowany w niestandardowych strukturach, takich jak TEAF , zbudowanych wokół podobnych struktur, macierzy TEAF .

  • Matryca poglądów i perspektyw TEAF .

  • Ramy kierunku, opisu i realizacji EA - omówienie.

  • Produkty TEAF.

  • TEAF Work Products dla EA Direction, opis i realizacji.

Innych źródeł:

  • Macierz TEAF nazywana jest próbką dostosowywania, patrz tutaj , str. 22

Standardy oparte na ramach Zachmana

Zachman Framework jest również używany jako ramy do opisywania standardów, na przykład standardów dotyczących opieki zdrowotnej i systemu informacji zdrowotnej. Każda komórka ram zawiera taki zestaw norm dotyczących opieki zdrowotnej i systemu informacyjnego opieki zdrowotnej.

Mapowanie innych frameworków

Innym zastosowaniem Zachman Framework jest model odniesienia dla innych architektur korporacyjnych, patrz na przykład te cztery:

  • EAP odwzorowany na Zachman Framework, 1999

  • Mapowanie C4ISR , 1999

  • Mapa produktów DoD do Zachman Framework Cells, 2003.

  • Mapowanie części DoDAF , 2007.

Inne przykłady:

  • Analiza Rational Unified Process jako procesu,
  • W jaki sposób modele architektury opartej na modelu (MDA) używane w tworzeniu oprogramowania są odwzorowywane na platformę Zachman.
  • Mapowanie modeli IEC 62264 na platformę Zachmana do analizy identyfikowalności informacji o produktach.
  • Odwzorowanie Metody Rozwoju Architektury TOGAF (np. Metodologii) na Zachman Framework.

Podstawa dla innych frameworków architektury korporacyjnej

Mniej oczywiste są sposoby, w jakie oryginalny framework Zachman stymulował rozwój innych frameworków architektury korporacyjnej , takich jak model architektury korporacyjnej NIST , C4ISR AE, DOE AE i DoDAF :

  • Model architektury korporacyjnej NIST.

  • C4ISR AE, 1997.

  • DOE AE, 1998.

  • DODAF , 2003.

Przykład: Architektura korporacyjna One-VA

Metodologia Zachmana Framework została na przykład wykorzystana przez Departament Spraw Weteranów Stanów Zjednoczonych (VA) do opracowania i utrzymania architektury przedsiębiorstwa One-VA w 2001 r. Ta metodologia wymagała zdefiniowania wszystkich aspektów przedsiębiorstwa VA z procesu biznesowego, danych, perspektywa techniczna, lokalizacja, personel i wymagania. Kolejnym krokiem wdrażania metodologii było zdefiniowanie wszystkich funkcji związanych z każdym procesem biznesowym oraz zidentyfikowanie powiązanych elementów danych. Po zidentyfikowaniu można zidentyfikować i rozwiązać powielanie funkcji i niespójność w definicji danych.

  • Zintegrowany przepływ procesów dla projektów VA IT (2001)

  • VA Zachman Framework Portal

  • Wprowadzenie do repozytorium VA EA (2008)

  • Samouczek dotyczący architektury Zachman Framework

Departament Spraw Weteranów na początku XXI wieku planował wdrożenie architektury korporacyjnej w pełni opartej na Ramach Zachmana.

  • Platforma Zachmana została wykorzystana jako model odniesienia do zainicjowania planowania architektury korporacyjnej w 2001 roku.
  • Gdzieś pomiędzy zbudowano portal VA Zachman Framework.
  • Ten portal ramowy VA Zachmana jest nadal używany jako model odniesienia, na przykład przy określaniu informacji EA zebranych z różnych dokumentów źródłowych dotyczących biznesu i projektów.

Ostatecznie repozytorium architektury korporacyjnej zostało utworzone na poziomie makr przez strukturę Zachmana i na poziomie komórki przez meta-model opisany poniżej.

VA EA Meta-model komórki Szczegóły w powiększeniu.

Diagram ten został włączony do VA-EA, aby zapewnić symboliczną reprezentację używanego przez niego metamodelu , opisać architekturę przedsiębiorstwa One-VA i zbudować repozytorium EA bez użycia komercyjnego oprogramowania EA Repository. Został opracowany przy użyciu zorientowanej obiektowo bazy danych w produkcie oprogramowania Calibre-RM. Calibre-RM ma być używane jako narzędzie do zarządzania konfiguracją oprogramowania ; nie jako repozytorium EA.

Jednak narzędzie to umożliwiało definiowanie podmiotów i relacji oraz definiowanie właściwości zarówno podmiotów, jak i relacji, co czyniło go wystarczającym do zbudowania repozytorium EA, biorąc pod uwagę technologię dostępną na początku 2003 r. Osobistą motywacją przy wyborze tego narzędzia było to, że żadna z Dostępne wtedy narzędzia repozytorium zapewniały prawdziwą reprezentację Zachman Framework i były wysoce zastrzeżone, co utrudniało włączenie komponentów od innych dostawców lub z oprogramowania open source.

Diagram ten podkreśla kilka ważnych interpretacji Ram Zachmana i jej dostosowania do zarządzania inwestycjami w technologie informacyjne .

  1. Przechodząc przez kolejne rzędy od góry do dołu, można prześledzić cykl życia rozwoju systemów (SDLC), który jest de facto standardem w branży informatycznej;
  2. Diagram podkreśla znaczenie często zaniedbywanego Zachmana Row-Six (Zintegrowany, Operacyjny Widok Przedsiębiorstwa). Reprezentacje w interpretacji wiersza szóstego Zachmana przez pana Zuecha obejmują w dużej mierze wymierne ulepszenia usług i oszczędności / unikanie kosztów, które wynikają z procesu biznesowego i innowacji technologicznych, które zostały opracowane w wierszach od drugiego do piątego.

Wiersz szósty zapewnia mierzalny zwrot z inwestycji dla projektów indywidualnych i potencjalnie dla całego portfela inwestycyjnego . Bez rzędu szóstego ramy identyfikują tylko koszty utopione, ale zwrot z inwestycji w wiersz szósty pozwala na mierzenie korzyści i wykorzystanie ich w procesie ciągłego doskonalenia, uchwycenie najlepszych praktyk i zastosowanie ich w drugim rzędzie.

Krytyka

Chociaż ramy Zachmana są szeroko dyskutowane, ich praktyczna wartość została zakwestionowana:

  • Ramy są czysto spekulatywne, nieempiryczne i oparte wyłącznie na argumentacji koncepcyjnej, że „równoważność [między reprezentacjami architektonicznymi przemysłu wytwórczego i budowlanego] wzmocniłaby argument, że analogiczny zestaw reprezentacji architektonicznych prawdopodobnie powstanie podczas proces budowy dowolnego złożonego produktu inżynierskiego, w tym systemu informacyjnego ”
  • Praktyczne informacje zwrotne pokazują, że ogólna idea tworzenia kompleksowych opisów przedsiębiorstw, zgodnie z sugestią Ram Zachmana, jest nierealna
  • W 2004 roku John Zachman przyznał, że ramy są teoretyczne i nigdy nie zostały w pełni wdrożone: „Jeśli zapytasz, kto z powodzeniem wdraża cały framework, odpowiedzią jest nikt, kogo jeszcze znamy”
  • Nie ma szczegółowych przykładów pokazujących udane praktyczne zastosowanie ram
  • Praktyk EA Stanley Gaver argumentuje, że „analogia do architektury klasycznej po raz pierwszy wykonana przez Johna Zachmana jest błędna i niekompletna”
  • Jason Bloomberg twierdzi, że „przedsiębiorstwo nie jest zwykłym systemem, takim jak maszyna czy budynek, i nie może być tak zaprojektowane ani zaprojektowane”
  • Szczegółowa analiza pokazuje, że Ramowa Zachmana w rzeczywistości opiera się wyłącznie na argumentach czysto spekulacyjnych, promowanych za pomocą fikcyjnych obietnic, nie ma praktycznych przypadków użycia i, z perspektywy historycznej, nie wprowadziła żadnych innowacyjnych pomysłów, których wcześniej brakowało.

Ta krytyka sugeruje, że ramy Zachmana nie mogą odzwierciedlać rzeczywistych najlepszych praktyk w EA.

Zobacz też

Bibliografia

Linki zewnętrzne