Zarządzanie portfelem aplikacji: klucz do cyfrowej transformacji

Digitalizacja to obecnie codzienność w każdej gałęzi biznesu. W tym kontekście ważne jest, aby firmy zwracały baczną uwagę na obszar IT, ponieważ to właśnie on jest często najważniejszym czynnikiem decydującym o powodzeniu inicjatyw związanych z transformacją. Kluczową rolę powinno tu odgrywać w szczególności zarządzanie portfelem aplikacji, jako że mają one zasadnicze znaczenie w tworzeniu „cyfrowego bliźniaka” organizacji. Co więcej, krytyczne spojrzenie na całą mapę aplikacji ujawnia potencjał optymalizacji i znacząco przyczynia się do wdrażania innowacji w biznesie.

Wychodząc od aplikacji, dokumentację architektury korporacyjnej (ang. Enterprise Architecture – EA) i cyfrowego bliźniaka można rozszerzyć zarówno w kierunku architektury biznesowej, jak i architektury technologicznej. Jednak to nie architektura jest tutaj ostatecznym celem. Należy raczej położyć nacisk na wyniki projektu transformacji, a przede wszystkim na ich wartość dodaną dla organizacji i użytkowników. Jaka jest jednak wartość dodana zarządzania portfelem aplikacji i w jaki sposób może ono wspierać projekty transformacyjne?

Więcej na ten temat oraz o znaczeniu projektowania całej mapy aplikacji dowiesz się z niniejszego artykułu. Sprawdź, co musisz wiedzieć o zarządzaniu portfelem aplikacji (ang. Application Portfolio Management – APM).

Nie ma praktycznie takich projektów transformacyjnych, które nie wymagałyby dostosowania aplikacji. Aby jak najlepiej wspierać wymagane zmiany w architekturze biznesowej, należy albo wprowadzić nowe aplikacje, albo dostosować istniejące aplikacje.

Łącząc to z zarządzaniem portfelem aplikacji, możliwe jest wprowadzanie innowacji tam, gdzie są one najbardziej potrzebne, a nie tylko tam, gdzie najłatwiej je wdrożyć. W tym celu wszystkie aplikacje, zarówno z krótkim, jak i długim cyklem życia, innowacyjne lub „utrzymujące system”, muszą być odpowiednio zarządzane w ramach portfela aplikacji.

• Jakie aplikacje istnieją w firmie i kto jest za nie odpowiedzialny?
• Jakie usługi aplikacji są dostarczane przez aplikację? Gdzie są one używane?
• Czy któraś z istniejących aplikacji nadaje się do świadczenia usług wymaganych przez użytkowników?
• W której fazie cyklu życia znajduje się aplikacja i jaka jest strategia inwestycyjna dla tej aplikacji?
• Jakie są bieżące przepływy informacji? Jakie interfejsy oferują istniejące aplikacje?
• Jakie są cykle zmian aplikacji? Czy można ją szybko dostosować do zmieniających się potrzeb użytkowników?
• Jakie zasady architektoniczne mają zastosowanie? W jakich warunkach można od nich odstąpić?
• Jakie oprogramowanie systemowe jest używane do implementacji aplikacji i ich interfejsów?
• Gdzie w środowisku aplikacji występują redundancje funkcjonalne? Czy rozwiązaniem może być konsolidacja?
• W jaki sposób ocenia się koszty, stabilność i sprawność technologiczną aplikacji? Jakie mierniki można zastosować?

W wielu branżach redundancje funkcjonalne często mają duży potencjał optymalizacji. Celem jest zatem odkrycie i zapobieganie takim redundancjom. Jeśli projekt transformacji miałby być czysto biznesowy, takie ustalenia nie byłyby możliwe. Używanie różnych aplikacji do tych samych zadań powoduje niepotrzebne koszty i często nie przynosi znaczącej wartości dodanej dla użytkowników. Dlatego jednym z celów zarządzania aplikacjami jest zmniejszenie tej heterogeniczności poprzez konsolidację i usprawnienie całej mapy aplikacji.¹

Doświadczenie pokazuje, że firmy mają bardzo różne wyobrażenia na temat tego, czym jest aplikacja. Termin „aplikacja” jest definiowany w następujący sposób:

Lub po prostu: program (komputerowy), który wykonuje funkcję przydatną dla użytkowników.

W praktyce istnieją inne wymagania, które musi spełniać aplikacja:

• Aplikacja odwzorowuje logikę biznesową. Przykładem tego jest np. funkcja dynamicznego obliczania ceny biletu w ośrodku narciarskim.
• Zwykle nie jest ona wykonywalna bez wsparcia innego oprogramowania systemowego, takiego jak systemy operacyjne lub systemy zarządzania bazami danych.
• Usługi aplikacji oferowane przez aplikację są w niej osadzone, dzięki czemu zarówno sama aplikacja, jak i jej usługi są wymienne. W ten sposób (fizyczna) aplikacja zawsze ma swój własny cykl życia.

„Portfel aplikacji opisuje zestaw istniejących i planowanych aplikacji.¹ Obejmuje nie tylko listę aplikacji, ale w szczególności oceny, które umożliwiają podejmowanie decyzji dotyczących planowanego dalszego rozwoju środowiska aplikacji”.

Poniżej przedstawiamy metodyczne podejście do zarządzania portfelem aplikacji. Można je dostosować indywidualnie do danej firmy i zintegrować z ramami architektury korporacyjnej, takimi jak TOGAF®. Na początku opiszemy interesariuszy i typy użytkowników, którzy są zazwyczaj zaangażowani w APM.

W APM zaangażowane są role biznesowe zarówno z biznesu, jak i IT.

Architekt korporacyjny jest odpowiedzialny za dokumentowanie i regularną ocenę aplikacji. Przy udziale innych interesariuszy określa, jakie informacje na temat aplikacji mają być gromadzone i przez kogo mają być dokumentowane. Przygotowuje wyniki oceny i jest odpowiedzialny za analizę portfela oraz zapewnia, że potencjalne ulepszenia są dokumentowane, oceniane i priorytetyzowane w formie wymagań.

Architekci jednostek biznesowych przejmują zadania architektów korporacyjnych, zwłaszcza w większych firmach, i ściśle z nimi współpracują. Koordynują zbieranie potrzebnych informacji i ocenę aplikacji oraz opracowywanie wymagań swojej jednostki na potrzeby rozwoju jednej lub więcej strategicznych zdolności. 

Właściciele aplikacji ponoszą główną odpowiedzialność za aplikacje będące w ich gestii. Ta rola biznesowa odpowiada roli menedżera usług, która jest powszechnie znana z IT Infrastructure Library (ITIL) ³. Właściciele aplikacji zapewniają przestrzeganie umów dotyczących poziomu usług. Działają jako mediatorzy między jednostką biznesową, operacjami IT i zespołami programistycznymi. Są również odpowiedzialni za dokumentowanie aplikacji będących pod ich nadzorem. Rola ta jest często podzielona na osobę odpowiedzialną z perspektywy biznesowej i jedną z perspektywy technicznej, przy czym ważne jest, aby upewnić się, że obowiązki są precyzyjnie zdefiniowane.

Pracownicy działów biznesowych mogą zapewniać wsparcie w opisywaniu usług aplikacji. Pomocni są również menedżerowie operacji IT, szczególnie w zakresie wskazywania oprogramowania systemowego i komponentów infrastruktury IT dla danej aplikacji.

Chief Information Officers (CIO) są przede wszystkim odbiorcami informacji. To oni odgrywają wiodącą rolę w określaniu, który obszar ma być oceniany w ramach APM. Zapewniają wytyczne dotyczące wyboru kryteriów, które mają być regularnie oceniane. Na podstawie przedstawionych im wyników muszą zdecydować, przy wsparciu architektów korporacyjnych, jakie środki należy zastosować. Określają, w jakich przypadkach należy składać propozycje projektów transformacyjnych.

Coraz częściej w wielu firmach pojawia się również rola CDO (ang. Chief Digital Officer). W idealnym przypadku ściśle współpracują oni z CIO i architektami korporacyjnymi. Razem stymulują cyfrową transformację firmy. CDO są odpowiedzialni za innowacyjne projekty i plany transformacji oraz koordynują niezbędne zmiany organizacyjne. Zapewniają, że zmiany konieczne do wprowadzenia w wyniku cyfryzacji są dostosowane do działalności operacyjnej, klientów, dostawców i produktów. ⁴

Nie należy zapominać o użytkownikach aplikacji, niezależnie od tego, czy są to pracownicy organizacji, czy klienci, którzy z nich korzystają. Zwłaszcza podczas przeprojektowywania aplikacji i usług aplikacji należy zaangażować przyszłych użytkowników. W przypadku istniejących aplikacji powinno się analizować również zachowanie użytkowników, aby uwzględnić ich potrzeby bezpośrednio w planowanych zmianach.

APM można opisać jako cykliczny model postępowania, który z grubsza dzieli się na cztery etapy. Kroki te niekoniecznie muszą być przetwarzane w sugerowanej tutaj kolejności. W niektórych przypadkach mogą one przebiegać równolegle:

W pierwszym kroku aplikacje muszą zostać zarejestrowane z najbardziej niezbędnymi informacjami. W tym przypadku zaleca się ograniczenie ilości informacji do najbardziej istotnych atrybutów: mniej znaczy więcej.

Do rejestrowania aplikacji można użyć narzędzia architektury korporacyjnej, takiego jak nasz pakiet architektury korporacyjnej ADOIT.

Następnie aplikacje można poddać ocenie. W tym przypadku należy zdefiniować kryteria oceny, takie jak przydatność biznesowa lub informatyczna. Samą ocenę można następnie przeprowadzić za pomocą kwestionariuszy. Wynikiem tego jest strategia inwestycyjna aplikacji. Jeśli chcesz dowiedzieć się więcej na temat strategii inwestycyjnej APM lub oceny portfela aplikacji, zachęcamy do przeczytania naszych innych artykułów na blogu.

Na podstawie oceny i zdefiniowanej strategii inwestycyjnej można zidentyfikować i przeanalizować potencjał usprawnienia.

Ostatnim, ale nie mniej ważnym krokiem jest określenie konkretnych działań w oparciu o spostrzeżenia z poprzednich kroków.

Model procedury cyklicznego APM

Jeszcze kilka lat temu powszechnym zaleceniem było przeprowadzanie corocznych cykli APM. Dziś nie wydaje się to już zasadne. W szczególności innowacyjne aplikacje, które charakteryzują się krótkimi cyklami rozwoju, dzięki czemu firmy mogą szybko reagować na zmieniające się potrzeby rynku, nie byłyby nawet brane pod uwagę w APM. Wskazane jest zatem rozumienie APM jako procesu ciągłego, który może mieć wpływ na strategię inwestycyjną portfela aplikacji.

Kluczowe dane wejściowe to istniejąca dokumentacja aplikacji, np. w formie tabel, podręczników aplikacji (dokument tekstowy) lub w narzędziu EA. Kluczowymi wynikami są ocenione aplikacje, zidentyfikowane słabości i potencjały optymalizacji oraz wynikające z nich wymagania i mierniki. Te z kolei uruchamiają projekty transformacji lub są brane pod uwagę w trwających już projektach.

Głównym rezultatem APM jest portfel aplikacji. Jest to repozytorium wszystkich obecnych i przyszłych aplikacji firmy i powinno być dostępne dla każdego w firmie. Portfel aplikacji można ocenić za pomocą prostych opcji wyszukiwania i filtrowania.

Przykład portfela aplikacji w pakiecie EA ADOIT

Szczególnie interesujące jest często spojrzenie na portfel aplikacji z perspektywy czasu. W przypadku projektów transformacyjnych ważne jest, aby zrozumieć, jak długo aplikacja będzie używana i kiedy można spodziewać się nowych wersji.

Przykład roadmapy aplikacji w pakiecie EA ADOIT

Nazwaliśmy to mapą drogową aplikacji. Na powyższym rysunku aplikacje zostały pogrupowane według ich potencjału strategicznego.

Raporty takie jak wykres zależności są przydatne do analizy otoczenia elementu architektury. Przedstawiają aplikacje i ich zależności w ramach architektury biznesowej i technologicznej.

Przykład diagramu zależności w pakiecie EA ADOIT

Ostatnim przykładem raportu APM jest tzw. mapa klastra. Pokazuje ona aplikacje i możliwości realizowane przez aplikacje. Korzystając z tzw. mechanizmu mapy ciepła, aplikacje są kolorowane w oparciu o kryteria zdefiniowane w portfolio aplikacji. W tym konkretnym przykładzie wyróżnione zostały wszystkie aplikacje o niewystarczającym poziomie bezpieczeństwa:

Przykład mapy klastra w pakiecie EA ADOIT

Zarządzanie portfelem aplikacji dostarcza podstawowych informacji o aplikacjach i ich wzajemnych zależnościach, a także o zależnościach od innych elementów architektury, takich jak procesy biznesowe lub elementy oprogramowania systemowego. Poniżej wymieniono inicjatywy EA, które w znacznym stopniu korzystają z tych informacji lub które bez nich nie funkcjonują lub funkcjonują w bardzo ograniczonym zakresie.

Zarządzanie portfelem aplikacji jest ważnym narzędziem zarządzania i optymalizacji, a tym samym stanowi centralny komponent architektury korporacyjnej w każdej organizacji. Znaczące korzyści z dojrzałego APM odnoszą również bieżące projekty transformacyjne, a także inne inicjatywy EA.

Portfel aplikacji jest jednym z najważniejszych wyników APM i stanowi podstawę do podejmowania zmian w krajobrazie aplikacji firmy, w którym każda aplikacja powinna być udokumentowana jako część cyfrowego bliźniaka.

Jednak aby tak się stało i aby można było mówić o prawdziwej wartości APM, należy uzyskać poparcie właścicieli aplikacji i wszystkich interesariuszy na poziomie zarządczym. Tylko w ten sposób APM może zaistnieć w organizacji i wnieść znaczący wkład w sukces firmy.

Aby jeszcze lepiej zrozumieć zarządzanie portfelem aplikacji, zachęcamy do zapoznania się z naszym bezpłatnym e-learningiem na temat zarządzania portfelem aplikacji, a także z naszymi materiałami na ten temat.

Wypróbuj również naszą najnowszą, zorientowaną na użytkownika usługę „Planowanie inwestycji w aplikacje”, umożliwiającą ocenę przydatności biznesowej i informatycznej aplikacji oraz ustalenie najbardziej odpowiedniej strategii inwestycyjnej, korzystając z bezpłatnego narzędzia architektury korporacyjnej.