RegułyChaosu

W ramach marketingu terminu „cyfrowa transformacja” pierwsze skrzypce grają firmy technologiczne, opowiadając jak to wiele można zrobić takim, czy innym narzędziem. Zupełnie nie o narzędzia to chodzi. Bez wątpienia, w Digital Transformation jest dużo Digital, ale – nawet jeśli potężne – Digital to tylko narzędzie, a nie cel.

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

W ramach przygotowań do OSAKA 2016 podjąłem dyskusję o wartości architektury korporacyjnej. Kolega po fachu poddał ciekawą myśl, że EA powstało w czasach, kiedy strategia IT była wyznaczana na 5 lat lub więcej, a współcześnie jakoś nie sposób tak daleko „strategować”, przez co EA jakby traci na sensowności. Czy aby na pewno?

Od kilku miesięcy krążą po Internecie grafiki prezentujące oszczędności wynikające z przeniesienia systemów „do chmury”. Szczególnie LinkedIn obfituje w takie rewelacje, a wizualizacje przedstawiają się cudnie, prawda? Próbowałem się dowiedzieć od publikujących, na czym budują ten optymistyczny obraz świata, ale – poza zdawkowymi, ogólnikowymi odpowiedziami – żadnych konkretów nie uzyskałem. Spróbowałem więc podsumować to, co dotychczas wiem.

Od pewnego czasu nawet w tzw. mainstreamowych publikacjach na temat IT pojawiają się wypowiedzi sugerujące, że czasy opłacalności budowy systemów na miarę minęły bezpowrotnie. Dzisiaj to wykorzystanie istniejących rozwiązań tworzy przewagę konkurencyjną, nie zaś budowa „doskonale dopasowanych do potrzeb” systemów. Kilka lat temu krytyczna publikacja “IT Doesn’t Matter” (Nicholas G. Carr) wzbudziła „święte oburzenie” i wywołała długą dyskusję. Po kilku latach wygląda jednak na to, że miał on rację.