Architektura mikrousługowa a analiza systemowa

mikrousługi.jpgAby jakoś zrównoważyć narzekania na korporacyjnego edżajla, drugi dzisiejszy wpis będzie bardziej inżynierski. Ostatnimi czasy mam okazję pracować nad systemami o architekturze mikrousługowej. Oczywiście jako analityk. I z tego analitycznego punktu widzenia, można powiedzieć, że architektura, jak architektura, za jednym wyjątkiem. Wydaje się bowiem, iż w przypadku tej konkretnej architektury, mniejszego znaczenia nabiera klasyk analizy, czyli analityczny model danych, rozumiany jako jednolita struktura opisująca dane, jakimi należy się posługiwać, aby można było zrealizować deklarowane funkcjonalności systemu.

Dlaczego? O tym będzie poniższy wpis.

Usługa

Mikrousługa, z analitycznego punktu widzenia, to usługa jak każda inna. Powinna mieć opisane zachowanie (jak realizuje kontrakt) oraz strukturę danych wejściowych (żądanie) i wyjściowych (odpowiedź). Koncepcyjnie (realizacja może wyglądać różnie w zależności od narzędzia do modelowania, metodyki i wynikających z niej standardów poziomu szczegółowości opisu), model usługi powinien zawierać powiązane ze sobą elementy przedstawione na rysunku poniżej.

Struktura opisu mikrousługi

Struktura opisu mikrousługi

Klient usługi

Załóżmy dla uproszczenia, że analityczną warstwą kliencką usługi będzie klasyczny przypadek użycia. Przebieg realizacji przypadku użycia, będzie zapewne opisany diagramem aktywności lub sekwencji (specyfika stosowanej metodyki). Bez względu na rodzaj diagramu, w momentach, w których zaistnieje zapotrzebowanie na dane, wymagane będzie odwołanie do usługi. Przykład takiej sytuacji prezentuje poniższy rysunek.

Wywołanie mikrousługi z przebiegu przypadku użycia

Wywołanie mikrousługi z przebiegu przypadku użycia

Moment wywołania usługi jest reprezentowany stosowną akcją, która w rożnych narzędziach do modelowania będzie troszkę inaczej wyglądała. Teoretycznie, na pinie wejściowym powinny się znaleźć dane zgodne co do typu z typem REQUEST z modelu opisu usługi. Pin wyjściowy jest zgodny, co do typu, z RESPONSE z modelu opisu usługi. Problem z pinem wejściowym zgodnym z teorią byłby taki, że należałoby albo dodać osobną akcję, która tworzy strukturę żądania na bazie dostępnych danych, albo transformację na przepływie danych, która dokonałaby przekształceń. W naszym podejściu stosujemy delikatne obejście – aby nie komplikować przejść i nie rozbudowywać diagramu o dodatkowe akcje, przypisanie danych pod cechy żądania opisujemy jako pre-condition w akcji wywołania usługi. W języku OCL przyjmuje to następującą postać.

pre:

let req: REQUEST.oclInNew() and
req.cecha1 = daneWejścioweAkcji.cechaA and 
...

Wynik wywołania usługi jest dostępny w pinie wyjściowym akcji. Tak pozyskane dane mogą być wykorzystywane w ramach przypadku użycia. Dostęp do nowych danych wymaga analogicznego wywołania kolejnej usługi.

Specyficzną cechą tego podejścia jest fakt, iż jeśli nawet w różnych usługach zwracamy logicznie te same dane, to faktycznie są one tylko takie same, gdyż znajdują się w różnych obiektach, czy strukturach danych. Specyfika ta powoduje, iż jeden logiczny model danych dla tego typu aplikacji aplikacji byłby tworem czysto abstrakcyjnym, którego zakresem zastosowań byłby jedynie model. Co więcej, odwoływanie się do niego w ramach przebiegów przypadków użycia byłoby okupione dużym wysiłkiem wynikającym z konieczności wiązania danych z mikrousług z jednolitym modelem danych.

Tego typu sytuacja nie ma zwykle miejsca w tradycyjnych, nazwijmy to, architekturach, w których aplikacja składa się z własnego frontendu i własnych danych. W takim kontekście, model danych służy zwykle jako punkt wyjścia dla konstrukcji modelu trwałego (najczęściej relacyjnej bazy danych), czy też, po konwersji do formatu XMI, jako wsad do tworzenia plików mapujących narzędzi OR-mapping. Z modelu logicznego można także generować skryptami MDA fragmenty docelowego kodu źródłowego, w szczególności deklaracje klas, konstruktory, destruktory oraz operacje trawersujące asocjacje.

Nie mając tego typu korzyści, wydaje się, że nie warto inwestować pracy w czysto abstrakcyjną warstwę opisu. Coś oczywiście tracimy, ale zyskujemy bezcenny czas.

 

 

Ilustracja: https://pl.freepik.com/darmowe-zdjecie/abstrakcyjne-geometrycznej-tła-z-futurystyczne-projektu_1104905.htm Designed by Kjpargeter

Reklamy

Edżajl 2018 (level Corpo, level hard)

agile2018mediumDługo nosiłem się z zamiarem powrotu do pisania. W końcu to nastąpiło, ale po raz kolejny sprawdziła się zasada, że rzecz raz odłożona dalej odkłada się już sama. Ostatecznie, zaniosłem się i idąc za ciosem postanowiłem kontynuować wątek zwinności. Dlaczego? Bo chyba nie da się go nie kontynuować, obserwując wszechobecne uzwinnianie się zespołów, metod pracy i całych organizacji. I ten ostatni poziom wydaje się być groźny. I o tym, w skali korporacyjnej, poniżej.

Co to jest ten Edżajl?

No właśnie. Na początku mojej przygody z tym trendem, było to nic innego jak sposób organizacji pracy w zespole projektowym. Kilka prostych zasad, proste narzędzie (stosowaliśmy ScrumDesk) i można było się w to pobawić. Fundamentalnych usprawnień nie odnotowaliśmy, ale miałem wrażenie, że w jakimś stopniu wzrosło poczucie świadomości stanu prac w zespole. Od strony inżynierskiej Scrum nie wpłynął na stosowane metody pracy. Tak było wiele lat temu.

Tymczasem mamy rok 2018. Mamy Edżajl. I tego Edżajla już nie rozumiem. Co oznacza, że nie rozumiem większości otaczającego mnie świata zawodowego.

Poziom IT

Co o nim wiem. Wiem, że Edżajl to klimat pracy. Ma być korzystny. O klimat troszczą się Edżajlkołczowie. Piękni dwudziestoletni, którzy są w stanie powiedzieć jakie metody pracy stosować, a jakie nie, bo się nie sprawdzają. Sprawdzają się metody proste albo nowe. Nie sprawdzają się metody kojarzone z Łoterfolem – siedliskiem zła, który kreatywnych ludzi wciskał w tryby biurokratycznej machiny i pozbawiał wpływu na cokolwiek.

Skąd to wiedzą? Wiedzą stąd, że spotykają się w swoim gronie pięknych dwudziestoletnich i dyskutują. Na tych spotkaniach panuje dobry klimat, skutkujący szczerą, otwartą rozmową, z której to powstają nowe pomysły. W sposób otwarty Edżajlkołczowie komunikują swoje przemyślenia zespołom edżajlowym. Ponieważ pracujemy w duchu akceptowania zmian i poprawek, nie przejmujemy się tym, że nowe pomysły często przeczą starym pomysłom. Refaktor idei, czyli pozytyw.

Edżajlkołczowie pracują ze swoimi zespołami. Zespoły mają ograniczoną liczebność, gdyż zespoły zbyt duże są nieefektywne. Przy większych przedsięwzięciach, powstaje wiele zespołów mających realizować wspólny cel. Ale zespoły są autonomiczne i nikt, ale to Nikt Spoza Zespołu, nie może czegokolwiek wrzucić do Baklogu. Tak więc zespoły muszą się ze sobą dogadywać. Customer collaboration over contract negotiation. Tako rzecze Manifest. Jak się uda, to się dogadają. Jak się nie uda, to zespół, który liczył ale się przeliczył, w swojej autonomiczności musi czekać na autonomię innego zespołu. Ale tym się nie martwimy, bo ważne, że klimat rozmów był korzystny. Kiedyś się dowiezie. Na razie zaślepimy, wdrożymy, i jakoś to będzie. Responding to change over following a plan. No przecież.

W dużych organizacjach systemów jest dużo. Najczęściej zmiana pociąga za sobą zmianę w więcej niż jednym systemie. Autonomiczny zespół musi więc posiadać u siebie specjalistów, którzy będą w stanie dokonać zmian w każdym z systemów. Ale nie zawsze się da. Bo jeśli zmiana dotyka kilkunastu systemów, to posiadanie choćby jednego specjalisty u siebie spowodowałoby przekroczenie maksymalnej liczby osób w zespole. Co więcej, może się także nie udać z racji tego, że system jest z gatunku centralnych i z założenia ma być dobrem wspólnym. A jeśli dobro wspólne, to nie prywatne. I na przykład sposób specyfikowania wymagań dla takiego dobra wspólnego może się różnić od tego, który wypracował zespół autonomiczny. Co więcej, zespół systemu centralnego może mieć całkiem rozbieżne z zespołem edżajlowym priorytety. I znowu trzeba czekać. I zaślepiać.

Manifest rzecze także  Working software over comprehensive documentation. Każdy przedszkolak, nie mówiąc o Edżajlkołczach, wie, że do produkcji softu potrzeba epików, storysów i tasków. Można też kanwasy, łajefrejmy i inne persony. Komunikacja, komunikacja, lekkość, zwinność. Tego nam potrzeba. Życie takiego bytu jest tak burzliwe, jak krótkie. Dyskusja, spory, poprawki, dyskusja, poprawki, zaimplementowane, DOD spełnione, poszło! A po roku jakiś inny, Obcy zespół musi sięgnąć do koncepcji rozwiązania. I męczy, i dręczy, i nawet próbuje się wbić do Baklogu autonomicznego systemu, ale ten ma przecież swoje, autonomiczne priorytety. Się uda, się wbije. Się nie uda, to powstanie kopia, łata, cokolwiek, co pozwoli Obcemu zrealizować swoje, autonomiczne plany. Że to niepotrzebne? Że to nadmiarowe? Kozioł ofiarny, by móc pracować w dobrym klimacie.

W bardzo dużych organizacjach, systemów i zespołów potrafi być bardzo dużo. Wprawdzie każdy jest zmotywowany, skoncentrowany na celu, ale jakaś kontrola – pardon, liderszip – być musi. Ktoś komuś jakiś raport na biurko czasami musi wrzucić. Najlepiej jakby z terminami, kosztami. Oczywiście wszystko edżajlowo, ale tak gdzieś pod spodem, jakby jakiegoś Ganta? Tylko, żeby nikt nie widział.

Poziom organizacji

No ale jak to zrobić? Ha! Proste! Tu do akcji wkraczają piękni trzydziestoletni – mistrzowie fechtunku słowem i pałerpojntem. Ci, którzy karierę pięknych dwudziestoletnich mają za sobą i doradzają. Oni mają wiedzę Świata, gdyż w takich organizacjach pracują, co to taką wiedzą dysponują. I oni wiedzą, że taka jedna firma, to kiedyś, podzieliła się na Trajby, Składy, Czaptery. I oni wiedzą, że tak trzeba postąpić, aby duch edżajla spłynął na całą organizację, a nie tylko na ajti. Wprawdzie piękni dwudziestoletni nie ogarnęli jeszcze zagadnienia współpracy w skali mikro, ale nie przeszkadza to we wdrażaniu zmiany w skali makro.

BPRRolnictwo w Polsce ma długą historię. I co, jak co, ale orki nikt nie musi nas uczyć. Zaorajmy więc dotychczasowe struktury i wdrażajmy podejścia autonomiczne na poziomie biznesu. Piękni trzydziestoletni nie pamiętają jednak, że tego typu radykalne zmiany historia zarządzania zna i ma za sobą. Jedną z najbardziej zbliżonych do Rewolucji Edżajl jest teoria Business Process Reingeenering, opisana przez Hammera i Champy’ego w latach dziewięćdziesiątych w książce Reengineering the Corporation: A Manifesto for Business Revolution. Doświadczenia z  wdrażania tej metody dały w efekcie łagodniejsze podejścia typu Business Process Improvement. Ale to było dawno, a teraz jest Edżajl. Będzie Pan zadowolony.

Tak więc, mamy nowe struktury organizacji edżajlowej. Wywiedzione wprost z koncepcji budowy oprogramowania, metody edżajl zaczynają rządzić biznesem. Edżajl to prostota, wobec czego wraz z nowymi strukturami dekretowane są redukcje (czytaj, uproszczenia) ról i stanowisk. Wprawdzie pracę trzeba wykonać, ale będzie jakoś prościej, bo stanowisk i ról mniej. Poza tym, edżajl to wymienność, więc zawsze można komuś obok coś wrzucić – niech czuje, że ma Edżajla. Czyli prościej i w dobrym klimacie. Nowe struktury są autonomiczne. Nie troszczą się szczególnie o inne, wszystko hermetyzują u siebie i dla siebie. Oczywiście za wyjątkiem tych obszarów, których ukryć się nie da. Ale tutaj jakoś trzeba się dogadać.

Każda zmiana ma jakieś skutki uboczne. To oczywiste. Wśród lekko zdezorientowanych skutków ubocznych stoją ramię w ramię osoby zajmujące się procesami biznesowymi, architekci biznesowi, architekci IT. Pojawia się bowiem zasadnicze pytanie – co ma być optymalizowane – praca Trajbów, czy praca całej organizacji? Co, jeśli te cele nie są zbieżne? Idąc dalej, jak tworzyć architekturę biznesową (choćby pojęcia) – dla Trajbu czy organizacji? Mamy architektury IT dla Trajbów czy dla organizacji? Jak wdrażać jednolite standardy w konstelacji autonomicznych jednostek? Senioredżajlkołczowie to wiedzą. Proponują jednostki wskrośtrajbowe. Ale to oznacza, że Trajb nie jest już tak autonomiczny, jak to obiecywali. Ale kto jest ważniejszy – ten od Wskroś, czy ten w Pionie? Pozostaje się dogadać.

I różne takie

Mylnym byłby wniosek, że tak fundamentalne problemy dotyczą jedynie poziomu organizacji. Na poziomach zespołów także mamy dylematy z gatunku dawno rozwiązanych ale w Edżajl fundamentalnych. Czy analiza powinna być elementem sprintów, czy też wyciągnąć ja poza sprinty, gdyż jest trudna do oszacowania. Wyciągnięcie jej poza sprint skutkuje rozpoczynaniem prac ze stabilnymi wymaganiami. Ale w takim razie w ramach czego powinna być prowadzona analiza? Jeśli zaś jest prowadzona w sprincie, opóźnienia stają się nagminne. Czy user story to wymaganie, czy coś innego? Jak się mają te wymagania do innych metod ich specyfikowania. Jak połączyć repozytorium user story z repozytoriami na przykład narzędzi do opisu wymagań technikami inżynierskimi (UML, BPMN, SysML). Czy elementem zmiany jest też poziom organizacji? Jeśli tak, jaki zespół powinien to robić? Ciężko sobie wyobrazić nieduży zespół posiadający w swoim składzie architektów, analityków biznesowych, analityków systemowych, specjalistów od usprawniania procesów, kontroli procesów, itd. Różne zespoły? To jaki produkt jest prezentowany Prodaktołnerom? Diagram? Jakby wbrew fundamentalnym obietnicom Edżajl.

To co to jest ten Edżajl?

No właśnie. Minął rok i dalej nie wiem. Intuicja podpowiada mi, że to prosta droga ku porażce. Że to już było. Że obietnice aż kłują populizmem w oczy. To, że ja nie rozumiem, co to Edżajl, to jeszcze nie problem. Problemem jest to, że wdrażający Edżajl, mam wrażenie, także nie wiedzą, co to tak do końca jest.

Ale kilkudziesięcioletnie doświadczenie mówi też, poczekajmy. Zobaczymy co z tego wyjdzie.  Idąc tym tokiem myślenia, mam wrażenie, że  Edżaj  zakończy swój dynamiczny żywot tak jak inne koncepcje, które miały zrewolucjonizować świat, a ostatecznie stały się małą częścią czegoś większego, dużo bardziej skomplikowanego. Pytanie oczywiście o koszty tej nauki. Ale to już inna bajka.

Ilustracja: https://pl.freepik.com/darmowe-wektory/ręcznie-rysowane-eleganckie-baleriny_849800.htm Designed by Freepik

 

The Business Agility Manifesto – jest nadzieja

Open flying old books

Agile (czytaj, ażil) w korporacji, jak na razie, kojarzy mi się z wielkim bałaganem, jeszcze większym nieporozumieniem i niekończącym się poganianiem jednego wzniosłego hasła, innym wzniosłym hasłem uzupełnianym metaforami coach’ów z zupełnie niepasującej bajki. Może trochę przesadzam, ale jeśli przesadzam, to tylko trochę.

Dwa tygodnie temu w ręce moje wpadł Manifest (https://busagilitymanifesto.org/) opracowany przez osoby, które bardziej kojarzą się z tymi niedobrymi czasami twardej inżynierii niźli ze zwinnością. Roger Burlton, Ronald Ross oraz John Zachman po raz kolejny połączyli siły i na bazie swoich doświadczeń wypracowali zestaw zasad dla zwinnego biznesu. I po raz kolejny, trafili w moje potrzeby. Najważniejszą z nich była potrzeba odnalezienia się w tym szaleństwie, które obserwuję i choćby drobnego odniesienia się do fundamentalnych wątpliwości odnośnie prób skalowania sofware’owego agile’a do potrzeb agile’owej korporacji. I postawienia przeciwwagi dla narracji w stylu „ostatecznie liczy się działający soft”. Bo moim zdaniem tak nie jest. Działający soft jest środkiem do celu, ale nie tylko on decyduje o zwinności organizacji. I od oprogramowania chciałbym zacząć analizę zaleceń manifestu, świadom tego, że zaczynam niejako od środka.

Developing software faster is not sufficient, in and of itself, for survival and growth because once operational, such software is likely to prove difficult to continuously and rapidly change without unintended consequences.

Samoorganizujące się zespoły, dobierające techniki głównie pod potrzeby szybkiego dostarczenia oprogramowania, nie zwracające szczególnej uwagi na szeroki kontekst organizacyjny tworzenia i utrzymania oprogramowania miesiąc po miesiącu dozbrajają tykającą od wdrożenia pierwszego przyrostu bombę. Ograniczanie wiedzy o biznesowym kontekście przedsięwzięcia do form akceptowanych w słownomuzycznym backlogu, odżegnywanie się od technik badających spójność biznesową rozwiązania oraz zgodność z otoczeniem, w którym przyjdzie je zastosować oraz stawianie na piedestale potrzeb deweloperów skutkuje zaciąganiem biznesowego i technologicznego długu, którego termin spłaty może nadejść gwałtownie, bez wcześniejszego uprzedzenia.

W moim przekonaniu, aby oprogramowanie mogło wspierać zwinne zarządzanie organizacją, musi być oparte o solidne fundamenty, w szczególności:

  • uwzględniać biznesową interpretację rzeczywistości organizacyjnej (być w zgodzie z modelem pojęć (koncepcji) ),
  • stanowić naturalne rozwinięcie wynikającego ze strategii organizacji łańcucha tworzenia wartości (być w zgodzie z modelem procesowym bądź innym, holistycznym spojrzeniem na opis realizowanych w organizacji działań dostarczających produkt Klientowi),
  • opierać się o solidny fundament analizy systemowej, zapewniający wewnętrzną spójność oprogramowania.

Część z tych tematów znajduje swoje rozwinięcie w materiałach uzupełniających manifest.

True business agility is measured not just by speed of response to requests, changes, or disruption, but also by the coherence of the response.

Spójność, której dotyczy postulat, powinna być traktowana wielowymiarowo – w poziomie, jako wewnętrzna synergia komponentów rozwiązania informatycznego, jak i w pionie – jako zgodność z rozwiązaniem biznesowym. Aby można było to stwierdzić, wymagane jest stworzenie jednoznacznego opisu wymiarów rozwiązania w formie umożliwiającej ich szczegółową analizę w efektywny sposób. Do tego potrzebny jest aparat narzędziowy bogatszy niż szkice i historyjki.

A critical skill for analysts is the ability to engage in dialogs to assess business knowledge for gaps, conflicts, ambiguity, and completeness.

Aparat ten daje szansę na nawiązanie efektywnego i skutecznego dialogu ze wszystkimi stronami wpływającymi na rozwiązanie, nie tylko tymi, którzy są w stanie zrozumieć potrzebę wytwórcy oprogramowania.

Instantaneous change is not the goal. The goal is well-considered change that achieves the desired business effect and avoids unintended side effects.

Frictionless change is not the goal. The goal is change that is dependably shaped according to business strategy, policies, and business obligations and commitments obligations.

Dobrze zaprojektowane rozwiązanie, uwzględniające wymagania wielu stron, pozwoli na jego płynniejsze wdrożenie oraz dłuższe wykorzystywanie, bez konieczności poprawiania go zaraz po wdrożeniu.

Skimping on the quality of business software – creating a tech debt – has no place in businesses striving for change in existing lines of business.

Dobrze zaprojektowanie rozwiązanie nie będzie automatycznie obciążone żadnym długiem, wręcz przeciwnie, będzie kolejnym małym krokiem w kierunku realizacji strategii.

Failing expensively or repeatedly, even if fast, is nonetheless waste to be eliminated.

The value of failing fast in order to learn fast must be balanced against other factors including: impact on business customers, cost of rework, and exposure to risk.

A jeśli już przyjdzie nam od razu poprawiać świeżo opracowany produkt, oznaczać to będzie, iż najprawdopodobniej po prostu źle wykonaliśmy swoją pracę. Strategia Fail fast ma swoje określone miejsce i nie powinna tłumaczyć każdej porażki.

Self-organizing teams and other agile organization schemes alone do not lead to business agility.

Self-organizing teams are a means, not an end. They do not reduce, but rather increase, the need for business strategy, value chain coherence, reuse of business knowledge, and effective portfolio governance.

A i jeszcze te zespoły. Samostanowiące o sobie. Samoorganizujące się. Szlachcic na zagrodzie… Pracujemy w dużej firmie. Musimy dbać o synergię. Musi być ktoś, kto ustanawia reguły, a zespoły samostanowiąc o sobie, muszą się w wyznaczonych ramach mieścić. Musi być ktoś, kto rozlicza ze stosowania się do reguł. Musi być lider. Konsekwentny.

Tyle na pierwszy raz.

Warsztaty nieoczywiste – style myślenia i działania a zespoły analityczne

Pod koniec czerwca, wraz z Jolantą Korczowską, poprowadzimy we Wrocławiu dwugodzinne warsztaty z zakresu stylów myślenia oraz działania, w kontekście organizacji pracy zespołów analitycznych. Z punktu widzenia teorii i standardów analizy biznesowej, temat należy uznać za rewolucyjny. Dla nas, jako prowadzących, temat jest sporym wyzwaniem. Mamy jednakże nadzieję, że dla Państwa, jako dla uczestników, temat będzie podróżą w nowym, inspirującym kierunku.

Serdecznie zapraszamy! Aktualności związane z warsztatami są publikowane na stronie IIBA Polska.

Analiza biznesowa jest ą, ę

Notebook and coffee with copy space on a wooden background. selective focus

Słuchałem jakiś czas wywiadu z prof. Bralczykiem na temat języka polskiego. Z wywiadu tego, utkwił mi w głowie fragment dotyczący ewolucji języka, która między innymi skutkuje znacznym zubożeniem słownictwa będącego w powszechnym użyciu. Mnogość określeń bazujących na subtelnościach i niuansach jest zastępowana zwrotami typu wporzo, mega, czy zapożyczeniami w stylu ołmajgod. Tak, wiem, makaronizmy od wieków uzupełniały nasz język, aczkolwiek, jak mi się wydaje, nie w takim stopniu.

Nałożyłem tę sytuację na inne języki – języki wyrazu myśli analitycznej. Od dziesiątek lat rozwijane z myślą o radzeniu sobie w sytuacjach, w których język naturalny jest niewystarczający, gdy zwykły zapis myśli w formie zdań utrudnia pracę, a czasami czyni ją niewykonalną w zadanym czasie i w oczekiwanej jakości. W obszarze tym także widać było pewną ewolucję – strukturalne metodyki wytwarzania oprogramowania zostały płynnie zastąpione paradygmatem obiektowym, poszerzający się zakres technologiczny odnajdywał wsparcie w nowych środkach wyrazu – nowych językach. Kolejne obszary analizy biznesowej, architektury biznesowej, architektury korporacyjnej zostały objęte dedykowanymi językami. Środki wyrazu, jakimi aktualnie dysponuje (a precyzyjniej, powinien dysponować) kompetentny analityk są ogromne. Nic tylko uczyć się, uczyć, uczyć, nabierać doświadczenia i świadomie, płynnie i adekwatnie do sytuacji stosować.

I nagle okazało się, że to wszystko jest niepotrzebne. Że JAKO analityk CHCĘ stosować bardzo proste techniki ABY szybko wdrażać rozwiązania. I niewiele więcej jest potrzebne. I skomplikowane stało się proste. Jak budowa cepa.

OMG! Ja jednak wolę ą, ę. Rili.

 

Analityk biznesowy jako lider

Lider. Często określenie to niesie za sobą skojarzenia z charyzmatycznym prezesem firmy, która osiągnęła spektakularny sukces. Bądź z rozpoznawalnym przywódcą partii politycznej. Z drużyną sportową i jej najlepszym zawodnikiem.

W analizie biznesowej, szczególnie w trudnych organizacyjnie projektach, w ramach których podejmowane są niełatwe decyzje analityk biznesowy musi stać się takim liderem. Liderem zmiany. Twarzą tej zmiany. Kompetencje przywódcze będą wymagane w różnych sytuacjach – w trakcie rozmów ze specjalistami dziedzinowymi o aktualnym stanie organizacji, o występujących problemach, w trakcie wypracowywania docelowych rozwiązań, prezentacji rozwiązań innym interesariuszom projektów. Uzyskanie właściwego poziomu dialogu będzie możliwe w sytuacji, gdy specjaliści dziedzinowi oraz osoby oceniające i podejmujące kierunkowe decyzje odnośnie wdrożenia rozwiązania uznają nas za wiarygodnego partnera. Na wiarygodność wpływa wiele kryteriów: wiedza dziedzinowa, kompetencje inżynierskie (analityczne), umiejętność komunikowania się, negocjowania. W ogromnym stopniu wiarygodność buduje postawa lidera, postawa osoby która całym sobą potwierdza zasadność uczestniczenia w pracach.

Analityk biznesowy uczestniczący w nietrywialnym przedsięwzięciu przez cały czas będzie się zmagał z koniecznością motywowania członków zespołu do zaangażowania się w prace, stawić będzie musiał czoła oporowi, który może się pojawić w sytuacjach, gdy uczestnicy zauważą zagrożenie dla swojego aktualnego miejsca w organizacji, będzie negocjował fragmenty rozwiązania z opiekunami obszarów biznesowych, na które zmiana wpłynie. W tego typu sytuacjach ogromną rolę będą odgrywały kompetencje przywódcze, kompetencje które przekonają inne strony do pójścia we wskazanym kierunku.

Liderem nie można zostać w efekcie dekretacji. Lidera wybiera i akceptuje grupa, z którą pracuje. Lider musi do siebie grupę przekonać. Lider musi pokazać, że warto z nim udać się w długą i niełatwą drogę. Lider musi o swoją pozycję dbać (nie mylić, z walką).

Liderem albo się jest z natury, albo trzeba się nauczyć nim być. Pozycja lidera nie jest dana raz na zawsze – o utrzymanie tej pozycji należy stale dbać. Aby dbać o nią skutecznie, trzeba wyrobić w sobie umiejętności zauważania sytuacji, w której wymagana będzie świadoma interwencja mająca na celu podtrzymanie pozycji. Skutecznego interweniowania także należy się nauczyć.

Proces dydaktyczny w tak subtelnej kompetencji, jaką jest przywództwo nie jest łatwy. W szczególności, niełatwo jest ocenić, czy prezentowana postawa jest przekonująca, czy da szanse zbudować wokół siebie zespół. Pomoc w tym zakresie przyszła do nas z zupełnie nieoczekiwanego kierunku. Wiele lat temu, w szeroko pojętym światku hipicznym, pojawił się nurt naturalnych metod pracy z końmi. Zaowocował on zakrojonymi na szerszą niż dotąd skalę pracami w zakresie behawioryzmu tych wrażliwych zwierząt. Potwierdziły one między innymi fakt, iż konie żyją w bardzo hierarchicznym świecie, w którym to od skuteczności lidera zależy dobrobyt, a często i życie grupy. Jest to świat w którym wykluczenie z grupy oznacza śmierć, a proces ustalania miejsca w stadnej hierarchii odbywa się nieustannie. Często sygnały świadczące o próbie zrewidowania miejsca w hierarchii są subtelne – koń „niechcący” delikatnie kogoś przesunął, koń „przypadkowo” nie usłyszał. Koń nie zrobił nic przypadkowo. Koń sprawdza, czy Ten Drugi jest wyżej (i musi go słuchać), czy przypadkiem dzisiaj To Ja jestem wyżej. Koń nie czyta wizytówek. Koń nie wie, kim jest tato, czy ciocia. Koń widzi Tego Drugiego. I sprawdza go.

Na bazie tego typu wiedzy powstały unikalne w swoim charakterze warsztaty budujące kompetencje przyszłych liderów. W trakcie warsztatów trzeba przekonać konie, iż warto nam zaufać. Konie szczerze nam odpowiedzą. A ja szczerze polecam.

Ulotka: Lustro Lidera

Unikalne warsztaty mające na celu budowanie kompetencji przywódczych, w trakcie których ocena uczestników jest dokonywana przez konie.

 

 

Grafika: http://www.freepik.com/free-photos-vectors/background Background image created by Katemangostar – Freepik.com

SCRUM responsibly

W którą stronę bym się nie obrócił, przed oczami widzę zwinność. Nie, żebym miał wizje – tak mnie uszczęśliwia szara rzeczywistość. W zasadzie nie miałbym nic przeciwko temu, gdyby nie fakt, iż w większości przypadków zwinność ta przybiera karykaturalną formę pogoni za nieosiągalnym – a im bardziej nieosiągalne staje się nieosiągalne, tym szybszy i mniej kontrolowany staje się pościg.

Patrząc na ten fenomen z punktu widzenia analityka biznesowego, nie mogę pojąć sposobu, w jaki zwinność, promowana przez praktyki SCRUM, miałaby pomóc realizować przedsięwzięcia prowadzone w nietrywialnym środowisku. Trudność z pojmowaniem rozpoczyna się już na poziomie roli o nazwie Product Owner. Tłumacząc literalnie na język polski, mamy do czynienia z właścicielem produktu. Ale jakiego produktu? Czy produktem jest cała zmiana, która została zainicjowana (na przykład w formie projektu)? Jeżeli tak, to właściciel produktu powinien być nazywany właścicielem zmiany. Jeżeli jednak powinien być jawnie wskazany produkt, to jaki? Załóżmy, że zmiana dotyczy usprawnienia jakiegoś obszaru organizacji – czy w takim razie ten obszar jest produktem? Jeżeli tak, to czy w przypadku szerokiej zmiany, dotykającej na przykład wielu procesów biznesowych, nie wystąpi konflikt choćby pomiędzy właścicielem produktu a właścicielami procesów biznesowych?

Bez względu na to, co jest produktem, zgodnie z zaleceniami SCRUM, właściciel tegoż jest odpowiedzialny za zawartość product backlogu, a zespół deweloperski, za jego przetworzenie w finalny, wartościowy produkt każdego sprintu. Załóżmy, że rozpoczynamy prace w przedsięwzięciu o charakterze opisanym wcześniej. Efektem prac sprintu mogą być wskazane w procesach punkty nieciągłości, wykazana niezgodność pomiędzy celami procesów a modelem biznesowym, oraz wskazane do zrewidowania polityki, reguły biznesowe oraz definicje niektórych pojęć. Pytanie, czy to ma wartość biznesową w kontekście SCRUM (boć nie jest to przecież działający fragment systemu).? Kim są deweloperzy (boć miejsca dla projektantów, programistów i testerów tam nie ma)? Analiza biznesowa na tym poziomie ma to do siebie, iż nie jest zbyt przewidywalna. Mnogość międzyludzkich interakcji, często powiązanych z emocjami wynikającymi z zaburzenia komfortu na najniższych poziomach piramidy potrzeb, powoduje, iż zwroty analitycznych akcji są częste, a z dnia na dzień odkrywane mogą być obszary wymagające osobnego potraktowania. W praktyce, sprinty zaczynają określać częstotliwość raportowania, pozostawiając prace swojemu własnemu rytmowi. Innymi słowy, zaczynamy praktykować sztukę dla sztuki. Po co?

W trakcie kilkunastu rozmów na temat praktyk SCRUM w kontekście analizy, docierał do mnie przekaz, iż SCRUM jest techniką deweloperską, w której deweloper to członek zespołu pracujący nad rozwiązaniem IT. Gdyby przyjąć taki punkt widzenia, to cała praca związana z projektowaniem docelowego kształtu organizacji w ramach szeroko pojętej zmiany odbywać się powinna poza SCRUM. Jeżeli tak, to za właścicielem produktu powinien stać sztab analityków biznesowych i architektów biznesowych, wspierających go w podejmowaniu decyzji dotyczących product backlogu. Ale zaraz – czy nie sankcjonujemy przypadkiem podejścia waterfall (które, dla przypomnienia, jest ZŁEM)? Najpierw analiza a potem „kodowanie”?

Kontynuując podróż w dół procesu wytwórczego, docieramy w końcu do zespołu deweloperskiego, którego zadaniem jest wytwarzanie, w odstępach wyrażanych długością sprintów, upragnionego oprogramowania. Podtrzymując założenie, iż pracujemy na problemach o złożoności nietrywialnej (np. dowolna korporacja), zmiana na poziomie IT będzie wymagała zmian w wielu systemach jednocześnie, które rozwijane są w różnych technologiach, jednostkach organizacyjnych i podmiotach (spółki zależne, dostawcy w pełni zewnętrzni). Zakładając zdroworozsądkowo, iż planowanie logiki rozwiązania (poziom PIM według MDA) dokonywane jest według zasad wspierających systemowe podejście do problemu, analiza poszczególnych funkcjonalności może trwać zauważalnie długo z punktu widzenia długości sprintu. W praktyce może się to przełożyć na funkcjonowanie podzespołów scrumowych dwóch prędkości – zespół analityków, ux-owców, architektów IT pracujących nad przyrostem n, i deweloperów, zajmujących się przyrostem n-1. Oczywiście, nic nie stoi na przeszkodzie aby deweloperzy w jakimś zakresie pracowali nad przyrostem n, aczkolwiek małe jest prawdopodobieństwo, aby ukończyli go w sprincie, w którym ukończą go analitycy. To tez prowadzi do wniosku, iż do pewnego stopnia mamy jawnie do czynienia z podejściem (iteracyjnym i przyrostowym) waterfall.

Poszczególne wątki można rozwijać dalej, aczkolwiek z punktu widzenia celu niniejszego wpisu nie jest to zasadne. Wątpliwości, które opisałem mam od dawna. Dane mi było przeprowadzić wiele rozmów, z wieloma osobami, z wielu organizacji i żadna z tych rozmów wątpliwości nie rozwiała, a większość tylko je potwierdziła. Z drugiej strony, ze środowisk promujących zwinne, oparte o SCRUM podejście, uzyskuję zapewnienia, iż da się to wszystko ogarnąć, tylko trzeba zmienić styl myślenia, podejście, zaufać, i takie tam. Cierpliwie czekam, bom ciekaw. Aczkolwiek coraz bardziej utwierdzam się w przekonaniu, że jedyną rzeczą, jaka nas może uchronić od porażki są wysokie kompetencje osób pełniących poszczególne role w projekcie (architektów korporacyjnych, architektów biznesowych, analityków biznesowych, analityków systemowych, architektów IT, projektantów, programistów, testerów, specjalistów dziedzinowych, scrum masterów, kierowników projektów, i innych), dobrze określony proces wytwórczy (metodyka dostosowana do charakteru przedsięwzięcia), dobrze określony proces zarządczy (dostosowany do specyfiki przedsięwzięcia), postawa skierowana na rozwiązywanie problemów oraz zdrowy rozsądek, nakazujący czerpanie z różnych źródeł (waterfall, agile, TQM, facylitacja, BPM, design thinking, itd.).

Howgh!

 

Grafika: http://www.freepik.com/free-photo/silhouettes-of-a-tree-and-a-man-on-a-book_969890.htm” Designed by Freepik

Back to the roots

Close-up of two white pieces of chalk on blackboardSzkolenia i konsultacje z zakresu analizy prowadzę już ponad 20 lat. Pomijając mój debiut, w trakcie którego posługiwałem się rzutnikiem slajdów oraz wydrukami na folii, zawsze towarzyszył mi PowerPoint. Stylistyka slajdów oraz ich charakter ewoluowały wraz z trendami (a te ładnie co roku opisuje m.in. SlideShare). I wydawało mi się, że od prezentacji nie ma odwrotu (pomijając konkretne narzędzie), aż tu wpadł mi w ręce artykuł o profesorach lwowskich, ich wiedzy, pasji i umiejętności fechtowania słowem i rysunkiem, która na godziny przykuwała uwagę słuchaczy.

I pomyślałem sobie, że może warto się zmierzyć z wyzwaniem. Że może warto sprawdzić się i wyjść na szkolenie jedynie z „kredą” i pomysłem w głowie. I przed takim wyzwaniem właśnie staję. Dwa dni praktycznych warsztatów z analizy biznesowej. Proces wytwórczy na poziomach CIM i PIM, kilka języków modelowania do wprowadzenia (BPMN, UML SysML, ArchiMate), dobór jedynie tych elementów języków, które są istotne z punktu widzenia prezentowanej metodyki, rzeczywisty, szeroki problem do warsztatowych rozważań. I to wszystko tylko z kredą i tablicą we współczesnym wydaniu. Ani jednego slajdu.

Przygotowując się do warsztatów już widzę, jak ogromna to różnica w stosunku do prezentacji, która prowadzi. Kto by pomyślał, że poczuję jeszcze tak intensywny dreszczyk emocji. Już czuję, że warto.

Model informacyjny w systemach klasy frontend

Frontend XSPrzez ostatnich kilka miesięcy mam okazję uczestniczyć w analizie biznesowej oraz systemowej systemu klasy frontend. Z jednej strony, system jak system, z drugiej, to co w nim wydaje się ciekawe to model danych. Oczywiście, z punktu widzenia języka specyfikacji, w dalszym ciągu jest to stary, dobry, sprawdzony diagram klas języka UML. Natomiast, to co w nim najciekawsze, to liczności.

Ale po kolei. Systemy omawianej kategorii sporą część danych prezentowanych na ekranach czerpią z innych systemów korzystając najczęściej z dedykowanych interfejsów. Różne funkcjonalności, mogą nieść ze sobą wymagania na określone dane, także w ramach jednej klasy. Dla przykładu, załóżmy, że w momencie wprowadzania wniosku o wydanie duplikatu prawa jazdy, osoba wprowadzająca wniosek ma za zadanie podanie swojego numeru PESEL, na podstawie którego system frontend, o hipotetycznej nazwie System Obsługi Dokumentów Drogowych (SODODRO), wysyła żądanie do Systemu Ewidencji Obywateli (SEO) i pobranie podstawowych danych o osobie, na które składają się imię, nazwisko, data urodzenia i miejsce zamieszkania. Przykładowa definicja klasy mogłaby wyglądać, jak poniżej.

klasy1

Podstawowe dane Obywatela

Takie dane są prezentowane osobie składającej wniosek, która po potwierdzeniu ich poprawności otrzymuje możliwość podania powodu ubiegania się o wystawienie duplikatu. Jednocześnie, dane te zostają przepisane do wniosku, stając się jego integralną częścią. W momencie kierowania wniosku do realizacji, odnotowywany jest moment jego złożenia oraz nadawany jest unikalny identyfikator wniosku. Przykładowy diagram klas systemu SODORO dla opisywanej sytuacji przedstawia poniższy rysunek.

 

klasy2

Model klas dla funkcjonalności składania wniosku

Wniosek jest zapisywany w systemie SOW (System Obsługi Wniosków) poprzez usługę zapiszWniosek. System SODORO musi przekształcić dane do struktury danych wejściowych usługi, co jest już odzwierciedlane w przebiegu przypadku użycia (jeżeli ta technika jest stosowana do opisu funkcjonalności systemu).

Inna funkcjonalność systemu SODORO, pozwala na wyświetlenie wszystkich wniosków złożonych przez określonego obywatela. W efekcie wywołania tej funkcjonalności, system SODORO wywołuje usługę dajWnioskiObywatela systemu SOW i w efekcie otrzymuje kolekcję wniosków, opisanych cechami: moment złożenia, identyfikator wniosku. Oznacza to, iż model informacyjny systemu musi uwzględnić fakt, iż w niektórych sytuacjach dane wniosku będą zubożone w stosunku do jego pełnej zawartości informacyjnej, co musi skutkować jawnym wprowadzeniem opcjonalności w modelu klas.  Atrybutom imię składającego, nazwisko składającego, data urodzenia składającego, PESEL składającego oraz miejsce zamieszkania składającego przypisano liczności [0..1]. Podobny zabieg został zastosowany dla roli składający asocjacji składa. Co więcej, w związku z faktem, iż dane wniosku są odczytywane bez kontekstu obywatela go składającego, należy usunąć znacznik wnioskowalności atrybutów. Przykład takiej modyfikacji przedstawia poniższy rysunek.

klasy3

Osłabione liczności w modelu klas

Wraz ze wzrostem opisywanej funkcjonalności może następować dalsze osłabianie wymagalności poszczególnych cech klas oraz końców asocjacji łączących klasy. Docelowy model, może więc teoretycznie przyjąć formę diagramu, w którym zdecydowana większość właściwości klas jest opcjonalna, dzięki czemu model stanie się adekwatny do kontekstu pojedynczych funkcjonalności.

Sytuacja taka może sprowokować pytanie, jaka jest wartość takiego modelu? Czy nie lepiej byłoby tworzyć modele pod pojedyncze funkcjonalności, i uznać, iż nie ma czegoś takiego jak jednolity model informacyjny systemu klasy frontend? Przyznam, że sam miałem jakiś czas temu takie dylematy, ale na chwilę obecną stwierdzam, iż model taki ma sens. Po pierwsze, prezentuje on spójny obraz tego, czego można się spodziewać po posiadanych danych. Po drugie, pozwala on na unifikację danych wykorzystywanych przez system frontend, niezależnie od tego, skąd te dane są zaczytywane (oczywiście, pod warunkiem, że można przekształcić dane z systemów źródłowych do struktury systemu frontend). A gdyby tak przyglądnąć się modelowi z punktu widzenia narzędzi integracyjnych, czy BPMS, można byłoby dojść do wniosku, że jest to nic innego, jak model kanoniczny. A takowy przecież sens ma.

Prace analityczne trwają, więc być może mój pogląd na sprawę się zmieni. Gdyby tak się stało, postaram się podzielić swoją opinią na powyższy temat ponownie.

A przed zakończeniem…

P.S. Sposób odnotowywania zapisu wniosku

Przebiegi przypadków użycia, w ramach których m.in. następują wywołania do systemów zewnętrznych, są opisywane w metodyce AION diagramami aktywności, w których odwołanie do współdzielonej funkcjonalności (zachowania, w terminologii UML) jest reprezentowane akcją wywołania zachowania (ang. call behavior action).  Sytuacje wywoływania usług zewnętrznych systemów doczekały się w metodyce wzorca analitycznego, na który składa się przede wszystkim aktywność zawierająca dwuetapowe wywołanie. Strukturę takiej aktywności, dostosowaną do omawianego przykładu, prezentuje poniższy rysunek. Pierwsza etap, to przekształcenie informacji zapisanych w modelu informacyjnym systemu wywołującego usługę, do struktury danych wymaganej do wywołania usługi. We wzorcu etap ten reprezentuje akcja Przygotowanie danych. Precyzyjne opisanie zasad przekształcania wymaga zastosowania prostych konstrukcji języka OCL (patrz P.S. 2). Drugi etap, to wywołanie samej usługi systemu zewnętrznego, reprezentowane akcją wywołania zachowania o nazwie Wywołanie usługi. Pinem wejściowym dla tej akcji jest struktura danych będąca pinem wyjściowym wcześniejszej akcji.

activity

Opis aktywności zawierającej ciąg działań wymaganych do wywołania zewnętrznej usługi

Odwołanie do wywołania usługi zewnętrznej w przebiegach poszczególnych przypadków użycia jest reprezentowane także akcją wywołania zachowania, ale w tym przypadku wywoływana jest aktywność opisana omówionym wzorcem. Przykład wywołania prezentuje poniższy rysunek.

 

use case flow

Wywołanie wzorca wywołania usługi z przebiegu przypadku użycia

 

P.S. 2 Sposób przygotowania wyrażenia OCL transformującego dane z modelu informacyjnego aplikacji frontend na struktury parametru wywołania usługi

Język OCL może znaleźć zastosowanie między innymi do jawnego pokazania konwersji danych ze struktur modelu informacyjnego systemu frontend do struktur wywołania usługi. Poniższy rysunek prezentuje przykładowe wyrażenie OCL. Pierwsza część wyrażenia, rozpoczynająca się od słowa context stanowi deklarację kontekstu definiowania ograniczenia. Kontekstem takim, zgodnie z UML, może być klasa, albo określone zachowanie. Odwołanie się do akcji jest konwencją AION, która moim zdaniem jest naturalnym rozszerzeniem koncepcji zawartych w UML.

Druga część wyrażenia, rozpoczynająca się od słowa post opisuje warunek, który musi być spełniony po zakończeniu realizacji akcji. Pierwsza linia wyrażenia  – result.oclIsNew() – wskazuje, iż elementem wyjściowym wywołania jest nowopowstały obiekt. Dalsze składowe wyrażenia pokazują zasady transformacji.

 

ocl

Przykład zastosowania OCL do jawnego pokazania konwersji struktur danych

 

 

Ilustracją wpisu jest zdjęcie pobrane z serwisu Freepik.

Pańskie oko w korporacji…a w zasadzie jego brak

Notebook and coffee with copy space on a wooden background. selective focus

O dawna wiadomo, że pańskie oko konia tuczy. Nie do końca jest jednak pewne, czym skutkuje pańskiego oka brak. Niniejszy wpis jest swoistą kontynuacją luźnych myśli na temat korporacji, wynikających z moich osobistych, analitycznych obserwacji.

Moje ostatnie dłuższe pobyty w korporacjach prowadzą jednakowoż do wniosku, iż brak jasno określonego Pana, który pańskim okiem swym, nastawionym na weryfikację kierunku rozwoju jego własności, powoduje, iż zarówno kierunek ten jak i tempo rozwoju mogą się zewnętrznemu obserwatorowi wydać co najmniej odbiegające od spodziewanego. Rozdrobnieni właściciele, weryfikujący skuteczność działania organizacji raportami giełdowymi, nie mający możliwości zweryfikowania w jaki sposób zarządza się ich środkami, powodują, iż w dużej mierze gospodarne zarządzanie jest efektem etyki menedżerów. A menedżerowie to przede wszystkim ludzie. Z ich ambicjami, problemami, animozjami, sympatiami, pragnieniami. Ludzie Ci stają bardzo często przed wyborami:

  • zburzyć status quo i zacząć działać inaczej (lepiej z punktu widzenia strategii organizacji), czy pozostać w układzie, który nie jest optymalny, ale stabilny,
  • podjąć ryzykowną decyzję, która może skutkować utratą pozycji, czy stabilnie iść utartym szlakiem,
  • podjąć decyzję, która pchnie firmę do przodu, czy taką, która utrudni życie wewnętrznemu rywalowi,
  • piąć się do góry, bez względu na koszty, czy zająć się działaniami w obszarze własnych kompetencji,
  • działać, czy trwać?

Dylematów różnej natury można mnożyć w nieskończoność. W nieskończoność można także mnożyć KejPIaje, KejeRaIe, którymi można w nieskończoność mierzyć skuteczność działań. Ale aby były rzetelne, potrzebne są wiarygodne dane i poprawne wyliczenia. Potrzebne są także osoby tym zainteresowane, posiadające jednocześnie zdolność do weryfikacji ich rzetelności. Gdy ich brakuje, dzieją się Rzeczy Różne.

Co to ma do analizy biznesowej? Ano to, że analiza pokazuje między innymi Różne Rzeczy. I co z  nimi robić, gdy Pańskiego oka brak?  Można robić różne rzeczy, a przy okazji narobić sobie wrogów. A korporacja będzie, niezależnie od tego, trwać.

Tu, przy okazji, dotykamy problemu etyki analityka… ale to już na osobny wpis.