RegułyChaosu

Pracuję ostatnio dla firmy, która nie tyle potrzebuje cyfrowej transformacji, co błaga o nią. Firmy, choć mają osobowość prawną, nie mają jednak prawa głosu w podejmowaniu decyzji o jej losach – robią to ludzie pracujący dla takie firmy. Przyglądałem się nieco mechanizmom gaszenia potrzeb firm.

No dobrze, może trochę przesadziłem z tym odkrywaniem. Ale tylko trochę. Prowadziłem niedawno kilka wystąpień o tematyce nawiązującej do zwinności w architekturze. Poza innymi ciekawymi dyskusjami często wracaliśmy także do zagadnień SOA. Kilka myśli cieszyło się szczególnym powodzeniem.

Imperatyw dopasowania w sferze rozwoju oprogramowania zmaterializował się w postaci zwinnych metod rozwoju oprogramowania. W sferze architektury IT zwinność sięgać musi znacznie dalej – powinna objawiać się niezależnie od procesów rozwoju oprogramowania. Chodzi wszak o to, żeby nie trzeba było uruchamiać zwinnego projektu, żeby w pośredni sposób uzyskać zwinność – powinna być ona wbudowana w reguły konstrukcji rozwiązań tak, aby istnieć niezależnie od procesów rozwoju oprogramowania.

Termin „agile” zrobił zawrotną karierę. Już nie tylko proces wytwórczy oprogramowania jest zwinny – zwinne są także projekty, nawet bez komponentu informatycznego. W praktyce jednak znaczenie tego terminu jest wypaczone, wręcz wykoślawione aż do granic karykatury. Kiedy słyszę „nasz projekt robimy w trybie agile” to już wiem, że w projekcie nie do końca znany jest cel, a jego zakres jest mglisty nawet dla największych optymistów. Chciałbym, aby architekturę nie spotkał ten sam los „zwinności” karykaturalnej.

Podstawą Agile Architecture jest zdolność do użycia rozwiązania lub komponentu na nowe sposoby, nie przewidziane podczas projektowania takiego rozwiązania czy komponentu. Brzmi prawie jak herezja inżynierska – wszak informatyka to nie magiczna różdżka zmieniająca coś bez zmieniania. Jak więc uzyskać zdolność dopasowania rozwiązań informatycznych? Jak sprawić, aby architektura była naprawdę zwinna?

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.

Przez lata spędzone w bardzo różnych organizacjach przyglądałem się sposobom działania ludzi, którzy na wizytówkach mieli napisane Architekt Korporacyjny (Enterprise Architect). Patrząc na poczynania takich ludzi – nie wszystkich, ale jednak znakomitej większości – można byłoby uznać, że EA (Enterprise Architecture) jest martwe, a podtrzymywanie EA przy życiu doprowadzi do Apokalipsy Zombie. W rzeczywistości jednak nie EA jest złe – to „metodycy od EA” sprowadzają na EA apokalipsę.

Ostatnio zdarzyło mi się przeprowadzić filozoficzną dysputę o wartości Enterprise Architecture. Nasza dysputa dość szybko przeszła w stadium zderzenia przekonań i skończyło się awanturą. Od kilku już lat wiadomo, że EA nie spełnia obietnic. Po ostatniej dyspucie już wiem, dlaczego.