O roli architektury w dużych wdrożeniach

Sztuka polowania a architektura

Polowanie jest zakodowane w naszym DNA. Nasi przodkowie wyprawiali się na łowy w zorganizowanych grupach. Towarzyszył temu rozbudowany proces i struktura organizacyjna.

Zwiadowcy obdarzeni najlepszym wzrokiem wypatrywali stada lub odnajdywali je na podstawie śladów. Zanim nastąpił atak, trzeba było wszystko zaplanować. Rozpoznać liczność stada, najsilniejsze i najsłabsze osobniki. Ocenić, w którym kierunku będzie ono uciekać i gdzie można je złapać w potrzask. Współpraca i dobre planowanie sprawiało, że całe plemię było najedzone.

Pozostańmy w tych realiach, nakładając jednak na nie współczesny sposób zarządzania, który jest widoczny w wielu projektach – zarządzanych kaskadowo i zwinnie.

Przywódca myśliwych wychodzi z szałasu wodza i mówi, że zespół dostał cel zapełnienia połowy spichlerzy w przeciągu dwóch dni. Myśliwi rozbiegają się w różnych kierunkach szukając jakiegoś pobliskiego stada. Po godzinie jeden z myśliwych daje znak – jest stado.

Chwilę później cała grupa z włóczniami w rękach i okrzykiem „hurraaaa!” na ustach pędzi na polowanie. Polowanie, którego wynikiem mogą być nie tylko „owocowe czwartki”, ale owocowe miesiące dla całego plemienia – do czasu aż myśliwi wyleczą swoje rany.

Na tym etapie większość z was zastanawia się pewnie, co wspólnego ma (bardzo zresztą uproszczony) schemat polowań ze współczesnymi projektami informatycznymi. Niektórzy z was myślą też zapewne, że to porównanie jest zbyt brutalne.

Zastanówmy się jednak przez chwilę. Jeśli pomyślimy o dużej firmie (a o takich tu mowa), posiada ona w swoim portfolio między 1000 a 4000 aplikacji. Nie istnieje fizyczna możliwość, żeby jeden architekt, a nawet ich grupa, była w stanie na bieżąco śledzić ich stan bez wsparcia narzędziowego. Tak samo jak dawni myśliwi nie byli w stanie śledzić ruchów i liczebności stad bez dostępu do dronów czy zwiadu lotniczego.

Rozpoznanie przed polowaniem zatem to nic innego, jak wstępna faza analizy architektonicznej. Faza, która powinna poprzedzać etap konstrukcji. Dlaczego? Ponieważ łatwiej się koryguje błędy popełnione w prezentacji w PowerPoint niż zakodowane przez 20-osobowy zespół programistów.

Powiecie, „my jesteśmy Agile, nie robimy dokumentacji tylko User Stories”. O tym będzie traktował odrębny artykuł, na razie przyjmijmy za pewnik, że metodyki zwinne nie sprawiają, że nie popełniamy błędów architektonicznych. Pozwalają je tylko szybciej naprawić.

Co to są „duże wdrożenia”?

Klasyfikator, który tu zastosowałem, może nie jest jednoznaczny, jednakże jest istotny. Inaczej można podejść do projektu wdrożenia narzędzia Marketing Automation w firmie posiadającej 20 systemów. Inaczej podchodzi się do wymiary ERP w międzynarodowej korporacji z tysiącami systemów.

To do tej drugiej kategorii odnosi się niniejszy artykuł.

Projekty tego typu mają swoją charakterystykę. Przede wszystkim najczęściej związane są z dużym dostawcą technologii i dużym partnerem wdrożeniowym. Efektem takiej konfiguracji jest duża koncentracja na wdrażanym rozwiązaniu.

Na pierwszy rzut oka to rozwiązanie wydaje się bardzo sensowne. W końcu naszym celem jest wymiana systemu ERP, centralnego systemu bankowego, CRM… angażujemy więc ludzi, którzy się na tym znają.

Trzeba jednak pamiętać, że takie systemy nigdy nie działają w próżni. Niezależnie od tego, co obiecują materiały marketingowe wiodących producentów systemów, nie są to rozwiązania „do wszystkiego”. Z jednej strony mamy więc inne duże rozwiązania, z drugiej – nieuniknione ławice małych aplikacyjek, które z czasem „obrastają” każdy duży system.

To są aplikacje, których nie można ot tak się pozbyć. Za każdą z nich stoją użytkownicy, którzy walczyć będą o nią jak o niepodległość. Te aplikacje, które pozostaną, muszą zostać odpowiednio zintegrowane.

Interfejsy integracyjne również nie piszą się same, więc potrzebujemy zaangażować odpowiednich dostawców, a oni z kolei najczęściej będą chcieli od nas sowitego zadośćuczynienia za pracę nad aplikacją, którą ostatni raz dotykali 15 lat temu.

Wyobraźmy sobie, co się stanie, jeśli inicjalny plan projektu tych wszystkich czynności nie przewidywał. Ja widziałem takich projektów już kilka, więc wyobrażać sobie nie muszę, mogę tylko powiedzieć, że nie ma takich memów w mediach społecznościowych, które potrafiłyby oddać atmosferę w takim projekcie.

Czy architekci są wszystkiemu winni?

Architekci, zgodnie z opisem swojej roli, powinni stać na straży aplikacyjnego porządku. Czy są więc winni?

Po części. Wielokrotnie podnosiliśmy zeszłoroczny Tech Trend, który mówił o przebudzeniu architektury. Architekci, którzy do tej pory zajmowali się głównie wydawaniem „dyrektyw”, mieli dołączyć do projektów i służyć zespołom radami.

I część dołącza. Powstają rady architektury, decyzje architektoniczne wypracowywane są razem z biznesem i uwzględniają potrzeby funkcjonalne. Bywa, że przed rozpoczęciem prac programistycznych powstaje faktyczna architektura rozwiązania.

Życie tych architektów jest trudne, a praca niewdzięczna… dlaczego?

Współczesne „hurraa!” z włócznią

Żeby zrozumieć ciężki żywot architekta, trzeba zwrócić uwagę na narzędzia, jakie dostaje on do dyspozycji.

Pamiętajmy, że mówimy o dużych wdrożeniach w międzynarodowych korporacjach. Przyjmijmy, że firma taka ma 2000 aplikacji, a każda powiązana jest z 20 innymi. Nie wchodzimy tu w ogóle na poziom interfejsów integracyjnych, ponieważ to temat wymagający odrębnego podejścia i narzędzi.

Opisane wyżej portfolio daje nam około 40000 powiązań, które należy przeanalizować w ramach takiego projektu. Dużo. A narzędziem, który nam pomaga w takiej analizie jest… MS Excel. Listy SharePoint jeśli mamy szczęście.

Przypomina to sytuację, w której rolnikowi do zaorania 40 ha pola pozostaje do dyspozycji ręczy pług i jednen koń. Niby się da, ale „dedlajny” na pewno nie zostaną dotrzymane.

A przecież to jeszcze nie koniec. Architekci są tylko jednym z zespołów, który pracuje na danych o aplikacjach. Mamy zespoły integracyjne, lokalne IT, równoległe projekty… W efekcie każdy tworzy swojego własnego „excela” i jakimś sposobem próbuje się zintegrować z innymi.

W rezultacie każdy ma trochę inne pojęcie o tym, jaka jest rola poszczególnych aplikacji i powiązań między nimi. I po tysiącleciach doświadczeń bierzemy nasze włócznie i z okrzykiem „hurraa!” na ustach biegniemy polować na najsłabsze aplikacje.

„Ja walczę umysłem”

Ten cytat pojawił się w pewnym serialu komediowym o ekscentrycznym naukowcu. Jako informatycy lubimy myśleć, że pracujemy naszymi umysłami, a narzędzia są dla nas dodatkiem. Stolarz mógłby powiedzieć, że wykonuje pracę fizyczną, więc jego narzędziami są mięśnie.

Stolarz po kilku minutach prób wydłubania otworu w belce paznokciem na pewno chwyci za wiertarkę (a nie za szpadel). Dlaczego architekci nie chcą chwycić za odpowiednie narzędzie?

W najlepszym wypadku wybieramy najtańsze narzędzie (z powodu ograniczeń budżetowych) i próbujemy w nim walczyć z materią. Efektem naszych starań są projekty, które tylko my potrafimy przeczytać i zrozumieć, co tylko pogłębia opinię, że są to „zabawki architektów”.

A czy tak trudno byłoby policzyć, ile pieniędzy kosztuje firmę praca z „darmowym Excelem”? Jeśli dobrze podsumować czas spędzony na integracji i poprawianiu rejestrów, może się okazać, że jest to koszt wyższy od narzędzia z górnej półki. A przecież nie robimy tego tylko dla siebie. Nasze pomyłki kosztują projekt realne pieniądze, które również należy tu wkalkulować.

Dlatego warto zainwestować w dobre narzędzie i poprawne jego wdrożenie.

Co architekt ma w swojej skrzynce narzędziowej?

Jak już sobie powiedzieliśmy, najpopularniejszym narzędziem jest arkusz kalkulacyjny. Ma on dwie poważne zalety i cały szereg wad. Po pierwsze z reguły jest dostępny w firmie za darmo. Po drugie jest na tyle elastyczny, że zaabsorbuje każdą fanaberię.

Jednakże… tak jak obrazek to nie model architektoniczny, tak lista aplikacji to jeszcze nie repozytorium. Pomijając ograniczoną możliwości współpracy wielu osób, niemożność audytowania i wersjonowania, niewiele jest modeli architektonicznych, które da się zamknąć w ramy dwuwymiarowej macierzy.

Idźmy więc dalej. W Europie centralnej prym wiedzie pewne narzędzie, które swoje pierwsze kroki stawiało jako oprogramowanie CASE (Computer Aided Software Engineering). Jego niebywałą zaletą (poza niską ceną tego konkretnego rozwiązania) jest to, że w jednym modelu można zamknąć praktycznie wszystkie aspekty związane z aplikacją. Od architektury korporacyjnej poza CMDB – choć to ostatnie wymaga bardzo dokładnego zaprojektowania???.

Na poziomie raczej ogólnej architektury, o której tu mówimy, narzędzia te są często zbyt skomplikowane. Również czytelność dla nie-architektów pozostawia wiele do życzenia. Obiektywnie lub subiektywnie.

Na zawsze zapadła mi w pamięć sytuacja, gdy pokazywałem klientowi diagram Archimate, pokazujący komponenty aplikacyjne, usługi i powiązania między nimi. Prezentował on bardzo ograniczony zakres architektury, ponieważ tego typu diagramy potrafią być bardzo skomplikowane.

Co usłyszałem na warsztacie? „Oj ja to nie jestem informatykiem, ja nie rozumiem takich specjalistycznych modeli”. Przyjąłem komentarz i na następny warsztat wróciłem… z tym samym diagramem… tylko zamiast wygenerowanych przez narzędzie kształtów Archimate na slajdzie były prostokąty. Nic poza tym nie zmieniłem. Merytoryczna dyskusja trwała ponad 2 godziny.

Ten przykład pokazuje jak istotne jest dobranie look & feel narzędzia do odbiorcy. Kiedy byłem początkującym analitykiem, z pogardą wyrażaliśmy się o wymaganiach biznesu dotyczących „kolorków” na ekranach. Przecież najważniejsze było dobrze sformułowane zapytanie SQL. Więc teraz już wiem, że „kolorki” również są ważne. Potrafią na przykład oszczędzić dwugodzinnego „spalonego” warsztatu.

Ale jest jeszcze jedna klasa narzędzi architektonicznych, która moim zdaniem dość dobrze nadaje się do zadania, o którym tu mówimy. Obejmuje ona rozwiązania z pogranicza prowadzenia rejestru i raportowania.

Narzędzia tego typu często nie potrafią przechowywać informacji o strukturze interfejsu integracyjnego, definicji WSDL czy nawet strukturze encji modelu danych.

Ale potrafią skutecznie przechowywać to, co jest istotne dla architekta korporacyjnego w dużej korporacji: listę aplikacji wraz z ich atrybutami (np. właścicielem biznesowym, strategią architektoniczną, oznaczeniem cyklu życia), powiązania między nimi oraz przetwarzane dane.

I tyle najczęściej wystarczy. Projektem interfejsów zajmą się architekci rozwiązania, a ich kolegom na poziomie korporacyjnym wystarczy informacja, że dwie aplikacje są ze sobą powiązane. Bo to oznacza, że trzeba je ująć w zakresie projektu.

Skoro jest tak dobrze, to czemu jest tak źle?

Skoro istnieje tyle opcji, to czemu dalej męczymy się z „Excelami”? Po części dlatego, że jak już zorientujemy się, że nie mamy w ręku włóczni, jesteśmy w połowie stoku, szarżując na bizona gołymi rękami.

Po części dlatego, że przygotowanie dobrze działającego repozytorium to zadanie wcale niełatwe. Wymaga de facto przeglądu całości organizacji, co może zająć parę miesięcy i wymagać odrywania właścicieli aplikacji od ich obowiązków. Nic przyjemnego.

Ale czy w projektach transformacyjnych nie to właśnie robimy? Czemu nie wykorzystać wyników zadań, które i tak wykonujemy, do utworzenia porządnego repozytorium? Repozytorium w arkuszu kalkulacyjnym jest odpowiednikiem papierowej rurki do napoju z fast food’u. Może wystarczy na wypicie jednego napoju, ale na pewno w drugim już się rozpuści.

Pozostaje oczywiście odwieczny argument finansowy. Tego typu rozwiązania muszą kosztować. Ale, jak to wspominałem wcześniej, na pewno nie kosztują więcej niż pięciu architektów korporacyjnych poświęcających 2 miesiące życia na tworzenie dokumentacji. Dla każdego projektu osobno.

W dzisiejszych czasach firmy żyją zmianami. Nowe kanały, nowi klienci, nowe produkty, to wszystko wymaga ciągłego dostosowywania narzędzi IT. Nasz zespół postawił sobie jeden cel – sprawić, żeby nasi klienci nie tylko przeszli przez te zmiany niepoturbowani, ale by jak najlepiej wykorzystywali technologie do realizacji swoich celów biznesowych.

Pomagamy liderom IT oraz ich zespołom w procesie przemian technologicznych:

• Opracowujemy nowe modele operacyjne, procesy i struktury.
• Wspieramy w uruchamianiu praktyk architektonicznych i planujemy wspólnie z nimi mapy drogowe rozwoju systemów.
• Prowadzimy również organizacje poprzez zwinne transformacje, wspierając w uruchomieniu wcześniej wypracowanych koncepcji strategicznych.

Zapraszamy do kontaktu.