Temat tego czy i na ile nietechniczne kadry zarządcze, czyli tak zwany biznes, rozumieją nowe technologie przewija się regularnie przez zarówno prasę jak i blogi. Po pierwsze jest w tym wiele prawdy a po drugie niby dlaczego miało by być inaczej? Jeżeli jakaś treść jest napisana tak zwanym technicznym językiem, to odbiorca, kim jest, sam się ujawni, podobnie jak w przypadku gdy np. w samolocie niemieckich linii lotniczych stewardesa  zawoła do kogoś po polsku podniosą się wyłącznie Polacy.

Z architekturą korporacyjną jest podobnie co potwierdza niżej mój kolega dr. hab. Andrzej Sobczak:

Po pierwsze TOGAF jest napisany w bardzo nieprzystępny sposób ? nawet dla osób dobrze znających angielski (występuje bardzo dużo pojęć, które nie są intuicyjne). Co więcej ?czuć?, że TOGAF został napisany przez informatyków dla informatyków (należy pamiętać, że TOGAF wywodzi się z TAFIM ? tj. Technical Architecture Framework for Information Management, a do wersji 7.0 włącznie w TOGAF?ie mówiono wyłącznie o architekturze IT, dopiero od wersji 8.0 wprowadzono koncepcję architektury korporacyjnej). Po drugie jest niezwykle obszerny (specyfikacja standardu liczy około 700 stron) i nie zawsze jest podzielona w logiczny sposób. Po trzecie wreszcie specyfikacja TOGAF jest miejscami niespójna (co do koncepcji i terminologii) i w niektórych obszarach mocno przestarzała (wynika to z historii rozwoju TOGAF?a jako standardu ? pierwsza jego wersja pojawiła się już w 1996 roku ? bez mała 20 lat temu).

To są minusy tego standardu. Jednak z roku na rok zyskuje on coraz większą popularność. Jeszcze 10 lat temu miał on 7% ?rynku ram archtektonicznych? na świecie?, obecnie jego udział zwiększył się do blisko 60%. Nie można go więc ignorować. Niezbędne jest odpowiednie ?sprzedanie? tego podejścia biznesowej części organizacji. (Jak rozmawiać z biznesem nt. TOGAF?a? | Architektura Korporacyjna).

Powyżej zwrócono uwagę na trzy problemy standardu TOGAF, który jak zauważa autor, ma obecnie 60% udział w rynku (standardów tych jest więcej, przeczytaj mój artykuł i książkę How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating or Choosing an Enterprise Architecture Framework).

Niezrozumiałość to chyba faktycznie efekt tego, że autorami są informatycy. Jest to akurat uzasadnione bo rodowód TOGAF to „konkurencja” dla ITIL.

Obszerność. Hm, tu akurat nie uważam by był to zarzut, specyfikacja notacji BPMN ma podobną objętość, a UML przekroczył 1000 stron. Ramy architektoniczne to także przestrzeń pojęciowa, potężny zestaw terminów mających definicje i cel istnienia czyli opisanie czegoś w spójny sposób. Tu płynnie przechodzimy do trzeciej wady: niespójność. To niestety w moich oczach praktycznie dyskwalifikuje każdy system jeżeli jest niespójny.

Niespójność oznacza powstanie potencjalnej niejednoznaczności w każdym dokumencie (modelu), w którym zostanie użyta niespójna przestrzeń pojęciowa (przypomnę, że poprawna przestrzeń pojęciowa to zestaw pojęć, które cechują: kompletność, niesprzeczność, wzajemna wykluczalność).  A TOGAF i jego słownik terminów to nic innego jak pewna przestrzeń pojęć.

Czy koniecznie musi to być TOGAF?

Ile razy szukam w sieci i książkach definicji pojęcia „architektura korporacyjna” tyle razy przekonuję się, że jej nie ma bo w zasadzie każda znaleziona jest „nieco inna”. Można jednak, studiując literaturę na ten temat, dojść do przekonania, że chodzi po protu o tak zwane całościowe (jak ktoś woli to  holistyczne) systemowe podejście do patrzenia na organizację (analiza systemowa).

Popatrzmy na definicje angielskie (w tym języku powstały pierwsze specyfikacje AE, źr. Oxford Dictionaries):

enteprise –  a business or company: entrepreneurial economic activity

architecture – the art or practice of designing and constructing buildings, the complex or carefully designed structure of something

Tak więc wypada przyjąć, że architektura korporacyjna to

„(całościowa) struktura organizacji prowadzącej działalność o charakterze  komercyjnym„.

[[Jaap Schekkerman]] w swojej książce [[How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating or Choosing an Enterprise Architecture Framework. Creating or choosing an Enteprice Architecture Framework]] tak definiuje AK:

Enterprise Architecture in a complete expression of the enterprise (architektura korporacyjna to kompletny opis organizacji)

Pozostaje odpowiedzieć na pytanie, co zawiera ten kompletny opis? Schekkerman, jak i wielu innych, mówi „wszystko”:

Mamy więc strategię i technologie oraz odpowiadające jej zdolności operacyjne (zarządcze) i technologiczne. Taki opis jest „kompatybilny” z opisem procesu biznesowego w konwencji IGOE (Input, Guide, Output, Enablers, model w projektach z obszaru [[Business Process Manamegent]]) który,  poza swoim wejściem i wyjściem, jest definiowany przez reguły (guide) oraz zasoby umożliwiające jego funkcjonowanie – enablers).

Tak więc mamy odpowiedź na pytanie „Co to znaczy wszystko”. Znaczy to: koncepcja biznesowa (strategia) i sposób zarządzania oraz wymagane technologie czyli strategia ich wykorzystania i zdolność użycia (ich absorpcji). Szczególnie to ostanie ma głęboki sens, gdyż sam fakt zakupu jakiejkolwiek technologii nie jest równoznaczny z jej operacyjnym wdrożeniem (o czym przekonał się niejeden beneficjent systemu np. ERP, CRM czy BI).

Teraz przewrotnie użyję fragmentu podtytułu ww. książki:

Creating an Enterprise Architecture Framework

Tworzenie ramy architektury korporacyjnej. Jak? W sumie, o czym wspominałem w niejednym poprzednim artykule, mamy darmowy komplet narzędzi, czyli systemy pojęciowe dla każdego z powyższych czterech obszarów: strategię możemy opisać z użyciem notacji BMM, reguł biznesowych oraz procesów end-2-end i notacji BPMN. Technologię i sposób jej wykorzystania z pomocą notacji UML. Odpowiednie mapowania (powyżej: poziome i pionowe) robimy albo w macierzy, albo z pomocą Siatki Zachmana. Wybór zależy od przyjętej metody i narzędzia CASE jakim zamierzamy ten projekt dokumentować (bez narzędzia odradzam).

Organizacja OMG dobrze zadbała o spójność tych notacji (Semantic Core), czego niestety nie można powiedzieć o TOGAF i The Open Group (notacja ArchiMate niestety, nie tylko moim zdaniem, pozostawia nieco do życzenia, pomijam już jej licencjonowanie).

Teraz polecam zapoznanie się artykułem Produkty w procesie analizy wymagań. Proszę zwrócić uwagę, że powyższe cztery obszary wiedzy o organizacji: strategia biznesowa, sposób zarządzania – model biznesowy, strategia i zdolność wykorzystania nowych technologii, są objęte opisaną analizą przed-wdrożeniową i analizą wymagań. Wzajemne mapowanie obiektów z tych czterech obszarów to nic innego jak tak zwane śladowanie i walidacja: każdy element musi czemuś służyć i z czegoś wynikać. Moim zdaniem:

Specyfikacja wymagań powinna być produktem (wynikać z) Architektury Korporacyjnej, a nie powstawać każdorazowo od zera z prowadzonych setek wywiadów i warsztatów. 

Tak więc projekt

Architektura Korporacyjna, moim zdaniem, nie ma sensu „sam dla siebie”. Tego typu dokumentacja służy najpierw do zrozumienia działania złożonej organizacji a potem do podejmowania decyzji o każdej reorganizacji czy inwestycji w zasoby.

Wystarczy,  że każda analiza wymagań będzie prowadzona w ten sam, powtarzalny sposób i jako efekt, będzie dawała kompatybilne z poprzedni modele (i dokumenty). Narastająco tworzona dokumentacja prostą drogą poprowadzi nas do dokumentu o nazwie Nasza Architektura Korporacyjna. Zwróci się (koszty stworzenia metodyki) najprawdopodobniej już przy drugim projekcie.

(linia czerwona obrazuje kolejne projekty analityczne i ich narastający koszt, linia niebieska to kolejne projekty analityczne zastąpione stworzeniem i utrzymaniem dokumentacji Architektury Korporacyjnej podczas pierwszego projektu, źr. Jarosław Żeliński, opracowanie własne)

Od czego należy zacząć? Od zbudowania własnej (lub  własnego wariantu) metodyki jej tworzenia oraz zatrudnieniu Architekta. Czy to powinien być własny pracownik? Moim zdaniem nie, gdyż po pierwsze nie będziemy w stanie obciążyć go pracą na 100%. Po drugie powinien to być ktoś z zewnątrz, by nie był uwikłany w wewnątrzorganizacyjne zależności – Architekt korporacyjny nigdy nie powinien być interesariuszem w projekcie związanym z reorganizacją a jako pracownik zawsze nim będzie (podobnie jak lekarz domowy to raczej nikt z domowników).  Kolega w innym swoim artykule pisze:

Architektura korporacyjna nie powinna być utożsamiana z formalnym opisem organizacji (jak to definiuje TOGAF) i nie powinna być tak ?sprzedawana? wewnątrz organizacji.

Jeżeli nie tak ? to w jaki inny sposób? W tym miejscu należy koniecznie odwołać się do ?ojca? koncepcji architektury korporacyjnej ? czyli J. Zachmana. Uważa on, że architektura korporacyjna pomaga rozwiązywać problemy organizacji w iteracyjny i przyrostowy sposób. Przedstawiciele  firmy iCMG idą wręcz dalej ? nazywają oni architekturę korporacyjną dyscypliną naukową zajmującą się tworzeniem, działaniem i rozwojem organizacji. (Czy już pora wymyślić od nowa architekturę korporacyjną? | Architektura Korporacyjna).

i wypada mi się z nim zgodzić 🙂 poza jednym: uważam, że powinien być to opis formalny bo tylko wtedy będzie jednoznaczny i „naukowy”. Tylko wtedy będzie możliwe jego „badanie” np. przeprowadzenie analizy skutków decyzji o reorganizacji zanim ją rozpoczniemy.

Teraz zapewne ktoś powie, że piszę tak tylko dlatego, że świadczę takie usługi. Otóż jest dokładnie odwrotnie: świadczę takie usługi bo głęboko wierzę, że tak właśnie należy postępować, bo – jeżeli organizacja istnieje to ona, architektura, też jest, należy ją tylko przeanalizować, zbudować jej model i korzystać z niego przy podejmowaniu każdej ryzykownej decyzji. Dobry model powinien wolno się zmieniać, tak jak wolno się zmienia organizacja. Jeżeli model jest zbyt szczegółowy i wymaga dużych nakładów na jego aktualizacje jest złym modelem.