Przez dziesięciolecia rozwoju metodologii i metodyk zarządzania projektami IT mówiliśmy o "permanentnym kryzysie" tej branży. Dodajmy, że pojęcie "metodologia" odnosi się do nauk o metodach, natomiast "metodyka" ma wymiar bardziej praktyczny i oznacza standaryzowane zarządzanie projektami. W tym ostatnim przypadku mówimy zatem o modelach referencyjnych ładu korporacyjnego (IT Governance). Ich powstanie wiąże się z genezą samej inżynierii software’owej (SE, software engineering) jako odpowiedzi na problemy zidentyfikowane podczas pamiętnej konferencji NATO w Garmisch-Partenkirchen (1968 r.). Postanowiono wówczas, aby projektowanie oprogramowania wyodrębnić jako samodzielną dziedzinę inżynierii. Od tego postulatu minęło wiele lat. Z jaką sytuacją mamy do czynienia dziś?

Warto tu wskazać na cyklicznie przygotowywane opracowania o wymownej nazwie "Chaos-Report" autorstwa amerykańskiego gremium badawczego - Standish Group Inc. Jej badacze przeanalizowali od 1994 roku kilkadziesiąt tysięcy (!) projektów informatycznych, dzieląc je na grupy:

- sukcesu (successful) - projekt zakończono i wdrożono zgodnie z założeniami;

- porażki (failed) - projekt przerwany lub niewdrożony;

- wątpliwości (challenged) - projekt zakończono i wdrożono, nie zachowując założonych ram finansowych, czasowych bądź jakościowych.

Wieloletnie statystyki dają zgrubnie trójdzielny obraz: w każdej kategorii znajduje się około 1/3 projektów. Choć w określonych latach udział poszczególnych grup waha się nawet o 10 punktów procentowych. Niezależnie jednak od szczegółów, podstawowy wniosek jest jednoznaczny: większość projektów IT nie kończy się pełnym sukcesem.

Na twardo i na miękko

Cytowane raporty są też podważane, a ich krytycy twierdzą, że "tak źle to nie jest“. Dotykamy tu z jednej strony interpretacji danych źródłowych, a z drugiej strony ich wiarygodności i reprezentatywności. Trzeba bowiem pamiętać, że sfera biznesowa, z naturalnych i akceptowalnych powodów, nie jest całkowicie demokratyczna i otwarta. Firmy niechętnie ujawniają dane, które mogą negatywnie wpływać na ich wizerunek. Mają także prawo do swoich tajemnic gospodarczych. Również wewnątrz przedsiębiorstw zdarzają się arbitralne oświadczenia typu: "właśnie z sukcesem zakończyliśmy projekt wdrożeniowy, kropka". I to wbrew użytkownikom, którzy na postawienie kropki akurat jeszcze nie mają ochoty.

Najważniejsza w praktyce jest jednak świadomość rodzajów ryzyka projektowego i możliwości ich zmniejszania. Istotne wskazówki w tym kontekście znajdzie Czytelnik na naszych łamach w poświęconemu inżynierii wymagań artykule Bogdana Berezy "Procedury chronią przed skutkami błędów" (Computerworld nr 33, 20 listopada 2012). Dodajmy, że referencyjne metody zarządzania projektami dają podzielić się na dwie grupy: "twarde" i "miękkie".

Pierwsze z nich mają charakter już klasyczny (są dłużej znane) i w znacznej mierze zarządczy, tj. bardziej koncentrują się na procesach decyzyjnych niż na kwestiach technicznych. Przykładami takich modeli postępowania mogą być: PMBoK (Project Management Body of Knowledge) czy Prince2 (Projects in Controlled Environments). Z kolei modele organizacyjne nakierowane są na szczegóły optymalizacji procesów zarządzania przedsiębiorstwa. Przykładem takiej metodyki może być COBIT (Control Objectives for Information and Related Technology).

Inny model referencyjny chętnie stosowany w sferze informatycznej to ITIL (IT Infrastructure Library). Jego istotą jest traktowanie działu IT jako dostawcy określonych usług dla tzw. klientów wewnętrznych, czyli innych sfer przedsiębiorstwa.

Trzeci poziom metodyk referencyjnych uzupełniają podejścia narzędziowe, to znaczy nakierowane na wytwarzanie produktów software’owych, np. RUP (Rational Unified Process) czy MSF (Microsoft Solutions Framework).

Matka wszystkich migracji

Widzimy zatem, że teoria i praktyka inżynierii software’owej wypracowały szereg podejść umożliwiających referencyjną budowę "software’owych domów". Posługując się dalej metaforami architektonicznymi, można powiedzieć, że te domy w przeszłości często budowano "na gołej ziemi" i było znacznie mniej "przeprowadzek“.

Owszem, każdy system informatyczny podlega modyfikacjom, ale dziś mamy do czynienia ze światem globalnej i dynamicznej gospodarki, w której zmiany są jeszcze szybsze. Fuzje i podziały w ramach dużych i wielkich firm są na porządku dziennym, a to oznacza automatycznie wymuszane zmiany także u tych średnich i mniejszych. W przeszłości, np. podczas przechodzenia od tradycyjnych systemów księgowania do wspomaganych komputerowo, istniała możliwość elastycznego kształtowania ich baz danych (w ramach dostępnych technologii). Tymczasem kolejne wersje systemów informatycznych są zależne od poprzednich, a jednocześnie wzrasta ich złożoność, co czyni modyfikacje trudniejszymi.

Szczególnym wyzwaniem projektowym są migracje. Łączą się one z problematyką integracji systemów. Nie zawsze jest tak, że jeden dominujący system może całkowicie narzucić swoją logikę funkcjonowania innemu. Wówczas stajemy przed problemem typu: jak z dwóch mniejszych traktorów zrobić jeden większy. Tyle że pierwszy z tych pojazdów wyprodukowano w systemie metrycznym, a drugi w calowym. Cóż z tego, że każdą z integrowanych aplikacji zaprojektowano referencyjnie, skoro w żadnej nie uwzględniono wyzwań, jakie pojawiają się w trakcie migracji. Działają znakomicie jako odrębne, ale podczas ich łączenia pojawią się nieuwzględnione wcześniej problemy.

Rozważmy to na przykładzie "matki wszelkich migracji", czyli bazy danych artykułów przedsiębiorstwa. Zawiera ona informacje o wyrobach gotowych, półproduktach, surowcach, a także specjalne dane materiałowe, np. techniczne, magazynowe, narzędziowe czy transportowe. Sposoby kodowania tych danych są różnorodne. W szczególności można to robić neutralnie, tzn. numerując produkty zgodnie z ich pojawianiem się w systemie (kreowanie). Rozpowszechnione są także metody specyficzne dla danej firmy, czyli usiłujące zawrzeć w kodzie produktu jak najwięcej informacji o nim. Zamiast niewiele mówiącego numeru 199861 pojawia się np. kombinacja liter KDTDH oznaczająca "krem do twarzy dzienny, hialuronowy". Zapamiętać łatwiej, migrować trudniej.

Prędzej czy później mogą nam także wyczerpać się kombinacje literowe, bo programy to nie tylko dane, ale także algorytmy je przetwarzające. Podczas analizy interfejsów okazuje się, że istniejące pola są numeryczne, a nie alfanumeryczne, że są za krótkie i jest ich za mało. A to, o czym mówimy, to nie żartobliwe cytaty praw Murphy’ego, ale migracyjne realia. Lecz nawet jednolicie projektowane systemy kodowania mogą się "przeciąć" i wymagają eliminacji dubletów, czyli zdefiniowania strategii mapowań migracyjnych. Przykładowo: zmiany numerów surowców pociągają za sobą zmiany list części, w których występują, czy też danych kontraktowych dla ich dostawców.

Migracje globalne

Ideałem byłoby zatem takie projektowanie systemów, aby były nie tylko skalowalne, ale także migrowalne, i to na skalę globalną. W rozważanym przykładzie z obszaru danych migracyjnych mamy już zręby takich rozwiązań. Wystarczy wskazać chociażby na kody GTIN (Global Trade Item Number). Przedsiębiorstwa jednak nie traktują ich jako jednoznacznych kluczy w bazie danych artykułów, posługując się krótszymi kodami.

Tymczasem badania gremium Bloor Research z roku 2007 wykazały, że aż 84% projektów o charakterze migracyjnym nie kończy się sukcesem. Przedsiębiorstwa zaczęły jednak w ostatnich latach odrabiać lekcje - badania powtórzono w roku 2011 i negatywny współczynnik zmalał do 38%. Proporcje zatem uległy odwróceniu - niemal 2/3 projektów migracyjnych zakończono z powodzeniem. Postęp jest wyraźny, niemniej nadal pozostaje 1/3 projektów nieudanych. Warto zatem przyjrzeć się zmianom strategii migracyjnych, jakie wystąpiły w badanych firmach (zob. tabelę).

Widać wyraźny wzrost stosowania metodyk skojarzonych z migracyjnymi procesami ETL (Extraction, Transformation, Loading), tj. pozyskiwania, modyfikacji i przenoszenia danych. W pierwszym kroku prowadzimy analizę danych dla zrozumienia ich logiki i źródeł oraz profilujemy je statystycznie z uwzględnieniem ich jakości. Potem następuje czyszczenie danych, co w wielu wypadkach wymaga czasochłonnych działań ręcznych, czyli niezautomatyzowanych. I wreszcie procesy eksportu/importu danych niezbędne dla ich ładowania: jednorazowego, inkrementalnego czy w trybie równoległej pracy różnych systemów.

W każdym przypadku należy także pamiętać o zdefiniowaniu procedur pielęgnacji danych (maintenance) dla zagwarantowania utrzymania ich jakości (monitoring).