Jak cię złapią, to znaczy, że oszukiwałeś. Jak nie, to znaczy, że posłużyłeś się odpowiednią taktyką.
doc
EWOLUCJA I DOJRZEWANIE ARCHITEKTURY — FUNKCJE A MOŻLIWOŚCI 31 Możliwości architektury czy dynamika funkcji W jednym z systemów, nad którymi pracowałem, użytkownicy mogli kooperatywnie porządkować wspólny zbiór dokumentów w foldery i przeszukiwać je. Regularnie napływały też nowe dokumenty z zewnątrz. Jedna z grup wymagań dotyczyła przechowywania i wykonywania okre- ślonych zapytań, operujących na nowych dokumentach. Druga grupa wymagań mówiła, że gdy użytkownik zmodyfikuje zawartość folderu, inny użytkownik otrzyma wiadomość e-mail z opisem wprowadzonych zmian. Obie grupy wymagały mechanizmu powiadamiania, czyli specy-ficznej możliwości architektury. Do czasu zaimplementowania tej możliwości żadna z wymaganych funkcji nie mogła zostać zapewniona. Głównym rynkiem docelowym systemu były firmy z listy Fortune 2000. Pierwotny model biznesowy opierał się na licencjach bezterminowych lub rocznych, udzielanych konkretnemu użytkownikowi lub na określoną liczbę jednoczesnych użytkowników. O ile jest to model popu-larny w przypadku oprogramowania dla przedsiębiorstw, uniemożliwiał sprzedaż produktu fir-mom prawniczym, które w rozliczeniach wymagają śledzenia użycia systemu. Dzięki współpracy z kierownictwem produktu, zdaliśmy sobie sprawę, że moglibyśmy otworzyć się na nowy segment rynku, o ile tylko zapewniona byłaby obsługa specyficznego dla niego modelu biznesowego. Niestety, zdefiniowanie nowego modelu biznesowego było znacznie łatwiejsze niż jego implementacja, która wymagała istotnych zmian w możliwościach wykorzystywanej architektury. W miejsce prostego zliczania jednoczesnych użytkowników (lub rozpoznawania ich), niezbędne było wprowadzenie kilku nowych możliwości, takich jak rejestrowanie pojedynczych zdarzeń w zabezpieczonych plikach dziennika, które potem byłyby przetwarzane przez system księgowy. Dopóki to nie było zapewnione, dostęp do nowego segmentu rynku pozostawał zamknięty. Inny system, z którym miałem do czynienia, odpowiadał za tworzenie próbnych wersji oprogramowania. Wersje próbne to potężne narzędzie marketingowe, powstające w drodze modyfikacji gotowego produktu przy użyciu specjalnych narzędzi, zapewniających jego trwałą ochronę. Klienci naszego systemu prosili o zwiększenie swobody w doborze ograniczeń użytkowania. Niestety, tego pozornie prostego wymagania nie przewidywała wykorzystywana architektura. Musiałem więc rozpocząć wprowadzanie w niej poważnych zmian, koniecznych do wyposażenia systemu w nowe możliwości. Typowym przykładem różnicy między funkcjami a możliwościami jest sytuacja, w której dział marketingu żąda, aby interfejs użytkownika został zlokalizowany i był dostępny w wielu wersjach językowych. Każdy język może być postrzegany jako osobna funkcja. Odpowiada to często zamierzeniom marketingowym. Jednak dopóki wykorzystywana architektura nie posiada możliwości związanych z internacjonalizacją produktu, obsługa wielu języków łatwo może stać się koszmarem prześladującym całą organizację. Można też przytoczyć wiele innych przykładów, zwłaszcza w obrębie oprogramowania dla przedsiębiorstw: przepływ pracy, elastyczne reguły sprawdzania poprawności, rosnące zapotrzebowanie na dostosowywanie aplikacji i inne. Jest jedna szczególna sytuacja, gdy cykl dojrzewania i ewolucji musi zostać złamany, a w pracach zespołu dominują rozważania na temat możliwości, a nie funkcji. Dzieje się tak, gdy trzeba przeprowa-dzić całkowite przeprojektowanie (przepisanie) systemu. Może to wynikać z różnych przyczyn, ale najbardziej typową jest fakt, że system nie dysponuje wymaganymi możliwościami, a dodanie ich jest zbyt kosztowne w kategoriach czasu lub zasobów. W takiej sytuacji bardzo ważne jest, aby architekt (lub zespół architektów) systemu bardzo dobrze znał i rozumiał brakujące możliwości techniczne. Wszyscy uczestnicy procesu muszą mieć pewność, że wkrótce rozpoczną pracę, która będzie miała za podstawę nowy, lepszy fundament. R01-03.doc 06-06-27 31 32 WIĘCEJ NIŻ ARCHITEKTURA OPROGRAMOWANIA Motywacja do zmiany konstrukcji (przepisania) systemu — brak wymaganych możliwości — ma często swoje źródło w bardzo szybkim prezentowaniu rosnącej bazie użytkowników nowych funkcji. Mówiąc prościej, szybki sukces może być ojcem przyszłej porażki. Niezbędne jest sprawne reagowanie na zmieniającą się sytuację. Degradacja architektury rozpoczyna się w bardzo prosty sposób. Gdy nacisk rynku na wprowadzanie nowych funkcji jest duży, a brakuje niezbędnych do ich implementacji możliwości systemu, skądinąd dobry i rozsądny menedżer może ulec pokusie nakłonienia programistów do zaimplementowania wymaganych funkcji bez towarzyszących im zmian w zakresie możliwości systemu. Uzasad-nienia takiego działania nadchodzą ze wszystkich kierunków. Konkurencja może zwrócić uwagę waż- nego klienta. Klient może odmówić aktualizacji do następnej wersji. Takie sytuacje pozbawiają zespół niezbędnych przychodów. Decyzje o dalszym rozwoju systemu nie są proste. Niemal pewnym skutkiem takiego dobrze uzasadnionego działania jest to, że przyszły koszt pielę- gnacji systemu i wprowadzania nowych funkcji będzie wysoki. Dodatkowo, ponieważ wciąż brakuje istotnych możliwości architektury, każda nowa, zależna od nich funkcja będzie równie kłopotliwa. Co gorsza, wpływ tego rodzaju sytuacji na morale zespołu prawdopodobnie zmniejszy efektywność jego pracy, co jeszcze pogłębi problem, zwłaszcza gdy rzekoma „presja rynku” okaże się mniejsza niż oczekiwano.
|
Wątki
|