Garaż Rulez!

Data: 2019-10-11
Autor: Sebastian Konkol
Garaż Rulez!

Duch startup’owy zachwyca możliwościami. Zero cynizmu, naprawdę. Skuteczność działań prowadzonych w ten sposób, choć oceniana jedynie po przedsięwzięciach „z sukcesem”, przekonuje duże firmy do realizacji przedsięwzięć w taki sposób. Jak więc powstają „systemy z garażu”? Opowiem o doświadczeniach na przykładzie dwóch przedsięwzięć, jakie oglądam z bliska.

Myśl pierwsza. Startup’owa skuteczność, organicznie nieosiągalna dla korpo, comes with a price tag. Podstawą tej skuteczności jest rutynowe, niemalże doktrynalne budowanie kompromisów. Wszystkie decyzje podporządkowywane są głównemu celowi startup’u – co się nie mieści, jest odkładane (na później lub na nigdy). Cel uświęca środki. Nie ma tu miejsca na zachowania a‘la compliance, które stanowią – zupełnie obiektywnie potrzebny – element kultury korpo. Zdolność prowadzenia rutynowej działalności w korpo – operacyjnej i rozwojowej – opiera się o różne funkcje klasy compliance, od prawnego, przez bezpieczeństwo po zgodność ze standardami wewnętrznymi. Dowolny startup, który miałby spełnić wymagania compliance, w formie przekazywanej zwykle do projektów realizowanych w korpo, umarłby zapewne na samym starcie. Nie twierdzę, że compliance to zło – twierdzę jednak, że praktyka stosowania takiego podejścia (np. wartościowanie wymagań, oparcie o realnie szacowane ryzyko) została na tyle wykrzywiona, że nie pomaga. I zdaję sobie sprawę z tego, że historia jest dłuższa, zawiera wiele pętli „eskalacji działań zbrojnych” między przedsięwzięciami rozwojowymi niechętnymi do finansowania narzucanych zagadnień i grupami compliance wytwarzającymi coraz bardziej złożone wymagania.

Myśl druga. Patrząc na startup z zewnątrz można dostrzec, że statystyczny startup w dużej części jest przedsięwzięciem technologicznym, któremu jednak „jakoś łatwiej idzie”. Spoglądając uważniej dostrzeże się jednak drive do szybkiego rozwiązania takiego czy innego zagadnienia. Szybkość jest możliwa, bo nie ma standardów, których trzeba się trzymać, ale przede wszystkim dlatego, że decyzje są podejmowane bez konsultacji, dyskusji i „w miejscu”. Trochę jest to jednak także efekt „wtórnego analfabetyzmu” – często widziałem zaskakujące konstrukcje wynikające z braku wiedzy, tym niemniej, szybko składanych z „ostatnio modnych” klocków. Niestety, taka składanka znacznie bardziej przypomina efekt nalotu klejem epoksydowym na składnicę złomu niż budowlę z klocków LEGO®. Z perspektywy posiadania technologii, bardzo zasadnej perspektywy korpo, takie działanie jest raczej ostrzegane jako działanie na szkodę organizacji w długim terminie. I właśnie o ten długi termin chodzi, bo perspektywa startup to perspektywa popchnięcia sprawy na dziś, a nie liczenia 5-letniego TCO.

Myśl trzecia. Kiedy dochodzi do zderzenia światów – startupu i korpo – na gruncie „architektury” zachodzą ciekawe zjawiska. Architekt w startupie to zwykle specjalista od software architecture, znacznie rzadziej system architecture. W każdym razie obraca się on w sferze konstrukcji wewnętrznej jednego rozwiązania, zoptymalizowanej pod kątem celu tego rozwiązania. Architekt w korpo (o ile to korpo ma szczęście) to specjalista od enterprise architecture. Ten obraca się w sferze zależności miedzy systemami i optymalizacji całości środowiska. W zetknięciu tych punktów widzenia ujawnia się stara zasada „gdzie jesteś, to wyznajesz”. W konsekwencji architekci ze startupu kpią z EA, bo nie rozumieją tej perspektywy, a architekci z korpo patrzą na rozwiązania startupowe i widzą garaż zaklejony taśmą klejącą i gumką recepturką. Cały ambaras polega jednak na tym, że obie strony mają swoje racje.

Myśl czwarta. Nie zdarzyło mi się jeszcze spotkać startupu, który zagadnienia bezpieczeństwa obsługiwałby od początku realizacji swojego rozwiązania. Z drugiej strony, nie spotkałem się jeszcze z korpo, w którym obsługa zagadnień bezpieczeństwa wykraczałaby poza absolutnie krytyczne minimum minimorum. Do tematów security architecture dochodzi się dopiero wtedy, kiedy cały stos technologiczny jest już wybrany, a nawet wykonany projekt rozwiązania – wtem okazuje się, że tak to nie może być, bo ryzyko. Wtedy projekt przechodzi w tryb „zrób coś z tym, byle małym kosztem, żeby jakoś było i nie zawracaj mi głowy, bo mam napięty harmonogram”, bez względu na to, czy startup, czy korpo. Pod względem ignorowania zagadnień bezpieczeństwa panuje tu pełna zgoda – na dłuższą metę szkodliwa dla każdego przedsięwzięcia, w startupie czy w korpo.

Kultura startupowa – poza ujmującym, rebelianckim nastawieniem do świata – udowadnia wyższą skuteczność, niż projekty w korpo. Moim zdaniem wynika to bardziej ze skupienia na celu i osobistego, wewnętrznego zaangażowania realizujących projekty, niż z jakiejś innej „magii startupu”. Tym niemniej, od rozwiązań dla korpo – zarówno w ich konstrukcji jak i sposobie eksploatacji – wymagane jest więcej. To „więcej” to konsekwencje skali działania korpo, w której nie ma miejsca na „wiele specyfiki”. Gdyby każde rozwiązanie mogło rządzić się własnymi prawami, powstałby chaos, którego – w tej skali działania – po prostu nie udałoby się ogarnąć. Na to „więcej” składają się wszystkie wysiłki standaryzacji i inżynierii, pozwalające włączyć nowy komponent do istniejących (i działających w tej skali) reguł gry. Aby rozwiązanie dało się zarządzać według tych reguł, musi mieć co najmniej podzbiór cech systemu Enterprise Grade. Pośród tych cech często wskazywane są: zdolność do skalowania rozwiązania w różnych aspektach (coraz częściej „załatwiane kontenerami”, wtórny analfabetyzm), wbudowana od samego początku perspektywa bezpieczeństwa (Privacy by Design to obowiązujące prawo, a nie fanaberia compliance), dostrzeganie istnienia i odrębności danych współdzielonych i dogmatycznie wymagana orkiestracja procesów (w korpo nic nie działa w kompletnym oderwaniu od całej reszty), zarządzalność rozwiązania (od automatyzacji operacji administracyjnych po bieżący nadzór działania na szczegółowym poziomie), czy bogata konfigurowalność (czyli możliwości zmiany sposobu działania rozwiązania, które nie spowodują awarii).

Z absolutnie oczywistych i zrozumiałych powodów żaden system startupowy nie jest tworzony w reżimie Enterprise Grade. Bez wątpienia na tym właśnie zasadza się przewaga skuteczności przedsięwzięć startupowych – tym bardziej, że wszystkie one są po prostu jakąś formą eksperymentu. Pomiędzy MVP startupu a użytkowaniem rozwiązania w korpo musi jednak nastąpić pewna ewolucja rozwiązania, której efektem będzie uzyskanie przez niego cech Enterprise Grade. Rozwiązanie garażowe musi po prostu w końcu dorosnąć. „To jak zdecydować, kiedy system musi przestać być garażowy?” usłyszałem w jednej z niedawnych dyskusji. Moja odpowiedź, choć dłuższa w oryginale, sprowadza się do kilku rad. Po pierwsze, do stanu Enterprise Grade dochodzi się krok po kroku, a nie rewolucją. Poszczególne cechy powinny być wbudowywane w rozwiązanie „garażowe” wraz ze wzrostem skali jego użytkowania. Po drugie, zbiór cech, jakie ma osiągnąć rozwiązanie, powinien być znany na początku – ale zbiór cech, a nie sposób ich realizacji. To drugie powinno być opracowane wtedy, kiedy charakterystyka rozwiązania będzie już lepiej poznana i będzie w tej wiedzy nieco więcej pewności. Realizacja takich cech powinna być traktowana jako wymagania na równi z biznesowymi (np. adresowane w backlogu). Po trzecie, uzasadnienie wprowadzania cech rozwiązania Enterprise Grade nie może opierać się na „widzimisiach”. W ostatnich przedsięwzięciach przykładane były miary wynikające z BCP (Business Continuity Planning) lub analizy ryzyka (finansowego, operacyjnego, prawnego, technologicznego, wycieku danych itd.), które dawało w efekcie ocenę ekspozycji wartości biznesowej na ryzyko w zestawieniu z kosztami usunięcia tej ekspozycji i potencjału wartości biznesowej do wygenerowania. Dopiero takie, trójpunktowe podparcie, dawało materiał do podejmowania decyzji o wyważeniu „rebelii” i compliance.

Im bardziej złożony organizm, tym więcej wysiłku poświęca na zapewnienie trwania. To uniwersalne prawo przyrody, a korpo wcale nie jest tu wyjątkiem. Z tego powodu obserwowany trend realizacji rozwiązań „rebeliancko” (w korpomowie takie projekty nazywane są „edżajlowymi”) będzie się umacniał. Skoro od tego zależy zdolność rozwoju, każde korpo musi sobie uchwalić zasady „dopuszczalnej rebelii garażowej”, w które nie ingeruje – to trochę taka zasada compliance mówiąca o tym, gdzie compliance nie ma wstępu, a od którego miejsca zaczyna się stymulowany proces dorastania. Bez tego żadne korpo nie będzie miało interesu w finansowaniu startupów. Obie perspektywy muszą te zasady gry zrozumieć i zaakceptować.

Pozostaw komentarz