Badania, analizy i opiniePublikacje

Czy zarządzanie technologiami informatycznymi jest potrzebne?

Ocena i dobór IT z punktu widzenia dostawcy oraz procesów wytwarzania oprogramowania

Wprowadzenie
Wydaje się, że zarządzanie technologiami informatycznymi (ang. Information Technology Management) staje się obecnie stosunkowo ważnym procesem silnie wpływającym na wytwarzanie systemów informatycznych. Takie podejście do technologii informatycznych wynika ze złożoności infrastruktury informatycznej, jak i skomplikowanych procesów ITSM (ang. IT Service Management) niezbędnych do zarządzania tą infrastrukturą. Również rozwój technologii internetowych (ang. Internet Technologies), a w szczególności webowych (ang. Web Technologies), wpłynął na powiększenie tej złożoności z uwagi m.in. na potrzebę zapewnienia zwielokrotnionego dostępu użytkowników oraz problemy z akceptowalnością i wiarygodnością opartych na nich systemów.
Aby efektywnie wykorzystywać technologie informatyczne, niektóre firmy wdrażają procesy ITSM oparte na najlepszych procedurach ITIL (ang. IT Infrastructure Library). Ich zastosowanie wymaga wykorzystania technologii bazujących na różnych kategoriach ITSM i integracji procesów w ramach tych kategorii. W nadmiernie złożonym środowisku informatycznym nie zarządzane procesy wytwarzania oraz nie zarządzane technologie informatyczne nie sprawdzają się. Dlatego też firmy informatyczne oraz przedsiębiorstwa wykorzystujące technologie informatyczne powinny stosować odpowiednie procedury wspomagające zarządzanie technologiami informatycznymi, jak też środowiskami, w których te technologie znajdują zastosowanie. Znajomość tych technologii, badanie, wykorzystanie, a w konsekwencji zarządzanie nimi staje się jednym z głównych trendów w rozwoju informatyki.

Czy zarządzać technologiami informatycznymi
Jak wobec tego zarządzać technologiami informatycznymi? Trudno znaleźć jest jednoznaczną odpowiedź. Dlatego też starać się będę przybliżyć ten problem, zachęcając czytelników do odpowiedzi na tak postawione pytanie. Ze swej strony, uczestnicząc w tej dyskusji starać się będę posiłkować odpowiedziami na pytania pomocnicze. Czy technologie informatyczne się dobiera? Jeżeli tak, to kiedy? Jeżeli się dobiera, to czy się je ocenia? Jeżeli się je ocenia, to jakie przyjmuje się kryteria tej oceny?
Z punktu widzenia dostawcy oprogramowania problem doboru technologii informatycznych występuje w następujących przypadkach:

  • gdy stare technologie nie umożliwiają realizacji funkcjonalności nowego systemu,
  • gdy radykalnie zmienia się środowisko wytwarzania,
  • kiedy następuje zmiana składu zespołu,
  • kiedy kierownik zespołu jest podatny na bieżące trendy i modę.

Uzasadnienie pierwszego przypadku wydaje się stosunkowo proste. Będąc dostawcą oprogramowania, wytwarzam systemy informatyczne, które nie są w stanie realizować pewnych funkcjonalności lub też implementacji tych funkcjonalności. Staram się więc zastosować nowe, bardziej adekwatne do wytwarzanego systemu technologie.
Przypadek drugi wynika z presji środowisk wytwarzania na dostawcę i jest jego reakcją na klasycznie postawione pytanie: Skoro wszyscy wykorzystują nowe środowisko, dlaczego ja nie korzystam z niego?
Zdecydowanie trudniejsza jest sytuacja w trzecim przypadku, kiedy członkowie zespołu, znający podobnie jak my technologie wytwarzania, odchodzą. Okazuje się wtedy, że zostajemy ukierunkowani na zastosowanie takich technologii, jakich specjalistów jesteśmy w stanie znaleźć na rynku (przy założeniu, że znamy ogólne funkcjonalności systemów, które będą przedmiotem wytwarzania). Możemy również próbować dobierać wstępnie skład zespołu, przeprowadzając ocenę rynku technologii informatycznych. I tutaj albo zdajemy się na eksperyment polegający na podpowiedzi zaprzyjaźnionych nam kolegów, albo też korzystamy (chcielibyśmy skorzystać) z usług doradcy, aby dla naszego składu zespołu i realizowanych projektów zasugerował nam odpowiednie technologie (często dla realizacji tak trudno pozyskanego zlecenia). Wiemy jednak, jakie mogą być konsekwencje takiego doboru. Myślę tutaj o sugestiach Barry’ego Bohema odnoszących się do efektywności przedsięwzięć osadzonych. Podobnym przypadkiem jest też chyba moda, kiedy nie w pełni przekonani próbujemy wykorzystać modne, ale nie do końca uzasadnione merytorycznie technologie.

Wpływ dojrzałości organizacji
Czy dojrzałość organizacji, którą kierujemy, ma wpływ na decyzje dotyczące doboru technologii informatycznych? Otóż wydaje się, że dobór technologii informatycznych może nastąpić w dwu przypadkach.
W pierwszym, kiedy firma jest firmą dojrzałą, funkcjonującą w niestabilnym otoczeniu z rozpoznanymi, powtarzalnymi procesami wytwórczymi o potwierdzonej dojrzałości, rozwijanej zgodnie ze standardami CMM/CMMI, ITIL, ISO 20000 itp. W takim przypadku wydaje się, że dobór taki jest raczej planowany niż przypadkowy. Ryzyko takiego doboru wydaje się niewielkie i stąd chyba tacy dostawcy byliby najczęściej zainteresowani problematyką wstępnego doboru technologii informatycznych.
Z kolei w przypadku organizacji niedojrzałych, funkcjonujących w niestabilnym otoczeniu, z procesami uruchamianymi doraźnie pod potrzeby bieżącego projektu, z niestałym lub niedoświadczonym zespołem projektowym, dobór technologii ma raczej charakter przypadkowy. Nie jest on poprzedzony ani analizą wstępną, ani też późniejszymi ocenami przydatności. Ale czy ten sektor rynku nie byłby również zainteresowany ocenami i dobrem technologii informatycznych?
Wydaje się, że problem tkwi w dostępności takich ocen. Gdyby na rynku oprogramowania istniały niezależne serwisy udostępniające takie oceny (o określonej renomie, a nie wspierane „dobrymi radami” producentów), być może kierownicy małych zespołów częściej korzystaliby z takich ocen i sugestii.

Jak dobierać technologie
Skoro odpowiedzieliśmy sobie na pytania: kiedy i dla jakich organizacji warto dobierać technologie informatyczne, może warto zastanowić się jak się je dobiera? I w tym przypadku realizowanych jest zwykle kilka scenariuszy zależnych głównie od dojrzałości organizacji wytwórczej i, jak zwykle, od decyzji kierownika zespołu opartych na schemacie: sugestie zewnętrzne wynikające z wpływu otoczenia (moda, potrzeby aplikacji) + szkolenia + zmiana technologii.
Powstaje jednak pytanie, czy szkolić cały zespół i wtedy rozpocząć prace. Ale każdy, kto choć raz uczestniczył w realizacji przedsięwzięcia, zdaje sobie sprawę, że tak rewolucyjne zmiany do niczego nie prowadzą. Zostajemy z zespołem, który z nowymi technologiami sobie nie radzi (zespół jest przeszkolony, ale znajomość nowych technologii jest niewystarczająca do realizacji przedsięwzięcia, chyba że czas nie jest parametrem krytycznym). Wydaje się więc, że lepiej jest zacząć zmiany od osoby/osób kluczowej/wych w zespole. Wtedy przejście od starych do nowych technologii jest łatwiejsze i obarczone mniejszym ryzykiem. Można zawsze wymienić (dobrać) nowy zespół wytwarzający system z wykorzystaniem dla nas nowych, ale dla zespołu sprawdzonych już technologii. Jest to jednak raczej rozwiązanie mocno teoretyczne. Wydaje mi się również, że trudno jest kierownikowi zespołu „przejąć” zespół, a zdecydowanie lepiej (i częściej) go zbudować. W obu jednak przypadkach sugeruje się kierownikowi (przed podjęciem decyzji dotyczących konkretnego wyboru) postawienie w stosunku do technologii informatycznych klasycznych pytań kompetencyjnych:

  • Czy technologia A nadaje się do zastosowania w organizacji Z?
  • Czy technologia A zapewnia większą skalowalność od technologii B?
  • Jaki będzie koszt wdrożenia technologii A w organizacji Z?
  • Które elementy technologii A wymagają zmian, by nadawała się ona do celów organizacji Z?
  • Jaka jest różnica w kosztach wdrożenia i funkcjonowania technologii A i B w organizacji Z w perspektywie M i N lat?
  • Ile wynosi ryzyko nieudanego wdrożenia technologii A w przedsiębiorstwie Z (procentowo i kwotowo)?

Oczywiście, zakres pytań kompetencyjnych może być zdecydowanie szerszy. Ważne jest jednak, aby oddawały one istotę problemu – potrzeby zmiany, co oczywiście pociąga za sobą konsekwencje organizacyjne, no i finansowe. Można jednak przyjąć, że pytania kompetencyjne stanowią pierwszy krok kierownika zespołu prowadzący do zmiany technologii.
Kolejnym krokiem może stać się pełna ocena realizowana w oparciu o wiedzę ekspertów, publikacje i raporty oraz doświadczenia własne. Gdybyśmy przeanalizowali te zasoby wiedzy, to w przypadku ekspertów, głównym problemem jest ich dobór. Kto jest najlepszym ekspertem? Myślę, że ten, kto na co dzień obcuje z danymi technologiami. Ale czy jego wiedza jest na tyle wystarczająca, aby moc porównać kilka technologii? Czy nie jest to jednak sytuacja, w której nie przydatność technologii, a poziom wiedzy eksperta decyduje (zakładając, że czynniki zewnętrzne nie są brane pod uwagę) o doborze. Wydaje się, że podobna sytuacja ma miejsce w przypadku przeglądania raportów. Czytane często raporty publikowane przez firmę Gartner (http://www.gartner.com) czy innych firm konsultingowych z obszaru informatyki mogą stanowić źródło wiedzy o technologiach informatycznych i ich wykorzystaniu. Pytanie jest wszakże, czy kierownik małego zespołu sięga po takie raporty i na ile – dzięki analizie tych raportów – jego wiedza jest uaktualniana. Uaktualniana na tyle, aby podjąć decyzję o wyborze odpowiednich technologii. Ich dostępność (nie należy mylić z dostępnością do szczegółowych raportów oceniających technologie), jak również rozproszenie często wpływają na wybór podejścia subiektywnego do takiej oceny. Ponieważ brak jest wiedzy „obiektywnej” (z pogranicza kilku technologii), lub też dostęp do takiej wiedzy jest utrudniony, dlatego też źródłem wiedzy o technologiach informatycznych stają się doświadczenia własne. Stąd już jest tylko krok do sytuacji, w której to właśnie my stajemy się ekspertami we własnej sprawie.
Czy jednak jesteśmy obiektywni? Czy wybrane przez nas technologie są adekwatne do wytwarzanych przez nas systemów? Jeżeli tak, to czy nie powinniśmy przed takim wyborem postawić określonych kryteriów doboru. Myślę tutaj o czterech grupach takich kryteriów:

  • techniczne, np.
    • dostosowanie do potrzeb wytwarzania aplikacji,
    • wspomaganie pracy grupowej,
    • skalowalność,
    • wspomagające zarządzanie zespołem,
    • automatyczne generowanie kodu źródłowego oraz zapewnienie jego analizy,
  • ekonomiczne – koszty zakupu, koszty utrzymania, wskaźniki TCO, ROI i inne,
  • ergonomiczne – malejące znaczenie z uwagi na fakt możliwości niemal całkowitej personalizacji interfejsów,
  • inne (technologie akceptowalne przez zespół, preferowanie technologii Open Source)

Jeżeli chodzi o kryteria techniczne, to ich dobór wydaje się kluczowy przy doborze technologii. Niemniej, w sytuacji, gdy większość środowisk łączących metody i techniki spełnia te najistotniejsze kryteria, decydujące o wyborze tej, a nie innej technologii, mogą być takie elementy jak funkcjonalność aplikacji czy zgodność ze strategią przyszłych prac realizowanych przez zespół wytwórczy.
Dobór zależy także od fazy wytwarzania oprogramowania (według Rational Unified Process). Stąd też dla uporządkowania wykorzystywanych technologii według faz powinniśmy je podzielić na te wykorzystywane na etapie rozpoczęcia i opracowania (analiza, specyfikacja i modelowanie) oraz te, które wykorzystane są w fazie konstrukcji (implementacja i testowanie). Oto przykład takiej klasyfikacji:

  • technologie i metodologie modelowania procesów biznesowych: BSC (Balanced Score Card), Six Sigma, Lean Management, BPML (Business Process Modeling Language), IGrafx, ARIS, IBM Rational,
  • technologie stosowane w implementacji systemów IT: języki wysokiego poziomu, narzędzia typu CASE (Computer-Assisted Software Engineering), środowiska wytwarzania (MS.NET, J2EE, rozwiązania Open Source),
  • technologie zarządzania przedsięwzięciami informatycznymi: PMM (Project Management Methodology), RUP (Rational Unified Process), metody „miękkie”: Agile, SCRUM, PMBoK (Project Management Book of Knowledge).

Taki podział ma absolutnie charakter umowny. Wskazuje zresztą, że przy podejmowaniu ocen dla zróżnicowanych technologii konieczne staje się ich wstępne przyporządkowanie do danej grupy, a następnie przyjęcie kryteriów ocen. Dla zobrazowania takiej oceny zaprezentowano przykład doboru kryterium do doboru technologii informatycznych służących modelowaniu procesów biznesowych. Poniżej zaprezentowano te kryteria:

  • możliwość budowy diagramów UML 2.0 lub BPMN,
  • weryfikacja poprawności modelu,
  • generowanie kodu (inżynieria w przód),
  • inżynieria w tył,
  • generowanie raportów (formaty?),
  • integracja z Eclipse/Visual Studio,
  • zarządzanie konfiguracją,
  • dokumentacja/tutoriale,
  • wymagania sprzętowe.

Dobór tych kryteriów zależy również od typu systemu, który mamy wytworzyć, jego wielkości i przeznaczenia, a także rodzaju i dojrzałości organizacji. Czy więc przy tak złożonym środowisku doboru i oceny możliwe jest przyjęcie dokładnych kryteriów oceny oraz czy istnieje biznesowe uzasadnienie dla przeprowadzenia takich ocen?
Wydaje się, że powinno zmienić się podejście do przeprowadzania takich ocen i dobór technologii informatycznych powinien być realizowany w oparciu o standardy narzucane przez wiodące w świecie informatyki organizacje. Myślę tutaj o organizacji W3C, i o rozwijanej przez tę organizację na przestrzeni ostatnich lat koncepcji Semantic Web, czyli sieci opartej na wiedzy. Ogólna struktura takiego podejścia jest przedstawiona na rysunku 1 (Koncepcja Semantic Web wdrażana przez W3C).

W koncepcji tej zakłada się, że zasoby sieci będą oparte na wiedzy i dzięki inteligentnym mechanizmom przeszukiwania, wyboru i oceny bazujących na ontologiach, bazach wiedzy i systemach agentowych będzie można wykorzystywać wiedzę, a nie rozproszone i trudne w tej chwili do ogarnięcia często niespójne dane. Wydaje się także, że przy takich zasobach, jakie oferuje obecne WWW, istnieje pilna potrzeba innego niż oparte na słowach kluczowych przeszukiwania, a przede wszystkim generowania wiedzy – zamiast prostych danych – z tej sieci.
W koncepcję tę doskonale wpasowuje się wielokryterialna i oparta na mechanizmach inteligentnych ocena technologii informatycznych. Trwają prace w Zespole, którym kieruję, nad budową prototypu systemu do takich ocen. Schemat funkcjonalny proponowanego prototypu przedstawiono na rysunku 1 (Schemat funkcjonalny systemu do oceny technologii informatycznych).

Obszary zastosowań
O ile budowa prototypu jest realizowana według przyjętego harmonogramu, o tyle ciągle niejasna jest jego użyteczność dla firm i organizacji wytwórczych. W artykule próbowano uzasadnić jego przydatność dla różnej wielkości firm i różnej funkcjonalności technologii, ale wydaje się, że wymagania jest szersza dyskusja grup informatyków dla wykazania przydatności proponowanego podejścia.
Zakładałem, że głównym celem tej publikacji jest właśnie skłonienie kolegów do podjęcia takiej dyskusji dla wskazania na miejsce i rolę takich systemów. Wydają się one potrzebne i użyteczne dla firm konsultingowych. Istotne mogą też być glosy dotyczące przydatności takich rozwiązań w innych obszarach niż technologie informatyczne. Może ci, którzy dobierali technologie, podzielą się swoimi spostrzeżeniami. Może ci, którzy nie dobierali technologii, a zostały one im narzucone, ocenią przydatność proponowanego podejścia. Chciałbym, aby artykuł ten stanowił otwarcie do dyskusji na temat przydatności planowania i doboru technologii, ich ocen oraz potrzeby stworzenia systemu do takich ocen. Zapraszam serdecznie do dyskusji

Cezary Orłowski
Zakład Zarządzania Technologiami Informatycznymi

Artykuł powstał w oparciu o materiały opracowane przez Zespół Zarządzania Technologiami Informatycznymi i prezentowane na konferencjach organizowanych przez Oddział Pomorski Polskiego Towarzystwa Informatycznego.

Autor: Cezary Orłowski