Bo ten projekt jest specyficzny...

Gdy rozmawiam z ludźmi zaangażowanymi w realizację projektów informatycznych i dochodzimy do kwestii stosowania standardów, czy to ogólnie przyjętych, czy też standardów ustanowionych w organizacji, często słyszę, że w odniesieniu do tego, konkretnego projektu niemożliwe jest zastosowanie żadnego standardu, bo ten projekt jest specyficzny...
Później przychodzi refleksja, że tak naprawdę można to powiedzieć o każdym projekcie. Czy to oznacza, że każdy projekt jest specyficzny?

Otóż według metodyk zarządzania projektami projekt to przedsięwzięcie:

• jednorazowe,
• niepowtarzalne,
• złożone.

Cechy traktujące o tym, że projekt jest jednorazowy i niepowtarzalny - oznaczają de facto, że projekt w swojej naturze jest specyficzny. Z drugiej strony złożoność przedsięwzięcia skłania do posiłkowania się jakimś usystematyzowanym podejściem, aby lepiej radzić sobie z planowaniem, kontrolowaniem i sterowaniem.

Jak to zatem jest w praktyce? Przecież osoby zaangażowane w projekty z reguły znają doskonale metodyki zarządzania projektami: PMI, Prince2..., znają standardy wytwarzania oprogramowania, takie jak: SWEBOK, standardy analityczne, takie jak: BABOK. A jak przychodzi do ich stosowania w świecie rzeczywistym, to kierują się bardziej intuicją niż wypracowanym podejściem?

Zauważam często problemy w przełożeniu teorii na praktykę. Trudno powiedzieć z czego one wynikają.
Czy źródło problemu leży po stronie metodyk, ludzi czy samych przedsięwzięć? A może po części wynika z każdego z tych elementów?

Z punktu widzenia metodyk, czy też innych standardów, które warto stosować w projektach być może za słabo jest akcentowany temat dostosowania przy jednoczesnym narzucaniu szczegółowych rozwiązań...
Choć często metodyka, czy standard wyróżnia elementy obligatoryjne oraz elementy fakultatywne. Jednakże być może brakuje dostatecznego uzasadnienia dla stosowania elementów obligatoryjnych. W przypadku metodyki Prince2 powstało nawet pojęcie PINO, czyli Prince In Name Only.

A może metodyki są zbyt szczegółowe i powinny narzucać tylko ogólne pryncypia, natomiast każdy specyficzny projekt określałby rozszerzenia wykonawcze opisujące, jak takie pryncypia są realizowane?
Ale, czy w takim ujęciu metodyki byłyby w ogóle przydatne?

A może problem nie leży jednak w po stronie metodyk i standardów, tylko ludzi, którzy powinni się nimi kierować? W trakcie szkoleń ludzie zapoznają się z materiałami w stopniu umożliwiającym im zdanie egzaminu. Nawet, jeśli pytania egzaminacyjne są nakierowane na wykorzystanie zdobytej wiedzy w praktyce, to jednak taka wiedza może jest niewystarczająca...  Rzeczywistość bywa z reguły bardziej złożona od modelu, który ją opisuje. Modele opisują rzeczywistość projektową, z którymi ludzie mają do czynienia w trakcie szkoleń i egzaminów. Modele te nie są w stanie opisać w pełni rzeczywistości. W rozpatrywanych przypadkach może brakować czynników takich, jak relacje międzyludzkie, konflikty interesów, brak zrozumienia po stronie klienta, czy menedżera. A są to czynniki, które pośrednio wpływają na podejmowane decyzje. W przypadku, gdy człowiek odczuwa zagrożenie (np. ze strony szefa, kolegów, klientów) zaczyna się kierować intuicją, która ma pomóc mu zmniejszyć zagrożenie. Można to porównać do ucieczki zwierzęcia przed drapieżnikiem: takie zwierzę skupia się bardziej nad tym, żeby biec, niż nad tym - dokąd biegnie.

Podobnie bywa w "lesie projektowym". Członkowie zespołu projektowego starają się "dowieźć" projekt. Zaczynają bieg, za nimi zawsze biegnie ktoś inny. W takiej sytuacji nie ma pewności, czy biegacz będzie biegł po ścieżkach wyznaczonych standardami, czy może jednak będzie wybierać drogi, które w danym momencie wydają się lepsze. A w takim przypadku nie ma pewności, czy dobiegnie do mety, czy po drodze nie wpadnie w jakieś pułapki, których nie dostrzegł w porę.

Po co architektura korporacyjna?

W ostatnich latach coraz częściej pisze się o architekturze korporacyjnej. Może to świadczyć o tym, że organizacje zaczynają powoli dostrzegać istnienie takiego zjawiska. Zastanawiam się jednak, czy firmy potrafią odpowiednio ocenić znaczenie i wagę architektury korporacyjnej.

Czasem odnoszę wrażenie, że organizacje powołują biura architektoniczne, ale w skład takiego biura wchodzą osoby na takich stanowiskach, które nie mają realnego wpływu na wyznaczanie kierunków rozwoju, czy też sposobów rozwiązywania problemów organizacji. W takiej sytuacji kierownictwo może być przeświadczone o tym, że wykorzystuje najlepsze narzędzia oraz, że zrobiło wszystko, co jest niezbędne do tego, żeby panować nad architekturą.

A jak to wygląda w praktyce? 

Zdarza się, że osoby, które wcześniej pełniły rolę architekta rozwiązań, czy wiodącego konsultanta zmieniają stanowisko na: architekta korporacyjnego jednocześnie pełniąc dotychczasowe obowiązki. Na przykład biorą nadal czynny udział w realizacji projektów informatycznych. Gdy takie osoby pytają, na czym mają polegać ich obowiązki jako architekta korporacyjnego - słyszą, że dodatkowo powinny tworzyć modele architektoniczne. Oznacza to dla nich, że zmiana stanowiska zamiast awansu w strukturze organizacyjnej polega na dołożeniu im dodatkowych obowiązków.
W rezultacie zadania polegające na tworzeniu i pielęgnacji architektury korporacyjnej są realizowane z niskim priorytetem, bo najważniejsza jest bieżąca praca przy realizacji projektów. Tradycyjnie projekty są postrzegane jako najważniejsze, gdyż to one zwiększają konkurencyjność na rynku i przekładają się na realne dochody.
Jeśli jednak architekt nie ma czasu i możliwości spojrzeć na organizację "z lotu ptaka", to może nie zobaczyć, wad, którymi takie projekty mogą być obarczone.

Może zatem warto przypominać o korzyściach płynących z architektury korporacyjnej?
+Andrzej Sobczak pisze w następujący sposób o roli architektów:

Zastanawiam się, czy architektów korporacyjnych nie można porównywać do lekarzy organizacji, a narzędzia którymi oni (tj. architekci) posługują się (tj. modele, symulacje, analizy…) do przyrządów medycznych (dzięki nim można wykazać/udowodnić “chorobę” organizacji i doradzić odpowiednie “leczenie”). Taki architekt / lekarz organizacji prowadziłby diagnostykę problemów organizacji, a następnie zalecał odpowiednią kurację :).

Myślę, że świetną ilustracją do tego jest również poniższy filmik pokazujący w humorystyczny sposób po co jest potrzebny architekt.

Walidacja czy weryfikacja?

W inżynierii oprogramowania w różnych kontekstach pojawiają się pojęcia walidacji i weryfikacji. Często te pojęcia wymieniane są razem, a przez to znaczenie każdego z tych słów bywa niejasne i różnie interpretowane. W języku angielskim istnieje nawet odpowiedni akronim dla nich: V&V (verification and validation).

Czy zastanawialiście się na przykład nad tym:

• Czy czynność polegająca na sprawdzeniu, czy wymagania funkcjonalne sformułowane przez analityka są zgodne z założonymi celami przedsięwzięcia, to - walidacja czy weryfikacja wymagań?
• Czy sprawdzenie zgodności kodu oprogramowania z przyjętymi standardami (np. konwencja nazewnictwa klas Javy), to - walidacja, czy weryfikacja kodu?
• Czy sprawdzenie zgodności komunikatu XML z XSD, to - walidacja, czy weryfikacja?
• Czy testy funkcjonalne lub niefunkcjonalne wykonywane przez testera, to - walidacja, czy weryfikacja oprogramowania?

Modelujmy tylko to, co możemy zmienić

Gdy tworzymy dowolny model w obojętnie jakim języku (czy to jest Archimate, UML, czy BPMN) powinna nam przyświecać jedna generalna zasada:

Modelujemy tylko to, co możemy zmienić.

A teraz wypadałoby wyjaśnić, jak należy rozumieć tę zasadę.

Chodzi o to, że modelowaniu powinny podlegać tylko obiekty, na które mamy jakikolwiek wpływ. Żeby to lepiej wyjaśnić, skupmy się na przykładach.

Enterprise Architect w Gartner Magic Quadrant

Firma Gartner raz do roku publikuje tzw. Magic Quadrant - obrazujący pozycję różnych narzędzi mogących służyć jako repozytorium architektoniczne w kontekście architektury korporacyjnej. Analiza ta jest przydatna dla organizacji, które stają przed wyborem narzędzia.

Enterprise Architecture Tools Magic Quadrant 2013

W bieżącym roku Gartner klasyfikuje narzędzia do architektury korporacyjnej w następujący sposób.

Widać, że Sparx Systems - jako producent Enterprise Architect jest klasyfikowany jako niszowy gracz.
Ale trzeba mieć na uwadze, że podstawowym przeznaczeniem EA jest modelowanie bazujące na języku UML. I w tej dziedzinie można uznać Sparx Systems za lidera.

Aby lepiej zrozumieć, w jaki sposób Gartner ocenia przydatność narzędzi warto zapoznać się z kryteriami oceny. Są to:

• A repository that supports, at a minimum, the business, information, technology and solution viewpoints and their relationships. The repository must also support business direction, vision and strategy, as well as business disruptions.
• Modeling capabilities that support the minimum viewpoints of business, information, technology and solutions.
• Decision analysis capabilities, such as gap analysis, impact analysis, scenario planning and system thinking.
• Presentation capabilities that are visual or interactive to meet the demands of a myriad of stakeholders.
• Administration capabilities that enable security, user management and other tasks.
• Configurability capabilities that are extensive, simple and straightforward to accomplish, while supporting multiple environments.
• Support for frameworks and standards, often used while providing the flexibility to modify the framework.
• Usability, including intuitive, flexible and easy-to-learn UIs.

W mojej ocenie EA wspiera wszystkie wymienione funkcjonalności oraz posiada ogromne możliwości w zakresie konfiguracji, czy wsparcia dla ram architektonicznych i standardów. 

Jednakże kluczowym czynnikiem, który świadczy o ułomności tego narzędzia w zastosowaniu jako repozytorium architektoniczne są:

• Nie intuicyjny i trudny do nauczenia interfejs użytkownika.
• Zmiany konfiguracji i rozszerzenia nie są łatwe do implementacji i stosowania, gdyż nierzadko konieczne jest kodowanie w formie skryptów (np. VBasic, JScript), pluginów w .NET, poznanie języka skryptowego ShapeScript, czy MDG Technology.

Przy podejmowaniu decyzji o ewentualnym wyborze Sparx EA dla celów architektury korporacyjnej warto jednak mieć na uwadze również inne kryteria, których Gartner nie bierze pod uwagę:

• Stosunek ceny do możliwości. W tym wypadku Sparx Systems byłby zdecydowanym liderem. Trudno znaleźć jakiekolwiek narzędzie, które oferowałoby tak dużą gamę funkcjonalności za tak niską cenę.
• Popularność narzędzia Enterprise Architect w Polsce. Dzięki temu możliwe jest zatrudnienie specjalistów w swojej dziedzinie, którzy doskonale znają to narzędzie. Ta cecha niweluje w pewnym stopniu wadę EA, jaką jest nie intuicyjny i trudny do nauczenia interfejs użytkownika.

Jeszcze dla porównania prezentuję poniżej poprzednie wyniki analizy Magic Quadrant z roku 2012.

Źródło

Więcej informacji na ten temat można znaleźć pod adresem: http://www.mikethearchitect.com/2013/10/gartners-2013-enterprise-architecture-tools-magic-quadrant.html

Agile lekarstwem dla zarządzania wymaganiami?

Organizacja Standish Group co roku publikuje swój sławny raport zatytułowany Chaos Report. Raport ten zawiera wyniki badań dotyczących jakości projektów informatycznych. Od kilkunastu lat Standish Group zadaje organizacjom te same pytania dotyczące liczby projektów kończących się sukcesem. Porównanie tych liczb na przestrzeni lat jest ciekawe przede wszystkim dla kierowników projektów, ale nie tylko.

Niedawno przeczytałem nie sam raport, ale wnioski z raportu za 2011 rok zaprezentowane przez Johna Parkera na blogu w artykule Why so Many IT Projects are Challenged, Under Deliver Promised Value, or Outright Fail.

Autor zamieścił tam następującą tabelkę:

Jest to porównanie liczby projektów zakończonych sukcesem (które zmieściły się w budżecie i harmonogramie i dostarczyły zamawiającemu oczekiwaną wartość), liczby projektów, które się zakończyły, ale nie zmieściły się w zaplanowanym budżecie, bądź były opóźnione lub też miały ograniczony zakres w stosunku do pierwotnych założeń oraz liczby projektów, które zostały zakończone porażką.

Z przedstawionych liczb widać, że na przestrzeni kilkunastu lat nastąpiła nieznaczna poprawa, ale mimo wszystko liczba projektów zakończonych pełnym sukcesem jest bardzo mała.

Najbardziej rzuca się w oczy jednak porównanie liczby projektów zakończonych sukcesem realizowanych według standardowej metody Waterfall - 14%, do liczby projektów zakończonych sukcesem prowadzonych według metodyk zwinnych, Agile - 42%. Różnica jest na tyle diametralna, że w samym opracowaniu raportu zamieszczono komentarz:

“The Agile process is the universal remedy for software development project failure. Software applications developed through the Agile process have three times the success rate of the traditional Waterfall method, and a much lower percentage of time and cost overruns.”

Przyznam, że nie zdawałem sobie sprawy z takiej przewagi podejścia Agile nad standardowym cyklem wytwarzania oprogramowania. Ciekawy jestem, czy firmy realizujące projekty informatyczne w ślad za tym opracowaniem w przyszłości będą stawiały jeszcze bardziej na metodyki zwinne.
W każdym bądź razie Standish Group dostarczył znaczących argumentów za tym kierunkiem rozwoju.

A dlaczego Agile miałoby być lekarstwem dla zarządzania wymaganiami?

Otóż, wg Standish Group trzy najważniejsze powody, dla których projekty nie kończą się pełnym sukcesem to:

• Lack of user input
• Incomplete requirements and specifications
• Changing requirements and specifications.

Wszystkie te czynniki są rezultatem niedostatecznej analizy biznesowej. Można wysnuć wniosek, że standardowe podejście, w którym pierwszą fazą projektu jest analiza kończąca się zatwierdzeniem specyfikacji wymagań - jest błędne. 

Ja nie spotkałem się jeszcze z projektem, w którym czas przeznaczony na analizę byłby wystarczający lub wyniki fazy analizy byłyby kompletne i zawierałyby dokładnie opisane wszystkie wymagania. Niby zakłada się, że wymagania mogą podlegać zmianom w późniejszych fazach projektu, przy czym istnieje świadomość, że im późniejsza zmiana wymagań, tym koszt jest większy. Ale najczęściej mimo wysiłku całego zespołu projektowego liczba zmian przekracza punkt krytyczny, po którym okazuje się, że sukces projektu jest zagrożony.

Czy zatem stosowanie podejścia Agile do zarządzania wymaganiami i prowadzenia całego projektu może kluczem do sukcesu? Wiele na to wskazuje. Choć w moim odczuciu potrzeba jeszcze wiele czasu, żeby się o tym przekonać na własnej skórze. Sądzę, że potrzebujemy jeszcze więcej opracowań na temat metodyk zwinnych oraz przekonania do nich organizacji i ludzi, którzy od lat realizują projekty zgodnie ze starymi i sprawdzonymi metodami.

MS Office vs. Enterprise Architect

W rozmaitych okolicznościach spotykam się z zespołami projektowymi, które skomplikowane zagadnienia projektowe dokumentują w postaci dokumentów MS Word i MS Excel. Twórcy takiej dokumentacji wkładają mnóstwo wysiłku w jej wytworzenie i są często z niej dumni.
Dla przykładu spotkałem się z arkuszem MS Excel, który opisuje szczegółowo procesy biznesowe w całej organizacji z uwzględnieniem obecnego i przyszłego wsparcia przez poszczególne funkcje systemów informatycznych w dodatku z rozróżnieniem na różnice w poszczególnych jednostkach organizacyjnych. Imponujące, prawda?
Twórcy takiego arkusza szczycą się tym, że w tym jednym dokumencie opisane są najważniejsze aspekty architektury biznesowej i wsparcia jej przez systemy informatyczne. Zdaję sobie sprawę, że wypełnienie treścią tego ogromnego arkusza poprzedzone zostało wieloma godzinami pracy i konsultacji z klientem.
Ja jednak czytając tego typu dokumenty mam problem, bo zdaję sobie sprawę z tego, że autorzy oczekują podziwu dla ogromu wykonanej pracy, ale ja nie mogę przestać zadawać sobie w kółko jednego pytania: "Dlaczego oni tego nie zrobili w EA?".
Myślałem sobie, że to ja mam skrzywione spojrzenie na rzeczywistość. Na szczęście miałem okazję przeczytać ciekawy wpis Jarka Żelinskiego pod tytułem Sabotaż dokumentacyjny.
Autor przytacza w nim między innymi 10 tez dotyczących prowadzenia dokumentacji w postaci dokumentów MS Word i MS Excel. Pisze między innymi, że:

Używanie arkuszy kalkulacyjnych do zarządzania zależnościami pomiędzy wymaganiami przenosi całe ryzyko błędów na Ciebie, jest także bardzo pracochłonne.

Autor argumentuje, dlaczego dokumentacja powinna być prowadzona przy użyciu narzędzi CASE, takich jak Visual Paradigm Agilian, czy Enterprise Architect, zamiast w postaci dokumentów i arkuszy.

Jeśli nawet część członków zespołu projektowego wskazuje na chęć wykorzystania Enterprise Architecta zamiast produkowania wielu dokumentów i ich wersji, to rzadko dochodzi do skutku tego typu zmiana.

Dlaczego tak się dzieje?
Jak zwykle mamy do czynienia z wieloma czynnikami. Ja jednak niedawno natknąłem się na jeden zasadniczy problem.

Otóż, gdy zespół stoi przed decyzją: porzucić pracę w MS Office na rzecz Enterprise Architect, czy nie, wówczas taki zespół powinien umieć sformułować zestaw własnych wymagań odnośnie takiego narzędzia.
Czyli, zespół powinien być w stanie określić, co takie narzędzie powinno być w stanie zrobić, żeby oni mogli go używać. Dopiero wtedy będą w stanie wyobrazić sobie, że z niego korzystają i w jaki sposób.

Niestety osoby tworzące skomplikowane dokumenty i arkusze kalkulacyjne nie znają narzędzi CASE, bo gdyby znali, to by ich użyli. Samo zapoznanie się z dokumentacją programu nie jest również wystarczające. Poza tym, z EA można wyciągnąć o wiele więcej, niż to widać na pierwszy rzut oka poprzez umiejętną kastomizację. Do pomocy potrzebny jest ktoś, kto zna Enterprise Architecta, czy inne narzędzie CASE "od deski do deski".

Gdy członkowie zespołu stwierdzą, że potrzebują arkuszy kalkulacyjnych, bo to jest najwygodniejsza forma komunikacji z klientem, to w odpowiedzi mogą usłyszeć, że z EA można na żądanie wyeksportować dane do arkusza.
Gdy członkowie zespołu stwierdzą, że zatwierdzone ustalenia powinny mieć charakter oficjalnego dokumentu, który powinien być podpisany przez obie strony, to w odpowiedzi mogą usłyszeć, że z EA można generować tego typu dokumenty.
Gdy członkowie zespołu stwierdzą, że wprowadzanie danych do EA jest zbyt skomplikowane i mogą powstawać błędy, to w odpowiedzi mogą usłyszeć, że do wprowadzania specyficznych danych można opracować odpowiedni plugin. A do walidacji wykorzystać skrypty i zapytania SQL, które zwrócą listę elementów nie spełniających reguł projektowych.

W takiej sytuacji dyskusja przenosi się z reguły na inny poziom: Kierownik projektu musi oszacować, czy koszty opracowania szablonów raportów i kastomizacji narzędzia są akceptowalne. Oby jeszcze kierownik projektu zgodziłby się z tezą pochodzącą z wyżej cytowanego artykułu o tym, że:

Dokumenty i arkusze kalkulacyjne sprowadzają Cię do roli biurokraty. Praca z dokumentami tekstowymi i arkuszami to permanentne pisanie, wycinanie, kopiowanie, sprawdzanie spójności, stanowi to nawet 85% czasu całej analizy, pozostała wartościowa praca to 15%.

Polecam anglojęzyczny blog o Enterprise Architect

W grudniu ub. roku +Michał Wolski zauważył, że Enterprise Architect jest coraz bardziej popularny w sieci. Na poparcie tej tezy chciałbym polecić wszystkim czytelnikom również anglojęzycznego bloga autorstwa niejakiego Hamisha -  analityka biznesowego z Melbourne.

Pod adresem http://www.hamishking.com/category/enterprise-architect/ można znaleźć już teraz ciekawe wpisy opisujące na przykład:

• metody śledzenia zmian w dokumentach wygenerowanych w EA,
• wskazówki jak uruchomić symulację diagramu stanów,
• opis importu danych z pliku CSV,
• oraz bardzo ciekawe zastosowanie dodatku eaDocX do importu i synchronizacji wymagań z plikiem MS Excel.

Oprócz zastosowania EA, autor porusza również inne wątki, ale widać, że w ostatnim czasie sukcesywnie dodaje ciekawe wpisy dotyczące możliwości programu Enterprise Architect.

Adresaci diagramów

Gdy tworzymy diagramy zazwyczaj skupiamy się na tym, aby wiernie odzwierciedlić rzeczywistość zgodnie z regułami zastosowanej notacji. Jednakże to nie jest wystarczające do tego, aby zostały poprawnie zrozumiane przez adresatów.

Czy zastanawialiście się nad tym, komu i do czego opracowywane diagramy mają służyć?

Zanim zaczniemy opracowywać diagramy, powinniśmy postawić się w roli adresata diagramów i spróbować sobie odpowiedzieć na poniższe pytania.

Zrozumienie diagramów UML

Język UML jest od lat uznanym standardem w dziedzinie modelowania. Jeśli istnieją opory w szerszym stosowaniu UML w projektowaniu systemów informatycznych, to najczęściej wynikają one z obaw o zrozumienie modeli przez interesariuszy.
Ostatnio natknąłem się na publikację pod tytułem System Analysis and Design for Advanced Modeling Methods: Best Practices opracowaną w 2009 roku pod redakcją Akhilesh Bajaj oraz Stanisława Wrycza (ISBN 9781605663449). Książka ta stanowi zbiór wyników badań naukowych w obszarze analizy i projektowania systemów oraz metodologii.

Dojrzałość organizacji w zarządzaniu danymi

W ramach opracowywania architektury korporacyjnej w organizacji jednym z nurtów jest architektura danych. W TOGAF zagadnienie to jest jedną z czterech domen architektonicznych:

• Business,
• Data,
• Application,
• Technology.

Słownik TOGAF® (dokument TOGAF® 9 Translation Glossary: English - Polish) definiuje, że architektura danych to:

Struktura logicznych i fizycznych danych organizacji, a także zasobów używanych do zarządzania tymi danymi.

W książce pod tytułem The Art of Enterprise Information Architecture: A Systems-Based Approach for Unlocking Business Insight znalazłem interesujący model dojrzałości organizacji w zarządzaniu informacjami. Model ten pokazuje w jaki sposób organizacja może rozwijać się w tym zakresie i do czego dążyć.

Czy IT umie zarządzać informacją?

Niedawno dyskutowałem w biurze z kolegą o tym, że podstawowym zadaniem branży informatycznej jest sprawne zarządzanie informacjami w organizacji oraz świadczenie usług dla biznesu. Praktyka pokazuje jednak, że sama branża informatyczna ma problem z zarządzaniem informacjami na własnym podwórku. Aby móc się sprawnie komunikować potrzebna jest platforma wspólnego porozumienia. Aby to osiągnąć powinniśmy mieć pewność, że pojęcia, których używamy są tak samo interpretowane przez wszystkich uczestników komunikacji. Czyli innymi słowy, odbiorca komunikatu tak samo jak nadawca rozumie, co się kryje pod danym pojęciem.

Czy naprawdę jest źle? 

Przecież, gdy ktoś mówi na przykład o aplikacji, to wiadomo o co chodzi.
W takim razie posłużmy się przykładem definicji pojęcia "aplikacja".

Definicja aplikacji wg ITIL® (pochodzi z "Polski glosariusz ITIL®, wersja 1.0, z dnia 15 grudnia 2011):

Oprogramowanie oferujące funkcjonalności konieczne do świadczenia usługi IT. Każda aplikacja może być komponentem więcej niż jednej usługi. Aplikacja działa na jednym lub większej liczbie serwerów lub stacji klienckich.

Definicja aplikacji wg TOGAF® (pochodzi z TOGAF® 9 Translation Glossary: English - Polish).

Aplikacja to wdrożony i działający system IT, który wspiera funkcje i usługi biznesowe. Aplikacje używają danych i wielu komponentów technicznych, ale same nie są komponentami technicznymi.

Mamy zatem do czynienia z dwoma różnymi podejściami, które patrzą na organizacje i procesy z różnych punktów widzenia. Pierwszy z wymienionych standardów stanowi, że aplikacja może być komponentem, a w drugi, że nie jest komponentem.

Jaki to ma wpływ na projekty informatyczne?

Po pierwsze, problem pojawia się już w kwestii modelowania i rodzi pytania typu: "Czy poprawnym jest umieszczenie jakiejś aplikacji w formie komponentu na diagramie?"
Ale tak naprawdę, problem jest głębszy, a kwestia definicji aplikacji jest tego przykładem. Jeśli członkowie zespołu projektowego bazują na przykład na którymś ze standardów określających ramy architektoniczne, a  osoby definiujące wymagania po stronie klienta bazują na przykład na standardzie ITIL, wówczas wymagania klienta mogą być niepoprawnie interpretowane. Takie sytuacje rodzą konflikty, a niepoprawnie zrealizowane wymagania mogą generować nawet wymierne straty czasu i pieniędzy ponoszone przez jedną lub drugą stronę.

Czy jest na to rada?

Skoro w świecie informatycznym istnieje wiele definicji tych samych pojęć, które różnią się między sobą, to musimy sobie sami poradzić.
Wydaje się, że najlepszym rozwiązaniem jest najpierw ustalenie w ramach zespołu, jakie podejście czy standard przyjmiemy za bazowy. Bazą do tych ustaleń powinny być oczekiwania klienta zdefiniowane w umowie, bądź też w formie ustnej. Kolejnym krokiem jest opracowanie słownika projektowego. Definicje zawarte w słowniku projektowym mają za zadanie rozwianie jakichkolwiek wątpliwości i powinny być sukcesywnie stosowane zarówno przez Wykonawcę, jak i Zamawiającego. Definicje w słowniku projektowym mogą pochodzić z wybranych standardów, ale powinny być ze sobą spójne.

Forum Sparx - nowa tendencja

W momentach, kiedy w pracy mam spokojniejsze chwile, a wszystkie pilne zadania zostały wykonane, wówczas staram się wykorzystać czas do tego, żeby się czegoś nowego dowiedzieć. W takich chwilach odwiedzam forum Sparx i czytam zamieszczone posty, bo - a nuż ktoś odkrył coś ciekawego i postanowił się tym podzielić z innymi.
Zauważyłem przy okazji, że to forum coraz częściej zaczyna służyć jako miejsce do reklamowania swoich własnych produktów związanych z Enterprise Architectem, takich jak ebooki, czy add-ins (pluginy).
Ktoś zadaje na przykład pytanie dotyczące tego, w jaki sposób na raporcie RTF umieścić coś tam, w odpowiedzi otrzymuje tylko informacje: sprawdź mój produkt, który służy do generowania raportów z EA, on z pewnością rozwiąże Twój problem.
Albo ktoś pyta, jak napisać skrypt, który ma coś zrobić, bo mu nie wychodzi, wówczas dostaje odpowiedź: sprawdź mojego ebooka, któy traktuje o pisaniu skryptów w EA.
Czytając tego typu odpowiedzi mam wrażenie, że osoby, które się reklamują nawet nie tracą czasu na wczytywanie się w istotę problemu i nie wnikają, czy rzeczywiście ich produkt potrafi rozwiązać opisany problem.
Chyba idea forum jest nieco inna... Ludzie korzystają z forum z przeświadczeniem, że znajdzie się jakaś dobra dusza, która bezinteresownie wskaże sposób rozwiązania problemu. A dobra dusza pomaga, bo myśli, że gdy sama będzie miała jakiś problem, to znajdzie się ktoś inny, kto jej również pomoże. A tu taka komercjalizacja...
Podobnie zresztą wygląda sytuacja z Community community.sparxsystems.com. Pojawia się tam coraz więcej artykułów reklamowych. Czyli ludzie, którzy chcą zarobić na popularności EA otrzymali do dyspozycji darmową formę reklamy.
Ale może ja się po prostu czepiam?