Architektura systemów w warunkach niepewności biznesowej

Tytuł: Architektura systemów w warunkach niepewności biznesowej
Kod: ddd-strategic
Kategoria: Domain Driven Design i Event Storming
Forma: 60% wykłady / 40% warsztaty
Czas trwania: 1 dzień
Odbiorcy: Product Owners, management, Scrum Masters, liderzy zespołów, testerzy, architekci, analitycy, kierownicy projektów
Zapisy: Indywidualne zamówienie i dopasowanie dla grupy.
Logistyka: W siedzibie klienta lub w innym dowolnym miejscu.

Masz za sobą kilka transformacji, z czego każda zakończona wielkim sukcesem, a jednak IT wciąż nie spełnia oczekiwań.

W rozmowie żonglują buzzwordami technicznymi nieudolnie przeplatając je z językiem korzyści zaczerpniętym ze szkoleń komunikacyjnych.

Rozumiesz już z czego wynikają opóźnienia i błędy: z mnogości zależności pomiędzy modułami i zawiłości reguł. Ale przecież ostatnia rewitalizacja architektury miała temu zapobiec.

Podczas warsztatu przejdziemy przez dramat współczesny w trzech aktach na przykładowym projekcie:
  • błędny podział systemu na obszary - który może uwypuklić problemy na poziomie organizacyjnym
  • błędną integrację tych obszarów - która prowadzi do paraliżu zależności
  • błędną topologię - która zabija autonomię produktów

    • Ale to tylko do pierwszej przerwy kawowej.

    Po niej podejdziemy jeszcze raz do zadania, tym razem racjonalnie i metodycznie. Celem ćwiczeń nie będzie nauczenie Ciebie technik analizy i architektury, celem będzie nauczenie Cię na co zwrócić uwagę podczas współpracy z IT, jak ich (po staropolsku) challengować i jak nie dać sobie wcisnąć wymówek: nie da się.

    Da się, robimy to od 22 lat.

    Przejdziemy przez wszystkie fazy strategicznego projektowania architektury:
  • zbieranie informacji nastawione na uwypuklenie kluczowych zmian stanu prowadzących do domknięcia procesów
  • analizę źródeł prawdy odnośnie istotnych pytań biznesowych
  • symulację zmienności procesów
  • tworzenie strategicznej mapy obszarów biznesowych
  • nadawanie kierunku i rodzaju zależności pomiędzy obszarami
  • zapewnienie autonomii twoim obszarom przez uszczelnianie komunikacji
  • mapowanie architektury na topologię produktową
  • dobieranie driverów architektonicznych wspierających cele biznesowe

    • A może jesteś tuż przed (kolejną) rewitalizacją i (tym razem) chcesz dopilnować aby inwestycja zwróciła się w oczekiwany sposób?

    Jakie umiejętności zdobędziesz:
  • pomoc przyjaciołom z IT w ustalania celów spotkań analitycznych
  • pomoc przyjaciołom z IT w skupianiu się na architekturze, która zapewnia autonomię procesów a nie naiwną segregację danych
  • pomoc przyjaciołom z IT w tworzeniu reużywalnych komponentów zapewniających potencjał biznesowy, na którym możesz budować kolejne produktyzacje

    • Wyróżniki szkolenia

    • Praca nad przykładem o realnym poziomie złożoności, zawierającym w sobie typowe jak i wyrafinowane przypadki biznesowe
    • Operowanie na sugestywnych metaforach pozwalających zrozumieć techniczne pojęcia
    • Porównanie 2 podejść do strategii i zestawienie konsekwencji wynikających z ich zastosowania

    Program Szkolenia

    Program jest ramą w jakiej możemy się poruszać merytorycznie - program dla konkretnego szkolenia dedykowanego ustalamy z grupą na podstawie analizy przed-szkoleniowej.

    1. Doświadczenie konsekwencji trywializacji analizy i naiwnej architektury
      1. Intuicyjny podział systemu na obszary
      2. Weryfikacja podziału przez pryzmat procesów biznesowych
      3. Weryfikacja podziału przez pryzmat przeciekania reguł biznesowych
      4. Diagnoza przyczyn braku autonomii i nazwanie antywzorców i złych praktyk
      5. Śmiech/płacz - zależnie od preferencji
    2. Podsumowanie doświadczenia
      1. Problemy
        1. Dlaczego architekt mówi, że "tego nie da się zrobić", skoro biznes uważa, że się da?
        2. Dlaczego jedna funkcjonalność trafia do systemu A, a nie B?
        3. Dlaczego jedna zmiana ma impakt na znaczną część organizacji?
        4. Skąd wiadomo, że moduł został źle wydzielony?
      2. Artefakty analityczne wspierające decyzje architektoniczne
        1. pytania biznesowe
        2. ograniczenia
        3. reguły
        4. zależności
        5. ryzyka
        6. alternatywy
      3. Skalowanie poziomów abstrakcji i szukanie miejsc do podejmowania decyzji
        1. Proces biznesowy
        2. Capability
        3. Bounded Context
        4. Moduł
        5. Komponent
        6. Klasa
      4. Jak architekt podejmuje decyzje?
        1. jakie informacje zbiera,
        2. czego szuka,
        3. co jest sygnałem ostrzegawczym,
        4. kiedy mówi "nie".
      5. Jakie są najczęstsze błędy analityków utrudniające pracę architektom?
      6. Jak prowadzić rozmowę architektoniczną
        1. jakie pytania zadawać,
        2. jak argumentować,
        3. jak przedstawiać alternatywy,
        4. jak przygotować warsztat,
        5. jak opisywać ryzyka.
    3. Zbieranie informacji - technika Event Storming - Process Level
      1. Podstawy facylitacji spotkania
        1. Określenie celu: as is, to be, weryfikacja procesu, eksploracja, projektowanie architektury
        2. Pomoc przyjaciołom z IT w zadawaniu adekwatnych pytań
      2. Modelowanie istotnych zmian stanu
      3. Rozróżnianie reguł biznesowych od walidacyjnych i technicznych
      4. Odpowiednie rozmieszczenie reguł
    4. Analiza zebranych informacji
      1. Stawianie istotnych pytań biznesowych
      2. Poszukiwanie źródeł prawdy dla pytań biznesowych
      3. Analiza alternatywnych procesów
      4. Destylacja generycznych modeli dla wspólnych obszarów biznesowych
    5. Mapowanie obszarów biznesowych
      1. Podejmowanie decyzji o tym kto zależy od kogo
      2. Konsekwencje decyzji na proces wytwórczy
      3. Wykrywanie i unikanie wąskich gardeł w procesie wytwórczym
      4. Analiza granic i odpowiedzialności
      5. 7 strategii mapowania - dobór do strategii biznesowej
    6. Integracja obszarów biznesowych w procesy z zachowaniem autonomii
      1. Projektowanie komunikacji między modułami - wzorce i antywzorce
      2. Unikanie przenikanie wiedzy biznesowej
      3. Komunikowanie zdarzeń biznesowych zamiast technicznych zmian
      4. Testowanie szczelności
    7. Dobór rodzaju rozwiązania technicznego do klasy problemu dziedzinowego
      1. Zarządzanie stanem
      2. Transformacje danych
      3. Operacje klasy CRUD (Create, Read, Update, Delete)
      4. Raportowanie i zaawansowane przeszukiwanie
      5. Integracja danych
      6. Integracja usług


    Pobierz program w formacie PDF

    Trenerzy

    Poznaj ekspertów, którzy mogą poprowadzić Twoje szkolenie.

    Sławomir Sobótka

    Trener

    Być częścią rozwiązania a nie częścią problemu.

    Zamów szkolenie

    Imię i nazwisko:
    Firma:
    E-mail:
    Nr tel:
    Temat:
    Wiadomość:

    Jeżeli preferujesz osobisty kontakt to zawsze możesz zadzwonić.

    Iwona Sobótka

    Koordynatorka szkoleń


    Twoje dane osobowe przetwarzamy, aby udzielić odpowiedzi na Twoje pytanie. Administratorem Twoich danych osobowych jest Bottega It Minds Sławomir Sobótka. Przysługuje Ci prawo wniesienia sprzeciwu wobec przetwarzania, prawo dostępu do danych, prawo żądania ich sprostowania, usunięcia lub ograniczenia ich przetwarzania. Szczegółowe informacje dotyczące przetwarzania Twoich danych osobowych znajdują się TUTAJ.