Agile i EA - wrogowie czy przyjaciele?
W wielu rozmowach, które ostatnio przeprowadziłem nt. wdrożenia zarządzania architekturą korporacyjną w organizacjach pojawia się szczególnie często jeden wątek – EA nie jest dobrym pomysłem na czasy kryzysu, teraz liczy się agile – czyli szybkie dostarczenie rezultatu biznesowego do organizacji. Zestawienie tych dwóch koncepcji (tj. architektury korporacyjnej i agile) w przeciwległych narożnikach “ringu bokserskiego” nie wydaje się chyba jednak dobrym pomysłem. Każe z tych podejść ma bowiem silne i słabe strony.
Oczywiście mam świadomość tego, że rezultaty z wdrożenia podejścia architektonicznego są odroczone w czasie (na pewno nie należy liczyć na zwrot z inwestycji w przeciągu 9-12 miesięcy), że często stanowią one jedynie “korzyść pośrednią” z punktu widzenia departamentów/pionów biznesowych (taką jak np.: zmniejszenie złożoności środowiska IT, poprawę stopnia interoperacyjności, itp. – a biznes chce “tu i teraz” działających systemów, ułatwiających osiągnięcie jego celów – często rozliczanych w trybie rocznym), wreszcie że bardzo trudno jest policzyć w wiarygodny sposób business case dla wdrożenia architektury korporacyjnej w organizacji (chociaż nie twierdzę, że się nie da).
Jednakże bez wdrożenia przynajmniej elementów zarządzania architekturą korporacyjną niezwykle trudno będzie zapanować nad złożonymi przedsięwzięciami transformacyjnymi czy też w wiarygodny sposób przygotować operacjonalizację strategii biznesowej organizacji.
Z drugiej strony nieporozumieniem dla mniej jest wskazywanie, że agile jest kryzysem na całe zło (czytaj: dotychczasowe nieefektywne funkcjonowanie działu IT w organizacji, który nie mógł poradzić sobie z dostarczaniem biznesu na czas do określonych rozwiązań informatycznych) – a taki sposób myślenia bardzo często teraz występuje. Ale jak najbardziej na miejscu jest stwierdzenie, że chyba rzeczywiście czas “klasycznych” metodyk projektowych (takich jak Prince2) powoli odchodzi w przeszłość. W wielu projektach informatycznych ich miejsce będzie mógł zająć np. Scrum (ale sądzę, że część projektów w niektórych branżach – w szczególności tych, gdzie mamy do czynienia z życiem ludzkim – powinna być mimo wszystko realizowana według “klasycznego” podejścia projektowego).
W związku z tym jak można spojrzeć na te dwa podejścia – tj. zwinne i architektoniczne?. Ja proponuję traktować je jako koncepcje komplementarne. Tzn. architektura korporacyjna dostarcza “latarni morskiej” [w postacie wizji architektonicznej czy też architektury strategicznej] i dba o to, abyśmy poruszali się w ustalonym “korytarzu transportowym”, natomiast wybrana przez organizację metodyka zwinna (najczęściej Scrum) pozwala na efektywną realizację projektów, które pozwolą dotrzeć do ustalonej wcześniej “latarni morskiej”.
Proponuję także wykonać również następujące ćwiczenie myślowe: proszę się zastanowić co kryje się pod stwierdzeniem, że organizacja jest “agile”. Czy oznacza to, że jej pracownicy szybko adaptują się do nowych wyzwań/przedsięwzięć realizowanych wewnątrz organizacji? Czy oznacza to, że projekty są prowadzone w “zwinny” sposób? Czy wreszcie oznacza to, że organizacja posiada tak skonstruowane środowiska IT (nie pojedyncze systemy, ale zbiory systemów) i tak zdefiniowane procesy, że bardzo szybko jest w stanie “zaabsorbować” nową zmianę (tj. rozwiązania informatyczne nie stanowią bariery we wprowadzeniu np. nowego produktu lub usługi).
Na bazie przeprowadzonych przez mnie dyskusji większość rozmówców “agile” utożsamia ze sposobem prowadzenia projektów. Ja jednak zadaję pytanie – świetnie projekty będą zrealizowane sprawnie, zakończą się sukcesem – tj. biznes będzie zadowolony, że dostał to co chciał na czas, w budżecie i zakresie ;), ale co dalej? Tj. w dużych organizacjach realizowanych jest naraz naście projektów. W ciągu roku ta liczba może zbliżać się do 20-30 przedsięwzięć. Jaki mechanizm organizacja wdrożyła, aby produkty projektów agile były ze sobą spójne, aby dało się je łatwo integrować, aby koszty ich utrzymania (TCO) nie rosły w zastraszającym tempie… I tutaj przydaje się właśnie zarządzania architekturą korporacyjną. Rozsądne wdrożone tej koncepcji pozwala bowiem osiągnąć i utrzymać “zwinność” organizacji (na poziomie biznesowym i IT) – w średnio i długookresowej perspektywie. Tego nie zapewnią rozwiązania budowane przy pomocy “zwinnej metodyki” (bo są one nastawione na osiąganie krótkookresowych celów).
Komentarze do wpisu
Ja z uporem maniaka, gdy słyszę agile, zadaje pytanie: czym jest agile w tym projekcie, jak brzmi definicja tego pojęcia? I najtwardsi obrońcy kończą na ogólnikach. Co do okresu zwrotu, hm... zaryzykuje tezę, że żaden większy projekt nie ma szansy zwrotu w okresie krótszym niż rok. Moim zdaniem architektura korporacyjna nie musi być odrębnym projektem. Jeżeli potraktować każdą, metodycznie prowadzoną, analizę wymagań, jako kolejną cegiełkę budowania architektury korporacyjnej, to ma szansę zwrócić się relatywnie szybko bo już w pierwszym projekcie.
Dodaj komentarz