Historia
W roku 1987, John Zachman opublikował strukturę Zachman dla architektury przedsiębiorstwa. Napisał „By ochronić biznes przed dezintegracją, koncept systemów informacyjnych przestaje być opcją, a staje się koniecznością”. W tej wierze, utworzył Instytut Zachman’a na rzecz Rozwoju Struktury (ZIFA).
Organizacja ta jest siecią profesjonalistów, którzy rozumieją wartość architektury przedsiębiorstwa w strukturach organizacji, które partycypują w globalnej ekonomii. Misją ZIFA jest promowanie wymiany informacji i doświadczeń, wdrożeń i rozwoju struktury Zachman’a w architekturze przedsiębiorstwa. Struktura Zachman’a stosowana jest najczęściej w biznesie i systemach inflacyjnych.
Cel
Struktura Zachman’a jest zbudowana na zasadach klasycznej architektury o wspólnym słownictwie i zbiorze perspektyw do opisywania złożonych systemów przedsiębiorstwa. Można zauważyć te wpływy w zestawie reguł, które zarządzają relacjami, które są zrównoważone, ortogonalne. Poprzez projektowanie systemu zgodnie z tymi regułami, architekt może być pewny, że projekt jest jasny, łatwy do zrozumienia, zrównoważony i kompletny. Struktura Zachman wyposaża w szczegółowy plan działania dla infrastruktury informacyjnej danej organizacji.
Zakres
Struktura Zachman’a opisuje całościowy model infrastruktury informacyjnej danego przedsiębiorstwa z sześciu perspektyw:
Planisty, właściciela, projektanta, wykonawcy, podwykonawcy oraz systemu roboczego. Nie ma wskazówek dotyczących ciągłości, procesu czy wdrażania struktury. Nałożony jest nacisk na zapewnienie, że wszystkie aspekty przedsiębiorstwa są dobrze zorganizowane i ukazują jasne relacje, które zapewniają kompletność systemu bez względu na kolejność wykonywanych procesów.
Zasady
Poprzez zdefiniowanie jasnych reguł projektu architektury, Zachman zapewnia, że każde dopasowane czy też rozszerzone wdrożenie będzie równie dobrze zbudowane, ponieważ projektant jak i wykonawca postępują według tych samych zasad.
Główne zasady, które zarządzają aplikacją struktury Zachman’a to:
– kompletny system może być modelowany poprzez odpowiedzi na pytania: dlaczego, kto, co, jak, gdzie i kiedy,
– sześć perspektyw zawiera wszystkie kluczowe modele potrzebne do rozwinięcia systemu,
– ograniczenia każdej perspektywy są adyktywne, te niższego rzędu są dodane to do rzędów wyższych celem zapewnienia rosnącej liczby ograniczeń,
– kolumny reprezentują różne wpisy, aby zredukować złożoność każdego budowanego modelu,
– kolumny nie są uporządkowane,
– model znajdujący się w którejkolwiek kolumnie jest unikalny,
– każdy rząd reprezentuje inną perspektywę,
– każda komórka jest unikalna,
– wrodzona logika jest rekursywna,
– Model biznesu. Pokazuje wszystkie jednostki i procesy oraz przedstawia jak one współdziałają,
– Model systemu. Używany przez analityka systemu, który musi określić elementy danych oraz funkcje oprogramowania, które reprezentują model biznesu.
– Model Technologiczny. Rozważa ograniczenia narzędzi, technologii i materiałów.
– Komponenty. Przedstawiają indywidualne, niezależne moduły, które mogą być przypisywane dla dostawców celem wdrożenia.
– System roboczy. Opisuje system operacyjny.
Kolumny są podzielone następująco:
– Kto. Prezentuje relacje ludzkie w obszarze przedsiębiorstwa. Projekt organizacji przedsiębiorstwa musi reagować na przypisanie pracy oraz na strukturę władzy i odpowiedzialności. Wartość pionowa przedstawia podział władzy, wartości poziome są przypisane dla odpowiedzialności.
– Kiedy. Przedstawia czas, lub relacje zdarzeń, które ustanawiają kryteria działania i poziomów obliczeniowych dla zasobów przedsiębiorstwa. Jest to użyteczne dla projektu planu generalnego, procesu architektury i architektury kontrolnej.
– Dlaczego. Opisuje motywacje przedsiębiorstwa. Przedstawia cele i zamierzenia przedsiębiorstwa, plan biznesowy, architekturę poznawczą i projekt poznawczy.
– Co. Opisuje podmioty zaangażowane w każdą perspektywę przedsiębiorstwa. Przykłady przedstawiają cele biznesu, dane systemu, tabele powiązań i opisy pól.
– Jak. Pokazuje funkcje w obszarze każdej perspektywy. Przykłady ukazują procesy biznesowe, funkcje aplikacji oprogramowania, funkcje osprzętu komputerowego.
– Gdzie. Pokazuje lokalizacje i wewnętrzne relacje w obszarze przedsiębiorstwa. Główne geograficzne lokalizacje biznesu, oddzielne sekcje sieci logistycznej, lokalizacje węzłów systemu lub nawet adresy pamięci w obszarze systemu.
Instrukcje
Większość przypisanych wskazówek jest podawanych poprzez usługi konsultingowe zakontraktowane przez Instytut Zachman’a. Chociaż proces rozwoju architektury nie jest opisany w tych publikacjach to jest tam zawartych kilka wskazówek, które mogą pomóc organizacjom w użyciu struktury w bardziej wydajny sposób.
– perspektywy i rzędy są bardzo odrębne i niekompletne w górze, a bardziej szczegółowe na dole aż do wdrożenia na ostatnim rzędzie. Powoduje to, że perspektywy mogą być oznaczane do cyklu rozwojowego produktu, przy czym górne rzędy są używane w fazie wstępnej, a dolne stają się ważniejsze w końcowej fazie.
– dwa górne rzędy są zorientowane na biznes i mogą być wyrażone w słownictwie biznesowym, podczas gdy cztery dolne rzędy są wyrażone w domenach technicznych.
– chociaż modele Zachman’a są ściśle proceduralne, nie ma powodu dla którego reprezentacja zastosowana dla każdego pola w strukturze nie mogłaby być w orientacji przedmiotowej. Dokumentacja opublikowana w Rational Edg wyjaśnia jak Rational Unified Process może być oznaczony w strukturze Zachman’a (de Villiers 2001)
– koncepty biznesowe z górnych rzędów muszą być umiejscowione w podmiotach i elementach biznesu w dolnych rzędach. Koncepty biznesu mogą być ulepszane w czasie, ale ich powiązania nie mogą być zmienione. Podmioty i elementy oprogramowania, razem z tymi z zasobów specyficznych domen, mogą być wybierane do zapełniania podstawy systemu, ale aplikacje specjalne w orientacji podmiotowej muszą być zaprojektowane i zintegrowane celem wdrożenia systemu podczas rozwoju.
– ponieważ porządek kolumn, nie ma przypisanego znaczenia, mogą być one aranżowane do przystosowania ich dla projektu w orientacji podmiotowej. Wymagania są utrzymywane w kolumnie „dlaczego” (ang. „why”), a sprawcy są kojarzeni z kolumną „kto” (ang. „who”). Ponieważ zaleca się, aby identyfikacja poprzedzała podmioty, następnymi kolumnami są „jak” (ang. „how”) i „co” (ang. „what”). Bez względu na wybrany porządek, zauważmy, że kolumny są powiązane tak samo jak w oprogramowaniu: dane przedstawiają wejścia i wyjścia dla usług. Kolumna kiedy (ang. „when”) poprzedza gdzie (ang. „where”), jeżeli takie ustawienie jest bardziej znaczące dla poszczególnego procesu rozwijania oprogramowania, ale ważne jest, że porządek kolumn może być użyty do ułatwiania dyskusji podczas rozwijania w orientacji podmiotowej. (Graham 1995)
Struktury mogą być używane wielokrotnie do zarządzania złożonością specyfikowania architektury przedsiębiorstwa. Na przykład, górna struktura prezentuje modelowanie przedsiębiorstwa całego biznesu, środkowa struktura prezentuje modelowanie niezależnego oddziału innej struktury, a dolna struktura prezentuje modelowanie niezależnych stanowisk roboczych.
Jest to tylko przykład, jak złożonym problemem może być dekompozycja na prostsze elementy, podczas gdy każdy element może być modelowany we własnym obszarze za pomocą struktury Zachman’a. Jedna struktura może być użyta do rozwijania architektury technicznej, na poziomie, który stosuje się do wszystkich oddziałów biznesu. Inna struktura może zostać użyta do opracowywania sieci departamentów, które muszą spełniać wymagania wszystkich ograniczeń określonych dla danego poziomu przedsiębiorstwa. Kolejna struktura może być użyta i zarządzania konfiguracją niezależnych stanowisk roboczych, które muszą spełniać wymagania ograniczeń opracowanych na poziomie oddziału lub departamentu.
