Digitized ≠ Digital

Wstęp

W dniu 11 czerwca 2019 uczestniczyłem w konferencji IX ForumArchitektów IT. Podczas konferencji opowiedziałem, jak zarządzamy architekturą korporacyjną w mojej obecnej, zwinnej firmie. Inne wystąpienia traktowały o roli architekta IT, o zarządzaniu innowacjami, o praktycznej przydatności modelu pojęciowego, o wartości danych w firmie, …

Po części prezentacyjnej miał miejsce m.in. warsztat pt. „Transformacja cyfrowa oczami architekta”. Warsztat miał formę moderowanej dyskusji, podczas której staraliśmy się odpowiedzieć na postawione przez moderatorów pytania dotyczące cyfrowej transformacji. Jedno z takich pytań, na które nie udało nam się odpowiedzieć a wręcz pojawiły się różne odpowiedzi, to pytanie „co to jest digital transformation”. Przykłady takich transformacji przytaczane przez moderatorów i zebranych często nie miały wspólnych cech a mimo to były nazywane „cyfrowymi transformacjami”. Stąd pomysł, aby podzielić się wynikami analiz i badań przeprowadzonych na ten temat przez:

• naukowców z MIT CISR, którzy - na podstawie badań 2014 - 2015 (27 firm) oraz 2016 (171 executives) - odróżniają i oddzielnie definiują znaczenie „digitized” oraz „digital” (niestety z braku dobrych odpowiedników w języku polskim w dalszej części tekstu pozostawiam angielskie nazwy)
• badaczy Gartnera, którzy odróżniają i oddzielnie definiują „digital business optimization” oraz „digital business transformation”

I nie jest to jedynie kwestia samych definicji, które mogą pomóc w komunikacji ale również wynikające z tych definicji różnice dotyczące celów i korzyści, ładu, podejścia do ryzyka oraz podejścia do zmian.

„Digitization”, stawanie się „digitized”

„Digitizaion”, to wg MIT transformacja, w której chodzi o standaryzację a następnie automatyzację głównych, back offic’owych procesów biznesowych. Chodzi o wydajność, skalowalność, stabilność i przewidywalną powtarzalność. Chodzi o bezpieczeństwo i dokładność przetwarzania transakcji. Chodzi o dostęp do danych z tych procesów. Na końcu chodzi o niższe ryzyko i niższe koszty operacyjne podstawowych operacji firmy.

Firmy robią to już od kilkudziesięciu lat wdrażąjąc CRM’y, ERP’y, itp. lecz z różnym efektem. Główną trudnością bowiem nie jest technologia, ale zmiana (zestandaryzowanie, dyscyplina) sposobu pracy. Te procesy i technologie tworzą platformę, którą naukowcy z MIT nazywają „operational backbone”.

„Digitalization”, stawanie się „digital”

Stawanie się „digital”, to już całkiem inne ćwiczenie od stawania się „digitized”. To całkiem inne podejście, cele i często (ale nie zawsze) inne technologie. Stawanie się „digital”, to transformacja, w której chodzi o nową, kliento-centryczną propozycję wartości możliwą do wytworzenia dzięki takim technologiom jak „social”, „mobile”, „analytics”, „cloud”, „internet of things” (SMACIT), czy sztuczna inteligencja, biometria i inne nowe technologie. Te technologie mogą oczywiście być użyte do optymalizacji operacji, ale przede wszystkim mogą być użyte do zbudowania całkiem nowej propozycji wartości. Firma, która jest „digital” używa tych technologii do innowacyjnej rozbudowy swoich produktów i usług oraz spersonalizowanego angażowania klientów. Korzyścią ze stawiania się „digital” nie są niższe koszty czy ryzyka ale wzrost przychodów i marż, wzrost lojalności klientów a także zdolność do pozyskiwania do pracy najlepszych talentów.

Firmy dostarczają tej nowej propozycji wartości w postaci tzw. „digital offerings”, które MIT CISR definiuje następująco: to rozwiązania klienckie wzbogacone o informacje i dostarczane jako bezproblemowe, spersonalizowane doświadczenia klienta (po polsku brzmi to średnio, więc przytaczam wersję oryginalną: „digital offerings = information-enriched customer solutions delivered as seamless, personalized customer experiences”). Przy czym chodzi tutaj zarówno o wzbogacone produkty i usługi (np. wzbogacone o informacje, zintegrowane - tworzące rozwiązanie, w sposób przezroczysty zawierające usługi i produkty partnerów, itp.) jak i o spersonalizowane angażowanie klientów (np. spójność interakcji w różnych kanałach, inne interakcje dla różnych segmentów, interakcje odpowiednie do oczekiwania klienta, dające klientowi więcej informacji/wglądu, itp.).

Efektem „digital offerings” jest wzrost przychodu. Firmy zwykle najpierw tworzą mały „digital” produkt lub usługę a później go szybko rozbudowują lub wprowadzają oferty powiązane. Dokładnie tak samo, jak to robią start-up’y.

Do szybkiego tworzenia i rozbudowy „digital offerings” nie wystarczy wspomniana platforma „operational backbone”. Dlatego w tym celu firmy budują drugą platformę – „digital offerings platform”. Ta druga platforma składa się zarówno z elementów wyłącznie technicznych takich, jak autentykacja czy integracje, ale również z elementów o przeznaczeniu biznesowym, takich jak onboarding klienta czy dashbordy, które firma wykorzystuje (reużywa) dla każdej nowej „digital offering”, co przyspiesza konfigurowanie nowych „digital offerings”.

„Digitized” vs. „digital”

Przytoczone opisy nie są bardzo ścisłymi definicjami, co to jest transformacja „digitized” i transformacja „digital” ale pokazują wyraźną różnicę w celach i korzyściach, podejściu do ładu i podejściu do ryzyka. Różnice podsumowuje poniższa tabela:

Źródło: MIT CISR

W Gartnerze myślą podobnie

Podobny sposób rozróżnienia, na optymalizację oraz budowę nowych propozycji wartości, proponuje Gartner, który odróżnia / zestawia ze sobą dwa różne rodzaje zmian możliwych dzięki technologiom: „Digital Business Optimization” oraz „Digital Business Transformation”. Przy czym używane technologie mogą być w obu przypadkach takie same. To co odróżnia te dwa rodzaje zmian od siebie, to, wg Gartner’a m.in. to, czy zmiany modyfikują / rozszerzają / tworzą nowy model biznesowy, czy nie:

• Jeśli model biznesowy (czyli w skrócie: docelowi klienci, propozycja wartości dla nich, zestaw zdolności, sposób zarabiania) się nie zmienia, to wg Gartner'a mamy do czynienia z „Digital Business Optimization”. Przykładem takiego działania jest np. wdrożenie ERP. Albo użycie drukarek 3D do redukcji kosztów. Albo użycie sztucznej inteligencji do lepszej oceny ryzyka. Czytałem też kiedyś o fabryce, w której wykorzystano virtual reality do poprawy motywacji pracowników pomagając im zobaczyć (właśnie za pomocą virtual reality), że części, które składają, są elementem większej całości (samolotu, statku).
• Jeśli jednak model biznesowy się zmienia lub tworzony jest całkiem nowy, to mamy do czynienia z „Digital Business Transformation”. Przykładem jest zmiana sposobu sprzedawania z produktu (np. płyta CD) na usługę typu pay-as-you-use (dostęp do muzyki). Albo zmiana: sprzedaję tylko swoje usługi / produkty na pośredniczę w sprzedaży czyichś usług / produktów.

Różnice podsumowują dwie poniższe tabele:

„Digital Business Optimization” = tworzy istotną wartość bez zmiany modelu biznesowego (w ramach istniejącego modelu biznesowego):

Źródło: Gartner

„Digital Business Transformation” = prowadzi do utworzenia nowych strumieni przychodów i nowych modeli biznesowych:

Źródło: Gartner

Inną cechą, którą Gartner przytacza jako odróżniającą „Digital Business Optimization” od „Digital Business Transformation” jest stopień kontrolowalności zmienianego środowiska. W „Digital Business Optimization” pracujemy w ramach istniejącego modelu biznesowego, w ramach środowiska, które kontrolujemy w całości. W „Digital Business Transformation” wychodzimy poza organizację i zaczynamy robić rzeczy, których nigdy nie robiliśmy, na których się jeszcze nie znamy. 

Przykładem „Digital Business Optimization”, czyli zmiany w ramach kontrolowanego środowiska, jest wdrożenie autonomicznych ciężarówek w kopalni odkrywkowej lub wdrożenie autonomicznych odśnieżarek na lotnisku – w obu przypadkach środowisko jest w całości kontrolowane przez organizację, wykorzystujemy nowe technologie, tworzymy istotną wartość ale poruszamy się w ramach istniejącego modelu biznesowego. Kontr-przykładem „Digital Business Transformation” jest wg Gartnera autonomiczny samochód poruszający się po drogach publicznych. Tutaj wkraczamy w środowisko, którego nie kontrolujemy.

Dwie różne platformy digi*

Wracamy jednak do badań MIT. Wspomniane wyżej dwie różne platformy „operational backbone” oraz „digital offerings platform” są wg badań MIT CISR i BCG konieczne do sprostania wyzwaniom dzisiejszej, cyfrowej ekonomii, gdyż razem umożliwiają szybkie testowanie, integrowanie i skalowanie cyfrowych innowacji w zakresie produktów i usługa oraz angażowania klienta.

Platformę „operational backbone”, która wspiera efektywność operacyjną, MIT CISR definiuje następująco: jest to zbiór systemów, procesów i danych, który zapewnia efektywność, skalowalność, niezawodność, jakość i przewidywalność podstawowych (ang. core) operacji firmy. Firmy budują takie platformy od lat wdrażając systemy typu CRM czy ERP aby zestandaryzować i zintegrować procesy firmy. Pomiędzy firmami budowa tej platformy może się różnić, ale w każdym przypadku posiada ona (platforma) następujące cechy:

• Automatyzuje zestandaryzowane, powtarzalne procesy
• Jest jednym źródłem prawdy dla krytycznych danych, takich jak dane klientów, dane o zamówienia, dane o produktach
• Zapewnia płynne i przejrzyste przetwarzanie transakcji
• Dostarcza wglądu w te transakcje
• Zapewnia bezpieczne, niezawodne, stabilne przetwarzanie
• Ma modułową architekturę

Posiadanie zbudowanej platformy „operational backbone”, której firma re-używa przy wchodzeniu na nowe rynki, nabywaniu innych firm, czy dodając nowe produkty, pozwala menadżerom skupić uwagę na budowie nowych cyfrowych usług i produktów.

Platforma „operational backbone” jest zaprojektowana, aby wspierać niezawodność i efektywność, ale nie zapewnia szybkości i elastyczności niezbędnych do szybkiego wdrażania cyfrowych innowacji za zakresie usług i produktów oraz w zakresie angażowania klienta. Do tego celu służy druga platforma, „digital offerings platform”, którą MIT CISR definiuje następująco: zbiór możliwości (ang. capabilities) biznesowych i technicznych służący jako baza dla szybkiego rozwoju i wdrażania cyfrowych innowacji. Ta druga platforma musi ułatwiać ciągłe innowacje bez naruszania niezawodności działania platformy „operational backbone”. „Digital offerings platform” posiada następujące cechy:

• Zawiera reużywalne komponenty / usługi techniczne (np. biometria) i biznesowe (np. wysyłanie powiadomień do klientów)
• Zawiera techniczne środowisko hostowania przyszłych cyfrowych, innowacyjnych usług
• Wspiera dostęp do usług zbudowanych przez partnerów
• Jest dostępna przez API dla partnerów zewnętrznych
• Jest dostępna przez API dla partnerów wewnętrznych
• Zawiera repozytoria do przechowywania wielkiej ilości danych z różnych źródeł: z sensorów, z mediów społecznościowych czy danych kupionych
• Zawiera silniki analityczne do analizy tych danych i wyciągania z nich wniosków
• Wykorzystuje platformy chmurowe (PaaS)
• Wykorzystuje oprogramowanie open-source
• Zawiera gotowe do reużycia połączenia do danych i procesów platformy „operational backbone”

Budowa obu platform stawia różne wymagania

Jak się można spodziewać, budowa tych dwóch platform, tych dwóch zbiorów zdolności (ang. capabilities), stawia przed firmą dwa odrębne zbiory wymagań operacyjnych. Firmy bardzo dokładnie projektują architekturę platformy „operational backbone” - tak, aby zrealizować wymagania na ogólnofirmową standaryzację i integrację procesów. Budowa platformy „operational backbone”, to duża zmiana organizacyjna i znaczne inwestycje w duże systemy. Implementacja jest zwykle wolna i zwykle realizowane w trybie waterfall. Niektóre firmy adoptują tutaj metody agile’owe ale zwykle efektem jest po prostu szybszy waterfall.

Wg badań MIT poniższe, tradycyjne praktyki zarządcze, mają największe znaczenie dla budowy platformy „operational backbone”:

• Przeglądy architektoniczne
• Priorytetyzacja inicjatyw technologicznych na poziomie firmy
• Roadmapa rozwoju infrastruktury na poziomie firmy
• Proces zarządzania inwestycjami na poziomie firmy
• Ustalone pryncypia architektoniczne

Dla kontrastu, budowa platformy „digital offerings platform” nie wymaga dużych inwestycji. Zwykle adoptuje się tutaj technologię chmurową, która wspiera szybki rozwój i reużycie mikroserwisów w celu realizacji wymagań pojedynczego produktu, kanału lub segmentu klientów. Elementem platformy są agile’owe metody pracy, z wykorzystaniem których małe, kros-organizacyjne zespoły budują i testują nowe mikroserwisy. Poprzez rozpoznawanie co działa a co nie, te zespoły powoli rozbudowują „digital offerings platform”.

Wg badań MIT poniższe praktyki zarządcze, mają największe znaczenie dla budowy platformy „digital offerings platform”:

• Zarządzanie kosztem i jakością usługi / produktu przez jego właściciela
• Zarządzanie przychodem i zyskiem (marżą) usługi / produktu przez jego właściciela
• Iteracyjny, cross-funkcyjny rozwój usługi / produktu
• Projektowanie kliento-centryczne
• Podejście MVP
• CI/CD

Poniższa tabela zestawia najważniejsze różnice i uwydatnia podejście do budowy ww. platform.

 Źródło: MIT CISR

Zakończenie: „Digitized” czy „digital”?

Wg badań MIT CIST firmy mogą tworzyć „digital offerings” nie posiadając dojrzałej platformy „operational backbone”. Robią to zwykle poprzez dedykowaną jednostkę biznesową odpowiedzialną za budowanie innowacyjnych rozwiązań. Ale okazuje się, że jeśli oferta takiego innowacyjnego rozwiązania znajdzie popyt, to wtedy trzeba szybko uzupełniać braki w platformie „operational backbone”, aby zapewnić przeskalowanie eksperymentu w działający biznes. Z drugiej strony z biegiem czasu firmy inwestujące w innowacyjne, cyfrowe rozwiązania dla klientów wytwarzają ich coraz więcej. Bez możliwości reużycia wspólnych usług i komponentów między nimi (czyli bez istnienia „platformy digital offerings” - platformy „enablującej” szybkie konfigurowanie nowych „digital offerings”) szybko okaże się, że są za drogie (bo zbudowane jako silosowe rozwiązania) lub nie daje się ich integrować tak, jakby tego oczekiwali klienci. Wniosek: aby stać się „digital”, czyli zaproponować klientom nowe propozycje wartości, niezbędne jest zbudowanie obu platform: „operational backbone” oraz „digital offerings platform”.

Deser

Na deser film, w którym obejrzycie i posłuchacie, jak Pani Jeanne Ross z MIT CISR osobiście mówi o różnicy między Digitized i Digital: http://cisr.mit.edu/publications-and-tools/publication-search/d4d-video1/

Polecam :)

Źródła:

• Prentice Brian, Digital Business Transformation Strategy Needs a Change of Perspective, Gartner, 2018, https://www.gartner.com/en/webinars/3858468/digital-business-transformation-strategy-needs-a-change-of-persp, [dostęp 2019-07-01].
• Ross Jeanne W., Sebastian Ina, Beath Cynthia M., DIGITIZED ≠ DIGITAL, MIT CISR, 2017, https://cisr.mit.edu/blog/documents/2017/10/19/2017_1001_digitizednotdigital_rossbeathsebastian.pdf/, [dostęp 2019-07-01].
• Ross Jeanne W., Sebastian Ina, Beath Cynthia M., Digital design: it’s a journej, MIT CISR, 2016, 2017, https://cisr.mit.edu/blog/documents/2016/04/21/2016_0401_digitaldesign_rosssebastianbeath.pdf/, [dostęp 2019-07-01].
• Ross Jeanne W., Sebastian Ina, Beath Cynthia M., Jha Lipsa, The Boston Consulting Group - Technology Advantage Practice, Designing Digital Organizations - Summary of Survey Findings, MIT CISR, 2017, https://cisr.mit.edu/blog/documents/2017/02/28/mit_cisrwp415_ddosurveyreport_rosssebastianbeathjhabcg.pdf/, [dostęp 2019-07-01].

Dług techniczny - czym jest a czym nie jest

Ostatnio w moim otoczeniu często stykam się z tematem „długu technicznego”. Ale podczas rozmów z różnymi ludźmi zauważyłem, że termin ten jest czasami przez różnych ludzi rozumiany w różny sposób. Stąd pomysł na ten tekst.

Wstęp

Termin „dług techniczny” (lub „dług projektowy”) stworzył Ward Cunningham (twórca pierwszego wiki) we wczesnych latach 90’ (patrz: https://www.youtube.com/watch?v=pqeJFYwnkjE). Wywodzi się on z analogii do kredytu, jaki zaciąga się w banku w celu szybszego uzyskania korzyści. W uproszczeniu: zbudowanie rozwiązania nieoptymalnego (na skróty) odpowiada zaciągnięciu kredytu. Dzięki kredytowi okazja rynkowa jest wykorzystana (korzyść mamy dzisiaj), koszt budowy rozwiązania o optymalnej jakości jest odroczony w czasie ale pojawiają się też odsetki. Te odsetki, to w uproszczeniu zmniejszona łatwość zmiany i/lub zmniejszona efektywność lub zwiększone ryzyko działania systemu. Z kolei rozliczenie kredytu równa się doprowadzeniu „zadłużonego” rozwiązania do optymalnej jakości poprzez jego refaktoring lub zastąpienie nowym.

Objawy

Dług techniczny może się objawiać na wiele różnych sposobów dla wielu różnych interesariuszy:

• Użytkownicy mogą być niezadowoleni z użyteczności aplikacji
• Ludzie od infrastruktury i utrzymania mogą być niezadowoleni z powodu wysokich kosztów operacyjnych aplikacji
• Menedżerowie biznesowi mogą być sfrustrowani kosztem i powolnym tempem dostarczania zmian w aplikacji a przez to w procesach biznesowych
• Ludzie z bezpieczeństwa i zarządzania ryzykiem zauważają, że aplikacja nie nadąża ze spełnianiem standardów bezpieczeństwa

Dług techniczny akumuluje się, jeśli nie jest zmniejszany. Z czasem może nawet przewyższyć możliwości firmy do poradzenia sobie z nim. Jednak, aby zmniejszać (spłacać) dług techniczny, trzeba go najpierw dobrze zrozumieć. Czym on zatem jest?

Definicja

Spotkałem się z wieloma definicjami terminu „dług techniczny” (przytaczam je w oryginale):

• "The residual cost of completing technology tasks left undone in the race to be agile, innovative, or from lack of funding".
• "The ongoing costs of inconvenience, inconsistencies, and lost opportunities".
• "Unfunded critical technical liabilities".
• "A design or construction approach that is expedient in the short term but that creates a technical context in which the same work will cost more to do later than it would cost to do now (including increased cost over time)".
• "Delayed technical work that is incurred when technical short cuts are taken, usually in pursuit of calendar-driven software schedules".
• "A trade-off between the short-term benefit of rapid delivery and long-term value".

Zgadzam się z powyższymi definicjami ale wciąż są one dla mnie zbyt ogólne. Z tego powodu najbardziej podoba mi się definicja Gartnera, która określa, o jakie braki techniczne chodzi (a o jakie nie), gdy mówimy o długu technicznym. Wg Gartnera dług techniczny jest „odchyleniem systemu od jego wszelkich wymagań niefunkcjonalnych”. Proste. Z tej definicji wynika na przykład, że:

• dług techniczny nie dotyczy funkcjonalności - brak wymaganej funkcji aplikacji nie jest długiem technicznym,
• dług techniczny jest względny - może się zmienić w jednej chwili jedynie poprzez zmianę wymagań niefunkcjonalnych (np. dostępność systemu wynosi dzisiaj 8/5 ale wymaganie też było 8/5 --> długu nie ma; ale jak tylko zmienimy wymaganie na 12/6, to w tej samej chwili dług się pojawi).

7 obszarów negatywnego wpływu

Skoro więc dług techniczny jest odchyleniem od wymagań niefunkcjonalnych, to do dokładniejszego zrozumienia i oceny poziomu tego długu będzie nam potrzebna klasyfikacja wymagań niefunkcjonalnych. Prosty model takiej klasyfikacji można znaleźć w standardzie ISO/IEC 25010, który jest ulepszona wersją lepiej znanego ale starszego ISO/IEC 9126. Standard ISO/IEC 25010 określa 8 cech jakości oprogramowania, z czego 1 dotyczy funkcjonalności a pozostałe 7 dotyczą cech niefunkcjonalnych aplikacji:

1. „Niezawodność” (ang. „Reliability”) - obejmuje atrybuty niższego poziomu, takie jak „Stabilność” (ang. „Stability”), „Dostępność” (ang. „Availability”) i „Możliwość odzyskania” (ang. „Recoverability”).
2. „Użyteczność” (ang. „Usability”) - obejmuje obszary, takie jak "szybkość uczenia się" a także „łatwość obsługi”.
3. „Wydajność” (ang. „Performance efficiency”) - ilość zasobów obliczeniowych potrzebnych do zapewnienia odpowiedniego poziomu wydajności.
4. „Utrzymywalność” (ang. „Maintainability”) - odnosi się do tych cech oprogramowania, które ułatwiają (lub utrudniają) wprowadzanie zmian w funkcjonalności, naprawianie błędów i zapewnienie jakości usług.
5. „Przenośność” (ang. „Portability”) - obejmuje przenośność między urządzeniami i systemami operacyjnymi a także łatwość, z jaką aplikacja może być zlokalizowana pod kątem specyficznych cech geograficznych, takich jak język czy podatek obrotowy.
6. „Bezpieczeństwo” (ang. „Security”) - obejmuje wszystkie atrybuty bezpieczeństwa systemu.
7. „Zgodność” (ang. „Compatibility”)  - określa łatwość i wydajność integracji zapewnianej przez oprogramowanie.

Wg definicji Gartnera dług techniczny może mieć negatywny wpływ w ww. 7 obszarach i nigdzie więcej. Oznacza to, że w przyrodzie występuje dokładnie 7 rodzajów długu technicznego:

1. Techniczny dług niezawodności (ang. „Reliability Technical Debt”).
2. Techniczny dług użyteczności (ang. „Usability Technical Debt”).
3. Techniczny dług wydajności (ang. „Performance efficiency Technical Debt”).
4. Techniczny dług utrzymywalności (ang. „Maintainability Technical Debt”).
5. Techniczny dług przenośności (ang. „Portability Technical Debt”)
6. Techniczny dług bezpieczeństwa (ang. „Security Technical Debt”).
7. Techniczny dług zgodności” (ang. „Compatibility Technical Debt”).

4 możliwe powody

Wg Gartnera dług techniczny może w systemie powstać z 4 powodów:

1. Dług planowany - zespół projektowy wie, że istnieje pewne wymaganie niefunkcjonalne N, ale z jakiegoś powodu zdecydowano się go nie realizować i wszyscy interesariusze o tym wiedzą. Np. wymaganie odtwarzalności – w przypadku utraty całego data center aplikacja powinna być odtworzona w ciągu 15 minut; niestety okazuje się to za drogie, więc będzie zapewnione odtworzenie w ciągu 4 godzin. Albo sytuacja, w której z powodu braku czasu (potrzeby dostarczenia rozwiązania szybko) rozwiązanie realizuje się bez zaimplementowanych znanych i wymaganych zabezpieczeń. Wszelkie rodzajów PoC’ów (ang. „Proof of Concept”) także się mieszczą w tej kategorii – w zamian za krótki czas budowy i naukę powstaje rozwiązanie o nie-docelowej jakości.
2. Dług dostarczony - zespół projektowy wiedział, że wymaganie niefunkcjonalne N istnieje i planował je zrealizować. Ale się nie udało. Np. system miał móc obsłużyć 200 równoległych użytkowników. Zaprojektowano pod to 6 serwerów. Ale po wdrożeniu okazało się, że te 6 serwerów wystarcza do obsłużenia 100 równoległych użytkowników. 200 równoległych użytkowników będzie wymagać 40 serwerów.
3. Dług odkryty - zespół projektowy spełnił wszystkie określone wymagania, ale po tym, jak system został dostarczony okazało się, że istnieją wymagania, które wcześniej nie zostały określone. Na przykład nie było wymogu "przenośności" językowej, ale po dostarczeniu systemu firma stwierdziła, że aplikacja musi również obsługiwać inne języki, bo firma zamierza otworzyć oddziały w innych krajach. Odkrywamy nowe wymagania niefunkcjonalne (przenośności językowej), które wcześniej nie były wyartykułowane.
4. Dług nabyty - dług, który system nabywa z biegiem czasu, czasami po wielu latach, z dwóch powodów:
1. Zmiana biznesowa – system pracuje dobrze przez wiele lat, ale w wyniku przeglądu bezpieczeństwa powstaje nowa polityka bezpieczeństwa, wcześniej nieistniejąca, która wymaga „single-sign-on” dla wszystkich aplikacji. Albo aplikacja pracuje dobrze w trybie 8/5, ale biznes rozszerza zakres czasowy swojej pracy i aplikacja musi pracować 12/6. W takim momencie aplikacja „nabyła dług”, który jest efektem zmiany wymagań niefunkcjonalnych.
2. Entropia oprogramowania - z czasem, wraz z dodawaniem nowych funkcji do aplikacji, aplikacja staje się coraz trudniejsza do zmiany z powodu wzrostu złożoności. Lub po prostu wzrósł wolumen przetwarzanych danych i aplikacja zaczęła działać wolniej.

Zaniechanie czynności utrzymaniowych nie jest długiem technicznym!

Ww. rodzaje długu są generalnie wynikiem decyzji co do sposobu realizacji lub wynikiem zmiany wymagań niefunkcjonalnych. Natomiast wg Gartnera nie odnoszą się one do sytuacji, w której nie wykonano wymaganych upgrade’ów i w efekcie używana technologia przestała być wspierana. Np. nie dokonaliśmy upgrade’u systemu operacyjnego lub bazy danych na wersję wspieraną, bo budżet, bo priorytety, bo byliśmy zajęci czymś innym. Według ww. definicji to nie jest dług techniczny, gdyż nie jest wynikiem decyzji projektowej, błędu w tej decyzji, zmiany wymagań niefunkcjonalnych, wzrostu złożoności czy wzrostu wolumenu transakcji. Jest wynikiem zaniechania czynności utrzymaniowych.
Dług utrzymaniowy (doprowadzenie do braku wsparcia) wynika zawsze z konfliktu zasobów - z decyzji, na co je przeznaczyć: na nową funkcjonalność, czy na upgrade bazy danych. Nowa funkcjonalność zamiast koniecznego upgrade’u, to odłożenie zobowiązania utrzymaniowego na później. Trzeba jednak zdawać sobie sprawę, że dokonując takiego odłożenia wcale nie oszczędzamy pieniędzy. Odraczamy jedynie nasze zobowiązanie na przyszłe pokolenia a w zamian za te pieniądze (i/lub czas) budujemy nowy feature dzisiaj. Prędzej czy później jednak to zobowiązanie trzeba będzie spłacić. Z długiem technicznym jest inaczej - można go zlikwidować np. poprzez rezygnację z wymagań niefunkcjonalnych.

Ten rodzaj długu - utrzymaniowego - Gartner nazywa „Długiem IT” i definiuje następująco: „Dług IT, to koszt obsługi opóźnionej lub odroczonej konserwacji portfela aplikacji”. Czyli dług IT, to wg Gartner’a ilość pieniędzy potrzebna na doprowadzenie wszystkich naszych systemów do stanu supported.

Podsumowując:

• Twórcą terminu „dług techniczny” jest Ward Cunningham i dotyczy on odchylenia systemu od jego wszelkich wymagań niefunkcjonalnych. Może się pojawić w wyniku decyzji podjętej podczas projektowania i budowy rozwiązania lub w skutek zmiany / nowych wymagań niefunkcjonalnych.
• „Dług techniczny” nie dotyczy odraczania czynności utrzymaniowych na później. Twórcą nazwy dla tego rodzaj długu jest Gartner, który nazywa ten dług „Długiem IT” (ang. „IT Debt”) i definiuje go jako koszt doprowadzenia portfela aplikacji do stanu supported.

Skutki długu technicznego

Wróćmy do długu technicznego, który jest odchyleniem od wszelkich wymagań niefunkcjonalnych. Generalnie celem definiowania wymagań niefunkcjonalnych jest zapewnienie wymaganej „ilości” danej usługi IT - tzn. jej stabilności, dostępności, wydajności, bezpieczeństwa, itd. (usługa IT wg ITIL v3, to funkcjonalność dostarczana w określonej „ilości”). Istnienie długu technicznego tę „ilość” zmniejsza, co z kolei powoduje zwiększenie kosztu i/lub ryzyka operacji, której tej wymaganej „ilości” usługi IT potrzebują. Na przykład:

• Aplikacja z długiem w obszarze utrzymywalności (ang. „Maintainability”) będzie miała wyższe koszty aktywności utrzymaniowych i czynności wprowadzania zmian.
• Aplikacja, która nie osiąga swoich celów w zakresie wydajności (ang. „Performance efficiency”), będzie powodowała wyższy poziom kosztów operacyjnych, gdyż procesy biznesowe przez nią wspierane również będą za mało wydajne.
• Aplikacja, która nie jest w stanie spełnić swoich celów związanych z odzyskiwalnością (ang. „Recoverability”) stwarza wysoki stopień ryzyka biznesowego ze względu na potencjał przedłużających się (tzn. dłuższych, niż dopuszczalne) przestojów w przypadku awarii systemu.
• Aplikacja, która nie jest w stanie spełnić swoich wymagań dotyczących użyteczności (ang. „Usability”), może powodować zwiększenie kosztów biznesowych spowodowanych niezdolnością jej użytkowników do skutecznego wykonywania swoich zadań.

Zarządzenie długiem technicznym jest szczególnie istotne w metodach agile’owych

W metodach waterfal’owych dług techniczny pojawia się zwykle z powodu objawiających się w trakcie projektu ograniczeń czasowych i budżetowych. Jeśli się pojawią (a im większym projekt, tym większe prawdopodobieństwo ich wystąpienia), to w ich efekcie obcina się zakres: nie dostarczymy dokumentacji potrzebnej do utrzymania, nie zoptymalizujemy bazy danych, nie będzie szyfrowania, zahardkodujemy, zamiast zbudować coś konfigurowalnego, itd. Te wszystkie rzeczy, których nie dostarczymy, przekłada się później na „fazę drugą”, na którą z reguły jednak już nie ma budżetu, nie ma zasobów, nie ma planu, … Innymi słowy w metodach waterfall’owych dług techniczny tworzymy w wyniku problemów ale później przeważnie nim nie zarządzamy.

Inaczej to wygląda w metodach agilowych, w których tworzenie długu technicznego jest integralną częścią: kiedy tworzymy MVP (ang. „Minimum Viable Product”), to z definicji tworzymy również dług techniczny, bo rozwiązanie z definicji nie jest docelowe! (to jest tak, jakbyśmy w każdym sprincie robili coraz lepszy PoC :-). Dlatego zarządzenie długiem technicznym jest wtedy szczególnie istotne. W dobrze wdrożonych metodach agile’owych stworzony dług techniczny zapisuje się backlogu. Oznacza to, że zobowiązujemy się do jego usunięcia. W ten sposób dług techniczny jest jawnie zarządzany.

Metody radzenia sobie z długiem technicznym

Wg Gartnera istnieją trzy metody radzenia sobie z istnieniem długu technicznego w aplikacjach legacy:

1. Pierwsza wynika z faktu, że dług techniczny jest względny – zależy od istnienia wymagań niefunkcjonalnych. Więc pierwsza metoda, to zrezygnować z wymagania niefunkcjonalnego. Np. mamy aplikację która działa 8/5 i postawiono przed nią wymaganie dostępności 12/7 (dług się pojawił). Teraz - jeśli z tego wymagania zrezygnujemy i pozostaniemy przy dostępności 8/5 – dług znika. Jeśli jednak wymaganie niefunkcjonalne jest naprawdę ważne i nie możemy z niego zrezygnować, to mamy dwie następne opcje:
2. Zrefaktoruj aplikację, napraw problem – usuń dług. Jednak z wymaganiami niefunkcjonalnymi jest tak, że nie można w ich przypadku mówić o bug’u, więc poprawa kilku linii kodu nie pomoże. Realizacja wymagań niefunkcjonalnych przeważnie zależy od struktury, od projektu całego rozwiązania lub jego dużych elementów, zależy od jego architektury, od decyzji, co jest przetwarzane wsadowo a co jest przetwarzane real-time, co jest zakodowane a co jest konfigurowalne. Innymi słowy naprawienie problemu z wymaganiem niefunkcjonalnym wymaga przeprojektowania aplikacji lub rozwiązania. Co z kolei wymaga uruchomienia dedykowanego projektu i nie da się naprawić w trybie utrzymaniowym.
3. Wreszcie, jeśli zrefaktorowanie aplikacji jest nieopłacalne, to ostatnią opcją jest jej wymiana na taką bez długu, na którego usunięciu nam zależy (i co też przeważnie niestety wprowadzi inny rodzaj długu, o czym prędzej czy później się dowiemy :-)

Zakończenie

Po pierwsze: mam nadzieję, że udało mi się uporządkować pojęcia dot. długów w IT:

• Dług techniczny jest odchyleniem systemu od jego wszelkich wymagań niefunkcjonalnych i jest wynikiem decyzji projektowych lub zmiany tych wymagań.
• Dług wynikający z zaniechania czynności utrzymaniowych Gartner nazywa długiem IT. Jest on wynikiem konfliktujących decyzji o przeznaczeniu zasobów: na utrzymanie czy na rozwój.

Ww. długi są powodowane czymś innym i inaczej usuwane. Warto je więc odróżniać.

Po drugie: Biznes przeważnie nie chce rozmawiać od długu technicznym uważając ten temat za sprawę IT. Zmiana przedmiotu tej konwersacji z dialogu o „długu” (= sprawa IT) na dialog o „wymaganiach” (= sprawa Biznesu) może tę rozmowę uczynić skuteczniejszą. Zamiast mówić o pieniądzach na spłatę długu można mówić o pieniądzach na realizację zmieniających się wymagań niefunkcjonalnych. Np. "Changability" (składnik "Maintainability" wg ISO 25010) - to jest ważne, czy nieważne wymaganie Biznesu? Jeśli ważne, to wymaga sfinansowania. Jeśli nie ważne, to zapomnijmy o skracaniu Time To Market.

Wreszcie po trzecie: ww. klasyfikacja wymagań niefunkcjonalnych i wynikająca z niej klasyfikacja typów długu technicznego (np. dług niezawodności, dług utrzymywalności itd.) może pozwolić na priorytetyzowanie usuwania tego długu. Jest to o tyle istotne, że dług techniczny jest jak problem - jak zaczniesz szukać, to na pewno go znajdziesz, ale nie zawsze akurat ten najważniejszy. Stąd mechanizm priorytetyzacji może być przydatny.

Materiały źródłowe

• BMC Blog, Technical Debt Explained: The Complete Guide to Understanding and Dealing with Technical Debt, 2017, https://www.bmc.com/blogs/technical-debt-explained-the-complete-guide-to-understanding-and-dealing-with-technical-debt/, [dostęp 2019-01-29].
• Carnegie Mellon University, Software Engineering Institute Blog, A Field Study of Technical Debt, 2015, https://insights.sei.cmu.edu/sei_blog/2015/07/a-field-study-of-technical-debt.html, [dostęp 2019-01-29].
• Data Language, Reassessing Technical Debt, 2018, https://datalanguage.com/news/reassessing-technical-debt, [dostęp 2019-01-29].
• Gartner, A Primer on Technical Debt, ID: G00307777, Refreshed: 24 April 2018, Published: 5 October 2016.
• Gartner, Manage Technical Debt to Reduce Cost and Risk, and Improve Delivery Velocity, 2017, https://www.gartner.com/webinar/3564717/player?commId=241241&channelId=5500&srcId=null&webinarType=UpcomingEvent, [dostęp 2019-01-29].
• Gartner, Measure and Manage Your IT Debt, 2010, http://imagesrv.gartner.com/media-products/pdf/cast_software/gartner2.pdf, [dostęp 2019-01-29].
• IDC, Technical Debt: A Framework for Unfunded, Critical Technical Liabilities.
• MIT CISR Blog, Exposing Technology Debt, 2014,  https://cisr.mit.edu/blog/blogs/2014/12/09/technology-debt/, [dostęp 2019-01-29].
• MIT SMR, Technical Debt Might Be Hindering Your Digital Transformation, 2018, https://sloanreview.mit.edu/article/technical-debt-might-be-hindering-your-digital-transformation/, [dostęp 2019-01-29].
• Wikipedia, Technical Debt, https://en.wikipedia.org/wiki/Technical_debt, [dostęp 2019-01-29].

Czy architektura korporacyjna jest potrzebna?

Minął już ponad rok od mojego ostatniego postu tutaj. Długo już nic nie napisałem. Ale chciałbym się usprawiedliwić - to wszystko przez architekturę...

Mniej więcej w marcu 2015 roku wpadłem na pomysł, że napiszę artykuł pt. „O istocie architektury”. Zacząłem go więc pisać: pisałem, pisałem, pisałem, … i utknąłem. Po napisaniu kilkunastu stronu stwierdziłem, że do sedna sprawy nawet się nie przybliżyłem a dodatku wciąż pojawiały się nowe aspekty. Później próbowałem ten artykuł dokończy jeszcze kilka razy, ale z podobnym skutkiem. Także na zdefiniowanie sedna architektury korporacyjnej muszę jeszcze poczekać – okazuje się bowiem, że to nie jest takie proste.

Zamiast więc pisać o tym, co to jest architektura, postanowiłem ponownie odpowiedzieć na pytanie, czy architektura korporacyjna jest potrzebna.

Czy architektura korporacyjna jest potrzebna?

Na pytanie o potrzebę posiadania architektury korporacyjnej próbowałem odpowiedzieć po raz pierwszy w październiku 2013. Opisałem wtedy model Niemanna obrazujący zależność potrzeby posiadania architektury korporacyjnej od cech organizacji.

Źródło: K.D. Niemann, From Enterprise Architecture to IT Governance, Elements of Effective IT Management, Vieweg, Wiesbaden, 2006.

Z modelu Niemanna wynika, że architektura korporacyjna nie jest potrzebna w organizacjach o niskiej zmienności. Jej potrzeba pojawia się wtedy im organizacja jest bardziej złożona lub im bardziej zmienna.

Dzisiaj, będąc o 3 lata mądrzejszy, twierdzę jednak, że pytanie, czy architektura korporacyjna jest potrzebna, czy nie, jest źle postawionym pytaniem. A dokładniej: jest pytaniem nie wystarczająco precyzyjnym, bo – jak się okazuje – pod pojęciem „architektura korporacyjna” można rozumieć różne rzeczy.

Trzy ujęcia architektury korporacyjnej

W swojej książce pt. „Architektura korporacyjna - Aspekty teoretyczne i wybrane zastosowania praktyczne” Prof. Andrzej Sobczak zauważa, że termin „architektura korporacyjna” jest rozumiany wieloznacznie. Prof. Sobczak wyróżnia trzy znaczenia tego terminu:

1. Ujęcie czynnościowe: architektura korporacyjna, to dyscyplina, praktyka albo działalność w zakresie definiowania, reprezentacji i zarządzania kluczowymi właściwościami korporacji (zarządzanie).
2. Ujęcie rzeczowe: architektura korporacyjna, to formalny opis struktury i funkcji komponentów korporacji, wzajemnych powiązań między tymi komponentami oraz pryncypiów i wytycznych zarządzających ich tworzeniem i rozwojem (modele).
3. Ujęcie atrybutowe: architektura korporacyjna, to zbiór właściwości danej organizacji i relacji między nimi, które stanowią o zdolności do realizacji jej misji oraz celów strategicznych (logika „ułożenia” komponentów organizacji). Taka architektura istnieje zawsze. Nie jest opcjonalna.

Architektura korporacyjna jest zawsze

Architektura korporacyjna rozumiana jako logika „ułożenia” komponentów organizacji (ujęcie atrybutowe) zawsze jest. Gdziekolwiek spotyka się grupa ludzi, których łączy realizowanie jakiejś misji i osiąganie wspólnych celów (enterprise), tam pojawia się architektura. Do jej stworzenia nie jest potrzebny żaden architekt korporacyjny. Architektura pojawi się z i jak i bez jego pomocy.

Teraz, jeśli się z tym zgadzamy, to lepszym pytaniem będzie: czy chcemy nią zarządzać? Jakie będą korzyści z formalnego zarządzania architekturą korporacyjną zamiast postawienia spraw swojemu biegowi? Jak dobrze i efektywnie chcemy to robić (wymagana dojrzałość)?

To są już kompletnie inne pytania, które mogą pomóc:

• sponsorom zrozumieć i wyrazić cele, które chcą osiągnąć za pomocą zarządzania architekturą
• architektom zrozumieć wartość, którą wnoszą do przedsiębiorstwa, zaprojektować metamodel i dobrać odpowiednie narzędzia pracy.

Update: Po co więc zarządzać architekturą korporacyjną?

Wg Wikipedi, zarządzanie, to "sztuka bądź praktyka rozumnego stosowania środków dla osiągnięcia wyznaczonych celów". Zarządzamy projektami, aby zmniejszyć ryzyko nie zmieszczenia się w budżecie, zakresie i czasie przeznaczonymi na wytworzenie produktu końcowego. Z architekturą korproacyjną jest podobnie - zarzamy nią formalnie po to, aby zmniejszyć ryzyko nie zrealizowania celów. Jakich ceów? To już zasadniczo zależy od organizacji, choć w ogólności można powiedzieć, że: takich, których osiągnięcie wymaga spójności zaplanowania i "zgrania" realizacji zmian w zarządzanych domenach architektury (technologi i/lub aplikacji i/lub danych i/lub biznesowej) danego enterprise.

Bibliografia

• Roger Evernden, Do We Need Enterprise Architecture?, Good e-Learning, 2017.
• K.D. Niemann, From Enterprise Architecture to IT Governance, Elements of Effective IT Management, Vieweg, Wiesbaden, 2006.
• Gerben Wierda, Losing a Limpet – What happens when we don’t have Enterprise Architecture?, 2015.
• Andrzej Sobczak, Architektura korporacyjna - Aspekty teoretyczne i wybrane zastosowania praktyczne, Ośrodek Studów nad Cyfrowym Państwem, 2013.
• Wikipedia, Zarządzanie, https://pl.wikipedia.org/wiki/Zarządzanie, [2017-01-23].

O typach strategii i IT - prezentacja

Miałem nie dawno okazję uczestniczyć w warsztacie, na którym dyskutowano kierunek rozwoju środowiska systemów IT zbudowanego dla dużej jednostki biznesowej. W dyskusji i wyborze tego kierunku pomocna okazała się koncepcja typów strategii biznesowych, o której pisałem tutaj i tutaj.

Podczas warsztatu udało się zidentyfikować typ strategii omawianej jednostki. Dzięki temu określono, które elementy środowiska IT są dla jednostki najistotniejsze i jaki zasadami należy się kierować przy planowaniu ich rozwoju.

Na potrzeby ww. warsztatu przygotowałem krótką prezentację zawierającą opis ww. koncepcji. Zapraszam do lektury: http://www.slideshare.net/BogdanGluszkowski/jakie-it-dla-jakich-strategii-biznesowych.

Model operacyjny - zobaczyć i dotknąć

Koncepcja modelu operacyjnego, o której pisałem tutaj i tutaj (a swego czasu nawet opowiadałem), została opracowana przez badaczy z MIT CISR już 10 lat temu (w 2005 roku). Pomimo to widzę, że wciąż nie jest do końca zrozumiała.

Przygotowałem więc dodatkową prezentację zawierającą przykład transformacji modelu operacyjnego hipotetycznego Banku X, która pozwoli lepiej tę koncepcję zrozumieć. Zapraszam do lektury: http://www.slideshare.net/BogdanGluszkowski/modele-operacyjne-zobaczy-i-dotkn-07.

Jeszcze o Międzynarodowym Forum Badań MIT CISR w Warszawie

W poprzednim moim wpisie przedstawiłem relację z konferencji pt. Międzynarodowe Forum Badań MIT CISR w Warszawie (ang. MIT CISR International Research Forum) (http://bogdangluszkowski.blogspot.com/2015/03/miedzynarodowe-forum-badan-mit-cisr-w.html), która odbyła się dniach 11-12 marca 2015 roku i w której miałem przyjemność uczestniczyć dzięki zaproszeniu od Przewodniczącego MIT CISR, Petera Weilla.

Tym razem zapraszam do lektury wywiadu z Peterem Weillem, którego udzielił on dziennikarzom IT WIZ. W wywiadzie tym Peter Weill rozwija dokładniej koncepcję przedsiębiorstwa następnej generacji, którą przedstawił podczas ww. konferencji w prezentacji p.t. "The Next Generation Enterprise: Consumer Intimacy & Digital Ecosystems". Serdecznie zachęcam do lektury wywiadu: http://itwiz.pl/digital-disruption-od-lancucha-wartosci-ekosystemu-przedsiebiorstw/.

Międzynarodowe Forum Badań MIT CISR w Warszawie

W dniach 11-12 marca 2015 roku odbyło się Międzynarodowe Forum Badań MIT CISR  (ang.: MIT CISR International Research Forum). Gospodarzem wydarzenia była firma Orange Polska i miało ono miejsce w Warszawie, w głównej siedzibie firmy. Link do opisu wydarzenia: http://cisr.mit.edu/events/calendar/eur2015/.

MIT CISR (ang. MIT Center for Information Systems Research), to instytut w Szkole Zarządzania MIT (ang. MIT Sloan School of Management), którego misją jest rozwój koncepcji i framework'ów pomagających w adresowaniu wyzwań związanych z zarządzaniem dużymi organizacjami coraz bardziej polegającymi na IT. Prace instytutu są finansowane przez organizacje sponsorujące, z którymi MIT CISR dzieli się wynikami swoich badań m.in. poprzez artykuły i konferencje.

Na tegoroczne Międzynarodowe Forum Badań MIT CISR przyjechali głównie CIO z firm sponsorujących a jego hasłem przewodnim było osiąganie sukcesu w gospodarce cyfrowej. Z kolei ze strony MIT CISR prelegentami konferencji byli Jeanne Ross, Peter Weill oraz Nils Fonstad.

Dzięki zaproszeniu od Petera Weilla miałem niepowtarzalną okazję uczestniczyć w tym wydarzeniu i ogromną przyjemność osobiście porozmawiać z Jeanne Ross i Peterem Weillem, którzy są światowymi autorytetami i badaczami tematu architektury korporacyjnej. To właśnie oni są twórcami takich koncepcji, jak model operacyjny (http://bogdangluszkowski.blogspot.com/2012/10/model-operacyjny.html) czy poziomy dojrzałości architektonicznej (http://bogdangluszkowski.blogspot.com/2012/11/poziomy-dojrzaosci-architektury.html). Dlatego spotkanie z nimi było dla mnie ogromnym przeżyciem.

Spotkanie zostało otwarte przez Prezesa Orange Polska, Bruno Duthoit i miało formę prezentacji wygłaszanych przez prelegentów, przeplatanych:

• pytaniami ankietowymi do zebranych (wszyscy uczestnicy mieli urządzenia do głosowania)
• wystąpieniami gości z firm, których doświadczenia prezentowano jako przykłady
• warsztatami w mniejszych lub większych grupach mającymi na celu albo ustosunkowanie się do przedstawianych wyników badań lub wypracowanie rozwiązania na postawiony w prezentacji problem.

Jeanne Ross: Defining a Digital Strategy

Podczas prezentacji Defining a Digital Strategy, Jeanne Ross stwierdziła, że dostępne dzisiaj technologie SMACIT (social, mobile, analytics, cloud, internet of things) wszystkie razem a nie każda osobno, wpływają na przedsiębiorstwa. Firmy oczekują, że dzięki tym technologiom m.in. wzmocnią lub zbudują trwałą przewagę konkurencyjną. Jednak, żeby te efekty uzyskać, firmy - zamiast budować oddzielne strategie na każdą technologię, powinny nauczyć się budować i realizować zintegrowane, biznesowe strategie cyfrowe. Następnie przedsiębiorstwa powinny nauczyć się określać i budować dwa rodzaje zdolności (ang. capabilities):

• zdolności nastawione na efektywność (zestandaryzowane procesy i dane; rzadkie zmiany)
• zdolności nastawione na innowacje (szybkie i częste zmiany).

Jeanne Ross stwierdziła, że kluczową kompetencją przedsiębiorstw stanie się architektura biznesowa, czyli służące konkretnemu celowi (ang. purposful) projektowanie / przeprojektowywanie procesów, struktur, ról i systemów IT tak, aby wytworzyć spójność pomiędzy misją biznesową lub celami firmy i jej zdolnościami biznesowymi (ang. business capabilities). Jednak niespójności na pewno będą się pojawiać, dlatego firmy będą potrzebować nowych metod zarządzania aby sobie z nimi radzić: innych struktur, nowych rodzajów nadzoru i nowych sposobów współpracy wewnątrz firmy.
Na koniec Jeanne Ross przypomniała model poziomów dojrzałości architektonicznej przedsiębiorstw (patrz http://bogdangluszkowski.blogspot.com/2012/11/poziomy-dojrzaosci-architektury.html) i stwierdziła, że o ile w erze przed-cyfrowej, przedsiębiorstwa mogły pokonywać kolejne poziomy dojrzałości architektonicznej w swoim własnym tempie, to era gospodarki cyfrowej powoduje pilną potrzebę dojścia na poziom czwarty. Bo dopiero na poziomie modularności biznesu firma, jako całość, uzyskuje wymaganą zwinność.

Przemyślenia:

1. w erze cyfrowej zwinność firm, jako całości, stanie się źródłem ich przewagi konkurencyjnej
2. stopień zwinności firmy jako całości determinowany jest poziomem dojrzałości architektonicznej przedsiębiorstwa, więc:

• inwestowanie w architekturę firmy jest inwestowaniem w zwinność firmy
• zarządzanie architekturą korporacyjną jest metodą / sposobem budowy tej zwinności.

Peter Weill: Mobile First? Effectively Engaging Customers with Mobile Apps

W prezentacji Mobile First? Effectively Engaging Customers with Mobile Apps Peter Weill przytoczył badania, z których wynika, że średni amerykański konsument większość swojego czasu korzystania z telefonu komórkowego spędza w aplikacjach. Wniosek – firmy będą musiały te aplikacje budować. Peter Weill przytoczył cztery strategie budowania tych aplikacji (ang. Mobile first,  Brand enhancement, Omni-channel, Targeted segment) oraz przedstawił filary sukcesu ich budowania, jednym z których jest istnienie oraz zasady korzystania z platformy reużywalnych procesów, danych i technologii. Platformy projektowanej i rozwijanej centralnie.

Przemyślenia:

1. tutaj podobnie, jak w poprzedniej prezentacji pojawia się temat celowej budowy i utrzymania platformy reżywalnych procesów, danych i technologii, której istnienie jest jednym z filarów szybkiego budowania aplikacji mobilnych dla klientów
2. czyli jeszcze raz odczytuję tutaj tezę, że najważniejszym celem / wartością wnoszoną przez zarządzanie architekturą korporacyjną jest zwiększenie zwinności firmy jako całości.

Nils Fonstad: Meeting the Growing Demand of Digital Leaders

W prezentacji Meeting the Growing Demand of Digital Leaders, Nils Fonstad poruszył kwestię cyfrowego przywództwa w przedsiębiorstwie. Stwierdził, że cyfrowy przywódca jednocześnie realizuje dwa cele: budowa lokalnych rozwiązań oraz synergie ogólnofirmowe.

Przemyślenia:

• ww. osiąganie synergii ogólnofirmowych jest niczym innym, jak budową ww. platformy reużywalnych procesów, danych i technologii – reużywanych przez lokalne rozwiązania
• czyli najlepszym wsparciem dla cyfrowych liderów przy projektowaniu, budowaniu i utrzymaniu potencjału ww. platformy będą architekci korporacyjni.

Peter Weill: The Next Generation Enterprise: Consumer Intimacy & Digital Ecosystems

W prezentacji The Next Generation Enterprise: Consumer Intimacy & Digital Ecosystems Peter Weill przedstawił metodę oceny wpływu digitalizacji na firmę. Następnie przedstawił wyniki badań MIT CISR na próbce 105 firm, w śród których ponad połowa oceniła ten wpływ jako bardzo wysoki, nazwany przez badaczy z MIT CISR "czerwoną strefą" (ang. red zone).
W reakcji na to zagrożenie / okazję rynkową firmy ewoluują od bycia dostawcami sprzedającymi przez agentów i nie znających swoich klientów (przykład: P&G) do bycia otwartymi platformami zapewniającymi doskonałe doświadczenia, doskonale znanego im klienta, z łatwym włączaniem produktów firm trzecich, platformami dopasowującymi znane potrzeby klienta ze znanymi i odpowiednimi dostawcami (przykłady: Amazon, Aetna).
Z badań MIT CISR wynika, że model platformowy jest najbardziej opłacalny (największy wzrost przychodów, największa rentowność netto). Jednak model ten stawia przedsiębiorstwom największe wymagania na zwinność. Dlatego tak trudno go zbudować - wg badań częściej udaje się małym firmom, dużym rzadziej.

Przemyślenia:

1. model platformowy kojarzy mi się z konfiguracją sieci wartości, którą opisywałem tutaj: http://bogdangluszkowski.blogspot.com/2013/10/konfiguracja-wartosci-czyli-co-telekomy.html
2. zarządzanie architekturą korporacyjną będzie najważniejszą umiejętnością przyszłych przedsiębiorstw, decydującą o uzyskaniu i utrzymaniu ich przewagi konkurencyjnej, gdyż:

• model platformowy jest najskuteczniejszą odpowiedzią firm na cyfrową gospodarkę
• stawia on jednak przedsiębiorstwom największe wymagania na zwinność (zbudowanie i utrzymanie)
• więc wysoki poziom zwinności staje się elementem przewagi konkurencyjnej
• więc zarządzanie architekturą korporacyjną, jako metoda budowy i utrzymania tej zwinności, będzie narzędziem uzyskiwania tej przewagi.

Jeanne Ross: Beyond Governance: How Top Performers Shape IT Demand

W prezentacji Beyond Governance: How Top Performers Shape IT Demand Jeanne Ross postawiła tezę, że jakość portfela inwestycji IT wpływa na wydajność finansową przedsiębiorstwa oraz wymieniła cztery cechy portfela dobrej jakości: 1) zawiera tylko przedsięwzięcia absolutelly must do, 2) tylko z absorbowalną zmianą biznesową, 3) buduje reużywalne zdolności IT lub biznesowe (ang. capabilities) 4) inteligentnie ułożone w czasie. Następnie stwierdziła, że jakość portfela inwestycji w IT zależy od jakości „konwersacji” na temat IT wewnątrz firmy, którą wspierają trzy rzeczy: 1) zrozumienie IT przez kierownictwo firmy, 2) ład IT zawierający decyzje o tym, które procesy i dane będą standaryzowane oraz 3) praktyki kształtowania popytu. Z tych ostatnich najskuteczniejsze, to: transparentność kosztów, roadmapowanie, zarządzanie relacjami biznes-IT, metodyki zwinne, poimplementacyjne oceny wartości oraz zarządzanie programami strategicznymi. Te ostatnie, aby poprawiało jakość konwersacji na temat IT, powinno polegać na:

• zidentyfikowaniu skończonej liczby celów strategicznych
• przypisaniu lidera programu zarządzającego wszystkimi projektami związanymi z danym celem
• przypisaniu do liderów odpowiedzialności zdefiniowania krytycznych zdolności koniecznych do realizacji danego celu
• uprawnieniu liderów programów do przesuwania funduszy pomiędzy projektami w celu uwzględnienia zmieniającej się rzeczywistości

Zwróciłem uwagę na następującą rzecz: w zarządzaniu programami strategicznymi, które wspiera konwersację na temat IT, wymagania na (reużywalne) zdolności, czyli wymagania na sposób realizacji strategicznego celu biznesowego, nie są definiowane w poszczególnych projektach - są definiowane przed nimi, w ramach / na rzecz realizacji danego strategicznego celu biznesowego. To wyniesienie decyzji co do sposobu realizacji celu strategicznego z projektów "przed nawias" jest dokładnie tym, czym jest zarządzanie architekturą korporacyjną i jest to dokładnie odwrotnie, niż powszechna praktyka kaskadowania celów do projektów, które same decydują o sposobie ich realizacji.

Nils Fonstad: Building Business Agility: From Silos to Synergies

W prezentacji Building Business Agility: From Silos to Synergies, Nils Fonstad definiuje dojrzałość ww. platformy reużywalnych procesów, danych i technologii jako stopień ich standaryzacji i współdzielenia. Definiuje również pojęcie konkurencyjnej zwinności, jako zdolności firmy do przewidywania zmian rynkowych i szybkiego rozwoju nowych produktów i usług zarówno dla obecnych, jak i nowych klientów, zdolności lepszej, niż średnia rynkowa. Na koniec przytacza wyniki badań, z których wynika, że:

• niska dojrzałość ww. platformy powoduje niską zwinność danej firmy i to praktycznie niezależnie od tego czy i ile dana firma inwestuje w usługi chmurowe; czyli inwestowanie w usługi chmurowe w celu podniesienia zwinności firmy jest w takim przypadku stratą pieniędzy
• wysoka dojrzałość ww. platformy powoduje natomiast wysoką zwinność danej firmy; dodatkowe inwestowanie w usługi chmurowe tę zwinność jeszcze zwiększa.

Przemyślenia:

• skoro zarządzanie architekturą korporacyjną jest metodą budowy i utrzymania konkurencyjnej zwinności, to będzie ono najważniejszą umiejętnością przyszłych przedsiębiorstw decydującą o uzyskaniu i utrzymaniu przewagi konkurencyjnej
• z rozmów z Jeanne Ross: metody zwinne można i należy stosować w projektach lokalnych, do realizacji szybkich zmian; ale same platformy umożliwiające szybie dokonywanie tych zmian należy budować w sposób tradycyjny, waterfall’owo
• z rozmów z uczestnikami: architektura korporacyjna zajmuje się tym, co niezmienne / wolno zmienne – w ramach zarządzania architekturą korporacyjną powinniśmy zajmować się budową ww. platformy w taki sposób, aby projekty zwinne wiedziały jak i czego muszą reużyć i to powinno być jedyne ograniczenie tych projektów ze strony architektury korporacyjnej; innymi słowy architektura korporacyjna ma swój koniec i jest nim zakres ww. platformy.

Zakończenie

Badacze z MIT CISR, to światowi orędownicy architektury korporacyjnej. Jednak zauważyłem, że podczas swoich wystąpień terminu "architektura korporacyjna" używali dość rzadko. Zamiast tego często używali takich sformułowań jak inwestowanie w zdolności (ang. capabilities), platforma reużywalnych procesów i danych, synergie ogólnofirmowe, podejmowanie decyzji, itp. Jeanne Ross wyjaśniła mi w przerwie, że powodem jest wciąż niska akceptacja tego terminu, który po prostu do słuchaczy nie trafia.

Pokazywane materiały były przeplatane wystąpieniami CIO z firm, których przykładami się posługiwano. W ich wystąpieniach można było zaobserwować elementy stosowania podejścia architektonicznego: dedykowane zespoły opracowujące architekturę poza (przed) projektami, podejmowanie decyzji o architekturze korporacyjnej poza (przed) projektami, ustanawianie pryncypiów architektonicznych sterujących decyzjami projektowymi, ścisłe powiązanie z celami strategicznymi, nastawienie na budowanie komponentów reużywalnych, itp. Jednak uczciwie muszę przyznać, że terminu "architektura korporacyjna" nie użył żaden występujących CIO.

Pomimo to prezentacje badaczy z MIT CISR pokazywane na konferencji utwierdzają mnie w moim obecnym rozumieniu wartości, celów i roli zarządzania architekturą korporacyjną w przedsiębiorstwie ery cyfrowej:

• zwinność firmy, to zdolność (ang. ability) do szybkiej realizacji pewnej wiązki zmian, z wykorzystaniem posiadanych zdolności / kompetencji i z zarządzalnym ryzykiem i kosztem
• firmy uzyskują zwinność poprzez zarządzanie architekturą platformy reużywalnych, wolnozmiennych, zestandaryzowanych procesów, danych i technologii oraz określenie zasad i sposobów ich reużycia przez projekty innowacyjne / lokalne
• era cyfryzacji jak nigdy dotąd wymaga od przedsiębiorstw zwinności
• więc zarządzanie architekturą korporacyjną będzie kluczową umiejętnością budowania trwałej przewagi konkurencyjnej przyszłych przedsiębiorstw
• istotą zarządzania architekturą korporacyjną jest:
  - powtarzalne i metodyczne (a więc obarczone mniejszym ryzykiem)
  - kierujące się interesem przedsiębiorstwa jako całości a nie celami pojedynczego projektu (chodzi tutaj o interes długoterminowy, rozumiany jako przygotowanie się firmy na przyszłe zmiany typu wzrost i optymalizacja, np. nowa aplikacja mobilna, nowa oferta konwergentna, podłączenie nowego partnera, usprawnienie procesu biznesowego, itp.)
  - czyli osadzone w planowaniu strategicznym
  - podejmowanie poza (przed) projektami decyzji o sposobie realizacji celów strategicznych
  - sposobie wyrażonym w postaci wymaganej struktury i wymaganych relacji
  - komponentów platformy reużywalnych, zestandaryzowanych procesów, danych i technologii,
  - która zawiera istotę sposobu działalności przedsiębiorstwa oraz ułatwia realizowanie założonej wiązki zmian.
  Tylko tyle. I aż tyle.