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]]).

Autor 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.