Osobowe zależności

Częściej jednak mamy do czynienia z generowaniem indywidualnego oprogramowania, które wydaje się być tańsze krótkoterminowo, "bo nasz programista nic nie kosztuje". W dłuższej perspektywie grozi jednak ślepą uliczką rozwojową, stając się coraz mniej efektywne. Postawione zatem wcześniej pytanie o standard można więc skonfrontować z dwoma kryteriami:

- czy zakupiony i zmodyfikowany standard można migrować do nowszych wersji, oferowanych przez jego dostawcę?

- czy nasze oprogramowanie nie jest zależne od jednej osoby?

W pierwszym przypadku mówimy o granicy modyfikowalności standardu, a więc wyspecyfikowaniu tego, co możemy zrobić bez utraty kompatybilności z jego przyszłymi wersjami. Taka utrata to dodatkowe koszty migracyjne. A przecież w umowach serwisowych, za które płacimy, występuje składnik opcji przechodzenia do nowszego oprogramowania. Z drugiej strony, rozbudowane oprogramowanie, zależne od jednej osoby, funkcjonuje tak naprawdę tylko tak długo, jak długo jest przez tą osobę pielęgnowane (maintenance). I nie mówimy tu o pojedynczych programach, które w najgorszym przypadku można szybko napisać na nowo, ale o złożonych a słabo dokumentowanych aplikacjach, składających się z dziesiątków powiązanych programów (np. zarządzających planowaniem produkcji), rozrastających się stopniowo przez całe lata.

Na co zatem możemy pozwolić naszym programistom? Dotykamy tu kwestii granic outsourcingu, a więc pytania: czego nie należy delegować na zewnątrz? Zgrubna odpowiedź brzmi: tego co jest krytyczne dla firmy, względnie tego w czym firma ma tak wysokie kompetencje, że sama mogłaby świadczyć innym usługi. Zasada ta działa także w druga stronę, a więc możemy zapytać: czy jako firma przemysłowa jesteśmy w stanie tworzyć profesjonalne oprogramowanie zarządzania produkcją, czy lepiej powierzyć to zadanie firmom, dla których jest ono chlebem powszednim.

Standardy językowe

Musimy przy tym pamiętać, że niezależnie od tego, czy parametryzujemy standardy, czy też generujemy całkowicie własne rozwiązania, mamy do czynienia z nowym projektem. A każdy nowy projekt informatyczny jest nowym wyzwaniem i ryzykiem, a jego indywidualność przeważa z reguły nad elementami typowości. Nasuwa się tu nieodparcie skojarzenie z modelem deterministycznego chaosu. Tym bardziej nieprzypadkowe, że dotyczy ono systemów złożonych, a takowymi są właśnie systemy informatyczne, gdzie "wszystko jest powiązane ze wszystkim". Tym różni się świat informacji od świata materialnego.

Dlatego łatwiej w ciągu kilku miesięcy planowo zbudować wykończony dom i w nim zamieszkać niż planowo skonstruować system informatyczny. W budownictwie nikomu nie przyszłoby do głowy dobudowywanie zapomnianej piwnicy na strychu. W informatyce zdarzają się tego typu żądania, motywowane brakiem świadomości, jak duże mogą być koszty takich zmian. Kolejną kwestią jest analogowość wymiaru materialnego (przynajmniej w makroświecie) i dyskretność (cyfrowość) narzędzi informatycznych i ich tworów. Wprawdzie wzbogacamy się o programy korzystające z logiki rozmytej (fuzzy logic), niemniej nadal dominującym jest paradygmat zero-jedynkowy. A to oznacza zmniejszoną, w relacji do świata analogowego, elastyczność. Jeden znak postawiony lub opuszczony w programie może być przyczyną, dosłownie, katastrofalnych skutków. Błąd konwersji 64-bitowej liczby zmiennoprzecinkowej na 16-bitową liczbę całkowitą wstrząsnął dżunglą francuskiej Gujany podczas eksplozji rakiety Ariane V z czterema satelitami na pokładzie. Koszt błędu: miliard euro.

I wreszcie rzecz najważniejsza: syndrom wieży Babel. Projekt informatyczny jest z definicji interdyscyplinarny. Informacja ma charakter dyfuzyjny i jako czynnik integrujący wiąże swoim przepływem inne obszary projektowe. To z kolei oznacza konieczność współpracy specjalistów z różnych dziedzin. Ci zaś mówią o tych samych sprawach różnymi językami. Z punktu widzenia informatyka wygląda to tak, że użytkownik nie bardzo wie, czego chce, ale za to, po wdrożeniu projektu, bardzo dokładnie wie... czego nie chce. Tymczasem standardy informatyczne tworzą także terminologiczne standardy komunikowania się, a więc wymuszają posługiwanie się określonym językiem modelowania przedsiębiorstwa.