Regularnie czytam blog Andrzeja Sobczaka, profesora SGH. Czasami bywa, że mam odmienne zdanie niż tam prezentowane, i tym razem też tak jest. Ostatni wpis na tym blogu zawiera siedmiopunktową prognozę na rok 2015. W zasadzie trudno w tych prognozach odmówić racji autorowi jednak dwa punkty, moim zdaniem, warte się komentarza.

2. W tym roku nie doczekamy się jeszcze wdrożenia w polskim przedsiębiorstwie pełnej koncepcji architektury korporacyjnej

Na pytanie ?ile organizacji w Polsce wdrożyło? kompleksowo koncepcję architektury korporacyjnej [w tym w domenie architektury biznesowej] ? ciągle odpowiadam: zero (jeżeli się mylę ? proszę o kontakt; przyjadę z butelką dobrego wina i przeproszę taką organizację i jej Głównego Architekta). (Architektura korporacyjna w roku 2015 ? prognoza | Architektura Korporacyjna).

Bez definicji owej “pełnej koncepcji architektury korporacyjnej” trudno jest mi uznać te prognozę za weryfikowalną. Tak więc można (trzeba) tu przyjąć ogólną powszechnie cytowana w literaturze definicję: Architektura korporacyjna (ang. Enterprise Architecture) ? zbiór właściwości danej korporacji (włącznie ze strukturą), które stanowią o zdolności do realizacji jej misji. Obecnie przyjmuje się, że owa struktura to cztery elementy:

Based on this broadening of scope, Enterprise Architecture now covers:

  1. Business Architecture
  2. Data Architecture
  3. Application Architecture
  4. Infrastructure Architecture

(źr. What is Enterprise Architecture? > Business Analyst Community & Resources | Modern Analyst).

Od siebie dodam, że punkt 2. to tak na prawdę, w obecnej postaci systemów  zorientowanych obiektowo, “obiekty biznesowe” rozumiane jako “nośniki danych” (np. Faktura, Zamówienie, itp.). Pojęcie to, nośnik danych, zostało już ugruntowane w notacjach od ponad dziesięciu lat, a od czasu pojawienia się notacji [[BPMN]] stało się standardem. Używanie pojęcia “architektura danych” może (z reguły już mylnie)  sugerować, że chodzi o model danych, rozumiany jako “relacyjny model danych” znany z metod strukturalnych z lat 80-tych.

Tak więc dzisiejsza struktura tego co nazywamy tu Architekturą Korporacyjną to:

  1. Architektura Biznesowa (strukturalny model biznesowy)
  2. Architektura Informacyjna (obiekty biznesowe , model informacyjny)
  3. Architektura Aplikacyjna (struktura komponentów oprogramowania IT)
  4. Architektura Infrastruktury (model wdrożeniowy)

Nie można zapomnieć, że to co nazywamy architekturą biznesową, jest modelem motywacji biznesowej skojarzonym z modelem procesów biznesowych.  W jednym ze swoich artykułów na ten temat podałem definicję:

Architektura Korporacyjna to model i jego dokumentacja, zawierający całą i wystarczającą wiedzę o tym, co ma wpływ na dostarczanie (przez organizację) produktu (Architektura korporacyjna z OMG.org | Jarosław Żeliński IT-Consulting).

Definicja ta powstała na użytek moich projektów, gdyż klienci pytali – i słusznie – co im dostarczę w ramach świadczonej usługi. Tak więc dostarczam to swoim klientom od kilku lat. Osobną kwestią jest to czy zawsze jest ten model dalej utrzymywany. Nie wiem, bo często tracę z nim kontakt po zakończeniu projektu, ale nie zawsze, bo u niektórych klientów zarządzam zmianą w tym modelu (jego cyklem życia).

Tak więc na pytanie czy na pewno “nie doczekamy się jeszcze wdrożenia w polskim przedsiębiorstwie pełnej koncepcji architektury korporacyjnej” odpowiadam: to zależy co rozumiemy pod pojęciem “pełna koncepcja”.

 

Kolejny punkt prognozy, który skomentuję to:

4. Architektura korporacyjna nie będzie jeszcze umiała odnaleźć się w świecie chmury i wirtualizacji

Brutalna prawda jest taka, że obecne języki modelowania architektury korporacyjnej (typy ArchiMate, UML) nakierowane są na opis statyczny (nawet, jak mówimy o transition ? to zawsze są określone momenty w czasie). (Architektura korporacyjna w roku 2015 ? prognoza | Architektura Korporacyjna).

Tu zupełnie się nie zgadzam. Chmura to  wyłącznie metoda implementacji i udostępnienia dwóch ostatnich warstw, przypomnę są to:  Architektura aplikacyjna (struktura komponentów oprogramowania IT) i Architektura Infrastruktury (model wdrożeniowy). Wobec tego nie musi powstać w żadna nowa notacja dla chmury (tu i nie tylko tu, kłania się [[brzytwa Ockhama]]). Po drugie [[UML]] zawiera dość bogaty zestaw narzędzi do modelowania dynamiki systemu, ot choćby diagram sekwencji czy komunikacji. Mamy  też od niedawna notacje (profil UML) [[SoaML]] (podobnie jak [[SysML]]).

ChaosMonkeyAutor w swoim artykule powołuje się na “niemożność opracowania modelu” czegoś co nazwano Chaos Monkey:

Chaos Monkey is a service which identifies groups of systems and randomly terminates one of the systems in a group.

Albo ja czegoś nie rozumiem, albo mówimy o usługach ad-hoc lub wywoływanych wg określonych reguł (tych może być wiele), a opracowanie modelu takiego systemu nie stanowi żadnego  problemu, jednak tu zaznaczam, że możliwe jest moje niezrozumienie. Zwrócę tu także uwagę, że reguły mogą być oparte na losowaniu.

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 2 komentarzy

  1. Andrej Sobczak

    Dziękuję za przygotowanie komentarza do mojego wpisu. Dla mnie architektura = modele + ich zastosowanie podczas podejmowania decyzji (czyli idą za tym określone struktury i procesy organizacyjne). Dlatego napisałem, że “nie doczekamy się jeszcze wdrożenia w polskim przedsiębiorstwie pełnej koncepcji architektury korporacyjnej?. Ale oczywiście jest to tylko jedno z możliwych spojrzeń na EA.
    Jeżeli chodzi o modelowanie dynamiki systemów – to oczywiście można wykorzystać tutaj UML’a i wskazane przez Ciebie diagramy. Przy czym nie jestem do końca przekonany, że jest to notacja dla architekta korporacyjnego (choć bardzo popularna, otwarta, wszechstronna,…).
    W żadnym projekcie nie spotkałem SoaML – ale może czas to zmienić :).

    1. Jaroslaw Zelinski

      Co do zastosowań moich produktów w 100% są używane do opracowania decyzji “co to ma zostać zmienione/kupione” więc jest 🙂
      Co do modelowania dynamiki to diagram sekwencji jako “model komunikacji” (pomijam forme graficzą) jest od dośc dawna w użyciu (np. w takiej mało UML’owej formie: http://www.codeproject.com/KB/dotnet/EmailFramework/Sequence.png)
      SoaML to kolejny profil UML, bardzo młoda notacja. Ale moim zdaniem skoro cloud to jakaś forma zasobów IT to zaniedbując “odległość do infrastruktury” w modelu AK niespecjalnie się chyba wyróżnia…

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.