(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.