Większość zespołów kierowniczych obwinia system zarządzania, gdy dostarczanie danych ulega spowolnieniu.
To prosta diagnoza. Nowy produkt danych wymaga zatwierdzeń, należy skonfigurować dostęp, utworzyć konta serwisowe oraz zarejestrować wpisy w katalogu. Ponadto kontrole bezpieczeństwa i zgodności pojawiają się z opóźnieniem, zazwyczaj w formie zgłoszeń, dokumentów i spotkań. Z zewnątrz zarządzanie wygląda jak hamulec.
Pytanie nie brzmi zatem, czy zarządzanie powinno istnieć – w poważnej platformie danych jest ono niezbędne. Prawdziwe pytanie dotyczy tego, czy zarządzanie funkcjonuje jako system kontroli wbudowany w platformę, czy też jako powtarzające się obciążenie przy każdym wydaniu.
Najważniejsze wnioski
- Zespoły ds. danych nie zwalniają tempa pracy z powodu samego istnienia mechanizmów zarządzania, ale dlatego, że zarządzanie to nadal odbywa się ręcznie.
Gdy kwestie bezpieczeństwa, dostępu, katalogowania i zgodności z przepisami są ujęte w dokumentach, zgłoszeniach i spotkaniach przeglądowych, a nie w samej platformie, każdy nowy produkt oparty na danych powoduje te same opóźnienia. Prawdziwym problemem jest słabo wdrożone zarządzanie. - „Guardrails-as-code” to czynnik przyspieszający działanie – a nie „podatek za zgodność z przepisami”.
Wartość biznesowa polega na wbudowaniu zasad w postaci kodu, umów dotyczących danych, automatycznych kontroli, integracji katalogów oraz standardowych wzorców dostępu bezpośrednio w procesy dostarczania. Dzięki temu zespoły nie muszą już zajmować się przebudową infrastruktury, a mogą skupić się na szybszym wdrażaniu logiki biznesowej przy mniejszym ryzyku operacyjnym. - Najważniejszym argumentem na poziomie zarządu jest przepustowość połączona z redukcją ryzyka.
Dla dyrektora finansowego (CFO), dyrektora generalnego (CEO) lub dyrektora ds. technologii (CTO) najsilniejszym argumentem jest wymierna poprawa czasu wprowadzenia produktu do produkcji, mniejsza liczba iteracji przed wydaniem, mniej błędów i incydentów oraz niższe koszty audytu. To właśnie w tym momencie inżynieria platformy staje się dźwignią wpływającą na wyniki biznesowe.
Za wszystko obwinia się przede wszystkim system zarządzania, ponieważ to właśnie on stanowi najbardziej widoczny punkt tarcia
Kiedy zespoły narzekają, że „zarządzanie nas spowalnia”, rzadko mają na myśli sam fakt istnienia standardów. Reagują raczej na sposób, w jaki te standardy są egzekwowane.
Jeśli egzekwowanie zasad odbywa się poprzez ręczne przeglądy, jeśli dostęp zależy od kolejki zgłoszeń, jeśli rejestracja metadanych jest traktowana jako odrębne zadanie administracyjne, a kontrole wdrażania pojawiają się dopiero na końcu procesu, wówczas zarządzanie staje się dla zespołów czymś w rodzaju przeszkody.
Właśnie dlatego tak wiele organizacji błędnie interpretuje tę sytuację. Dostrzegają one utrudnienia związane z zapewnieniem zgodności i dochodzą do wniosku, że to sama zgodność jest przyczyną problemu.
Nasze raporty wskazują jednak na problem o charakterze bardziej strukturalnym: tylko około jedna trzecia firm egzekwuje oznaczanie kosztów za pomocą zautomatyzowanych zasad, a jedynie 29% programistów ma narzędzia do optymalizacji zintegrowane z procesem tworzenia oprogramowania.
Konsekwencja jest przewidywalna – sprawowanie rządów sprowadza się do czekania:
- na zatwierdzenia,
- na dostęp,
- na kogoś, kto zinterpretuje dokument dotyczący zasad,
- na to, by zespół platformy po raz piąty w tym kwartale odtworzył ten sam standardowy wzorzec.
To nie jest silne zarządzanie, lecz słaba konstrukcja platformy z objawami zarządzania.
Większa liczba osób nie naprawi platformy, która za każdym razem powoduje te same utrudnienia
Kiedy tempo dostaw spada, kierownictwo często sięga po najbardziej znane rozwiązanie: zatrudnia więcej osób. Działa to tylko wtedy, gdy wąskim gardłem jest rzeczywisty brak zdolności produkcyjnych; nie sprawdza się natomiast, gdy przyczyną jest powtarzalność strukturalna.
Jeśli doświadczeni inżynierowie wciąż muszą wykonywać te same prace konfiguracyjne przy każdym nowym produkcie danych, zatrudnienie kolejnych inżynierów po prostu zwiększa skalę tego samego marnotrawstwa. Więcej osób generuje w rezultacie więcej zgłoszeń, więcej przekazów zadań, więcej powtarzających się prac związanych z platformą i więcej stanów oczekiwania.
Prawdziwym problemem nie jest słabe wdrażanie nowych pracowników ani problemy kierownicze, ale platforma, która zmusza nawet doświadczone zespoły do odtwarzania za każdym razem tych samych mechanizmów wspomagających. Raporty rynkowe dochodzą do tego samego wniosku z innej perspektywy: 62% programistów chce większej kontroli nad wydatkami na chmurę, a 77% twierdzi, że uniemożliwia to złożoność.
Ma to znaczenie wykraczające poza efektywność techniczną. Te same raporty wskazują, że 72% organizacji przekroczyło swoje budżety na chmurę w ostatnim roku obrotowym. Gdy platforma zmusza zespoły do powtarzania ręcznych konfiguracji i przeprowadzania weryfikacji na późnym etapie, nie tylko spowalnia to realizację projektów, ale także utrudnia przewidywanie zmian kosztów i ich przypisywanie.
Raport rynkowy dotyczący liderów branży technologicznej
72% organizacji nadal przekracza swoje budżety przeznaczone na chmurę, a przyczyna tego zjawiska ma charakter strukturalny. Niniejszy materiał zapewnia kadrze kierowniczej wspólny język oraz plan działania oparty na 7 zasadach, który należy wdrożyć w ciągu 90 dni.
Prawdziwe wąskie gardło: konieczność ponownego tworzenia dostępu, mechanizmów kontroli i konfiguracji dla każdego nowego produktu danych
Strata czasu zazwyczaj nie ma miejsca w tej części, o której kierownictwo chętnie mówi: sprytnym modelu, logice transformacji, wnioskach analitycznych czy efektownym panelu kontrolnym.
Występuje ona w powtarzających się zadaniach związanych z tym wszystkim. Dla wielu zespołów „nowy produkt danych” wciąż wywołuje tę samą ukrytą listę kontrolną:
- zdefiniowanie uprawnień i ścieżek dostępu
- utworzenie kont usługowych i kluczy tajnych
- zarejestrowanie metadanych i wpisów w katalogu
- przekształcenie wymagań polityki w środki kontroli technicznej
- ustalenie zasad wdrażania, monitorowania i przywracania
- powtarzaj procesy zatwierdzania dla wzorca, który organizacja widziała już wiele razy
To właśnie w tym momencie liderzy często nie doceniają skali szkód. Ponieważ praca jest rozdrobniona, wydaje się nieistotna. Dzień tu, pół dnia tam, kilka wymian zdań z działem bezpieczeństwa, kolejna runda z zespołem platformy, zadanie związane z katalogiem w ostatniej chwili przed wydaniem.
Jednak ta wada projektowa prowadzi do spowolnienia tempa wdrażania, a konsekwencje stają się z czasem coraz bardziej widoczne. Zespoły powinny otrzymać gotowy szablon lub szkielet rozwiązania, który pozwoli im przejść od razu do realizacji wymagań biznesowych.
Co oznacza pojęcie „guardrails-as-code” w nowoczesnej platformie danych
„Guardrails-as-code” to prosta koncepcja ujęta w technicznym języku. Mówiąc językiem biznesowym, oznacza to, że zasady przestają istnieć w plikach PDF, a zaczynają funkcjonować w samej platformie.
Zamiast wymagać od zespołów zapamiętywania standardów, ręcznej ich interpretacji i stosowania z opóźnieniem, platforma koduje te standardy bezpośrednio w infrastrukturze, szablonach i procesach wdrażania. Wymagania bezpieczeństwa, schematy dostępu, reguły tagowania, kontrole zgodności z polityką oraz warunki wdrożenia stają się domyślnymi ustawieniami egzekwowanymi automatycznie, a nie opcjonalnymi zadaniami wykonywanymi przez ludzi.
Bariery zabezpieczające powinny być wbudowane w „Infrastructure-as-Code” oraz potoki CI/CD, z automatycznym egzekwowaniem tagowania, wykrywaniem anomalii i limitami budżetowymi wbudowanymi w proces dostarczania. Taki jest właściwy model myślenia – „guardrails-as-code” to nie dodatkowa warstwa zarządzania nałożona z góry, ale przeniesienie zarządzania na ścieżkę, na której praca już się odbywa.
Ta zmiana zmienia charakter kontroli – dobrze zaprojektowane zabezpieczenia nie spowalniają pracy zespołów – eliminują one decyzje, które od początku nie powinny były być podejmowane na poziomie produktu.
Podstawowe elementy: polityka jako kod, umowy dotyczące danych, automatyczne kontrole, katalogi
Nie każda organizacja potrzebuje gruntownej przebudowy, aby móc działać szybciej, ale potrzebuje pewnych podstawowych elementów: polityki jako kodu, umów dotyczących danych, zautomatyzowanych narzędzi do sprawdzania poprawności kodu i kontroli, integracji z katalogiem danych oraz ustandaryzowanych uprawnień i kont usługowych wbudowanych w strukturę rozwiązania.
W praktyce każdy z tych elementów eliminuje inne źródło opóźnień:
- Polityka jako kod przekształca ogólne założenia dotyczące zarządzania w reguły, które można wykonać. Ma to znaczenie, ponieważ niejasne standardy powodują cykle interpretacji, a cykle interpretacji powodują opóźnienia.
- Umowy dotyczące danych zmniejszają niejasności, które prowadzą do konieczności ponownej pracy na dalszych etapach procesu. Określają one oczekiwania dotyczące schematu, własności, aktualności i zmian, co sprawia, że przekazywanie zadań przebiega sprawniej, a awarie są wykrywane wcześniej.
- Zautomatyzowane kontrole przesuwają walidację na wcześniejszy etap. Narzędzia linterowe, testy zgodności z polityką i kontrole wdrożeniowe służą do wykrywania przewidywalnych awarii, zanim staną się one przeszkodami w wydaniu lub incydentami produkcyjnymi.
- Integracja katalogu i metadanych sprawia, że wykrywalność staje się częścią procesu dostarczania, a nie zadaniem administracyjnym wykonywanym po jego zakończeniu.
- Wstępnie zdefiniowane tożsamości i wzorce dostępu eliminują jedno z najbardziej uporczywych źródeł tarć. Zespoły nie powinny negocjować tego samego modelu kont usługowych i uprawnień dla każdego produktu z osobna, jeśli organizacja już wie, jak wygląda „dobry” model.
W jaki sposób gotowe szablony platformowe pozwalają skrócić czas wprowadzenia produktu na rynek bez uszczerbku dla zgodności z przepisami?
Najbardziej praktycznym przejawem koncepcji „guardrails-as-code” są gotowe szablony wielokrotnego użytku.
Dobry szablon nie tylko tworzy repozytorium i strukturę folderów – zawiera on również założenia operacyjne organizacji. Obejmuje on domyślny model dostępu, zatwierdzony wzorzec tożsamości, reguły tagowania, punkty zaczepienia katalogu, pakiet zasad, ścieżkę CI/CD, szkielet testowy, domyślne ustawienia obserwowalności oraz logikę przywracania.
Future Processing proponuje model operacyjny z zabezpieczeniami, które zapewniają równowagę między kontrolą kosztów, zarządzaniem ryzykiem i jakością danych, nie spowalniając przy tym pracy zespołów inżynierów, poprzez wbudowanie ich bezpośrednio w IaC i CI/CD.
Typowe cele wdrożeniowe obejmują zautomatyzowany zasięg tagów powyżej 90%, miesięczne cele dotyczące dokładności prognoz oraz zapobieganie znacznej części regresji dzięki wbudowanym zabezpieczeniom. Nie są to uniwersalne punkty odniesienia dla każdej organizacji, ale wskazują one kierunek, w którym należy podążać.
Zyskaj kontrolę nad swoimi danymi i kosztami związanymi ze sztuczną inteligencją – ogranicz marnotrawstwo, zwiększ wydajność i podejmuj trafniejsze decyzje w oparciu o wiarygodne dane.
Prezentacja na temat wskaźników KPI, którą dyrektor ds. technologii może przedstawić zarządowi
Zarząd nie potrzebuje wykładu na temat mechanizmów kształtowania polityki, ale jasnego wyjaśnienia, dlaczego platforma może zapewnić większą wartość biznesową, przy mniejszej liczbie niespodzianek i niższym obciążeniu operacyjnym.
Rozsądny zestaw wskaźników KPI powinien obejmować:
- Czas wprowadzenia do produkcji – ile czasu zajmuje przejście od zatwierdzonego zlecenia do pierwszego wydania produkcyjnego.
- Liczba iteracji do osiągnięcia gotowości do produkcji – ile cykli jest potrzebnych, zanim produkt będzie gotowy do wydania.
- Usterki i incydenty – zwłaszcza w pierwszych tygodniach życia produktu.
- Wskaźnik niepowodzeń zmian i wskaźnik wycofania – ponieważ bezpieczna automatyzacja ma większe znaczenie niż nominalna prędkość wydawania wersji.
- Nakład pracy związany z audytem i dokumentacją na każdą wersję – ile ręcznej pracy generuje zapewnienie zgodności z przepisami.
- Koszt na produkt danych i dokładność prognoz – ponieważ tempo, którego nie da się powiązać z ekonomią, nie przetrwa analizy zarządu.
Właśnie w przypadku tej ostatniej pary argumentów argumentacja nabiera większego znaczenia strategicznego. Z naszych raportów wynika, że tylko 43% dużych przedsiębiorstw jest w stanie obliczyć koszt na produkt danych, głównie dlatego, że kontekst operacyjny i finansowy pozostają od siebie oddzielone.
Dlatego dyrektor ds. technologii (CTO), który potrafi wykazać szybsze wdrażanie i lepszą atrybucję ekonomiczną, nie prosi już o inwestycje w porządek na platformie, ale o inwestycje w lepszy model operacyjny.
Tak wygląda argumentacja na poziomie zarządu: krótszy czas wprowadzenia produktu na rynek, mniej iteracji, mniej incydentów, mniejsze obciążenie związane z audytami, jaśniejszy podział odpowiedzialności oraz wyraźniejszy związek między wydatkami na platformę a wynikami biznesowymi.
