Poznaj prawdziwy zakres swojego projektu od samego początku

W wcześniejsze części tej serii, rozmawialiśmy o tym, jak skoncentrować zakres projektu na tym, co najważniejsze, oraz o tym, jak przegląd bazy kodu może pomóc w zwiększeniu wydajności i podejmowaniu lepszych decyzji dotyczących projektu.

W części 3 chcemy zająć się jedną z największych przeszkód, które większość z nas bardzo dobrze zna z osobistych i zawodowych doświadczeń: „Znalezienie dobrego miejsca do rozpoczęcia”.

Nie ma znaczenia, czy Twój projekt Notes/Domino modernizuje Twoją infrastrukturę, migruje do chmury, czy całkowicie opuszcza platformę. Konsolidacja istniejącej infrastruktury to kluczowy pierwszy krok w najbardziej udanych projektach. Znalezienie i usunięcie martwego drewna w Twoim środowisku znacznie zmniejszy ogólny wysiłek projektu i obniży koszty.

Proszę zaakceptuj marketingowe pliki cookie aby wyświetlić ten film.

Zadawaj pytania, które ujawniają istotę Twojego projektu

Zadawanie właściwych pytań było kluczowym czynnikiem w zmniejszeniu zakresu projektu w pierwsza część tej serii. Przyjrzyjmy się ponownie niektórym z tych pytań i skoncentrujmy się na tym, jak możemy wykorzystać odpowiedzi do identyfikacji potencjału konsolidacji.

1. Jaka jest struktura i rozmiar mojego środowiska?

Musisz mieć prawdziwe zrozumienie wielkości przedsięwzięcia. Potrzebujesz wskaźników KPI, które pomogą ocenić potencjał konsolidacji i zmierzyć sukces:

użytkownicy

  • Ilu użytkowników jest zarejestrowanych czy aktywnych?
  • Kiedy użytkownicy byli ostatnio aktywni?
  • Z iloma aplikacjami naprawdę pracują moi użytkownicy?

Serwery

  • Ile serwerów jest aktywnych?
  • Ile to serwery aplikacji?
  • Ile baz danych jest używanych na serwerze?
  • Ilu użytkowników jest aktywnych na serwerze?

Zastosowania

  • Ile aplikacji zostało wdrożonych, a ile używanych?
  • Ile baz danych można wykluczyć z mojego projektu?
  • Ile baz danych bazuje na standardowych szablonach?
  • Ile istnieje replik każdej bazy danych?
  • Ilu użytkowników jest aktywnych na bazę danych?

2. Ile baz danych jest niewykorzystanych?

To jedno z najczęściej zadawanych pytań, jakie słyszymy. To oczywisty punkt wyjścia do konsolidacji.

Pierwszym odruchem jest często po prostu usunięcie wszystkich nieużywanych instancji bazy danych i świętowanie szybkiej wygranej. Może to mieć sens w niektórych sytuacjach: np. – gdy chce się tylko zmniejszyć liczbę serwerów, ale bardzo zawodne jest ocenianie, które aplikacje można wycofać z eksploatacji.

Bardziej interesujące jest sprawdzenie, dla ilu aplikacji nie jest używana żadna instancja bazy danych. Te grupy instancji bazy danych, które mają ten sam identyfikator repliki, nazywamy „zestawami replik”. Tylko wtedy, gdy cały zestaw replik jest nieużywany, a aktywność nie występuje na żadnym serwerze, aplikację można naprawdę uznać za nieużywaną.

Okres, w którym obserwowana jest działalność, odgrywa ważną rolę w likwidacji. Nie każda baza danych jest używana codziennie. Możesz mieć bazy danych o użyciu sezonowym, które są używane tylko raz w roku, kwartale lub miesiącu. Aby uchwycić tę odmianę, panagenda zaleca minimalny okres obserwacji wynoszący trzy miesiące, aby upewnić się, że baza danych nie jest używana. Im dłuższy okres obserwacji, tym lepsze decyzje będziesz w stanie podjąć.

Po zidentyfikowaniu martwego drewna robimy pierwszy krok do oczyszczenia naszego środowiska, nadal szukamy możliwości w nieco bardziej wymagających obszarach.

3. Gdzie można obniżyć koszty?

Konsolidacja to szansa na znalezienie i wyeliminowanie kosztów niewykorzystanych licencji. Większość organizacji ma w swoich książkach nieaktywnych użytkowników i niewykorzystane serwery. Działanie w oparciu o te informacje może zaoszczędzić dużo pieniędzy przy niewielkim wysiłku.

Znajdowanie i eliminowanie nieaktywnych baz danych z Twojego środowiska powoduje zmniejszenie wykorzystania serwera. Skonsolidowanie kilku niewykorzystanych serwerów zmniejsza koszty licencji, operacji i administracji.

Konsolidacja jest również okazją do przeglądu projektu sieci Domino. Na przykład należy ponownie ocenić środowiska zaprojektowane 15 lat temu z myślą o uwzględnieniu przepustowości. Nowoczesna infrastruktura mogła już spowodować, że wcześniej ważne redundancje lub części koncepcji decentralizacji serwerów stały się przestarzałe.

Wiele organizacji decyduje się na tworzenie środowisk hybrydowych z aplikacjami działającymi na wielu rozwiązaniach. Nawet jeśli Domino pozostanie strategiczną platformą aplikacji, niektóre usługi ogólne (np. poczta, pokoje zespołów lub biblioteki plików) mogą z czasem zostać od niej oddzielone. W takim scenariuszu migracji wpływa również na aktywność użytkownika. Generowany jest dodatkowy potencjał oszczędności licencyjnych, który można przewidzieć dzięki zrozumieniu projektu bazy danych.

Nawet jeśli nie jesteś obecnie zaangażowany w konkretny projekt, szybkie tempo zmian w dynamicznych środowiskach pracy stwarza ciągłe możliwości zmniejszenia ogólnych wydatków na IT poprzez ciągłe przeglądy aktywności.

Znajdź nisko wiszące owoce – standardowe aplikacje oparte na szablonach

Pojęcie dziedziczenia projektu będzie ważnym tematem podczas całej podróży projektowej. Druga część tej serii wprowadził nas w ogólny temat i jego wpływ na rozwój środowisk Notes/Domino. Ogólnie wzornictwo ma duże znaczenie podczas projektów migracji i modernizacji. Jego znaczenie może rozpocząć się już w fazie konsolidacji.

Identyfikacja baz danych dziedziczących projekt ze standardowych szablonów jest ważna z kilku różnych powodów. Z perspektywy organizacyjnej stosunkowo łatwo jest zrozumieć cel, któremu służą, nawet bez znajomości procesu biznesowego, w który są zaangażowani. Na przykład biblioteka dokumentów będzie używana do wymiany plików, archiwizowania dokumentów lub czegoś podobnego. Nieważne, czy są wykorzystywane w działach Zakupów, Controllingu czy Produkcji. Uzyskanie takiego poziomu wglądu w opracowane na zamówienie aplikacje może być sporym wyzwaniem, jeśli aplikacje te ewoluowały przez lata. Jest to szczególnie prawdziwe, jeśli nie patrzysz tylko na jeden lub dwa, ale na setki lub tysiące.

Z technicznego punktu widzenia niezmiernie cenna jest wiedza, jakie funkcje techniczne zapewniają takie standardowe bazy danych. Zapewni perspektywę, czy można z nich korzystać w Internecie, czy też udostępniać je na urządzeniach mobilnych. Zwłaszcza, że ​​HCL dużo inwestuje w modernizację klasycznych szablonów, co może być ogromnym zyskiem w projekcie modernizacji. W migracji może to być również bardzo opłacalne, ponieważ w przypadku większości standardowych szablonów istnieją ISV, którzy oferują standardowe ścieżki migracji na inne platformy. Można je niemal wykluczyć z zakresu ręcznej migracji, co z kolei wpływa na różne wskaźniki KPI, takie jak „aktywni użytkownicy” czy „bazy danych używane na serwerze”. Niezależnie od ścieżki, praca ze standardowymi aplikacjami opartymi na szablonach będzie znacznie tańsza niż przekształcanie niestandardowych aplikacji opracowanych.

Teraz zbieraj nagrody

Połączmy te tematy i zastosujmy je w projekcie konsolidacji, aby podsumować, jak najlepiej wykorzystać wyniki. Możemy nawet stworzyć małą listę kontrolną do wykorzystania jako krok po kroku guide przez najważniejsze rzeczy do rozważenia:

Zadanie: zidentyfikować nieużywane aplikacje

  • Wpływ: przygotowanie redukcji wykorzystania serwera
  • Wpływ: zmniejszenie zakresu projektu

Zadanie: identyfikacja aplikacji na podstawie standardowych szablonów

  • Wpływ: zminimalizowanie wysiłku związanego z migracją/modernizacją
  • Wpływ: odkryj potencjał redukcji kosztów licencji użytkownika

Zadanie: zidentyfikować nieaktywnych użytkowników

  • Wpływ: odkryj nadmierne wydatki na licencje użytkownika
  • Wpływ: przygotowanie redukcji wykorzystania serwera

Zadanie: zidentyfikować niewykorzystane serwery

  • Wpływ: odkryj potencjał redukcji kosztów licencji serwerowych

Zadanie: przegląd projektu sieci Domino

  • Wpływ: odkryj potencjał redukcji kosztów licencji serwerowych

Następny w naszej serii

Po tej początkowej fazie konsolidacji, gdy wszystko jest już okrojone, nisko wiszące owoce są zbierane, a potencjał oszczędności kosztów licencji jest jasny, podejmujemy się zadań, które wymagają więcej czasu i zasobów. Tutaj różnica między projektami modernizacyjnymi a migracyjnymi stanie się bardziej wyraźna. Jednak będzie to również czas na weryfikację obliczeń stojących za Twoimi business case. Jeśli chcesz dowiedzieć się więcej, ten temat zostanie omówiony w trwać blog post i webinar z tej serii.

Niezależnie od tego, jaki jest Twój projekt, zawsze będziesz potrzebować kilku strategicznych informacji. W najbliższym czasie omówimy dwa najważniejsze tematy blog posty i webinars:

Umiejętność identyfikacji interesariuszy aplikacji ma kluczowe znaczenie przy podejmowaniu decyzji o przyszłości aplikacji. Potrzebujemy działów lub osób korzystających z aplikacji, aby zrozumieć jej rolę w procesie biznesowym. Jednak musimy również wiedzieć, które działy lub lokalizacje z niego korzystają, aby móc rozłożyć koszty naszych wysiłków związanych z modernizacją lub migracją.

Większość twoich aplikacji będzie zależna od jednej lub drugiej części twojego środowiska. Wiele z nich będzie zakorzenionych w samym kodzie: zakodowane na stałe serwery lub nazwy użytkowników, adresy IP, biblioteki zewnętrzne, systemy faksowe itp. Musimy wiedzieć, gdzie są te zależności, jaki mają wpływ i jak można je naprawić w najbardziej efektywny sposób, bez konieczności ponownego projektowania setek lub tysięcy projektów.

Odtąd będzie to ciągłe poszerzanie kręgu zastosowań, nad którymi pracujemy. Każdy krok będzie bardziej kosztowny, a rozważne planowanie przyniesie jeszcze większe korzyści.

O tej serii:

Wiele firm na całym świecie zobowiązało się do HCL Notes/Domino* przez lata. Znają wiele korzyści płynących z tego związku. Ponadto Notes/Domino leży w centrum ich procesów i sposobu ich działania. Mimo to decydenci IT na całym świecie zaczynają wyobrażać sobie przyszłość, w której Notes/Domino może odgrywać mniejszą rolę lub wcale.

*dawniej IBM Notes/Domino