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

Not everyone must have a college degree and not everyone can be an architect

December 24, 2011

I have decided for a brief moment to move away from enterprise architecture and transfer into the field of solution architecture. Why? It is common to misunderstand not only the role of an enterprise architect but also the role of a solution architect.  People who fill these two roles must closely cooperate with each other. That is why, it is necessary to understand mutual responsibilities.

Seven basic guidelines for the enterprise architect

November 26, 2011

Guideline 1. Don’t create architectures for the sake of creating

Even if you have the best architectural idea don’t sacrifice more time than the situation demands.  If you don’t find a strongly anchored representative in the organization, who can finance the idea and convince a broader group of people, abandon any further activities.  But make sure that the idea gets through to the organization. When the time is right, somebody will hopefully come back to it.

Identyfikowanie przypadków użycia poprzez cele użytkowników

April 24, 2010

Pewien zespół analityczny w ciągu miesiąca musiał zrealizować jeden z etapów projektu polegający na opisie funkcjonalności aplikacji przedsiębiorstwa z użyciem przypadków użycia. Wyniki prac tego etapu były konieczne do realizacji kolejnego etapu projektu. Projekt był realizowany w dużym przedsiębiorstwie państwowym o niepowtarzalnym charakterze działalności w skali kraju. Liczba aplikacji podlegająca opisowi była bardzo duża. Część zespołu analitycznego przed przystąpieniem do prac pracowała już na rzecz tego przedsiębiorstwa, dlatego znana im była działalność przedsiębiorstwa oraz ogólne funkcjonalności aplikacji podlegających opisowi.