Kiedy świadomość architektoniczna umiera

Kwiecień 14, 2012

Rozbudzanie świadomości architektonicznej rozumianej, jako myślenie w kategoriach architektonicznych w społeczności całego przedsiębiorstwa  i z uszanowaniem złożoności architektonicznej firmy, może  przebiegać tylko w jedną stronę – ku coraz większej świadomości… Nic bardziej błędnego. Świadomość architektoniczna, jak również inne aspekty leżące w gestii odpowiedzialności architektury korporacyjnej są kruche, bo niewłaściwie pielęgnowane i nie wzmacniane kruszeją i rozpadają się.  W przedsiębiorstwie, które próbuje budować świadomą i dobrze zestrojoną organizację bez uwzględnienia, którejkolwiek z warstw społecznych naraża się na możliwość zburzenia wszystkiego co próbowano misternie zbudować miesiącami, czy raczej latami.

Wezmę pod uwagę najczęstszy przykład możliwości zaistnienienia takiej sytuacji. Załóżmy, że w ramach warstwy aplikacji udało się zbudować dość dobry model operacji, jak również dostarczyć dojrzałą architekturę warstw aplikacji i infrastruktury. Ta dojrzałość architektoniczna przełożyła się na wzrost możliwości IT i gotowości do zmian.  Udało się m.in. znacząco zwiększyć elastyczność łańcucha wartości.  Odpowiedzialni za IT,  chociaż nie wszyscy, zrozumieli już dawno, że aby dostarczać wartość należy uporządkować własny ogródek i zacząć wspierać firmę w podobny i powtarzalny sposób. Ponieważ możliwości IT były coraz większe strona biznesowa zaczęła żądać coraz więcej. Oczekiwała pełnej gotowości do realizacji zmian. Gotowość taka była. Złożoność architektoniczna poprzez realizację nawet najdziwniejszych wymagań wzrastała. W pewnym momencie okazało się, że wymagań biznesu realizować już się nie da.  Koszty rozwoju wzrosły radykalnie. Z uwagi na skalę i złożoność musiała również wzrosnąć liczba mechanizmów scalających, np. punkty kontroli.  Liczba negatywnych wyników kontroli projektów wzrastała. Niektóre były respektowane pozostała większość nie. Atmosfera zaczęła się psuć. Przedstawiciele strony biznesowej zaczęli postrzegać IT, jako największego sprawcę niepowodzeń projektów.

Niektórzy w samym IT przyczyn tego stanu zaczęli upatrywać w liczbie punktów kontroli, które zaczęto utożsamiać z niepotrzebną biurokracją a przez to większymi kosztami i wydłużeniem czasu realizacji.  Inni twierdzili, że problem polega na tym, że wymagań jest za wiele i są niespójne, a przez to zbyt wiele niepotrzebnej energii traci się na kolejnych etapach: weryfikacjach, kontrolach i próbach zrozumienia wartości biznesowej samych projektów. Bo, że każdy z projektów był  najważniejszy i konieczny nie podlegało żadnej dyskusji w rozmowach z właścicielami wymagań.  Tak zwani „antybiurokraci”, czyli osoby upatrujące przyczyn w według nich niepotrzebnych kontrolach  stwierdzili, że lata temu było prościej. Projekty realizowały się szybko i sprawnie. Nie było zasad architektonicznych, punktów kontroli,  itd.  Zaczęto z tęsknotą wspominać te dobre, proste czasy. Stwierdzono, że do podobnego modelu pracy w IT należy powrócić. Mniej weryfikacji, mniej kontroli a „więcej i częściej”. Bo według tej ostatniej grupy rolą IT jest dostarczać wszystko, szybko i sprawnie.

Firma działała w nowych „zwinnym” modelu przez dwa lata. Po tym czasie nastąpił wielki kryzys, który narastał stopniowo zaczynając od i tak nieciekawego punktu startowego. Zaczęto zmieniać kolejnych przedstawicieli wyższego personelu zarządzającego. Zaczynając oczywiście od tego, który odpowiadał za IT. Sprawność spadała, złożoność urosła do granic niemożliwości jej zrozumienia. Zaczęto ponownie zastanawiać się nad przyczynami. O czym zapomniano i czego nie zrozumiano rok wcześniej? Przede wszystkim zabrakło świadomości i woli poprawy sytuacji w przedsiębiorstwie,  widzianym jako całość, jako jeden organizm. Zapomniano o tym,  że nie może być lepiej w całym przedsiębiorstwie, jeśli dzieje się nie najlepiej w jednej z warstw: warstwie biznesowej. W warstwie z nieuporządkowanymi procesami, niestabilnym modelem operacyjnym, lub jego braku, pośród społeczności  cechującej się niezrozumieniem tego,  że firma to całość, a nie tylko biznes.

Przedstawiony powyżej przykład jest dość jednostronny, tj. ukazuje „dobre” IT i „zły” biznes. Równie dobrze można ten sam przykład opisać odwracając role „złego” i „dobrego”. Proszę zauważyć również, że w opisanym przykładzie rolę „złego” odgrywali również niektórzy przedstawiciele IT – którzy, albo byli nieświadomi architektonicznie, albo mieli jakiś prywatny interes w tym, aby dokonać radykalnej zmiany.  W rzeczywistości rozpoznanie przyczyn nie jest wcale aż tak proste, a przyczyny często występują po jednej, jak i drugiej stronie. A oto kilka powodów, które mogły zaistnieć w przedsiębiorstwie znacznie wcześniej:

1. Organizacja optymalizowała jedynie komórki rozwojowe i procesy rozwojowe zapominając o strukturach i procesach biznesowych.

2. Organizacja traktowała wymagania biznesowe, jako wartość nadrzędną w stosunku do stabilności przedsiębiorstwa.

3. Architektura korporacyjna, jeśli istniała w przedsiębiorstwie, nie realizowała należycie podstawowych funkcji: edukowania, kontroli, wsparcia, wytwarzania.

4. Architektura korporacyjna, jeśli istniała w przedsiębiorstwie, była blokowana przez przedstawicieli „zwinnego” modelu realizacji każdego z wymagań.

5. IT nieustannie zmieniała (optymalizowała?)  swoje struktury i procesy podczas, gdy strona biznesowa reprezentowała niezmienne struktury i procesy (skostniała struktura?)

6. Zarządzający administrowali i żyli w przeświadczeniu, że nowoczesne przedsiębiorstwo to takie, w którym IT pełni rolę dostawczą i nie należy IT traktować jako równorzędnego interesariusza przedsiębiorstwa.

7. Brakowało mechanizmów scalających (kontrola, priorytetyzacja,…) po stronie biznesowej.

Maciej Leks