RegułyChaosu

Od ponad dwóch dekad rozwiązuję zagadki ze świata informatyki praktycznej, sfery nazywanej w literaturze “Enterprise Information Systems”, posługując się warsztatem i narzędziami architekta. Wraz ze wzrostem doświadczenia rośnie we mnie przekonanie, że najważniejszą klasą narzędzi architekta są wzorce architektury, wszak po co za każdym razem na nowo wymyślać koło, skoro już wiemy, jak ma wyglądać? Z drugiej strony jednak stosowanie wzorców staje się coraz trudniejsze, wymaga coraz większego wysiłku, napotyka na coraz więcej przeszkód. Coś jest nie tak ze wzorcami? Problemy są tak specyficzne dla każdego przypadku? Myślę, że nie, a prawdziwa zagadka jest w nieco innym miejscu.

Umysł architekta pracuje inaczej. Jest wrażliwy na schematy i wzorce. Praca architekta opiera się często na zasadach, tzw. pryncypiach (Architecture Principles). Jakimi pryncypiami powinien kierować się architekt tworząc zwinną architekturę (Agile Architecture)?

Wiele uwagi poświęcono miarom stosowanym dla oceny sprawności działania procesów wytwórczych opartych na zwinnym podejściu do tworzenia oprogramowania. Od jakości kodu, przez satysfakcję użytkowników, po zadowolenie każdego z członków zespołu i prędkość działania zespołu jako całości. W jaki sposób zmierzyć jednak zwinność w architekturze? Bo jak nie zmierzymy, nie uwierzymy…

Jest takie branżowa prawda: aplikacje się zmieniają, dane pozostają. Dane – ich modelowanie, sposoby przetwarzania i składowania – mają już najdłuższą historię. Wszak to, co robimy, IT (Information Technology) to praktyka przetwarzania informacji. Tym niemniej, jak pokazuje praktyka, kiedy po raz pierwszy wprowadzimy do jakiegoś systemu określoną strukturę danych, nie tylko pozostaje ona taką samą, ale jeszcze ma tendencje do „infekowania” sobą wszystkiego dookoła. W takich warunkach dopasowanie jest co najmniej trudne – warunki antyzwinności.

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.