Ponieważ projekty informatyczne są traktowane jako projekty technologiczne i najczęściej zlecane dostawcom technologii.
To największy błąd, jaki można popełnić. W tym miejscu chciałbym zwrócić uwagę, że wymagania dzielą się na funkcjonalne i niefunkcjonalne. Wymagania niefunkcjonalne nigdy nie stanowiły problemu, ale wymagania funkcjonalne zawsze są problemem. Dlaczego więc zarządzanie projektami powierza się dostawcom technologii?
Architektura korporacyjna – stary model SOA
Poniższy schemat (Street, K. (2006). Budowanie architektury zorientowanej na usługi z wykorzystaniem BPM i MDA. 2(1), 8.) ilustruje kluczowe warstwy (poziomy) opisu organizacyjnego:
- procesy biznesowe
- usługi biznesowe (wymagane przez biznes)
- komponenty (aplikacje świadczące te usługi)
- zasoby (środowisko, w którym działają te aplikacje)
Model ten doskonale opisuje „to, co istnieje”. Problem z projektami informatycznymi polega na tym, czego nie widać w tym modelu: mechanizm przetwarzania treści. Drugim problemem jest zrozumienie, że dane nie są treścią. Dane to znaki przetwarzane przez komputer. Treść to to, co rozumie osoba mająca dostęp do tych danych. Książka napisana w języku, którego nie znamy, jest danymi, ale nie ma dla nas żadnej treści.
Przyjrzyjmy się poszczególnym warstwom tego modelu.
Business processes
Zazwyczaj modelujemy procesy biznesowe przy użyciu notacji BPMN (OMG.org). Model ten opisuje przepływ pracy i przepływ dokumentów. Jest to ważny model, ponieważ opisuje sposób funkcjonowania organizacji. Stanowi mechanizm działalności ludzkiej.
UWAGA! Model ten nie opisuje mechanizmu przetwarzania treści dokumentów.
Business services
Usługi aplikacyjne to wsparcie, jakie komputery zapewniają osobom wykonującym te zadania. Gdyby praca z dokumentami polegała wyłącznie na tworzeniu i przetwarzaniu treści przez ludzi, komputery byłyby jedynie pamięcią. Ta warstwa stanowi specyfikację potrzeb: semantykę i wymagania, kluczowe elementy projektu informatycznego, które nie zostały uwzględnione na tym schemacie i są pomijane w większości projektów.
Czego brakuje temu modelowi: mechanizm działania
Jeśli oczekujemy, że komputer będzie wspierał nas w przetwarzaniu treści, musimy wyrazić to w formie mechanizmu przetwarzania określonych danych. Chodzi o to, że komputer nie rozumie przechowywanych danych, ale doskonale radzi sobie z wykonywaniem procedur ich przetwarzania.
Dlatego trzeba stworzyć opis tego mechanizmu. Wielu autorów go opisuje, ale wszystkie te publikacje mają jedną wspólną cechę: zawierają modele. Na przykład taki jak ten poniżej (Rosenberg, D., Stephens, M. i Collins-Cope, M. (2005). Agile development with ICONIX process: People, process, and pragmatism. Apress).:
Powyższy schemat przedstawia proces projektowania mechanizmów oprogramowania:
- zawartość ekranu, tj. dokument w procesie biznesowym (GUI),
- opis mechanizmu przetwarzania danych (dynamiczny),
- architektura kodu aplikacji implementującego ten mechanizm (statyczny),
- kod jako wynik wyboru technologii,
- testy weryfikują poprawność działania aplikacji.
Alistair Cockburn opisał to jako Validation-V, znane również jako V-model:
Wynikiem tego projektu jest projekt. Mając go w ręku, można rozważyć, jaką technologię zastosować do jego wdrożenia. Po utworzeniu aplikacji powyższe diagramy służą jako dokumentacja opisująca działanie istniejącej aplikacji. Taka dokumentacja pozwala również na odtworzenie aplikacji w dowolnej innej technologii. Dlatego modele te nazywane są modelami niezależnymi od platformy (OMG.org, MDA).
Niestety, jest to rodzaj pracy, której sztuczna inteligencja nadal nie jest w stanie wykonać, ponieważ „posiada dane, ale ich nie rozumie”.
Components
Oto architektura integracji aplikacji i jej wdrożenie w środowisku:
Operation resources
Dzięki projektowi aplikacji i wiedzy na temat wybranej technologii można w końcu wybrać środowisko technologiczne i przeprowadzić wdrożenia w konkretnym języku programowania. Paradoksalnie jest to najmniej ryzykowna część pracy, pod warunkiem, że wiadomo, co i jak programować.
Dwie najniższe warstwy można wyrazić za pomocą modelu C4 opisanego przez Simon Brown.
Podsumowanie
Branża IT jest dziedziną inżynierii o najniższej efektywności. Szacuje się, że liczba udanych projektów nie przekracza 20–30%. Jedną z podawanych przyczyn takiego stanu rzeczy jest fakt, że projekty te są inicjowane bezpośrednio na poziomie technicznym, tj. bez wiedzy na temat tego, co ma zostać stworzone i w jaki sposób. Ta brakująca wiedza stanowi mechanizm systemu.
