Strefa wolna od botów!
Piszemy my, nie maszyny.

Jak powstaje szyty na miarę model operacyjny dla środowiska wielochmurowego?

Mindbox posługuje się uniwersalnymi, wypracowanymi schematami analizy, poprawy i budowy efektywnego modelu zarządzania środowiskiem, które pozwalają tworzyć zindywidualizowane, dopasowane do sytuacji klienta rozwiązania.

 

W ramach etapu discovery, który przeprowadziliśmy u klienta – międzynarodowej grupy edukacyjno-mediowej, uzyskaliśmy wiedzę o strukturze podziału usług, czynności i odpowiedzialności pomiędzy różnymi działającymi w firmie jednostkami <LINK do tekstu o etapie discovery w S>

Poznaliśmy sposób współpracy i trudności, jakie występują w modelu operacyjnym, którego zadaniem jest obsługa złożonego, wielo-chmurowego środowiska. Wnioski z tej analizy pozwoliły nam nakreślić plan transformacji z modelu pozornie centralnego o słabej efektywności – do modelu rzeczywiście scentralizowanego wokół silnej i kompetentnej jednostki, ze wspólnym, działającym governance oraz docelową wizją rozbudowy do rozproszonego modelu dojrzałych i efektywnych jednostek.  

 

 

Modele bazowe jako punkt odniesienia

 

Założenie dotyczące hybrydowego charakteru architektury pozostaje niezmienne. Wyzwaniem jest uczynienie modelu operacyjnego dla tej architektury wydajnym, skalowalnym, perspektywicznym – w odniesieniu do celów biznesowych firmy. 

Punktem wyjścia do zdefiniowania modelu operacyjnego były, obok analizy, także najlepsze praktyki opublikowane przez AWS i Azure. Mindbox na bazie tych frameworków jest jednak w stanie wykreować model indywidualny, który lepiej odpowiada temu, co zastano i temu, co zaplanowano w firmie klienta. Inne podejście – próba dopasowania firmy do ogólnych ram – zdarza się w praktyce projektowej różnych firm integratorskich i doradczych. Są to jednak próby skazane w większości na niepowodzenie ze względu na złożoną rzeczywistość jaką napotyka się w dużych przedsiębiorstwach. Dobrze ilustruje to zresztą omawiany przykład współpracy z klientem – grupą edukacyjno-mediową.

Podstawowy schemat modelu operacyjnego dla środowiska chmurowego (wielochmurowego) przedstawia podział według wymiarów engineering i operations oraz applications i platform. Obrazują one relacje i zależności pomiędzy wytwarzaniem oprogramowania i zarządzaniem. 

 

Jakie modele rozpatrywaliśmy w przypadku naszego klienta?

 

W pierwszej rozpatrywanej opcji przewidziano kontynuację współpracy z zewnętrznym dostawcą w ramach wspólnego, scentralizowanego governance. Wydzielone są zespoły aplikacyjny i infrastrukturalny, oba odpowiedzialne za wytwarzanie, a następnie utrzymanie oprogramowania i środowisk. Zespół po stronie klienta zajmuje się wytwarzaniem, utrzymaniem i zmianami w aplikacjach. W całości wyoutsource’owane są usługi infrastrukturalne, które dostarcza zewnętrzna firma zajmująca się także tworzeniem obsługiwanej platformy.  

W drugim rozpatrywanym modelu całość obsługi przejmują wewnętrzne zespoły klienta. Zespół odpowiedzialny za wytwarzanie i zarządzanie aplikacjami nie rozwija kompetencji w obszarze zarządzania operacyjnego, koncentrując się na jakości wytwarzania w dostarczanym mu środowisku. Z kolei zespół odpowiedzialny za dostarczenie platformy obejmuje rolę dostawcy i zarządzającego środowiskiem i platformą chmurową – Cloud Operations and Platform Enablement (COPE). W związku z tym przejmuje także częściowo zarządzanie utrzymaniem aplikacji. 

W ocenie zespołu analityków i ekspertów Mindbox żaden z tych modeli nie był adekwatny dla obecnych zadań ani wyznaczonego celu transformacji jednostki centralnej i jej relacji z pozostałymi jednostkami w firmie klienta. 

 

 

Model o rysach indywidualnych

 

Zaproponowaliśmy hybrydę obu modeli. 

W proponowanym modelu powołujemy warstwę COPE, która dostarcza i utrzymuje środowisko dla zespołów tworzących aplikacje. Tym samym klient rozumie i jest w stanie wspierać te aplikacje. Model uwzględnia jednak także część usług zarządzanych przez zewnętrznego dostawcę (managed services), która realizuje powtarzalne zadania i schematy zarówno na rzecz zespołu COPE jak i w zakresie przygotowywania najbardziej podstawowej, ogólnej platformy. 

Taki złożony schemat jest możliwy do utrzymania ze względu na wdrożony proces wymiany informacji pomiędzy warstwami. Wiedza o wszystkich wytwarzanych w nich elementach czy realizowanych działaniach jest dzięki temu ogólnie dostępna w postaci dokumentacji i bazy wiedzy. 

Zaproponowany model ma charakter standardu – ale dla konkretnej sytuacji w danej firmie. Z pewnością nie jest to wzorzec metra, który będzie do każdego pasował, ponieważ wynika z indywidualnej historii, uwarunkowań i celów. 

 

 

Warsztat budowy modeli “na miarę”

 

Wypracowanie modelu dokonało się w ramach szerokiej i intensywnej dyskusji. 

Dotyczyło to także sposobu właściwej komunikacji tej propozycji klientowi. Jej bazę stanowiło przyporządkowanie wypracowanej propozycji modelu istniejących i wcześniej omawianych procesów do kontekstu klienta. 

Kolejny krok stanowiło zdefiniowanie i przypisanie ról oraz odpowiedzialność za realizację poszczególnych procesów w ramach modelu. Jasnym stało się wówczas także, jak niektóre z nich zmienią przyporządkowanie, inne z kolei będą musiały zmienić zakres albo – co okazało się częstym przypadkiem – zostać powołane, ponieważ wcześniej ich nie było. Fundamentem do tego działania jest transfer wiedzy, jaki uzyskuje klient od Mindbox, poczynając od współpracy przy etapie discovery. Natomiast działający model operacyjny będzie można dzięki wspomnianym procesowi wymiany wiedzy modyfikować i doskonalić. Warunkiem jest oczywiście aktywność i  zaangażowanie ze strony uczestników procesu.   

Komunikacja i uzgadnianie założeń propozycji wymaga uważności i odpowiedzialności ze strony Mindbox. Stanowi element metodyki – podejścia, które wypracowaliśmy. W tym procesie – z założenia angażującym interesariuszy po stronie klienta – pewna dopuszczalna żywiołowość musi być poddana kontroli. Największa odpowiedzialność polega na “neutralizowaniu” tendencji do abstrahowania od założeń architektury, holistycznego podejścia. Podejmowane są próby modyfikacji, przesunięć zakresów odpowiedzialności czy zależności, które przyjęte – niweczyłyby ogólny, całościowy efekt. 

***

Opisywana ścieżka dojścia do proponowanego modelu jest uniwersalna – stanowi w zasadzie zamkniętą metodykę wynikającą z doświadczenia Mindbox. Jej efektem są natomiast dostosowane, indywidualne rozwiązania – modele organizacyjne pozwalające efektywnie panować nad złożonym i zmiennym środowiskiem technologicznym. 

 

Porozmawiajmy!

    Wypełnij formularz,
    a my pomożemy Ci wdrożyć najnowsze rozwiązania!