„Nie radzę sobie z rozwojem systemów. Potrzebuję ITIL!”

Data: 2014-04-16
Autor: Sebastian Konkol
„Nie radzę sobie z rozwojem systemów. Potrzebuję ITIL!”

Wiele lat mojej działalności zawodowej poświęciłem biznesowi telekomunikacyjnemu, a konkretnie mobilnemu. Branża ta to jeden z przykładów ścisłej zależności od ICT (Information and Communications Technology) – wręcz zdeterminowania technologicznego tego biznesu. Działalność operacyjna takich firm opiera się na wielu złożonych systemach, a zmiana w modelach biznesowych (oferta, produkt, obsługa klienta) wymaga wprowadzania zmian do wielu z tych systemów – i to wprowadzania częstego. Dla objęcia zarządzaniem tego obszaru wykorzystywane są praktyki ITIL, a konkretnie Release Management. Mimo dużego wysiłku organizacji, wprowadzanie tych zmian w sposób w pełni kontrolowany jednak się nie udaje. Czy oznacza to, że coś jest nie tak z dobrymi praktykami ITIL? Nie koniecznie.

Podchodząc do zagadnienia z perspektywy teorii ograniczeń, praktyka Release Management umożliwia dostarczanie wyników odpowiedniej jakości, jednak w tym celu konieczne jest spełnienie kilku założeń. Głównym z nich jest zdolność do merytorycznego panowania nad przedmiotem wydania. Powyżej wskazany problem nie dotyczy samej praktyki, ale przedmiotu wydania – jest zbyt złożony, aby dawał się kontrolować jako całość. To właśnie wielkość i złożoność środowiska, do którego mają być wprowadzone zmiany, jest tu największym ograniczeniem – znacznie większym, niż sprawność praktyk zarządzania.

Zniesienie tego ograniczenia wymaga spojrzenia merytorycznego na przedmiot wydania, nie na praktyki zarządzania samym wdrażaniem zmian. Poprawne rozwiązanie wymaga spojrzenia z perspektywy architektury (EA, Enterprise Architecture), zapewniającego spełnienie następujących zasad:

  • Całość środowiska informatycznego powinna być logicznie podzielona na „wyspy” (domeny architektury). Każda z domen (np. obsługa klienta, rozliczenia, zmiany umów i danych klientów, windykacja) powinna być wewnętrznie spójna i obejmować całość procesów i rozwiązań z tej domeny.
  • Granice pomiędzy domenami powinny być określone tak, aby minimalizować złożoność powiązań między domenami (architektura biznesowa, danych i aplikacji).
  • Każda relacja między domenami powinna być skodyfikowana jako ściśle zdefiniowany i kontrolowany interfejs. Ponieważ szczególnie poważne zmiany w jednej z domen mogą skutkować modyfikacjami interfejsów, każdy z nich powinien być implementowany zgodnie z wzorcem wersjonowania protokołów (zdolność do obsługi różnych wersji tego samego interfejsu), umożliwiającym obsługę zgłoszeń w „starej wersji” przekazywanych przez domenę „nieświadomą” zmiany.

Wynikiem powinna być architektura zorganizowana jako federacja luźno powiązanych domen, wiązanych bez wymuszania synchronizacji zmian logiki działania pomiędzy nimi. W takim środowisku przedmiotem wysiłku Release Management powinny być każda z domen niezależnie. Praktyka pokazuje, że najefektywniejszym trybem wiązania między domenami jest wykorzystanie wzorców SOA (Service-Oriented Architecture) i EDA (Event-Driven Architecture).

Praktyki Release Management to tylko jeden z obszarów zarządzania, który natrafia na ograniczenia wynikające nie z samych praktyk, ale ze złożoności rozwiązań tym praktykom podlegających. W wielu innych przypadkach architektoniczne spojrzenie domenowe umożliwia objęcie kontrolą procesów zarządzania ICT. W mojej ocenie architektura korporacyjna to silniejszy paradygmat optymalizacji rozwiązań ICT. Zastosowany poprawnie pozwala na „użytkowanie” praktyk zarządczych, które – wobec złożoności środowisk ICT – ponoszą dzisiaj klęskę.

Pozostaw komentarz