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.