Upraszczanie systemów informatycznych

Architektura informatyczna przedsiębiorstwa po latach budowy niezależnych systemów i aplikacji oraz platform, które mają je integrować, przypomina talerz spaghetti. Modyfikacja jednego elementu powoduje wiele trudnych do przewidzenia konsekwencji. Kolejne projekty przedłużają się, rosną koszty, coraz częściej występują przestoje. Lekarstwem może być tylko uproszczenie środowiska.

Architektura typowego przedsiębiorstwa AD 2013 przypomina patchwork. Jest konsekwencją kilku- albo kilkunastoletniej praktyki wdrażania systemów. Takie przedsięwzięcia charakteryzuje cykl: najpierw potrzeba biznesowa, potem analiza systemowa, projektowanie architektury, wykonanie systemu, testy i wreszcie uruchomienie. Przedsiębiorstwa preferują rozwiązania zintegrowane, czyli jeden dostawca dostarcza komplet: sprzęt, system operacyjny, platformy, a czasami nawet własny system archiwizacyjny, metody uwierzytelnienia, szkolenia oraz system uprawnień. Wszystko pozostaje zamknięte w granicach jednej aplikacji, nazywanej silosem.

Cztery wdrożenia i pogrzeb

Potem taki system trafia do eksploatacji i poprawek: tutaj dorobić nową funkcjonalność, tam zapewnić zgodność ze zmienionymi przepisami, gdzie indziej zmodyfikować raport czy wydruk itd. Jedno, drugie, trzecie wdrożenie... Aż pojawia się potrzeba integracji. Najłatwiej jest dorobić interfejsy wymiany danych. I znowu: jeden interfejs, drugi, potem trzeci... Jak łatwo policzyć, z każdym kolejnym wdrożonym systemem liczba interfejsów rośnie iloczynowo. Efektem jest tzw. architektura spaghetti, czyli system, w którym modyfikacja jednego elementu powoduje wiele trudnych do określenia konsekwencji, tak jak wyciągnięcie jednej nitki makaronu ze spaghetti powoduje poruszenie całego dania.

Oczywiście, częściowym rozwiązaniem byłaby (i często jest) zmiana architektury na opartą na usługach (SOA - Service Oriented Infrastructure), porządkującą komunikację między systemami, ale ta zmiana z reguły napotyka problemy. Po pierwsze, szyna komunikacyjna sama w sobie jest nowym systemem i wymaga wdrożenia. Po drugie, potrzeba znaczących modyfikacji systemów bazowych (mają komunikować się nie bezpośrednio, tylko za pośrednictwem platformy i jej usług). Po trzecie i najważniejsze, w krótkim okresie taka zmiana nie daje bezpośredniej korzyści biznesowej mierzonej jako wzrost sprzedaży lub spadek kosztów, trudno więc pozyskać sponsora w firmie dla kosztownej inwestycji.

Jakby problemów było mało, złożoność środowiska infrastrukturalnego zaczyna przekraczać masę krytyczną. Jeśli każdy system wytworzył własną platformę bazodanową, po paru latach w przedsiębiorstwie są trzy produkty w ośmiu wersjach rozwojowych. Dołączając do tego systemy operacyjne, sprzęt, technologie sieciowe, systemy archiwizacji, technologie middleware itp., można zrozumieć, dlaczego zaczynają dziać się rzeczy niepokojące: spadek dostępności, lawinowy wzrost kosztów, przedłużające się projekty, ciągłe przestoje technologiczne oraz zmęczenie i frustracja personelu IT.

Strategia upraszczania infrastruktury

To dobry moment, żeby rozpocząć strategię upraszczania. Zazwyczaj będzie to wymagać kilku kroków.

1. Standaryzacja

W pierwszym etapie należy określić standardy technologiczne przedsiębiorstwa i je wdrożyć. Jeśli więc bazy danych - należy wybrać jedną, dwie platformy (w jednej wersji!), ograniczoną liczbę systemów operacyjnych (np. jedną platformę uniksową, jedną windowsową), określić standard "biurkowego" środowiska pracy (może być w wersji stacjonarnej i przenośnej) itd. W efekcie z kilkudziesięciu technologii robi się kilkanaście, co od razu upraszcza zarządzanie i zmniejsza jego koszty.

2. Konsolidacja

Infrastruktura zostaje "uwolniona z silosów". Jeśli sześć systemów miało osiem serwerów baz danych (bo dwa były dla bezpieczeństwa zdublowane), to prawdopodobnie docelowo potrzebne są nie więcej niż dwa lub trzy, w tym zapasowy. Podobnie z serwerami i systemami operacyjnymi. Pozwala to zaoszczędzić nie tylko na sprzęcie, ale także na licencjach i ich odnowieniach. Konsolidacja na początku wymaga inwestycji, ale łatwo jest udowodnić jej opłacalność: zakup nowego sprzętu i licencji dzisiaj pozwoli na oszczędności w przyszłości.

3. Wirtualizacja

Kolejnym krokiem może być wirtualizacja, potrzebna zwłaszcza na warstwie serwerowej. Zamiast kilkudziesięciu serwerów fizycznych można mieć kilka, może kilkanaście, zaś resztę powoływać ad hoc, w miarę potrzeb. Wirtualizacja środowiska hardware pozwala na kolejne znaczące ograniczenie kosztów i uproszczenie zarządzania. Ale nie tylko - również na większą elastyczność biznesową. Moc obliczeniowa, dotąd zamknięta w granicach jednego serwera lub silosa aplikacyjnego, może zostać "uwolniona" i może być przenoszona.

Na przykład przed świętami, gdy aplikacja sprzedażowa przeżywa oblężenie, moc może zostać wykorzystana do jej wsparcia; kiedy zaś potem trwa zamknięcie księgowego roku, ta sama moc może być wykorzystana do wsparcia aplikacji finansowych. Wirtualizacja może również dotyczyć środowiska pracy: zamiast "grubych" stacji roboczych i laptopów, przedsiębiorstwo może zaoferować tańsze w zakupie i utrzymaniu "cienkie" terminale lub urządzenia mobilne.

4. Optymalizacja

Ten etap polega na sukcesywnym doskonaleniu infrastruktury. Nie tylko poprzez dalszą konsolidację i standaryzację, a także inne działania. Przede wszystkim kontrolę jej rozbudowy, aby korzystać tylko z posiadanych platform podczas wdrażania i wymiany systemów, a także monitoring i optymalizację pojemności. Również trzeba rozważyć oddawanie części rozwiązań do chmury publicznej, bo nie ma dzisiaj powodów, aby przedsiębiorstwo miało pewne systemy (np. pocztę elektroniczną) u siebie.

W toku optymalizacji warto badać całkowite koszty utrzymania. Koszty zarządzania infrastrukturą mogą sięgnąć nawet połowy (!) jej kosztu. Uproszczona może być więc nie tylko struktura aplikacji, ale i zespołów. Jeśli specjaliści nie będą musieli nadzorować infrastruktury, będą mogli skupić się na rozwoju.

Strategia upraszczania aplikacji

Wprowadzanie ładu w infrastrukturze musi przebiegać jednocześnie z wprowadzaniem podobnych porządków w warstwie aplikacyjnej. Jest na to kilka sposobów, mniej albo bardziej skomplikowanych.

1. Wyłączanie aplikacji

Jedną, najbardziej oczywistą i dlatego chyba najczęściej pomijaną i najtrudniejszą metodą jest proste wyłączanie aplikacji (ang. retirement). Potrzeby biznesowe pojawiają się i znikają, zadania, które były istotne kilka lat temu, przestają być potrzebne. Przykładem może być aplikacja pozwalająca na przyjmowanie zamówień faksem. Faks jako medium w wielu branżach wychodzi z użycia, zastępowany przez rozwiązania e-commerce oparte na sieci, znacznie prostsze, bezpieczniejsze i tańsze w utrzymaniu.

Często też nowe aplikacje mają funkcjonalność starych. Kiedyś np. potrzebne były osobne systemy zarządzania zamówieniami lub stanami magazynowymi, dzisiaj taka funkcjonalność dostępna jest praktycznie we wszystkich systemach ERP, w tym tych najtańszych. Po co więc osobny system?

Usunięcie danej aplikacji oznacza też często szansę na uproszczenie procesów w firmie - podobnie jak w przykładzie faksowych zamówień. Zadaniem jest tak naprawdę nie usunięcie aplikacji faksowej, ale całego procesu sprzedażowego opartego na faksie.

Z jednej strony, to szansa na dodatkowe oszczędności, z drugiej - wielkie wyzwanie. Problem z wyłączaniem aplikacji jest taki, że każda z nich ma oddane grono adwokatów - przyzwyczajonych do nich, pracujących od lat, często milcząco zakładających, że zniknięcie danej aplikacji oznacza zniknięcie miejsc pracy z nią związanych. Zabierając się do uproszczenia środowiska IT, trzeba pamiętać, że to zadanie nie tylko techniczne, ale przede wszystkim organizacyjne, czy wręcz psychologiczne.

2. Archiwizacja danych

Wyłączeniu aplikacji może towarzyszyć archiwizacja danych, np. na potrzeby raportowe lub audytowe. Należy się zastanowić, czy firma potrzebuje wszystkich danych (np. o każdej transakcji), czy tylko tzw. agregatów (np. wielkości sprzedaży w podziale na tygodnie). Do archiwizacji można wykorzystać platformę hurtowni danych, jeśli firma ją wdrożyła. Pozwala sięgnąć do danych w każdej chwili, jest przygotowana na duże objętości, a - w przeciwieństwie do prostego pozostawienia aplikacji - nie wymaga osobnej licencji ani specjalnego zarządzania.

3. Refaktoring

Wreszcie ostatnią strategią eliminacji aplikacji jest refaktoring, czyli ich ponowne wykonanie, ale przy użyciu tańszych, bardziej nowoczesnych i łatwiejszych w utrzymaniu technologii. W ten sposób system napisany w latach 90. na platformie klient-serwer można dzisiaj przepisać na aplikację trójwarstwową, przy okazji ją upraszczając, i zaoszczędzić na kosztach utrzymania, kosztach wprowadzania zmian oraz licencjach, np. zastępując platformy komercyjne narzędziami open source.

Na koniec warto powiedzieć: ładu raz zrobionego nie wolno zmarnować. Równocześnie z porządkowaniem warstwy aplikacyjnej przedsiębiorstwo powinno wdrożyć zasady ładu architektonicznego (ang. architecture governance), a więc kontrolę procesów rozwojowych i zakupowych z uwzględnieniem opracowanej wizji architektury przedsiębiorstwa. Inaczej za parę lat może obudzić się w tej samej rzeczywistości, z której właśnie się wyrwało: czyli zbyt dużej liczby zbyt złożonych i trudnych w utrzymaniu aplikacji.

Na pierwszy ogień

W każdym przedsiębiorstwie koszty zarządzania środowiskiem informatycznym są inne; podobnie jak awaryjność poszczególnych komponentów i nakład pracy na ich utrzymanie. Ale można być niemal pewnym, że - zgodnie z zasadą Pareto - za 80% kosztów utrzymania odpowiada 20% infrastruktury i aplikacji. Pierwszym krokiem powinno być więc wskazanie tych krytycznych 20%, na których warto się skoncentrować, szukając okazji do uproszczeń i oszczędności.

Czy warto? Do wszystkich racjonalnych argumentów biznesowych dodajmy jeszcze jeden. Odpowiedzmy sobie na pytanie: czy jako informatycy chcemy się koncentrować na wymyślaniu nowych rozwiązań, czy wolimy do końca kariery utrzymywać wiele systemów, często starych i niewydajnych? Odpowiedź powinna być prosta; pomoże ona uzyskać motywację do zajęcia się uproszczeniem systemów.

ABC upraszczania

Archiwizacja danych - przenoszenie danych z wyłączanych systemów do innych, np. na platformę hurtowni danych. Często jednocześnie następuje zmniejszenie ilości danych poprzez tworzenie tzw. agregatów.

Architektura spaghetti - duża liczba aplikacji powiązanych z sobą interfejsami, gdzie każda modyfikacja jednego systemu powoduje lawinę zmian w systemach i interfejsach.

Konsolidacja - drugi po standaryzacji krok uproszczenia zasobów infrastruktury. Polega na zmniejszeniu liczby fizycznych instancji komponentów (np. liczby serwerów) i umieszczenie ich na mniejszej liczbie większych, "silniejszych". Pozwala zoptymalizować wykorzystanie infrastruktury, zaoszczędzić na licencjach i zarządzaniu.

Ład architektoniczny - sposób na zapewnienie, by nowe projekty rozwojowe i wdrożeniowe były zgodne z docelową wizją infrastruktury i aplikacji, prowadząc do utrzymania i dalszego ograniczania kosztów utrzymania środowiska informatycznego. Warunek konieczny udanego uproszczenia zasobów IT przedsiębiorstwa.

Optymalizacja - ostatni krok w zarządzaniu infrastrukturą, polegający na sukcesywnym ograniczaniu zasobów, upraszczaniu struktury i zarządzania, a także przenoszeniu wybranych technologii, systemów i zasobów do chmury publicznej.

Silos - architektura, w której jeden element infrastruktury (np. serwer, platforma bazodanowa lub aplikacyjna) obsługuje tylko jedną aplikację. Prowadzi do niskiej dostępności, nieoptymalnego wykorzystania infrastruktury (np. niektóre serwery są przeciążone, inne niedociążone, ale mocy nie daje się przemieścić między nimi) i trudności w zarządzaniu, a w konsekwencji zwiększenia kosztów.

Standaryzacja - pierwszy krok uproszczenia infrastruktury, wybór i wdrożenie mniejszej liczby (najlepiej: jednego) produktu danego typu, np. systemu operacyjnego. Pozwala ograniczyć koszty zarządzania środowiskiem informatycznych, choć jeszcze nie prowadzi do optymalizacji wykorzystania posiadanych zasobów.

Refaktoring - technika polegająca na zastępowaniu starej aplikacji nową, z zewnątrz "wyglądającą" tak samo, ale wykonaną w innej (tańszej, łatwiejszej w utrzymaniu) technologii. Pozwala zaoszczędzić na kosztach zarządzania architekturą aplikacji oraz ograniczyć awaryjność środowiska IT, jednocześnie prowadząc do jego konsolidacji i optymalizacji.

Wirtualizacja - zamiana fizycznych komponentów infrastruktury na wirtualne. Dotyczy przede wszystkim serwerów, przestrzeni dyskowej oraz środowiska użytkownika. Na jednym fizycznym komponencie (np. serwerze) może zostać uruchomionych wiele wirtualnych, a zasoby sprzętowe mogą być swobodnie przemieszczane między nimi.

Wyłączenia systemów - wyłączanie starych, nieużywanych systemów. Najlepiej powiązać ze zmianą procesów w przedsiębiorstwie tak, by zadania obsługiwane przez stary system były upraszczane lub usuwane - by nie odtwarzać ich w pozostających systemach. Zadanie tyleż z dziedziny technologii, co zarządzania i psychologii - bowiem każda aplikacja zawsze ma swoich wiernych użytkowników.