Inteca

Strategia prewencji przed fragmentacją i usuwania fragmentacji IT

2011.07.08

W poprzednich artykułach skupiliśmy się na genezie oraz problemach fragmentacji IT. W tym artykule opiszemy strategię oraz taktykę podejścia do defragmentacji portfela aplikacji. Pokażemy jak wykorzystując usługi i rozwiązania Inteca adresować narastające problemy portfela aplikacji.

Strategia defragmentacji portfela aplikacji jest zazwyczaj dwutorowa. Z jednej strony usuwamy istniejącą fragmentację IT, a z drugiej zabezpieczamy się przed jej odnowieniem (prewencja). Podejście do usuwania powinniśmy oprzeć na konsolidacji systemów. Rozwiązaniem prewencyjnym jest wdrożenie architektury korporacyjnej oraz architektury opartej o usługi (SOA).

Architektura korporacyjna i SOA a fragmentacja portfela IT

Architektura korporacyjna adresuje problem powstawania fragmentacji IT dzięki zastosowaniu modeli referencyjnych (procesów biznesowych, zdolności biznesowych, modelu informacyjnego, dekompozycji domenowej itd.) w inwestycjach IT. Dzięki modelom organizacja może na wczesnym etapie projektu (analiza i architektura biznesowa) wykryć tworzącą się redundancję funkcjonalności/danych i jej zapobiec. Kluczowym aspektem jest tutaj wprowadzenie ładu IT (IT Governance). Architektura zorientowana na usługi dopełnia to podejście wprowadzając możliwość wielokrotnego używania istniejących usług (funkcjonalności). SOA jest jedynym podejściem architektonicznym nie wymuszającym technologicznie fragmentacji IT. Z jednej strony architektura korporacyjna identyfikuje miejsca o wysokim ryzyku redundancji, a z drugiej architektura SOA umożliwia implementacje, która nie wprowadza fragmentacji IT. Ważnym aspektem jest tutaj integracja obu podejść. Artefakty informacyjne, procedury zgodności, procesy zarządcze i zarządzane to tylko wybrane elementy integracji obu podejść. Architektura Korporacyjna i SOA, aby przynosić oczekiwane rezultaty biznesowe muszą ze sobą współpracować. Przykładem rozwiązania, które integruje oba koncepty jest Inteca SOA Continuum.

Konsolidacja systemów IT

Konsolidacja systemów zawsze wiąże się z wyłączeniem jednej lub więcej aplikacji IT. Technologicznie jest to możliwe. Ciężko jest jednak zbudować „Business Case” dla usunięcia aplikacji. Wynika to w dużej mierze z często przyjmowanego w organizacjach modelu finansowania IT, który w skrócie można przedstawić następująco. Jednostki biznesowe ograniczają się do płacenia za stworzenie systemu. Następnie system przechodzi w ręce IT i jest tam utrzymywany przez długie lata ze wspólnego dla organizacji worka pieniędzy. W przedstawionym modelu brakuje przejrzystości. Jednostki biznesowe nie płacą za wykorzystanie systemu. Mają więc mylne przeświadczenie, że utrzymanie raz zbudowanego systemu nic nie kosztuje. Dodatkowo mając jedno miejsce powstawania kosztu utrzymania, czyli cały portfel aplikacji, nie znamy faktycznych kosztów przypadających na poszczególne aplikacje. W takiej sytuacji problemem staje się wyliczenie ROI dla projektu zamknięcia aplikacji.

Podejście Inteca

Poniżej przedstawimy podejście do tworzenia planu konsolidacji systemów, który uwzględnia opisany problem budowania „Business Case”. Oprzemy się na rozwiązaniach i usługach oferowanych przez Inteca. Podejście składa się z trzech kroków przedstawionych na poniższym rysunku.

1.

 

Krok 1 Analiza portfela aplikacji

Celem kroku jest identyfikacji systemów, które należy poddać konsolidacji oraz budowa argumentacji biznesowej dla konsolidacji. W osiągnięciu celu pomoże nam analiza portfela aplikacji – APM (Application Portfolio Management). Z perspektywy rozważanego problemu ważnym produktem analizy APM jest macierz rekomendacji (rysunek poniżej). Analiza pozycjonuje aplikacje w ćwiartkach macierzy wykorzystując trzy wartości: Wartość Biznesowa, Ryzyko Techniczne i Koszt. Macierz w jasny sposób identyfikuje aplikacje, które należy poddać konsolidacji. Dużą wartością APM jest to, że ocenę aplikacji wykonuje również biznes. Odpowiedzi biznesu pozycjonują aplikację w jednej z czterech ćwiartek macierzy rekomendacji. Jest to ważne w perspektywie późniejszego wsparcia biznesu dla planu konsolidacji zbudowanego w oparciu między innymi o wyniki APM.

 

 

Krok 2 Identyfikacja klastrów konsolidacyjnych

W tym kroku skupiamy się na budowie mapy zdolności biznesowych oraz mapowaniu zdolności biznesowych na systemy w organizacji (rysunek poniżej). Dzięki temu zabiegowi potrafimy wskazać elementy modelu biznesowego, które są zależne od konsolidowanych systemów. Celem kroku jest identyfikacja klastrów konsolidacyjnych, które są odpowiedzialne za fragmentację IT oraz ocena wpływu konsolidacji na model biznesowy.

Krok 3 Opracowanie planu konsolidacji

W tym kroku budujemy Heat Map (rysunek poniżej) i wiążemy konsolidację ze strategią biznesową organizacji. Stworzony w tym kroku harmonogram pozwala:

  • Uzasadnić biznesowo decyzję o konsolidacji systemów.
  • Wskazać wartości biznesowe w kolejnych Transition Architecture.
  • Pozyskać fundusze na konsolidację.
  • Otrzymać wsparcie biznesu.
  • Powiązać konsolidację systemów ze strategią biznesową.

Zastosowanie opisanego trzy krokowego podejścia do budowy planu konsolidacji systemów pozwoli organizacji w krótkim czasie:

  • Zidentyfikować systemy do konsolidacji
  • Uzasadnić konsolidację na poziomie poszczególnych systemów
  • Zbudować „Business Case”
  • Zdobyć poparcie biznesu
  • Przygotować wartościowy biznesowo plan migracji dla konsolidacji.

Dużą zaletą opisanego podejścia jest możliwość wykonania wszystkich kroków równocześnie. Pozwala to skrócić czas przygotowanie planu konsolidacji systemów do kilku miesięcy.

Powyżej opisaliśmy podejście do defragmentacji portfela IT jak również do zapobiegania fragmentacji portfela. Prewencja i usuwanie fragmentacji jest złożonym procesem. Zastosowanie wszystkich przedstawionych powyżej elementów jednocześnie daje gwarancję pozbycia się fragmentacji.

Enterprise Architecture

Architektura Korporacyjna

Analiza, projektowanie i planowanie Architektury Korporacyjnej w obszarach biznesu, danych, aplikacji i technologii w celu wsparcia zarządzania portfelem projektów i zarządzania projektami.

Używamy cookies w celach świadczenia usług i statystyk. Brak zmiany ustawień przeglądarki oznacza, że będą one umieszczane na Twoim urządzeniu. Możesz zmienić te ustawienia. zamknij