O roli architektury i architektów w transformacji cyfrowej

Z prof. dr hab. Andrzejem Sobczakiem, kierownikiem Zakładu Zarządzania Informatyką w Instytucie Informatyki i Gospodarki Cyfrowej SGH, specjalistą od strategicznego zarządzania IT i architektury korporacyjnej rozmawiamy o tym czym jest dziś cyfrowa transformacja, w jakim zakresie koncepcję architektury korporacyjnej da się wykorzystać podczas realizacji transformacji cyfrowej, a także jakie zdolności architektoniczne powinny zostać zbudowane przez organizację, aby zarządzanie architekturą było użyteczne w tych przedsięwzięciach i jaka jest rola architektów w cyfrowej transformacji?

Jak wspomina Pan we wstępie do swojej prelekcji na 8 Kongresie itSMF Polska – który odbędzie się w dniu 26 października w Warszawie – podejście architektoniczne jest stosowane głównie w procesach zarządzania dużymi zmianami, programami transformacyjnymi. Ostatnio mówi się dużo o nich w kontekście cyfrowej transformacji. Czym jednak jest ona sama w sobie? Z jakimi projektami IT, projektami architektonicznymi się wiąże?

Kieruję Zakładem Zarządzania Informatyki w Szkole Głównej Handlowej. Mówiąc więc o IT nakładam na tę tematykę perspektywę zarządczą, a nie techniczną. Dla mnie – osoby zajmującej się strategicznym zarządzaniem IT – cyfrowa transformacja to przeobrażenie funkcjonowania biznesu za pomocą nowoczesnych technologii. Michał Boni, będąc Ministrem Administracji i Cyfryzacji wprowadził zamiast pojęcia informatyzacji pojęcie cyfryzacji. Zarzucano mu nowomowę, ale takie podejście pozwala na dokonanie zmiany w sposobie myślenia na temat tego typu projektów. W warstwie komunikacyjnej mówienie o informatyzacji kojarzy się z informatykiem we flanelowej koszuli i jego komputerami. Cyfryzacja zaś to właśnie przebudowa modeli biznesowych i tworzenie tzw. platform wzrostu przy pomocy rozwiązań IT. Łatwiej dotrzeć z takim przekazem do zarządów i biznesu.

Pana wystąpienie zostanie wpisane w kontekst architektury systemów IT. Jaka wobec tego jest jej rola w projektach transformacji cyfrowej? Tym bardziej, że architektura kojarzy się zwykle właśnie z systemami i infrastrukturą IT…

Każdy pod pojęciem architektury rozumie coś innego. Najczęściej kojarzy się ona z diagramami, które pokazują właśnie strukturę i powiązania pomiędzy systemami IT i elementami biznesowymi (np. procesami). Dla mnie to raczej mechanizm zarządczy, bazujący na modelach (w szczególności, kiedy mówimy o architekturze korporacyjnej). Ale możemy oczywiście mieć także do czynienia z architekturą rozwiązania, np. architekturą pojedynczego systemu np. CRM, billing. Istnieje wreszcie architektury oprogramowania.

Moim zdaniem architektura pozwala przede wszystkim zaplanować i przeprowadzić – w sposób skoordynowany i bezpieczny – cyfrową transformację. Architektura jest narzędziem do skomunikowania procesów objętych cyfrową transformacją. Musimy jednak – w tym kontekście – myśleć o architekturze korporacyjnej, bo architektura systemów IT to trochę za mało, aby móc zobaczyć realne korzyść przy stosowaniu tego podejścia w odniesieniu do cyfrowej transformacji. Tu niestety napotykamy na spory problem, zwłaszcza w Polsce, ponieważ większość firm albo wdrożyła architekturę IT właśnie albo – jeśli nawet jest to architektura korporacyjna – to jest ona nastawiona na obszar IT (jest to tzw. architektura korporacyjna IT).

Ponieważ w 90 proc. przypadków podejście do architektury zaczyna się od IT, to biznes – uważając, że to problem IT – nie chce się w tego typu projekty angażować. Jeśli nawet w kolejnym kroku IT chce rozszerzyć koncepcję architektury korporacyjnej o aspekty biznesowe, to napotyka wówczas na szklany sufit zniechęcenia i niezrozumienia ze strony biznesu. Zwykle też, gdy mówimy o cyfrowej transformacji mamy do czynienia z CDO – Chief Digital Officer, który – z wymienionego wyżej powodu – stara się zbudować własną strukturę i kompetencje. O ile więc CIO nie zmieni podejścia, nie założy „czapki biznesowej”, to po raz kolejny zostanie zepchnięty do defensywy i ograniczony głównie do zarządzania infrastrukturą. Ta zaś stanie się wkrótce commodity i zapewne ostatecznie – jako taka – zostanie oddana w outsourcing.

W jaki sposób architektura korporacyjna może pomóc zmieniać biznes?

Architektura to uporządkowana wiedza organizacji przedstawiona w postaci modeli i zasad dotycząca działania organizacji. To także – zgonie z podejściem Gartnera – sposób na usprawnienie zarządzania zmianą w organizacji przy wykorzystaniu wyżej wymienionych modeli. Oczywiście należy pamiętać, że sama architektura nie zastąpi zarządzani projektami, czy procesu tworzenia nowych produktów. W kontekście cyfrowej transformacji konieczne jest rozpisanie modeli, co jest często czasochłonne i pracochłonne. Można także stosować podejście bazujące na koncepcji Agile Modelling (stosowałem je wielokrotnie w praktyce i daje ona zdecydowanie lepsze rezultaty niż próba „opisania wszystkiego”). Potrzebne są jednak do tego kompetencje biznesowe, zrozumienie technologii i wykorzystanie odpowiednich narzędzi informatycznych. Swoją drogą z czasem przekonuję się, że dla architekta – zwłaszcza takiego, który chce zaprezentować koncepcję transformacji zarządowi – lepszy jest PowerPoint, niż dedykowane narzędzia do tworzenia modeli architektonicznych (nie chodzi bowiem o uchwycenie wszystkiego, lecz zakomunikowanie na poziomie zarządu kluczowych kwestii/decyzji architektonicznych). Architektura to także Governance, czyli nadzór zmierzający do tego, aby projekty „dowoziły” wartość, a nie tylko rozwiązanie (i to zarówno w średnim jak i długim okresie czasu). Powinna więc gwarantować dostarczanie tej wartości klientów wewnątrz i na zewnątrz organizacji.

Czy wobec tego powinna zmienić się też rola architektów? Jaką rolę będą oni pełnić w transformacji cyfrowej?

Architekci zwykle nastawieni są na wnętrze organizacji, na opisanie tego, jakie systemy w niej funkcjonują i jak wspierają one biznes. W erze cyfrowej transformacji powinni zaś patrzeć raczej na to, jak się komunikujemy – API stosowanych rozwiązań – oraz na to, w jaki sposób dostarczamy dane partnerom, jak wpływają one na nasz i ich biznes. Mamy dziś bowiem do czynienia z koncepcją organizacji rozszerzonej – Extended Enterprise, tworzeniem cyfrowych ekosystemów. Świat cyfrowy jest z założenia otwarty.

A jakie zdolności architektoniczne powinny zostać zbudowane przez organizację, aby zarządzanie architekturą było użyteczne w tych przedsięwzięciach?

To przede wszystkim wspomniane już przeze mnie otwarcie się na zewnątrz organizacji. Mówimy raczej o coopetition niż o konkurencji, raczej o budowaniu ekosystemów i platform, niż zamkniętych systemów i rozwiązań. W Polsce platform – takich, jak te stworzone przez Amazon, Apple czy Google – nie będzie dużo. Powstają one raczej na poziomie globalnym. W Polsce możemy jedynie podłączyć się do nich. Architekci korporacyjni powinni więc myśleć w jaki sposób to zrobić. W tym właśnie powinni dziś pomagać.

Ich rolą jest też tworzenie synergii pomiędzy działaniami w różnych częściach organizacji, aby żadna z nich nie cyfryzowała się z osobna, aby o architekturze – jak o bezpieczeństwie – myśleć już na samym początku. Architekt ma wspierać organizację, proponować rozwiązania. Natomiast architektura korporacyjna powinna stanowić element zarządczy. Co ciekawe, na Zachodzie architektów kształci się na wydziałach zarządzania, w Polsce zaś na politechnikach… poza SGH ;).

Jak widać wymagana jest zmiana postrzegania architektury. Jak ją najlepiej „sprzedawać”?

Powinniśmy mówić o architekturze cyfrowej (transformacji), a nie korporacyjnej. Powinniśmy mówić o architektach zmiany cyfrowej. Dzięki temu stracą oni plakietkę „IT”, a zyskają wsparcie biznesu. Jest jednak jeszcze jeden problem, zapewnienie niezawodności architektury. Dużo mówi się o proponowanym rozwiązaniu, a na koniec dostarczane jest coś zupełnie innego. Co zawiniło? Zapewne złożony proces wytwórczy. Dlatego warto by wprowadzić koncepcję  ArchDevOps – tak, aby architekci nie „odlecieli” z jednej strony w „bujanie w chmurach”, a z drugiej strony, aby programiści nie dostarczali rozwiązań punktowych, trudnych w rozwoju. Swoją drogą ciekawe co stanie się z systemami powstającymi w modelu agile za 5, 10, 15 lat? Zostaną „zaorane”, czy da się je utrzymywać? Czy myślano o cyklu życia tych systemów tworząc ich architekturę?