W dzisiejszym świecie szybko zmieniających się wymagań w stosunku do aplikacji, teoria Darwina o przetrwaniu najlepszych ma fatalne konsekwencje dla informatyków.

Aplikacja do obsługi działalności gospodarczej jest tak długo dobra, jak długo zmienia się wraz z nowymi warunkami działalności, wymaganiami klientów, zmianami organizacyjnymi. Wiele firm zainwestowało duże zasoby finansowe w stworzenie solidnej architektury swoich rozwiązań architektonicznych w złudnym przekonaniu, że stworzy im ona warunki do szybkiego przystosowania aplikacji do nowych wymagań. Wprawdzie stosunkowo łatwo przenosi się aplikacje na nowe platformy systemowe, ale nie oznacza to bynajmniej równie dużej elastyczności w dostosowywaniu aplikacji.

Architektura aplikacji klient/serwer

Rozwiązania architektoniczne współczesnych aplikacji działających pod Unixem i Windows NT to projekty dwu- (serwer bazy danych, programy na stacji klienta) lub trójwarstwowe (serwer bazy danych, programy na stacji klienta, specjalizowany serwer aplikacji), złożone z wielu powiązanych komponentów i programów. Każdy z tych elementów aplikacji może działać na różnych platformach systemowych i w różny sposób współpracuje z danymi w bazie.

Tak więc nawet mała modyfikacja bazy danych może mieć trudne do przewidzenia konsekwencje, jeśli chodzi o działanie aplikacji. Przystosowanie jej do zmieniających się warunków działania przedsiębiorstwa wymaga szczegółowego poznania struktury i ogromnego nakładu pracy. Stąd często spotykane powiedzenie szefów informatyki: "Jeśli aplikacja nie padła, nie poprawiać jej!"

Praktyczne możliwości modyfikacji aplikacji mają jedynie ci analitycy, projektanci i programiści, którzy ją stworzyli. Nie jest jednak łatwo utrzymać wciąż ten sam zespół przez czas trwania aplikacji. Tymczasem rzeczywistość wymaga jej zmiany i to na ogół szybko. Firmy, którym uda się zastosować skuteczne techniki ewolucji aplikacji do zmieniających się potrzeb i wymagań, osiągają przewagę nad konkurencją.

Ewolucja aplikacji

Aby móc radzić sobie ze zmieniającymi się wymaganiami, wiele firm stosuje podejście iteracyjne w ewolucji aplikacji, produkując wiele wersji, tylko nieznacznie różniących się od poprzednich; każda z nich to kolejny etap zbliżający produkt do wymagań użytkownika. Jeżeli w jakimś momencie pojawią się niezgodności lub system się załamuje, wystarczy wrócić do poprzedniej wersji, działającej poprawnie.

Przejście do kolejnej wersji wymaga wykonania trzech etapów: zrozumienia aplikacji, określenia wpływu, jaki na działanie aplikacji będą miały proponowane zmiany, i dokonania zmian.

Zrozumieć aplikację klient/serwer

Podstawą dowolnej modyfikacji aplikacji jest zrozumienie skomplikowanych zależności między poszczególnymi obiektami aplikacji, zarówno na stacji klienta, serwerze aplikacji, jak i w bazie danych. Zwykle jest to utrudnione przez braki w dokumentacji, brak lub nieaktualny model logiczny aplikacji i bazy danych, nieobecność osób tworzących aplikację itp.

Średniej wielkości aplikacja klient/serwer zawiera ok. 3 tys. obiektów (tabel w bazie danych, indeksów, trygerów, zapamiętanych procedur, modułów funkcyjnych w programie, ekranów klienckich, in.), ściśle powiązanych zależnościami, które trudno jest skontrolować i zrozumieć na podstawie kodu źródłowego i dokumentacji.

Zmierzyć wpływ zmian

Poprawna ewolucja projektu wymaga określenia wpływu proponowanych zmian na działanie innych elementów aplikacji, bezpośrednio powiązanych ze zmienianymi elementami. Ponieważ nigdy nie ma pewności, które będą wymagały zmiany, nie można nawet zgrubnie ocenić pracochłonności projektu. Efekty uboczne ujawnią się w postaci błędów podczas testowania zmienionej aplikacji lub - co gorsza - dopiero w produkcji.

Dla zrozumienia wpływu postulowanych zmian w aplikacji konieczne jest poznanie działania każdego jej elementu, co jest tym trudniejsze, im większa aplikacja. W efekcie w wielu przypadkach stosuje się raczej metodę "prób i błędów", mimo że wymaga to ogromnego wysiłku przy testowaniu aplikacji.