Swego czasu, gdy dowiedziałem się, że notacja ArchiMate ma jednak być chroniona prawami autorskimi przez The Open Group a koszt certyfikacji TOGAF to całkiem niezły haracz, napisałem:
Przyznaję, że rezygnuję z tej notacji jak i z TOGAF?a jako metodyki. W dwóch projektach sprawdziła się moja hipoteza: modelowanie i analiza warstwy biznesowej i IT oraz ocena wzajemnych zależności nie wymaga nowej notacji a dobrze wykonanego modelu w już znanych, wystarczą notacje BMM, BPMN, UML oraz narzędzie potrafiące zarządzać relacjami pomiędzy obiektami na tych modelach? zaryzykuję tezę, że jest to efektywniejsze niż tworzenie kolejnych dziesiątek diagramów ArchiMate. (Pokazać więcej z sensem? ).
Podstawowym powodem jest to, że skądinąd dobry pomysł, jakim jest sama architektura korporacyjna, jest obkładany ideologią (marketing?!) i opłatami, których nie rozumiem (albo raczej rozumiem, ale nie mam ochoty ich ponosić ;)), moi klienci nie raz także nie).
Cóż to jest ta Architektura Korporacyjna (dalej Architektura lub AK)? Ogólnie:
Based on this broadening of scope, Enterprise Architecture now covers:
- Business Architecture
- Data Architecture
- Application Architecture
- Infrastructure Architecture
(polecam cały, krótki wpis na Business Analyst Interview Questions | Modern Analyst > What is Enterprise Architecture?).
Przytoczę tu prostą i bardzo dobrą moim zdaniem definicję zaczerpniętą z referatu [[dr. Andrzeja Sobczaka (SGH)]]:
Architektura korporacyjna – formalny opis struktury i funkcji komponentów korporacji (obejmujących ludzi, procesy, informacje i technikę), wzajemnych relacji pomiędzy tymi komponentami oraz pryncypia i wytyczne odnośnie do zarządzania projektowaniem i zarządzania zmianą tych komponentów w czasie.
Moim zdaniem nie trzeba nic więcej dodawać. Dla porządku przytoczę definicję słowa pryncypium ze słownika j.polskiego:
pryncypium, principium [wym. princ-ipium] ?najważniejsza dla kogoś lub dla czegoś zasada albo wartość? (Portal Wiedzy PWN – słowniki, encyklopedie, podręczniki akademickie, książki specjalistyczne, repetytoria, poradniki, przewodniki).
Te pryncypia, to moim zdaniem uznanie formalizmu w budowie modeli i sformalizowane zarządzanie ich zmianą.
Narzędzia OMG.org
Co mamy w “skrzynce narzędziowej OMG” (www.omg.org)? Ludzie i procesy to nic innego jak BPMN i struktura organizacyjna (ta druga w BPMN lub jako sformalizowany [[organigram]]). Informacje i technika to nic innego jak UML i diagramy strukturalne. Nie rozwodząc się, całość wygląda ogólnie tak:
Powyższy diagram obrazuje:
- kolejne wymagane w AK warstwy (dodano na szczycie tak zwaną motywację biznesową),
- mapowanie zstępujące
W efekcie, mają zastosowanie wskazane narzędzia (diagramy, modele). Z ich pomocą możemy nie tylko opracować model Architektury Korporacyjnej ale także nadzorować go, budując macierze mapowania.
Tu pojawia się pojęcie pragmatyki w stosowaniu języka (notacji). Ta pragmatyka to wspomniane już pryncypia procesowe i obiektowe, oraz wskazane na diagramie powyżej użycie pojęć w każdej z wymienionych notacji, czyli co i na co mapujemy. Mapowanie wymaga doprecyzowania semantyki modeli czyli definicji pojęć. Jak? Najprościej nie kombinować np. z przypadkami użycia na biznesowe, systemowe i inne bo to zupełnie nie potrzebne i nie pozwala na proste mapowanie.
Jawne mapowanie na diagramach pomiędzy warstwami
Notacja ArchiMate ma możliwość (taki jest jej pośredni cel) jawnego pokazania mapowania pomiędzy obiektami warstw na diagramach. W przypadku UML też jest to formalnie możliwe od wersji 2.0, zaś mapowania BPMN->UML dokonuje się w dokumentacji (typowe śladowanie Czynność -> Przypadek użycia).
Otóż mapowanie można pokazać na wiele sposobów. Moim zdaniem robienie tego na diagramach, po pierwsze nieco je zaciemnia, po drugie i tak nie eliminuje przydatności stworzenia macierzy mapowania. Ta druga może być wygenerowana automatycznie, jeżeli tylko używamy dobrego narzędzia CASE (bez niego zresztą nie wyobrażam sobie wykonania żadnego większego modelu przy zachowaniu rozsądnej pracochłonności).
Po drugie nawet średni model, mający kilkadziesiąt obiektów, będzie wymagał dużej ilości dodatkowych diagramów obrazujących samo mapowanie, które to dodatkowe diagramy nie wnoszą wartości dodanej do projektu, bo macierz generowana automatycznie z repozytorium narzędzia CASE i tak jest łatwiejsza w użyciu i percepcji, stanowi też niejako automatyczny “walidator” czy jest ono – mapowanie – poprawne i kompletne.
TOGAF – subiektywnych słów kilka
O tym krótko. Wiem, że stanowi swego rodzaju “gotowca”, ale czy skórka warta wyprawki? Celem budowania AK nie jest “wdrożenie TOGAF”a” (czy też Siatki Zachmann’a), celem jest … no właśnie co? O tym na końcu.
W przypadku TOGAF v 8.x mamy cztery obszary modelowania:
- Business Architecture
- Data Architecture
- Applications Architecture
- Technology Architecture
(źr. The Open Group Architecture Framework Version 8.1.1., nowa wersja TOGAF 9, w porównaniu z powyższym, rozciąga się na elementy motywacji biznesowej).
Nie będę się rozpisywał na temat wszystkich warstw. Kilka słów o jednej: Architektura Danych.
TOGAF i ArchiMate (jak ja rozumiem obie specyfikacje) operuje pojęciem danych, oddzielonych od logiki biznesowej. Obecnie stosowane metody i narzędzia w procesie wytwarzania oprogramowania oparte są na paradygmacie obiektowym, który kompletnie ignoruje pojęcie wydzielonych danych jako takich. Mam tu na myśli bazy danych (w szczególności relacyjne). Bazy danych, w metodach obiektowych, to elementy implementacji, więc są one poza obszarem analizy i projektowania. Przedmiotem przetwarzania w paradygmacie obiektowym są obiekty biznesowe wraz z ich wewnętrzną logiką i zachowaniami.
Jaki jest więc sens brnięcia wstecz do czasów analizy strukturalnej (odrębnie analizowane i implementowane dane i funkcje ich przekształcania)?
Przypomnę tu tylko delikatnie, że np. celem procesu sprzedaży nie są dane zapisane na Fakturze VAT a pozyskanie środków ze sprzedaży produktów, obiekt biznesowy Faktura VAT wraz z regułami naliczania podatku, to jakaś materializacja tego faktu a nie cel sam w sobie. Powoływanie się więc na “dane” w moich oczach nie jest żadnym “postępem”.
Na zakończenie
Mamy więc pomysł o wdzięcznej nazwie Architektura Korporacyjna. Jej definicję, moim zdaniem, można sprowadzić do treści:
Architektura Korporacyjna to model i jego dokumentacja, zawierający całą i wystarczającą wiedzę o tym, co ma wpływ na dostarczanie produktu (J.Żeliński)
Po nam to? Po co nam taka dokumentacja? Przykłady korzyści z jej posiadania:
- mamy “na tacy” model systemu zależności (w tym analiza wpływu) pozwalający natychmiast ocenić ryzyka związane z wzajemnym wpływem na siebie procesów, ludzi, zasobów (np. jakie skutki będzie miało wyłączenie konkretnego serwera czy spóźnienie do pracy konkretnego pracownika),
- mamy “na tacy” wymagania na oprogramowanie, bez niepotrzebnego “zwinnego” ich poszukiwania metodą prób i błędów, niezależnie od tego czy kupujemy nowe czy wymieniamy (niestety, tak zwane zwinne metody to nie raz bardzo duże koszty “zarzuconych bocznych ścieżek” odkrywanych burzą mózgów),
- od razu zauważymy, że idea posiadania monolitycznego systemu ERP II nie bardzo ma sens, usztywnia organizacje oraz tworzy potężny [[“single point of failure”]] (złośliwi dodają “single point of big cost” :)),
- i najważniejsze: jak tylko przeprowadzimy analizę i wykonamy model AK, szybko wychwycimy tak zwane osierocone wymagania na oprogramowanie, osierocone stanowiska pracy, osierocone procedury, … (osierocone: niewykorzystywane), to nie raz źródło samo w sobie – eliminacja “sierot” – ogromnych oszczędności juz na samym początku projektu,
- i inne …
Jak tym zarządzać? Na pewno nie ręcznie, bez oprogramowania CASE w zasadzie nierealne. Czy to kosztowne? Hm… kłania się analiza ROI, każda organizacja ma swój próg rentowności. Jednak od siebie powiem tak: oszczędności pojawiają się natychmiast w postaci identyfikacji “sierot”. Kolejny etap oszczędności to reorganizacja kosztów i ryzyk zarządzania organizacją, kosztów posiadania oprogramowania, kosztów jego rozwoju, kosztów zakupu i tworzenia. Dobra wiadomość: początek każdy już ma w postaci prowadzonej dokumentacji w dziale HR.
Jak więc wyglądają narzędzia rodem z OMG, które w zupełności wystarczą??
Jest to zestaw notacji (BMM, BPMN, UML), który ma niemalże każdy pakiet CASE. Notację ArchiMate mają niestety tylko niektóre z nich, a jak The Open Group zacznie egzekwować opłaty licencyjne to będzie chyba tylko gorzej (co ciekawe sami twócy ArchiMate piszą, że uszczegółowienie modelu AK wykonanego z pomocą ArchiMate wymaga użycia notacji UML). Koszty jednej licencji pakietu CASE (nie raz wystarczy mieć jednego Architekta w organizacji) w wielu przypadkach nie przekraczają 1000USD. Jeżeli więc uda się uniknąć kolejnej analizy wymagań za kilkadziesiąt tysięcy to już ROI mamy w kieszeni.
A po co te formalizmy (pryncypia)? Na etapie analizy i modelowania pozwalają weryfikować poprawność modeli i całej struktury. Na etapie zarządzania zmianą panować nad kosztami zmian i ryzykami w rodzaju “i czasopisma”…:)
Druga dobra wiadomość: spokojnie można to (rola Architekta) outsoursować, będzie jeszcze taniej.
Czyli OooMyGood 🙂
Kiedyś bardzo szanowałem OMG za CORBA, ale jak zaczęli komplikować bez umiaru, przestało mi się to podobać.
OMG to kilkadziesiąt różnych specyfikacji, nie oczekujmy że każda każdemu przypasuje. To co moim zdaniem dobrego wnosi ta organizacja to standaryzacja. Każdy standard, który OMG “wchłonie”, a w zasadzie przyjmie (tam się aplikuje), staje się po pierwsze otwarty (z zasady nie podlega patentowaniu czy ochronie majątkowej) po drugie zostaje dodatkowo dopracowany od strony teoretycznej (widać to ładnie po zmianach jakie zaszły w notacji BMM). To troszkę jak z językami, można sobie odpuścić i pisać slangiem, nie dbać o składnie, wtrąca bez powodu wyrażenia obcojęzyczne, prowadzi to jednak to zawężania liczby odbiorców takiego tekstu. Ma głęboki sens purystyczne używanie języka (także własnego). Rolą OMG nie jest upraszczanie a ujednolicanie. Jednak rolą ich jest także silne oparcie tego co robią na teorii, co z jednej strony bardzo pomaga w utrzymaniu spójności tych standardów, z drugiej pozwala utrzymać ich naukowy charakter, czyli przydatność także do prac akademickich (podobnie zresztą jak języki programowania). Nadmiarowość to nie to samo co komplikowanie.
Panie Jarosławie, jestem wielkim zwolennikiem Pańskiej filozofii i kultury informatycznej i niejednokrotnie czerpię z tego inspiarację 😉
Powyższa wykładnia EA – Data Architecture jest jednak daleko idącym uproszczeniem całej koncepcji. Wydaje mi się, że trochę deprecjonujesz rolę Architekta Danych (w ujęciu EA) i sprowadzasz ją do poziomu Projektanta Baz Danych. To o nie o to tu chodzi. Fizyczny model danych to potencjalnie jeden z “deliverables” architektury i wcale nie najważniejszy. Celem architektury danych jest stworzenie pewnego porzadku, zasad, uporzadkowanie semantyki, zarzadzania, etc. Ma to szczególne znaczenie w przypadku korporacji, dużych organizaji gdzie relacje biznesowe są złożone, systemów i baz danych są setki czy tysiące.
Taka mała refleksja, która przyszła mi na myśl po przeczytaniu Twojego artykułu.
Pozdrawiam,
RF
Przyznaję, że nieco “zaatakowałem” pojęcie Data Architecture (taka mała prowokacja ;)), ale to efekt tego z czym się spotykam. Nie jestem guru TOGAF’a ale widuję często dokumenty traktujące owe dane jako “model danych”, stąd mój opór. Problem jaki spotykam w wielu projektach to mylenie pojęć (nie wiem czy na pewno właśnie mylenie). Mamy takie obiekty biznesowe jak: Faktura VAT, opis produktu, umowa, dokument przewozowy, dokument WZ, i masa innych ale operujemy takimi danymi jak: dane adresowe podmiotów gospodarczych, dane adresowane osób, dane o produktach oferowanych, dane własne firmy, itp… (uogólniając: dane o wybrane atrybuty obiektów). Pytanie brzmi: czym jest tu Data Architecture? W obecnie projektowanych i wykorzystywanych systemach obiektowych (jeżeli faktycznie są w tym paradygmacie projektowane i implementowane) obiektem jest np. Faktura VAT, Adres podmiotu to może być tak zwany ValueObject (albo atrybuty obiektu Faktura VAT), jednak dane w bazie z polami ulica, nr posesji, nr lokalu, miasto, kod itp… to dane w bazie danych, zapewne znormalizowanej czyli totalna sieczka. Przeciętny śmiertelnik w organizacji nie operuje danymi o dokumentami czyli obiektami biznesowymi.
Z czego i na co mapować “dane” i czym one tu są? Gdzie widzę “problem”? Czynność Wystawienie Faktury VAT w procesie sprzedaży, “przejdzie” (mapowanie) w usługę systemu (jego przypadek użycia) Wystawienie Faktury VAT (czynność ma wejście i wyjście, przypadek użycia ma dane początkowe i dane wytworzone). Dokument Faktura VAT jest “integralną” częścią tej usługi (bo ona bez tego dokumentu nie zaistnieje). Jedyne miejsce gdzie “leżą” Faktury VAT jako “coś”, to model dziedziny (klasy) i konkretne obiekty “w systemie” (bo na tym poziomie nie “w bazie”). Ja tu nadal “szukam” jakiejś zasady, ale jak na razie “dane” na poziomie architektury korporacyjnej nijak mi tu nie pasują…. ale mogę się mylić :). Moim zdaniem jest tu “potężna niekonsekwencja” w TOGAF’ie, zresztą semantyka ArchiMate nie pasuje w 100% do UML mimo, że jej autorzy zaznaczają, że uszczegółowienie modeli ArchiMate należy (można) tworzyć w BPMN i UML zależnie od warstwy.
Ot zagwozdka…
Przeciętny śmiertelnik w organizacji nie rozróżnia pojęć proces, wymaganie, reguła biznesowa etc. Przeciętny informatyk ma problem z abstrakcją, koncepcją, logiką i fizyką czy to danych czy czegokolwiek innego.
Zgadzam się, że TOGAF czy też inne “framework’i” z architekturą w tle jest czasem niekonsekwentny i można lawirować/interpretować pewne definicje w zależności od perspektywy. Biorąc pod lupę jednak Architekturę Danych to w TOGAF brzmi ona mnie więcej tak: “Logiczny i fizyczny opis struktury danych oraz zasobów do zarządzania nimi”.
Projektant/Programista udający architekta zacznie od ERD, typów i relacji – i pewnie to jest traktowane jako główny artefakt architektoniczny i być może mylnie (lub z pełnym przekonaniem) jest to nazwane architekturą danych.
W mojej definicj Architaktura Danych to nie tylko struktura fizyczna i logiczna ale przedewszystkim te “zasoby do zarządzania nimi”. Tutaj, bardzo krótko – szeroko pojęte Data Management kierowany przez rolę typu: Lead Data Modeler, Chief Data Architect, Corporate Data Architect etc. Głównym celem architektury danych jest nie ERD praktyki rodzaju: Data Governance, Data Quality, Data Standards, Data Stewardship etc.
Być może trafniejszym określeniem byłby termin Data Management zamiast Data Architecture ale to pozostawiam The Open Group 🙂 Osobiście w IT w moim wykonaniu rozróżniam dodatkowo jeszcze jedną architekturę: Integration Architecture i jestem niezmiernie zainteresowany wynikami Data Architecture oraz Business Architecture.
Pozdrawiam,
RF
Teraz rozumiem i zgadzam się :). Z każdym kolejnym projektem narasta moje “zaufanie” do obiektowego paradygmatu… dane to narzędzie pracy a nie byt sam w sobie, człowiek ma wiele umiejętności, wie także kiedy się urodził i jak się nazywa, jednak to człowiek coś robi a nie jego imię i nazwisko, to ostatnie służy jedynie do identyfikacji. System IT co najwyżej gromadzi dane o ludziach, jeżeli jest czymś więcej niż rejestrem, potrafi zachowywać się zgodnie z przewidzianymi recepturami… :), problem polega na tym, że oddzielenie ‘wiedzy o tym jak” o d wiedzy “co” prowadzi do utraty kontekstu czyli tego czym charakteryzują się metody strukturalne.
Architektura Danych to dla mnie “obiekty biznesowe”, Architektura Biznesowa… cóż to takiego :), chyba że mowa o obiektowy model organizacji…