Skąd ten BizDevOps?

Składowe koncepcji BizDevOps - rysunek własny
Składowe koncepcji BizDevOps - rysunek własny

Skąd ten BizDevOps?

Koncepcja BizDevOps jest odpowiedzią na naturalną potrzebę włączenia Biznesu lub jego przedstawicieli w prace zespołów technologicznych. Zjawisko to nie jest nowe – przykładowo w PRINCE2 takim przedstawicielem jest Główny Użytkownik (ang. Senior User), w SCRUM Właściciel Produktu (ang. Product Owner), natomiast w ITIL Odbiorca Usługi (ang. Service Customer). Różnica polega na stopniu zaangażowania takiego przedstawiciela Biznesu, głębokości zainteresowania (interesuje się tylko efektem, czy też sposobem uzyskania tego efektu) oraz posiadanymi uprawnieniami do samodzielnego podejmowania decyzji.

Pomysły na włączenie Biznesu w prace zespołów technologicznych pojawiały się w wielu organizacjach, publikacjach i na konferencjach. Jako prekursora tej koncepcji podaje się Gary Kinga, byłego CIO firmy T-Mobile, który w 2013 roku doprowadził do wspólnego tworzenia planów i śledzenia rezultatów przez Biznes i IT. Nie nazywał tego, ale gdy trzy lata później opuszczał firmę liczba abonentów była dwukrotnie większa a zmiany produktów były dokonywane w czasie rzeczywistym. (Valerie Silverthorne: Wondering what comes after DevOps? Developers, it's time for BizDevOps, TechTarget, 08 Nov 2016).

Spis treści

DevOps 2.0

Sugestie angażowania Biznesu zaczęły pojawiać się również w samym podejściu DevOps, w którym wybrzmiały jako DevOps 2.0. Jednak DevOps 2.0, podobnie jak podejścia przedstawione w publikacji Vallerine Silwerthorne, czy też w opublikowanym nieco później artykule Margaret Rouse (Margaret Rouse: BizDevOps (Business, Development and Operations), TechTarget) koncentruje się głównie na zacieśnieniu współpracy między Biznesem i zespołami DevOps w ramach agileowych zespołów projektowych i wdrożeniowych (Gene Kim, Jez Humble, Patrick Debois& John Willis: The DevOps Handbook, IT Revolution Press, LLC, Portland 2016). Nie będąc jednak podejściem kompleksowym pozostawia szereg tematów nierozstrzygniętych zarówno z obszaru technologicznego, jak i biznesowego. W obszarze technologicznym to przede wszystkim zagadnienie architektury mikrousługowej (ang. Microservices Architecture, MSA) i wynikającego z niej ładu architektonicznego (ang. Architecture Govermnance). W obszarze biznesowym nierozwiązanym problemem są silosy biznesowe oraz ulegająca ich silnym wpływom hierarchiczna struktura decyzyjna a także brak stałych mechanizmów koordynujących rozwiązania na poziomie biznesowym.

Brak uregulowania tych kluczowych kwestii wprowadza ogromną inercję decyzyjną, ograniczając i spowalniając zwinne działania zespołów wdrożeniowych. To stąd, a nie ze złej woli, może wynikać brak decyzyjności Właściciela Produktu (ang. Prodact Owner) czy przesunięcie terminu dostawy, wynikające np. z oczekiwania na wdrożenie innych komponentów w najbliższym wydaniu (ang. release).



Wpływy organizacji ograniczające zwinność zespołów wdrożeniowych


BizDevOps – główne składowe koncepcji

Pomysł na kompleksowe podejście do modelu zarządzania opartego o ścisłą współpracę Biznesu i IT oraz adresującego powyżej opisane ograniczenia zrodził się podczas przygotowywania programu 8 Kongresu itSMF Polska, w Warszawie. Inspiracją była idea i termin BizDevOps zaprezentowany przez jednego z autorów artykułu podczas Forum SPEED IT 21 czerwca 2016 r. Wokół tej idei rozwinęła się ogólna koncepcja BizDevOps opublikowana na portalu Governica, a w ślad za nią pojawiły się kolejne artykuły opisujące szczegółowe zagadnienia odnoszące się do: IoT i firm produkcyjnych, narzędzi wspierających, pracy zespołowej czy testowania.

Koncepcja BizDevOps opiera się na trzech filarach:
  1. konwergencji IT i Biznesu (ang. Convergence of IT and Business)
  2. mikrousługach (ang. Microservices)
  3. inteligencji rozproszonej (ang. Swarm Intelligence)
Stabilność takiego rozwiązania gwarantuje oparcie całości na solidnym fundamencie Architektury Przedsiębiorstwa 2.0 (ang. Enterprise Architecture 2.0), która konsoliduje poszczególne elementy, zapewniając platformę współpracy.



Składowe koncepcji BizDevOps


Konwergencja IT i Biznesu

Pierwszym i najważniejszym założeniem koncepcji BizDevOps jest konwergencja IT i Biznesu przeprowadzona na poziomie organizacyjnym, kulturowym i architektonicznym.

Na poziomie organizacyjnym konwergencja oznacza utworzenie stałych, mieszanych zespołów, w skład których wchodzą osoby z Biznesu i IT. Zespół taki odpowiada za cały cykl życia danej usługi biznesowej, w tym udział w procesie biznesowym, który ona realizuje. Czynnikami, które pozwalają na tak rozumianą konwergencję jest z jednej strony upowszechnienie wiedzy z zakresu IT wśród osób zajmujących się biznesem, a z drugiej strony wzrost świadomości i kompetencji biznesowych wśród informatyków.

Z czasem następuje utożsamienie, zacieranie różnic pomiędzy przedstawicielami Biznesu i IT w podejściu do kreowania produktów biznesowych przy pełnym wykorzystaniu technologii, w ich dalszym rozwoju oraz w ich bieżącej obsłudze. Możemy wówczas mówić o konwergencji na poziomie kulturowym. Oczywiście wewnątrz zespołu może występować zróżnicowanie umiejętności, jednak jest ono relatywnie niewielkie – poszczególni członkowie zespołu robią coś mniej lub bardziej efektywnie, ale z czasem nie powinno być większych problemów w przejmowaniu swoich zadań.

Zmiany w zakresie wiedzy, kompetencji i mentalności są warunkiem koniecznym konwergencji, jednak nie wystarczającym. Niezbędny jest odpowiedni poziom automatyzacji, a w szczególności dostępność narzędzi wspomagających tworzenie oprogramowania, jego uruchamianie czy też testowanie. Pisze o tym m.in. Tomasz Sobczyk w artykule Rewolucja w DevOps – Server less computing.

Jako przykład konwergencji Biznesu i IT może posłużyć firma, w której podjął pracę znajomy informatyk. Firma zbudowała i zarządza serwisem pozwalającym znaleźć ośrodek narciarski, zarezerwować i zapłacić za pobyt oraz uzyskać potwierdzenie rezerwacji. Co może dziwić, informatyk był rozliczany za zyski płynące z transakcji z ośrodkami narciarskimi będącymi pod jego opieką. Jako nowozatrudniony pracownik otrzymał listę ośrodków, których oferty miał włączyć do systemu. Do jego obowiązków należało nawiązanie kontaktu, uzgodnienie warunków współpracy, oprogramowanie interfejsów pozwalających na wymianę informacji w czasie rzeczywistym, utrzymywanie łącza i interweniowanie w przypadku zgłoszeń od użytkowników.

Ten prosty przykład odnosi się do zespołu jednoosobowego jednak eksperymenty z tworzeniem mieszanych zespołów są również od jakiegoś czasu prowadzone w wiodących technologicznie bankach i firmach e-commerce.

O konwergencji możemy mówić również na poziomie architektonicznym. Oznacza to brak potrzeby rozróżnienia między architekturą biznesową a architekturą IT, ponieważ procesy biznesowe są równocześnie procesami informacyjnymi, struktura biznesowa jest tożsama ze strukturą IT, a uczestnicy procesu realizują zarówno zadania IT jak i biznesowe.

Mikrousługa

Kolejnym warunkiem powodzenia we wdrażaniu koncepcji BizDevOps jest zmiana aplikacji i systemów monolitycznych na rozwiązania oparte na mikrousługach. Mimo, że podejście mikrousługowe jest stosowane m.in. przez takie firmy jak Amazon, The Guardian, czy Netflix, do tej pory nie wypracowano jednej, obowiązującej definicji tego pojęcia. Martin Fowler zauważa, że mikrousługi są jednym ze stylów architektonicznych. Według niego powstające oprogramowanie składa się z zestawu mikrousług, z których każda działa w ramach własnego procesu i komunikuje się z innymi mikrousługami za pomocą lekkich protokołów komunikacyjnych – takich jak np. HTTP.

Każda mikrousługa koncentruje się na wsparciu określonego potencjału biznesowego organizacji a jej kluczową cechą jest niezależność od innych mikrousług. Niezależność ta przejawia się przede wszystkim w niezależnym implementowaniu oraz autonomicznej skalowalności. Ponadto nie ma scentralizowanego zarządzania mikrousługami, co powoduje, że każda z nich może być przygotowana w innym języku programowania oraz może używać innej technologii przechowywania danych. Jednak aby spełnić te wszystkie warunki i uzyskać płynące z nich korzyści konieczne jest zapewnienie logicznej separacji pomiędzy kodem odpowiadającym za funkcjonalność mikrousługi a jej interfejsem, który powinien być jak najmniej zmienny (Anne Thomas, Aashish Gupta: „Innovation Insight for Microservices”, Gartner 27 January 2017, ID: G00312990 ).

Korzyści z przejścia na mikrousługi zauważyło wiele firm i ich nowe systemy tworzone są z wykorzystaniem tej technologii. Problemem są istniejące (ang. legacy) systemy monolityczne – mało jest firm, które dostrzegając ewidentne korzyści decydują się na przepisanie głównych systemów na mikrousługi. Wyzwanie takie podjęło np. Allegro, gdzie ok. 400 programistom zajęło to prawie dwa lata.

Model mikrousługowy jest przede wszystkim kompatybilny z wizją zespołów BizDevOps, które nie są kompetentne do pisania dużych monolitycznych systemów, natomiast bez problemu są sobie w stanie poradzić z napisaniem i wdrożeniem mikrousługi.

Wdrożenie mikrousług ma również ogromne znaczenie dla samego procesu tworzenia, testowania i wdrażania nowych funkcjonalności. Jak już zostało powiedziane, napisanie kolejnej mikrousługi wymaga umiejętności, którymi dysponuje zespół BizDevOps i może być wspierane przez narzędzia automatyzujące. Wielkość i sposób komunikacji z innymi mikrousługami ogranicza potrzebę przeprowadzania testów regresji. Z tego samego względu dołączenie kolejnej mikrousługi do istniejących nie wiąże się, tak jak to jest w przypadku systemów monolitycznych, z dużym ryzykiem. W związku z tym możemy osiągnąć ideał podejścia Agile i realizować wydania (ang. release) natychmiast, gdy powstanie nowa funkcjonalność.

Inteligencja rozproszona

Trzecim, ale nie mniej ważnym filarem koncepcji BizDevOps jest zastosowanie w zarządzaniu przedsiębiorstwem podejścia nazywanego inteligencją rozproszoną lub inteligencją roju (ang. Swarm Intelligence). Wykorzystanie inteligencji rozproszonej jest rozumiane jako tworzenie w miarę płaskiej struktury organizacyjnej, w której zespoły o ściśle określonych rolach i zadaniach, sieciowo współpracują ze sobą w oparciu o ustalone zasady i reguły zarządcze.

Podejście takie umożliwia praktyczne wykorzystanie potencjału wiedzy i innowacyjności często uśpionego na najniższym, operacyjnym szczeblu organizacji. Jest to również podejście najbardziej naturalne dla pokolenia C, które w 2020 roku będzie stanowić około 40% populacji Stanów Zjednoczonych i 10 procent populacji reszty świata. Specjaliści od HR charakteryzują to pokolenie trzema przymiotnikami: połączeni, skomunikowani, zmienni (ang. connected, communicated, changed). Równocześnie osoby z tego pokolenia są w znacznie większym stopniu niż wcześniejsze, świadome swojej wiedzy i potrzebują poczucia koherencji (ang. the sense of coherence).

Wdrożenie inteligencji rozproszonej wiąże się z bardzo dużą zmianą kulturową oraz wymaga zapewnienia odpowiednich warunków i narzędzi do komunikacji. Jest to tym ważniejsze im organizacja jest większa. Potwierdzeniem efektywności takiego podejścia, poza organizacjami, jest wspólne tworzenie narzędzi informatycznych przez wielu niezależnych programistów pracujących poza formalnymi strukturami zarządczymi. Przykładem tego rodzaju działań jest system operacyjny Linux, wolne oprogramowanie oraz przeglądarka Firefox stworzona w dużej części przez wolontariuszy. Podobnie Wikipedia jako całość również powstała w ten sam sposób.

Wykorzystanie inteligencji rozproszonej jest spójne zarówno z architekturą mikrousługową, jak i konwergencją kompetencji biznesowych i informatycznych. Poszczególne funkcje biznesowe są realizowane przez zespoły, które posiadają wiedzę wynikającą z bezpośredniego kontaktu z Klientem. Jeśli dany zespół nie posiada odpowiednich kompetencji zgłasza taką potrzebę i staje się Klientem innego zespołu. W ten sposób nie ma potrzeby analizowania, budowania i testowania złożonych systemów monolitycznych. Powstają one jako sieć połączonych ze sobą mikrousług.

Architektura Przedsiębiorstwa 2.0

Aby te trzy - ideowe filary BizDevOps mogły w przedsiębiorstwie zaistnieć, muszą zostać osadzone w jego architekturze. Dotychczas Architektura Przedsiębiorstwa (ang. Enterprise Architecture) rozumiana była przede wszystkim jako architektura IT. Aspekt biznesowy, choć coraz częściej akcentowany w metodykach architektonicznych (np. TOGAF, Archimate) w praktyce był pomijany lub stosowany punktowo. Architektura Przedsiębiorstwa 2.0 (ang. Enterprise Architecture 2.0, EA 2.0), stanowiąca fundament koncepcji BizDevOps, całkowicie zmienia to podejście, ponieważ jej podstawowym założeniem jest konwergencja architektury biznesowej i architektury IT.

Architektura Przedsiębiorstwa 2.0 to przede wszystkim architektura wspierająca ciągły tryb dostarczania zmian (ang. continuous delivery) w pełnym cyklu ich życia, co z biznesowego punktu widzenia bezpośrednio przekłada się na skracanie okresu od momentu powstania konceptu aż do wprowadzenia produktu lub usługi na rynek (ang. Time-to-Market). Jest to architektura mikrousługowa (MSA) wraz całym zapleczem technologicznym opartym o wykorzystanie konteneryzacji (ang. software container) i rozwiązań chmurowych (ang. cloud computing). Jej głównym założeniem jest ścisłe powiązanie mikrousług z funkcjami biznesowymi (przy uwzględnieniu kontekstu biznesowego) w ramach domen i potencjałów biznesowych. Architektura 2.0 charakteryzuje się również podstawowymi cechami inteligencji rozproszonej, czyli sieciowością – wskazującą na równorzędność jej komponentów oraz otwartością -pozwalającą na jej rozszerzanie lub udostępnienie jej komponentów innym podmiotom w danym ekosystemie biznesowym (ang. Business Ecosystem). Przykładem pokazującym jak istotna jest cecha otwartości może być dyrektywa unijna PSD2 pozwalająca na udostępnienie informacji o rachunku oraz realizację płatności za pośrednictwem firm, nie posiadających licencji bankowej np. technologicznych.

Bezpośrednim rezultatem powyższych założeń EA 2.0 jest wynikający z nich ład architektoniczny (ang. Architecture Governance). Głównym zadaniem tego ładu jest zapewnienie spójności realizowanych zmian z celami przedsiębiorstwa, co w środowisku licznych, rozproszonych zespołów BizDevOps, realizujących zmiany w trybie agile jest szczególnie istotne.

Do Architektury 2.0 nie można jednak podchodzić ortodoksyjnie, próbując ją wdrażać w każdym przedsiębiorstwie lub od razu we wszystkich jego obszarach biznesowych. Po podjęciu decyzji o stosowaniu podejścia BizDevOps lepiej jest przyjąć Architekturę 2.0 jako stan docelowy, sukcesywnie dochodząc do niej w kolejnych obszarach biznesowych i na bazie kolejnych komponentów architektonicznych.

Podsumowanie

Koncepcja BizDevOps jest kompleksową odpowiedzią na rosnącą potrzebę ścisłej integracji Biznesu i Informatyki. O znaczeniu takiej potrzeby świadczy fakt, że próby tego typu rozwiązań pojawiają się niezależnie w wielu różnych organizacjach - oprócz wspomnianego już T-Mobile, są to ING Groep N.V., Grupa Allegro, Grupa Onet.pl. Ten trend pojawia się przede wszystkim w dużych organizacjach, dla których granulacja biznesu i delegowanie uprawnień decyzyjnych na niższy poziom może być wyzwalaczem dla zwiększenia zwinności na rynku. W zupełnie innej sytuacji są startupy, w których główne założenia BizDevOps są realizowane w niemal naturalny sposób - cały startup to praktycznie jeden zespól BizDevOps, w którym wszyscy pracują razem, wspólnie wypracowując decyzje i wspomagając się w działaniach operacyjnych.

Autorzy
  • Ewa Zaleska
  • Krzysztof Tomkiewicz


Zobacz też