RegułyChaosu

Jestem fanem zwinności – nie tylko w rozwoju oprogramowania, ale w zarządzaniu projektami, a przede wszystkim w architekturze rozwiązań informatycznych, na każdym poziomie. Rozumiem jednak także ograniczenia podejścia agile. Wdrażając podejście zwinne w nieprzygotowanym środowisku nie tylko dramatycznie obniża szanse na sukces, ale także deprecjonuje to podejście i na dłuższy czas tworzy konotację agile = porażka. Zanim więc wybierzesz podejście zwinne upewnij się, że środowisko działania ma szanse je przyjąć i wspierać. Jak to zrobić?

Naturalnie, mam na myśli architekta w sferze ICT, ale bardzo podoba mi się analogia z branż dojrzałych i stabilnych, np. budownictwa. Kiedy postanawiasz wybudować dom, nie ma wątpliwości, szukasz architekta, a nie „analityka”, „projektanta” czy developera. Każdy, kto budował dom lub wykańczał mieszkanie czuje dlaczego. To odczucie jest bardzo adekwatne także dla sfery ICT.

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.

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…

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.

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.