(Polski) Kiedy świadomość architektoniczna umiera

April 14, 2012

Rozbudzanie świadomości architektonicznej rozumianej tu, jako myślenie w kategoriach architektonicznych  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ść, jak również inne aspekty leżące w gestii odpowiedzialności AK są tak kruche,  jak faktycznie krucha jest świadomość, którą budują.  W przedsiębiorstwie, które buduje ś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, lub latami.

Weźmy najczęstszy przykład takiej sytuacji w ujęciu dwóch warstw: biznesowej i aplikacji.  Załóżmy, że w ramach warstwy aplikacji udało się zbudować bardzo dobry model operacji, jak również dostarczyć dojrzałą architekturę warstw aplikacji i infrastruktury.  Ta dojrzałość przełożyła się na wzrost możliwości IT w zakresie oferowanych możliwości i gotowości do zmian.  Możliwe stało się radykalne zwiększenie łańcucha wartości.  Pracownicy IT zrozumieli już dawno, że aby dostarczać wartość należy uporządkować ogródek i zacząć wspierać firmę w podobny sposób. Ponieważ możliwości IT były coraz większe strona biznesowa oczekiwała coraz więcej. Oczekiwała pełnej gotowosci 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, .

Niektórzy przyczyny tego stanu zaczęli upatrywać liczbie niezbędnych punktów kontroli, które zaczęli utożsamiać z biurokracją .  Inni twierdzili, że problem polega na tym, że wymagań jest za wiele i są niespójne. Że każde z nich jest najważniejsze i że strona Biznesowa nie rozumie, “że wąskie gardło IT to nie problem IT a całej organizacji”. Tzw. “antybiurokraci” 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 w IT należy powrócić. Mniej weryfikacji, mniej kontroli a “więcej i częściej”. Bo według tych ostatnich rolą IT jest dostarczać wszystko, szybko i sprawnie.

Firma działała w nowych “zwinnym” modelu rok czasu. Po tym czasie nastąpił kryzys. Zmienił się jeden dyrektor. Kolejny,… i jeszcze kilku. Sprawność spadała, złożoność rosła. Zaczęto ponownie zastanawiać się nad przyczyną takiego stanu rzeczy. O czym zapomniano? Przede wszystkim o tym,  że nie może być lepiej w całym przedsiębiorstwie, jeśli jest źle w jednej z warstw: warstwie biznesowej. Warstwie z nieuporządkowanymi procesami, niestabilnym modelem operacyjnym, lub jego braku oraz nieustającym koncertem życzeń, który w pewnym momencie przestał w ogóle przypominać marsz ku lepszemu jutro.

Przyczyny:

1. Organizacja optymalizuje jedynie komórki rozwojowe i procesy rozwojowe zapominając o strukturach biznesowych.

2. Organizacja traktuje wymagania biznesowe, jako wartość nadrzędną w stosunku do stabilności.

3. AK nie realizuje podstawowych celów: kontroli, wsparcia, wytwarzania.

4. AK niewłaściwie osadzone w mechanizmach scalających, np. nie kontroluje projektów.

5. AK nie wspiera, a duma.

6. IT nieustannie zmienia swoje struktury podczas, gdy Biznes [...] – “puszczanie w eter sygnału ciągle się zmieniamy bo z nami jest coś nie tak”.

7. Brak pracy zgodnie z ideą – just enaough just in time.