Agile Enterprise Architecture

Data: 2017-05-22
Autor: Sebastian Konkol
Agile Enterprise Architecture

Wiele lat temu propagowałem zwinność (agility) na poziomie architektury, także korporacyjnej. Po latach dochodzę do wniosku, że wtedy było za wcześnie. Gospodarka była wtedy wyrozumiała, konkurencja mniejsza i presja biznesu pozostawiała IT sporo komfortu. Można było wydawać miliony na „zabawy w EA” – próbować metod i narzędzi, weryfikować w boju wizje „odtechnologiczne”. Obecne z warunków otoczenia rynkowego firm usunięto łagodność i pobłażliwość, a biznes stał się do szpiku pragmatyczny.

W dzisiejszych warunkach hasła presji konkurencyjnej i ciągłej zmiany nie są wizją przyszłości, ale codziennością biznesową. Co ciekawe, IT en masse rozumie tę zmianę i wkłada sporo wysiłku z dostosowanie się do tej sytuacji (Agile Software Development, DevOps, Cloud). Jak w każdej rodzinie jednak znajdzie się czarna owca, tak i IT „obrywa się” za skostniałość jednego z trybów IT – architekturę korporacyjną (Enterprise Architecture). Aby być precyzyjnym, EA to dwa obszary: przedmiot pracy (architektura) i metody pracy. Rozróżnienie to jest o tyle ważne, że zdarza się oceniać architektów korporacyjnych przez pryzmat „dokonań” metodyków od architektury korporacyjnej, a to po prostu nieuczciwe – architektura może być zwinna, tylko metodycy do tego jeszcze nie doszli. Dowód? Według każdej metody pracy na EA, pierwszym krokiem prac (lub jednym z pierwszych) jest ustalenie docelowego stanu architektury, którą organizacja będzie w trudzie i znoju tworzyć przez lata. Ta architektura ma podobno wspierać biznes – jak więc opracować wsparcie bez precyzyjnej, udokumentowanej wizji działania biznesu za kilka lat? Ale właśnie tej wizji biznesu nie ma i nie będzie – takie są właśnie warunki działania biznesu. Wyśnione, wymarzone TO-BE nie istnieje. Celem nie jest punkt w przestrzeni, tylko zdolność do dopasowania. Metody pracy na EA są więc przestarzałe – nie jest jednak przestarzałe EA, jako przedmiot prac.

Gdybym włożył czapkę metodyka od EA, uznałbym, że EA musi skupić się bardziej na AS-IS, uporządkowanym i dobrze zrozumiałym oraz na operacyjnej zdolności do wykonywania korekt w tymże AS-IS. Metody pracy na EA powinny organizować zdolność szybkiego, niskokosztowego korygowania bieżącego stanu tak, aby „amortyzować” zachodzące zmiany. Nie chcę jednak wchodzić w drogę metodykom, więc na tej wskazówce poprzestanę – w zamian skupię się na przedmiocie prac oraz tym, jak uzyskać w nim cechy wymagane przez współczesny biznes.

No więc właśnie – dopasowanie, adaptacja, korekty kursu. Przyroda zna bardzo skuteczne metody działania w tej sferze – podlega procesom ewolucji. Procesy te opierają się jednak na możliwościach działania w skali czasu niedostępnych współczesnemu biznesowi. W tej skali wymaganie dopasowania wsparcia informatycznego do zachodzących zmian wymusza zaprzęgniecie do pracy świadomości i inteligencji – wymaga udziału człowieka, jednak nie w tradycyjnie pasywnym trybie „użytkownika IT”, wykonawcy zadań przewidzianych przez twórców systemów, ale aktywnym trybie zmieniającego reguły gry, nawet poza te, które przewidzieli projektanci systemów. Żadna architektura nie będzie miała zdolności autodopasowania, jeśli ludzie i organizacja nie będą częścią mechanizmu dopasowania. Dopasowanie jest realizowane przez ludzi, a nie systemy informatyczne. Celem działania IT powinno być dostarczenie takich rozwiązań, które dawałyby możliwość wykorzystania ich na wile sposobów, wykraczających poza „przesztywnione”, przewidziane wcześniej schematy. Informatyka powinna się skupić na narzędziach mogących być różnie użytych bez konieczności wprowadzania zmian w ich konstrukcji oraz na ułatwieniu przejścia przez proces dopasowania. Informatyka nie zapewni dopasowania – to jest zdolność człowieka.

Czy takie narzędzia mogą być dostępne? Oczywiście, że tak – choćby dla siebie potrafimy takie tworzyć. My, technole, namiętnie używamy command line i skryptów. Nie ma takiej rzeczy, której nie dałoby się zrealizować pisząc skrypt powłoki systemu Unix. Wymaga wiedzy i szkoleń? Bez wątpienia. Ale to bardzo dobry przykład doskonale zwinnego, adaptacyjnego podejścia do budowy rozwiązań otwartych na przyszłe, nieprzewidziane wykorzystania. Inny przykład, znów z naszego podwórka, to zakres zmian, jakie można wprowadzić do sposobu działania systemu informatycznego działając na jego parametrach konfiguracyjnych. Dobry admin potrafi robić cuda z systemem, choć nie jest jego twórcą. Taka charakterystyka to także przejaw zdolności dostosowania.

Oczywiście, wielkie możliwości to wielka odpowiedzialność a niewiele jest w nas wiary w „użyszkodników”. Po części ten brak wiary jest uzasadniony, ale – po części – sami przyzwyczailiśmy ich do braku odpowiedzialności za skutki ich działań oraz że każdy ich błąd jakoś tam naprawimy. Tak, jakbyśmy traktowali ich jak dzieci. Każdy świadomy rodzic potwierdziłby, że pozwolenie na nieodczuwanie konsekwencji swoich czynów to poważny błąd wychowawczy. Mamy traktować biznes jak partnerów, więc nie traktujmy ich jak dzieci – z blaskami i cieniami tego postanowienia. W sumie to oni zarabiają na te wszystkie nasze zabawki, a potrzebują jedynie narzędzi i możliwości świadomego ich używania.

Pozostaw komentarz