9 obserwacji o złożoności IT
Złożoność oznacza cechę obiektu czy też systemu. Obiekty/systemy złożone charakteryzują się skomplikowaną budową, są trudne do zrozumienia. Obecnie coraz częściej mówi się o konieczności zmniejszania złożoności rozwiązań IT. Problemem złożoności od wielu lat zajmuje się Roger Sessions z firmy ObjectWatch. Jest on m.in. autorem opatentowanej metodyki SIP, która jest nakierowana na minimalizację złożoności dużych systemów IT. Od lat Roger działa także jako “ewangelista”, pokazując jak należy walczyć ze złożonością świata IT. W ramach tych działań prowadzi on na serwisie LinkedIn grupę SimplerIT. Parę dni temu opublikował on w ramach tej grupy materiał pt. “10 obserwacji o złożoności IT” (ale faktycznie omówił 9 obserwacji ;) – dlatego mój wpis ma odmienny tytuł od jego opracowania).
Pozwoliłem sobie te obserwacje przetłumaczyć na język polski i wzbogacić o moje komentarze.
Obserwacja 1. Większość systemów IT jest zbyt złożona.
Komentarz: Prawdą jest, że większość systemów IT klasy enterprise jest bardzo złożona. Ale złożoność ta jest pochodną złożoności biznesowej (proszę zwrócić uwagę np. na liczbę ofert w telco czy strukturę niektórych produktów bankowych). Czyli to nie dział IT jest winien, że systemy informatyczne są złożone. Co więcej bez świadomego zarządzania złożonością po stronie biznesu nie ma szans, aby zmniejszyć złożoność po stronie IT.
Obserwacja 2. “Dobre praktyki” powodują wzrost złożoności.
Komentarz: Rozumiem, że autor miał na myśli np. ITIL’a, TOGAFA, PM BOOK’a. Uważam, że zależy jak wdraża się “dobre praktyki w organizacji – jeżeli literalnie, bez adaptacji – to faktycznie zwiększają one i biurokrację i złożoność. Ale rozsądnie wdrożone (skastomizowane) są mieczem do walki ze złożonością.
Obserwacja 3. Budowa systemów złożonych jest bardziej kosztowna.
Komentarz: Absolutnie zgadam się z tym stwierdzeniem. Wolę opracować i wdrożyć trzy mniejsze systemy, niż 1 bardzo złożonych. W przypadku złożonych systemów dramatycznie rosną narzuty związane z trudnościami w komunikacji w dużych zespołach, pojawiają się błędy wynikające z dramatycznego wzrostu skomplikowania wszystkich elementów składowych (i na poziomie interfejsów i na poziomie funkcji itd…).
Obserwacja 4. Systemy złożone są trudniejsze do dostarczenia.
Komentarz: Zgadzam się z tym stwierdzeniem. Trudniej jest zaplanować wdrożenie systemów złożonych. Pojawiają się problemy ze szkoleniami użytkowników. Ciężej jest uruchamiać (konfigurować) środowiska dla systemów złożonych.
Obserwacja 5. Systemy złożone są mniej bezpieczne.
Komentarz: Raczej zgadzam się z tym stwierdzeniem. Przy bardzo dużej złożoności łatwiej coś przeoczyć (np. na etapie weryfikacji). Z drugiej jednak strony architektura niektórych systemów krytycznych po prostu musi być złożona.
Obserwacja 6. Systemy złożone są mniej wiarygodne.
Komentarz: Raczej zgadzam się z tym stwierdzeniem. W przypadku systemów złożonych istotnym problem jest przygotowanie i przeprowadzenie wiarygodnych testów (np. integracyjnych).
Obserwacja 7. Systemy złożone są mniej zwinne (elastyczne).
Komentarz: Zgadzam się z do pewnego stopnia z tym stwierdzeniem. Uważam, że każdy system ma swój punkt optimum jeżeli chodzi o złożoność. Jeżeli system jest zbyt prosty może okazać się, że nie osiągniemy oczekiwanej elastyczności. Jednak przekroczenie pewnego progu elastyczności prowadzi do tego, że implementacja zmian w systemach staje się koszmarem.
Obserwacja 8. Systemy złożone są kosztowne na etapie ich uruchamiania
Komentarz: Jak najbardziej zgadzam się z tym stwierdzeniem. Niestety pojawia się tutaj efekt kuli śnieżnej – systemy złożone są trudne w budowie, testach, na etapie migracji…
Obserwacja 9. Brak w materiałach Rogera
Komentarz: Jest to najprawdopodobniej błąd.
10. Istniejące metody zarządzania ignorują problem złożoności.
Komentarz: Zgadzam się z tym. Chociaż powoli zaczyna się to zmieniać, bo duże firmy doradcze (np. Bain & Company) zaczynają interesować się tym problemem. Należy się więc spodziewać, że w najbliższym czasie pojawią się również metodyki pozwalające zarządzać złożonością [zarówno na poziomie IT jak i biznesowym].
Dawno temu Friedrich von Schiller stwierdził: Prostota jest owocem dojrzałości. I rzeczywiście, patrząc na powyższe obserwacje Rogera należy stwierdzić, że aby organizacja miała proste systemy – musi być na określonym poziomie dojrzałości – bo dopiero to pozwala jej dostrzec i zmierzyć się z problemem złożoności.
Komentarze do wpisu
Chciałbym wtrącić swoje trzy grosze (a może cztery).
1. W Polsce króluje raczej architektura korporacyjna IT, w związku z czym nasze lokalne spojrzenie jest różne. Naszym celem jest nie tyle minimalizacja złożoności (bo to poziom architektury biznesowej, na którą nie mamy wpływu), ale minimalizacja dodatkowej (dokładanej przez IT) złożoności.
Więc jeśli złożoność po stronie IT jest taka jak po stronie biznesu to jest to sukces i bardziej jej się nie da zmniejszyć.
2. Moim zdaniem w stwierdzeniach, że system złożony jest bardziej kosztowny, czy trudny, chodzi o porównanie do systemu mniej złożonego. Zupełnie niezasadne jest stwierdzenie, że 3 mniejsze łatwiej niż jeden duży. Bo te trzy muszą być zintegrowane, funkcjonalności są na nie rozpraszane, niektóre współdzielone - w takim przypadku musimy mówić o układzie a nie pojedynczym systemie.
3. Dobre praktyki moim zdaniem nie powodują całościowego wzrostu złożoności. One przenoszą złożoność z architektury IT na poziom zarządzania. Np. partycjonowanie architektury zmniejsza jej złożoność, ale zwiększa złożoność zarządzania.
Pozdrawiam
Dodaj komentarz