Zwinność i Architektura Korporacyjna – czy to w ogóle możliwe?

Data: 2017-04-24
Autor: Sebastian Konkol
Zwinność i Architektura Korporacyjna – czy to w ogóle możliwe?

Przez lata spędzone w bardzo różnych organizacjach przyglądałem się sposobom działania ludzi, którzy na wizytówkach mieli napisane Architekt Korporacyjny (Enterprise Architect). Patrząc na poczynania takich ludzi – nie wszystkich, ale jednak znakomitej większości – można byłoby uznać, że EA (Enterprise Architecture) jest martwe, a podtrzymywanie EA przy życiu doprowadzi do Apokalipsy Zombie. W rzeczywistości jednak nie EA jest złe – to „metodycy od EA” sprowadzają na EA apokalipsę.

Żadna inna sfera architektury – rozwiązań, integracji, techniczna, .Net vs. Java (pomijam architekturę bezpieczeństwa, bo to inna para kaloszy J) – nie obrosła taką gęstwiną metod pracy, jak architektura korporacyjna. Ten „narzut metodyczny” (procesy, narzędzia, reguły, nadzór, struktury organizacyjne, role i odpowiedzialności) jest do tego stopnia przytłaczający, że EA jest dzisiaj utożsamiane bardziej z metodą pracy, niż z jej przedmiotem – samą architekturą. W żadnym wypadku nie wynika to z różnicy złożoności działań architektów w tych sferach – EA wcale nie jest zajęciem bardziej złożonym lub wymagającym specjalnej troski dla jej organizacji. EA było, jest i będzie przede wszystkim architekturą, czyli „podstawowa organizacja systemu obejmująca jego komponenty, związki między nimi i środowiskiem oraz reguły kierujące jego projektowaniem i ewolucją” (definicja IEEE) na poziomie Enterprise. Dopiero na podstawie znajomości przedmiotu pracy EA można kojarzyć go ze zbiorem metod pracy nad architekturą w skali firmy.

EA jest bez wątpienia inne, niż wszystkie inne sfery architektury. Kiedy decydujemy o tworzeniu architektury rozwiązania, robimy to zanim rozwiązanie powstanie. O architekturze korporacyjnej zaczynamy jednak mówić dopiero wtedy, kiedy firma jest już „klasy wagowej” korporacji – przeciętnemu fundatorowi biznesu nie przychodzi do głowy, aby rozpędzanie swojego startupu zacząć od ustanowienia architektury korporacyjnej. EA powstaje wraz z rozwojem firmy, podobnie jak kultura organizacyjna i jest po prostu rzeczywistością. Każda firma ma architekturę korporacyjną, gdyż ma jakąś strukturę. Taka firma może – czasami z wyboru, ale zwykle nieświadomie – nie kształtować tej struktury świadomie. Każda firma, jak której „uzależnienie od IT” wykracza poza wykorzystanie poczty elektronicznej i pakietu biurowego, potrzebuje zarządzania EA, jako struktury zapewniającej zdolność firmowej informatyki do realizacji tej części biznesu, która powierzana jest narzędziom informatycznym. Dla przypomnienia, zarządzanie  jest zwykle definiowane jako świadome kształtowanie zgodnie ze znanymi celami i sposobem działania.

Głoszony od wielu już lat kryzys EA jest kryzysem metod pracy nad architekturą korporacyjną, nie zaś samej architektury. Wyjście z tej sytuacji kryzysu wymaga zmian metod pracy, a nie „ubicia” koncepcji EA jako całości. Ludzkość doliczyła się wielu „grzechów ciężkich” popełnianych rutynowo przez EA-wizytówkowców. Najczęstszym zarzutem jest budowanie „wieży z kości słoniowej”, w której zasiadają metodycy EA oderwani zarówno od biznesu jak i technologii, świetnie rozumiejący się wzajemnie, ale nie wykazujący nawet potrzeby kontaktu z kimkolwiek innym (no, może poza chęcią błyszczenia przed Zarządami swoich firm). Często pojawiają się także argumentu odhumanizowania EA, oparcia wyłączni o procesy, reguły i narzędzia, blokujące jakiekolwiek możliwości innowacji. W efekcie działań metodyków, jak twierdzi ludzkość, powstają zwykle przesztywnione konstrukcje, pochłaniając ogromny wysiłek całej organizacji, tak rozciągnięte w czasie, że stają się “dead on arival”.

W mojej ocenie najpoważniejszym jednak grzechem jest sam fundament wszystkich metod pracy na EA – zakładanie istnienia jakiegoś ustalonego na przynajmniej lata do przodu stanu, którego osiągnięcie biznes zadeklaruje bez względu na okoliczności. Ten grzech jest najpoważniejszy, bo – przyjmując istnienie takiego stanu – metody pracy na EA dają ułudę bardzo przemyślanego, deterministycznego przejścia przez wszystkie kroki, jakie będą potrzebne, aby ten stan osiągnąć. Ten miraż determinizmu znika natychmiast, kiedy przyjmiemy do wiadomości rzeczywistość otoczenia rynkowego typowej firmy działającej dzisiaj na rynku – “The Only Constant is Change”. Współczesny biznes jest do szpiku pragmatyczny. Otoczenie rynkowe wymusza ciągłe działania w krótkich krokach dopasowanych nie w wieloletnich cyklach transformacji lecz w cyklach tygodniowych. Nie istnieje nic takiego, jak Święty Graal metodyków, ustalony stan „TO-BE za dwa lata”. Paradoksalnie, każda metodyczna „inicjatywa EA” zaczyna się jednak od zdefiniowania tego stanu – wymaga od biznesu jego zdefiniowania lub (o zgrozo!) definiuje ten stanu „pomimo” biznesu.

Biznes potrzebuje zwinności w biznesie, bo taka jest natura otoczenia ekonomicznego, nie zaś lenistwa biznesu (choć to także bywa niestety prawdą). Architektura – zarówno jako struktura, jak i metoda działania – musi w dostarczeniu tej zwinności uczestniczyć. Nie można jednak przesadzić – architektura ma uczestniczyć w tworzeniu zwinności, bo to biznes ma być zwinny.

Takie myśli kłębią mi się ostatnio w głowie i będzie tego ciąg dalszy, obiecuję. Agile Enterprise Architecture jest nie tylko możliwe, ale wręcz konieczne. Stay Tuned!

Pozostaw komentarz