Zarządzanie portfelem aplikacji - Application portfolio management

IT Application Zarządzanie portfelem ( APM ) jest praktyką, która pojawiła się w połowie do wielkogabarytowego technologii informatycznych (IT) organizacji od połowy 1990 roku. Zarządzanie portfelem aplikacji próbuje wykorzystać wnioski płynące z zarządzania portfelem finansowym, aby uzasadnić i zmierzyć korzyści finansowe każdej aplikacji w porównaniu z kosztami jej utrzymania i eksploatacji.

Ewolucja praktyki

Najprawdopodobniej najwcześniejsza wzmianka o portfolio aplikacji pojawiła się w artykule HBR Cyrusa Gibsona i Richarda Nolana „Managing the Four Stages of EDP Growth” w 1974 roku.

Gibson i Nolan zasugerowali, że zrozumienie i pomyślne wykorzystanie IT przez firmy „rośnie” w przewidywalnych etapach, a postęp danej firmy na tych etapach można mierzyć obserwując portfel aplikacji, świadomość użytkowników, praktyki zarządzania IT i zasoby IT w kontekście analizy całkowitych wydatków na IT.

Firma Nolan, Norton & Co. była pionierem w stosowaniu tych koncepcji w praktyce, m.in. dzięki badaniom w DuPont, Deere, Union Carbide, IBM i Merrill Lynch. W ramach tych „ocen etapów” zmierzyli stopień, w jakim każda aplikacja wspierała lub „obejmowała” każdą funkcję lub proces biznesowy, wydatki na aplikację, jej cechy funkcjonalne i techniczne. Środki te zapewniły kompleksowy obraz zastosowania IT w biznesie, mocne i słabe strony oraz mapę drogową do poprawy.

Metoda APM została powszechnie przyjęta pod koniec lat 80. i przez lata 90., gdy organizacje zaczęły reagować na zagrożenie niepowodzeniem aplikacji, gdy data zmieniła się na rok 2000 (zagrożenie znane jako rok 2000 lub rok 2000). W tym czasie dziesiątki tysięcy organizacji IT na całym świecie opracowało obszerną listę swoich aplikacji wraz z informacjami o każdej aplikacji.

W wielu organizacjach wartość opracowania tej listy została zakwestionowana przez liderów biznesu zaniepokojonych kosztami sprostania ryzyku roku 2000 . W niektórych organizacjach pojęcie zarządzania portfelem zostało przedstawione przedsiębiorcom odpowiedzialnym za budżet IT jako korzyść z wykonywania pracy, wykraczającą poza zarządzanie ryzykiem awarii aplikacji .

Istnieją dwie główne kategorie rozwiązań do zarządzania portfelem aplikacji, ogólnie określane jako podejście „odgórne” i „oddolne”. Pierwszą potrzebą w każdej organizacji jest zrozumienie, jakie aplikacje istnieją i jakie są ich główne cechy (takie jak elastyczność, łatwość konserwacji, właściciel itp.), Zazwyczaj określane jako „Wykaz”. Innym podejściem do APM jest uzyskanie szczegółowego zrozumienia aplikacji znajdujących się w portfelu poprzez analizę kodu źródłowego aplikacji i powiązanych z nim komponentów w bazie danych repozytorium (tzw. „Bottom Up”). Narzędzia do eksploracji aplikacji, obecnie sprzedawane jako narzędzia APM, obsługują to podejście.

Dostępnych jest setki narzędzi wspierających podejście „odgórne”. Nie jest to zaskakujące, ponieważ większość zadań polega na zebraniu odpowiednich informacji; faktyczną obsługę i przechowywanie informacji można wdrożyć stosunkowo łatwo. Z tego powodu wiele organizacji omija narzędzia komercyjne i używa programu Microsoft Excel do przechowywania danych o zapasach. Jeśli jednak zapasy staną się skomplikowane, obsługa programu Excel może stać się kłopotliwa. Automatyczne aktualizowanie danych nie jest dobrze obsługiwane przez rozwiązanie oparte na programie Excel. Wreszcie, takie rozwiązanie Inventory jest całkowicie niezależne od potrzeb rozumienia „oddolnych”.

Uzasadnienie biznesowe dla APM

Według Forrester Research , „W przypadku budżetów operacyjnych IT przedsiębiorstwa wydają dwie trzecie lub więcej na bieżące operacje i konserwację”.

Często spotyka się organizacje, które mają wiele systemów pełniących tę samą funkcję. Powodów tego powielania może być wiele, w tym dawne znaczenie wydziałowych informatyki, silosy aplikacji z lat 70. i 80. XX wieku, proliferacja fuzji i przejęć przedsiębiorstw oraz nieudane próby przyjęcia nowych narzędzi. Niezależnie od powielania, każda aplikacja jest oddzielnie obsługiwana i okresowo aktualizowana, a nadmiarowość zwiększa złożoność i koszty.

Ponieważ znaczna większość wydatków jest przeznaczona na zarządzanie istniejącymi aplikacjami IT, przejrzystość bieżącej inwentaryzacji aplikacji i zużycia zasobów jest głównym celem zarządzania portfelem aplikacji. Umożliwia to firmom: 1) identyfikację i eliminację częściowo i całkowicie nadmiarowych aplikacji, 2) ilościowe określenie stanu aplikacji pod względem stabilności, jakości i łatwości konserwacji, 3) ilościowe określenie wartości biznesowej / wpływu aplikacji oraz względnego znaczenia każdej aplikacji do biznesu, 4) alokować zasoby zgodnie ze stanem i wagą aplikacji w kontekście priorytetów biznesowych.

Przejrzystość pomaga również w planowaniu strategicznym i rozprasza konflikt biznes / IT, ponieważ gdy liderzy biznesowi rozumieją, w jaki sposób aplikacje wspierają ich kluczowe funkcje biznesowe oraz wpływ przestojów i niskiej jakości, rozmowy odwracają się od obwiniania IT za nadmierne koszty i w kierunku najlepszego wydawania cenne zasoby wspierające priorytety korporacyjne.

Teczka

Opierając się na pomysłach z zarządzania portfelem inwestycyjnym, praktycy APM zbierają informacje o każdej aplikacji używanej w firmie lub organizacji, w tym o kosztach zbudowania i utrzymania aplikacji, wytworzonej wartości biznesowej, jakości aplikacji i oczekiwanej żywotności. Korzystając z tych informacji, zarządzający portfelem jest w stanie przedstawić szczegółowe raporty dotyczące wydajności infrastruktury IT w odniesieniu do kosztu posiadania i dostarczanej wartości biznesowej.

Definicja wniosku

W zarządzaniu portfelem aplikacji definicja aplikacji jest elementem krytycznym. Wielu usługodawców pomaga organizacjom w tworzeniu własnych definicji ze względu na często kontrowersyjne wyniki wynikające z tych definicji.

  • Oprogramowanie aplikacyjne - wykonywalny składnik oprogramowania lub ściśle powiązany zestaw wykonywalnych składników oprogramowania (jeden lub więcej), wdrożonych razem, które zapewniają niektóre lub wszystkie serie kroków niezbędnych do tworzenia, aktualizowania, zarządzania, obliczania lub wyświetlania informacji dla określonej firmy. cel, powód. Aby zostać policzonym, każdy składnik nie może należeć do innej aplikacji.
  • Komponent oprogramowania - wykonywalny zestaw instrukcji komputerowych zawartych w pojedynczym kontenerze wdrożeniowym w taki sposób, że nie można go dalej rozdzielić. Przykłady obejmują bibliotekę Dynamic Link Library , stronę internetową ASP i aplikację „ EXE ” wiersza poleceń . Plik zip może zawierać zero lub więcej składników oprogramowania, ponieważ łatwo jest je dalej podzielić (przez rozpakowanie archiwum ZIP).

Aplikacja i składnik oprogramowania to terminy techniczne używane do opisania konkretnego wystąpienia klasy oprogramowania aplikacyjnego na potrzeby zarządzania portfelem IT . Zobacz oprogramowanie aplikacyjne, aby zapoznać się z definicją dla osób niepraktykujących w zakresie zarządzania IT lub architektury korporacyjnej.

Sztuka i praktyka zarządzania portfelem aplikacji wymaga dość szczegółowej i konkretnej definicji aplikacji w celu stworzenia katalogu aplikacji zainstalowanych w organizacji.

Wymagania dotyczące definicji aplikacji

Definicja aplikacji ma następujące potrzeby w kontekście zarządzania portfelem aplikacji:

  • Członkowie zespołu biznesowego muszą łatwo wyjaśniać, rozumieć i stosować.
  • Musi mieć sens w zakresie rozwoju, operacji i zarządzania projektami w grupach IT.
  • Musi być użyteczna jako dane wejściowe do złożonej funkcji, której wynikiem jest całkowity koszt portfela. Innymi słowy, istnieje wiele czynników, które prowadzą do ogólnego kosztu portfolio IT. Jednym z tych czynników jest sama liczba aplikacji. Dlatego definicja aplikacji musi być przydatna w tych obliczeniach.
  • Musi być przydatny dla członków zespołu architektury korporacyjnej, którzy próbują ocenić projekt pod kątem ich celów optymalizacji i uproszczenia portfela.
  • Musi jasno określić granice aplikacji, tak aby osoba pracująca nad mierzalnym działaniem „upraszczania portfela” nie mogła tak po prostu przedefiniować granic dwóch istniejących aplikacji w taki sposób, aby nazwać je pojedynczą aplikacją.

Wiele organizacji zmieni definicję aplikacji w kontekście zarządzania portfelem IT i praktyk ładu korporacyjnego . Z tego powodu tę definicję należy traktować jako początek pracy.

Przykłady

Definicja wniosku może być trudna do jednoznacznego przekazania. W organizacji IT mogą występować drobne różnice w definicji między zespołami, a nawet w ramach jednego zespołu IT. Definicję można zilustrować przykładami. Poniższa sekcja zawiera kilka przykładów rzeczy, które są aplikacjami, rzeczy, które nie są aplikacjami i rzeczy, które składają się z dwóch lub więcej aplikacji.

Włączenia

Zgodnie z tą definicją następujące aplikacje to:

  • Punkt końcowy usługi sieci Web, który przedstawia trzy usługi internetowe: InvoiceCreate, InvoiceSearch i InvoiceDetailGet
  • Zorientowana na usługi aplikacja biznesowa ( SOBA ), która przedstawia interfejs użytkownika do tworzenia faktur i która odwraca się i wywołuje usługę InvoiceCreate . (zwróć uwagę, że sama usługa to inna aplikacja).
  • Aplikacja mobilna, która jest publikowana w sklepie z aplikacjami przedsiębiorstwa , a tym samym wdrażana na urządzeniach przenośnych należących do pracowników lub obsługiwanych przez nich, umożliwiających uwierzytelniony dostęp do danych i usług.
  • Starszy system składa się z bogatego klienta, serwer oparty na warstwie pośredniej, a baza danych, z których wszystkie są ściśle sprzężone. (np. zmiany w jednym z dużym prawdopodobieństwem spowodują zmiany w innym).
  • System publikowania witryn internetowych, który pobiera dane z bazy danych i publikuje je w formacie HTML jako podstronę pod publicznym adresem URL.
  • Baza danych, która przedstawia dane w skoroszycie programu Microsoft Excel, w którym odpytuje informacje dotyczące układu i obliczeń. Jest to interesujące, ponieważ sama baza danych jest aplikacją, chyba że baza danych jest już zawarta w innej aplikacji (na przykład w starszym systemie).
  • Arkusza kalkulacyjnego Excel , który zawiera spójny zestaw makr wielokrotnego użytku, które dostarczają wartość biznesową. Sam arkusz kalkulacyjny stanowi kontener wdrożeniowy dla aplikacji (podobnie jak plik TAR lub CAB ).
  • Zestaw stron internetowych ASP lub PHP, które współpracują ze sobą, zapewniając wrażenia i logikę aplikacji internetowej. Jest całkowicie możliwe, że podobiekt kwalifikowałby się jako oddzielny wniosek zgodnie z tą definicją, gdyby połączenie było luźne.
  • Punkt końcowy usługi sieci Web ustanowiony do komunikacji maszyna-maszyna (nie do interakcji międzyludzkich), ale który można racjonalnie rozumieć jako reprezentujący jeden lub więcej użytecznych kroków w procesie biznesowym.

Wyłączenia

Poniższe nie są aplikacjami:

  • Witryna HTML.
  • Baza danych, która zawiera dane, ale nie jest częścią żadnej serii kroków w celu dostarczenia wartości biznesowej przy użyciu tych danych.
  • Usługa internetowa, która strukturalnie nie może być częścią zestawu kroków, które zapewniają wartość. Na przykład usługa internetowa, która wymaga danych przychodzących, które naruszają udostępniony schemat.
  • Samodzielny skrypt wsadowy, który porównuje zawartość dwóch baz danych, wykonując wywołania do każdej z nich, a następnie wysyła wiadomość e-mail do aliasu monitorującego, jeśli zostaną zauważone anomalie danych. W takim przypadku skrypt wsadowy najprawdopodobniej będzie ściśle powiązany z co najmniej jedną z dwóch baz danych, a zatem powinien zostać włączony do granicy aplikacji, która zawiera bazę danych, z którą jest najściślej powiązany.

Kompozyty

Poniżej znajduje się wiele zastosowań:

  • Kompozyt SOA Aplikacja składa się z zestawu usług wielokrotnego użytku oraz interfejs użytkownika, który korzysta z tych usług. Znajdują się tutaj co najmniej dwie aplikacje (interfejs użytkownika i jeden lub więcej komponentów usług). Każda usługa nie jest liczona jako aplikacja.
  • Starsza aplikacja typu klient-serwer, która zapisuje dane w bazie danych w celu przechowywania danych, oraz arkusz kalkulacyjny programu Excel, który używa makr do odczytywania danych z bazy danych w celu przedstawienia raportu. W tym przykładzie są DWIE aplikacje. Baza danych bez wątpienia należy do starszej aplikacji, ponieważ została z nią opracowana, dostarczona wraz z nią i jest z nią ściśle powiązana. Dzieje się tak nawet wtedy, gdy starszy system używa tych samych procedur składowanych, co arkusz kalkulacyjny programu Excel.

Metody i miary oceny wniosków

Istnieje wiele popularnych miar finansowych, a nawet więcej mierników różnych (niefinansowych lub złożonych) typów, które są używane do oceny aplikacji lub systemów informatycznych.

Zwrot z inwestycji (ROI)

Zwrot z inwestycji to jeden z najpopularniejszych wskaźników pomiaru i oceny wyników stosowanych w analizie biznesowej. Analiza zwrotu z inwestycji (jeśli jest stosowana prawidłowo) jest potężnym narzędziem do oceny istniejących systemów informatycznych i podejmowania świadomych decyzji dotyczących zakupu oprogramowania i innych projektów. Jednak ROI jest miernikiem zaprojektowanym w określonym celu - do oceny rentowności lub efektywności finansowej. Nie może niezawodnie zastąpić wielu innych wskaźników finansowych w dostarczaniu ogólnego obrazu ekonomicznego rozwiązania informacyjnego. Próby wykorzystania ROI jako jedynej lub głównej miary do podejmowania decyzji dotyczących systemów informacyjnych nie mogą być produktywne. Może to być właściwe w bardzo ograniczonej liczbie przypadków / projektów. ROI jest miarą finansową i nie dostarcza informacji o wydajności lub skuteczności systemów informatycznych.

Ekonomiczna wartość dodana (EVA)

Miara wyników finansowych przedsiębiorstwa oparta na majątku rezydualnym obliczona poprzez odjęcie kosztu kapitału od zysku operacyjnego (skorygowana o podatki na zasadzie kasowej). (Nazywany również „zyskiem ekonomicznym”).

Wzór = zysk operacyjny netto po opodatkowaniu (NOPAT) - (kapitał * koszt kapitału)

Całkowity koszt posiadania (TCO)

Całkowity koszt posiadania to sposób obliczenia kosztu aplikacji w określonym przedziale czasu. W modelu TCO koszty sprzętu, oprogramowania i robocizny są rejestrowane i organizowane na różnych etapach cyklu życia aplikacji. Dogłębny model TCO pomaga kierownictwu zrozumieć rzeczywisty koszt aplikacji, gdy próbuje zmierzyć koszty budowy, eksploatacji / wsparcia i koszty pośrednie. Wiele dużych firm konsultingowych ma zdefiniowane strategie budowania pełnego modelu TCO.

Całkowity wpływ ekonomiczny (TEI)

TEI zostało opracowane przez firmę Forrester Research Inc. Forrester twierdzi, że TEI systematycznie analizuje potencjalne skutki inwestycji technologicznych w czterech wymiarach: wpływ kosztów na IT; korzyści - wpływ na biznes; elastyczność - przyszłe opcje stworzone przez inwestycję; ryzyko - niepewność.

Wartość biznesowa IT (ITBV)

Program ITBV został opracowany przez firmę Intel Corporation w 2002 roku. Program wykorzystuje zestaw miar finansowych wartości biznesowej, zwanych Business Value Dials (Indicators). Jest to program wielowymiarowy, obejmujący komponent biznesowy i jest stosunkowo łatwy do wdrożenia.

Stosowana ekonomia informacji (AIE)

AIE to metoda analizy decyzji opracowana przez Hubbard Decision Research. AIE twierdzi, że jest „pierwszą prawdziwie naukową i teoretycznie poprawną metodą”, która opiera się na kilku metodach z teorii decyzji i analizie ryzyka, w tym na wykorzystaniu metod Monte Carlo. AIE nie jest często używany ze względu na jego złożoność.

Bibliografia