Ewolucyjna architektura (Spotkanie Strefy Wiedzy Liderów IT)

www.bnsit.pl

Ewolucyjna architektura

www.sxc.hu/photo/850368

www.bnsit.pl

Poznajmy się!

Imię i nazwisko Firma 3 słowa o sobie

www.bnsit.pl

# 1. spotkanie 16 września

# W prasie

• Artykuły w czasopiśmie Programista

• Strefa Wiedzy Lidera IT na portalu czasopisma

• Napisz do nas [email protected]

# Kolejne spotkanie: 19 kwietnia 2012

Strefa Wiedzy Lidera IT

Strefa Wiedzy Lidera IT 3

mailto:[email protected]

www.bnsit.pl

# 1-2 h konsultacji

• Omówienie problemów

• Wspólne pomysły na rozwiązania

• Dalsza współpraca

# Kupon do portalu DevCastZone.com

# Książka Eseje o efektywności programistów

Tylko dla uczestników tego spotkania


http://devcastzone.com/

www.bnsit.pl

# Jak zdefiniowad proces ewolucji architektury?

# Jak wdrożyd ten proces?

# Jak określid zakres odpowiedzialności architekta?

# Jak powiązad proces ewolucji architektury z cyklem produkcyjnym w organizacji?

# Jak rozwijad architekturę w nowych i istniejących projektach?

# Jak zarządzad wiedzą o architekturze i projektowaniu w

firmie?

Po co się spotkaliśmy?


www.bnsit.pl

1. Problemy z architekturą i konsekwencje

2. Idea ewolucji architektury

3. Modele organizacyjne i rola architekta

4. Proces ewolucji architektury

5. Jak wdrożyd proces?

6. Praktyki związane z architekturą w organizacji

Agenda


www.bnsit.pl

# 12.00 – 13.30 – sesja

# 13.30 – 13.45 – przerwa kawowa

# 13.45 – 15.15 – sesja

# 15.15 – 15.45 – przerwa lunchowa

# 15.45 – 17.00 – sesja

Harmonogram


www.bnsit.pl

Jak powstaje architektura? Ewolucyjna architektura


www.bnsit.pl

# Architektura jest tworzona na początku

# Opór przed zmianą architektury • Duży wpływ na resztę systemu

• Duży koszt

• Duże ryzyko

Najczęściej...

www.bnsit.pl

# Na początku będzie szybciej

Dlaczego tak się dzieje?


www.bnsit.pl

# Nie zdążymy zrobid wszystkiego, czego oczekuje klient



www.bnsit.pl

# Bywają naciski, aby wykonywad tylko to, co „widad”



Najważniejsze jest to, co nie widoczne dla oczu Mały Książę

www.bnsit.pl

# Ludzie sobie jakoś poradzą



www.bnsit.pl

A z tego wynika... Ewolucyjna architektura

www.bnsit.pl

# Może się okazad, że trzeba będzie zakopad system

Problem 1

www.bnsit.pl

# Rozwój systemu nie nadąża za potrzebami biznesowymi

Problem 2


www.bnsit.pl

# Demotywacja zespołu

Problem 3


www.bnsit.pl

# Coraz trudniej odnajdowad błędy

Problem 4


www.bnsit.pl

# Brak powtarzalnych rozwiązao i powielanie pracy

Problem 5


www.bnsit.pl

# Rozwój systemu to obsługa przypadków szczególnych

Problem 6


www.bnsit.pl

Podejścia do rozwoju architektury Ewolucyjna architektura

www.bnsit.pl

# Nic nie robid – „Ludzie sobie jakoś poradzą”

# Reagowanie na poważne problemy (blokery)

# Faza refaktoryzacji po implementacji

# Zarządzanie ewolucją architektury • Alokowanie zasobów na prace nad architekturą • Dodatkowe iteracje

# CDN…

Na razie hasłowo


www.bnsit.pl

Idea ewolucji architektury Ewolucja architektury

www.bnsit.pl

# Jeśli proces rozwoju architektury toczy się przypadkowo, to przypadkowe będą również efekty

Idea ewolucji architektury


www.bnsit.pl

Korzyści z ewolucji Ewolucyjna architektura

www.bnsit.pl

# Przetrwanie

Korzyść najważniejsza

www.bnsit.pl

# Architektura będzie się upraszczad

Korzyść 2


www.bnsit.pl

# Zmiana wymagao nie będzie aż taką tragedią

Korzyść 3


www.bnsit.pl

# Krótszy czas implementacji i poszukiwania błędów i niższy kosz utrzymania

Korzyść 4


www.bnsit.pl

# Nie będą potrzebni zewnętrzni konsultanci

Korzyść 5


www.bnsit.pl

ale...


www.bnsit.pl

# Nie jest istotne ulepszenie architektury jako

takiej, lecz rozwiązanie problemów

# Dla konkretnego przypadku potrzeba analizy biznesowej

# Konsultacje dla uczestników tego spotkania

Jakie „ale”?


www.bnsit.pl

# Rozwiązania architektoniczne powinny szybko zaradzid problemom

# Brak zdefiniowanego procesu pracy nad

architekturą

# Rozwój architektury powinien odbywad się w międzyczasie

Oczekiwanie: żeby było szybko



www.bnsit.pl

# Nie zmieniad od razu wszystkiego, lecz stopniowo tylko to, co konieczne

# Architektura powinna dojrzewad wraz z funkcjonalnościami systemu

# Zapominamy, że ewolucja również wymaga czasu

Oczekiwanie: ewolucyjnie nie rewolucyjnie



www.bnsit.pl

# Sprytny trik architektoniczny rozwiąże problemy

# Nie zmieniad zbyt wiele, a jedynie nieznacznie zmodyfikowad

# Nie potrzeba na to zbyt wiele wysiłku

Oczekiwanie: Dużo magicznych sztuczek



www.bnsit.pl

Modele organizacyjne Ewolucyjna architektura

www.bnsit.pl

# Lider architektury wyłania się samoczynnie

# Zazwyczaj jest to programista z największym doświadczeniem

# Istnieje niebezpieczeostwo, że nikt nie zainteresuje się architekturą

Trywialny model



www.bnsit.pl

Architekt Korporacyjny (Enterprise Architect)

Złożony model organizacyjny



Architekt Aplikacji (Software Architect)

www.bnsit.pl

# Przygotowywanie mapy systemów dla organizacji

# Opracowywanie infrastruktury programowej dla organizacji

Architekt Korporacyjny



# Szacowanie kosztu usunięcia/dodania systemu do/z infrastruktury

# Opracowywanie polityki i harmonogramu wdrożeo

www.bnsit.pl

# Dobieranie technologii do wymagao funkcjonalnych

# Zaprojektowanie sposobu działania, przechowywania i prezentacji danych w systemie

# Opracowanie sposobu egzekwowania zasad bezpieczeostwa przez system

# etc.

Architekt aplikacji



www.bnsit.pl

Jeszcze bardziej złożony model organizacyjny



www.bnsit.pl

# Główny Architekt (Chief Enterprise Architect) • Dba, by wdrażanie konkretnych rozwiązao wspierało

procesy biznesowe w organizacji • Przewodniczy Komitetowi Architektonicznemu

# Architekt Funkcjonalny • Łączy odpowiedzialności Analityka Biznesowego,

Analityka Funkcjonalnego i menadżera • Analizuje proces biznesowy i definiuje

funkcjonalności, do których powinni mied dostęp użytkownicy

• Określa, w których systemach powinny zostad zaimplementowane poszczególne funkcjonalności

Odpowiedzialności architektów



www.bnsit.pl

Architekt: stanowisko czy rola? Ewolucyjna architektura

www.bnsit.pl

Minusy stanowiska



# Wąskie specjalizacje poszczególnych osób

# Sztuczne oddzielanie myślenia o architekturze od programowania

# Powstawanie Power Point architects

# Tłumienie kreatywności programistów

www.bnsit.pl

Lider Architektury

# Bierze udział w pracach, ma kontakt z kodem

# Zbiera informacje o problemach z architekturą

# Zbiera pomysły na poprawę architektury

# Edukuje programistów w zakresie architektury

# Inicjuje zmiany w architekturze

# Opracowuje dokumentację oraz mantrę architektoniczną

# Dba o wymianę wiedzy technicznej w zespole



www.bnsit.pl

Skalowanie roli lidera architektury



www.bnsit.pl

Stanowisko może mieć znaczenie

# Daje możliwośd awansu

# Uatrakcyjnia CV

# Stanowisko architekt uważane jest za bardziej prestiżowe niż stanowisko programista



www.bnsit.pl

# Listy gratulacyjne za konkretne osiągniecia

# System certyfikacji wewnętrznej

# Kultura zdobywania sprawności na zasadzie Black Belt Factory

# Oddzielenie stanowisk od ról pełnionych w projekcie

Możliwe rozwiązania



www.bnsit.pl

1. Zespoły, które kodują także projektują system

2. Twórz najprostszą architekturę, która prawdopodobnie zadziała.

3. Kiedy nie masz pewności, spróbuj zakodowad fragment

rozwiązania lub zamodeluj.

4. Ci którzy piszą, testują.

5. Im większy system, tym dłuższy czas wydania.

6. Architektura jest efektem działania wszystkich osób

zaangażowanych w projekt.

7. Nie ma monopolu na innowacje.

8. Rozwijaj architekturę w sposób ciągły.

Zasady zwinnej architektury



www.bnsit.pl

Proces ewolucji architektury Ewolucyjna architektura

www.bnsit.pl

Założenia

# JIT (just in time) – zajmuj się tylko tym, co jest ważne teraz

# Zakłada się, że architektura będzie ewoluowad i zmieniad się w miarę postępu projektu

# Proces ewolucji architektury musi zostad zdefiniowany w organizacji


Proces rozwoju architektury

www.bnsit.pl

Proces ewolucji architektury



www.bnsit.pl

Najprostsza implementacja


www.bnsit.pl

Szczegóły procesu Ewolucja architektury

www.bnsit.pl

# W Koszyku przechowywane są pomysły (epics) na udoskonalenia w architekturze

# Kto może wrzucad do Koszyka? • Programiści • Testerzy • Liderzy architektury

# Jaką formę ma Koszyk? • Pudełko • Dedykowany adres mailowy • Lista mailingowa • Strona wiki • Tickety w systemie bugtracker

Koszyk



www.bnsit.pl

# Pomysł (epic) to luźne zdanie opisujące udoskonalenie w architekturze

# Przykłady

• Zastąpić Hibernate przez myBatis

• Wprowadzić loadbalancing

• Usunąć nieużywane funkcjonalności

# Pomysły muszą zostad podzielone

Koszyk: pomysły (architectural epics)



www.bnsit.pl

# Każdy pomysł oceniany jest pod kątem • Wartości biznesowej

• Kosztu stworzenia

• Pomysły powyżej ustalonego poziomu: wartość/koszt trafiają do Rejestru

• Pomysły poniżej poziomu są definitywnie odrzucane

# W jakich jednostkach ocenia się pomysły? • Wartośd: liczba całkowita, pieniądze

• Koszt: osobodni, pieniądze

• Jednostka względna: 2, 4, 8, 16, 32, 64, 128

Koszyk: Ocena pomysłu



www.bnsit.pl

# Przykładowy sposób wyliczania wskaźnika

Rozmiar zadania – 1, 2, 3, 5, 8, 13, 20, 40

Wartośd biznesowa – 1, 2, 3, 5, 8, 13, 20, 40

Dopasowanie do obecnych celów biznesowych – 0, ¼, ½, ¾, 1

Wskaźnik = (Wartość biznesowa/Rozmiar) * Dopasowanie




www.bnsit.pl

# Jak często pomysły są oceniane? • Regularnie, co ustalony odstęp czasu • Nieregularnie, gdy koszyk przekroczy założoną

pojemnośd • Wprowadza się dodatkowy wskaźnik czas życia

pomysłu w koszyku, aby zapobiec odraczaniu oceny pomysłów

# Ile pomysłów w koszyku? • maksymalnie 50-75

# Kto ocenia pomysły? • Liderzy architektury




www.bnsit.pl

# Pozycje rejestru (backlog items) są uporządkowane według wskaźnika

# Kto może dodawad pozycje do Rejestru? • Liderzy architektury • Jeden z liderów architektury

# Jaką formę ma Rejestr? • Plik arkusza kalkulacyjnego • Folder mailowy • Najistotniejszą cechą rejestru jest jego

uporządkowanie

Rejestr (backlog)



www.bnsit.pl

# Każda pozycja z Rejestru • Oceniana jest pod katem kosztu zaniechania • Ma aktualizowaną wartośd oraz koszt • Ma aktualizowany wskaźnik • Jeśli przebywa w Rejestrze ponad określony czas jest

z niego usuwana • Pozycja/e ze szczytu Rejestru przekazywane są do analizy

# Jak dużo elementów? • maksymalnie 20-25

# Jak często analizowany jest Rejestr? • W trakcie planowania wydania • Jeśli cykle produkcyjne są długie, to w trakcie planowania

kolejnego cyklu

Rejestr: Analiza Rejestru



www.bnsit.pl

# Celem Analizy jest opracowanie alternatyw projektowych oraz oszacowanie zasobów niezbędnych do wdrożenia danej pozycji

# Ile elementów? • maksymalnie 5-7

# Kto wykonuje analizę? • Lider komponentu

• Lider architektury

Analiza



www.bnsit.pl

# Funkcjonalności (potentially shippable increments) oraz architektura mają całkowicie inną charakterystykę rozwoju

# Proces ewolucji architektury musi promowad rozwój funkcjonalności, aby powiększad wartośd biznesową produktu

Zasada wartości biznesowej



www.bnsit.pl

Zasada wartości biznesowej

# Idea rozbudowy architektury: architectural slices of customer-centric features

# Kolejne slices architektury są wpisane w cykl zwiększania wartości biznesowej



www.bnsit.pl

# Interesariusze i sponsorzy • Kto odczuje korzyśd z wdrożenia tej zmiany?

# Wpływ na projekty • Na które projekty/produkty ma wpływ to wdrożenie? • Na które usługi ma wpływ to wdrożenie?

# Wpływ na procesy • Jaki ma to wpływ na sprzedaż? • Jaki ma to wpływ na dystrybucję produktów i usług?

# Koszt i zasoby • Jak bardzo czasochłonny jest ten temat? • Ile osób, o jakich kompetencjach i przez jaki czas potrzeba na

wdrożenie tej zmiany?

Analiza: Zrąb raportu biznesowego



www.bnsit.pl

KRYTYCZNE cechy procesu Ewolucja architektury

www.bnsit.pl

# Widoczne konsekwencje wprowadzanych zmian

# Kontrolowane ryzyko

Minimalizuj liczbę jednocześnie wykonywanych zadań

www.bnsit.pl

# Możliwie szybko dąż do zakooczenia i wdrożenia zmian

Koncentracja wysiłków

www.bnsit.pl

# W widocznych miejscach

# Co wizualizowad? • Koszyk, Rejestr, zadania w toku • Prosty diagram HLD

Wizualizuj postępy prac

www.bnsit.pl

Wdrażanie – dodatkowe iteracje Ewolucyjna architektura

www.bnsit.pl

Iteracyjny proces pracy zespołu



# Cele procesu iteracyjnego • Stopniowe odkrywanie potrzebnych funkcjonalności i

ich ciągłe dostarczanie • Koncentracja na wartości biznesowej • Dbanie o jakośd wytwarzanego kodu • Stymulowanie innowacji w architekturze

www.bnsit.pl

Iteracja „0”


Wstępne określenie wymagao

(dni)

Wstępne określenie architektury

(dni)

Iteracja 0: Wizualizacja

# Przygotowanie do kolejnego wydania

# Stworzenie podwalin architektury

# Wybranie z Rejestru pozycji do realizacji

# Określenie celu wydania

# Określenie listy wymagao do implementacji


www.bnsit.pl

Iteracja „0”: Wstępne modelowanie

# Szkic technologii

# Ekrany użytkownika

# Model konceptualny

# Przypadki zmian



www.bnsit.pl

Iteracja zakańczająca (Hardening Iteration)

# Cel iteracji: spłacenie części długu technicznego występującego w kodzie

# Działania podejmowane w trakcie iteracji

• Implementowanie pozycji Rejestru, dla których nie było miejsca w standardowych iteracjach

• Poprawianie czytelności kodu

• Doprowadzanie kodu do stanu, w którym spełnia on przyjęte normy jakości



www.bnsit.pl

Iteracja innowacji (Hackathon Iteration)

# Cel iteracji: stymulowanie innowacji w obszarze architektury

# Działania podejmowane w trakcie iteracji • Eksperymentowanie z nowymi technologiami pod

kątem użyteczności dla organizacji

# Korzyści z Iteracji innowacji • Czas na „złapanie oddechu” dla zespołu • Generuje nowe innowacyjne pomysły • Pomaga programistom byd „na czasie” i poprawia

motywację



www.bnsit.pl

# Wydania i iteracje nie muszą (i zazwyczaj nie są) zorganizowane szeregowo

# Gdy prace w jednym cyklu są wygaszane, rozpoczynają się wstępne prace w kolejnych

Iteracje i wydania



www.bnsit.pl

Wdrażanie – alokacja zasobów Ewolucyjna architektura

www.bnsit.pl

# W ramach przydzielania zasobów częśd prac przewiduje się na rozwój architektury

# Początkowo można przyjąd 10-15% OD

Alokacja czasu na prace architektoniczne

www.bnsit.pl

Wdrażanie – DUŻA refaktoryzacja Ewolucyjna architektura

www.bnsit.pl

# Wydzielenie czasu (np. iteracji) tylko na rozwój architektury

# Duże ryzyko zaniechania prac ze względu brak szybkich efektów

# Duże wyzwanie na poziomie integracyjnym # Zatrzymanie rozwoju produktu

Duża refaktoryzacja

www.bnsit.pl

Wdrażanie – przepisanie systemu Ewolucyjna architektura

www.bnsit.pl

# Istnieją dwie linie produktu (duży koszt utrzymania spójności)

# Przy nowej technologii – duży koszt pozyskania kompetencji

# Przepisanie młodego systemu zajmuje 20-25% pierwotnego czasu

Przepisanie systemu

www.bnsit.pl

Wdrażanie – usuwanie wąskich gardeł Ewolucyjna architektura

www.bnsit.pl

Usuwanie wąskich gardeł

Lider architektury/zespoły

# wiedzą, gdzie są wąskie gardła

# należy wybrad te 2-3 zmiany, które będą miały największy efekt

www.bnsit.pl

Wdrażanie – izolowanie starego kodu Ewolucyjna architektura

www.bnsit.pl

Izolowanie starego kodu

# Znacząca częśd kodu jest stabilna

# Mimo że słabo napisana lub oparta na starej technologii

# Opakuj stabilną częśd systemu warstwą izolacyjną

# Odizoluj nowe funkcjonalności

www.bnsit.pl

Wdrażanie - arkusz pytań Ewolucyjna architektura

www.bnsit.pl

Arkusz pytań – definiowanie procesu

www.bnsit.pl

Praktyki Proces rozwoju architektury

www.bnsit.pl

Spotkanie rozpoczynające



www.bnsit.pl

# Cel: zbudowanie wspólnego rozumienia produktu, który należy dostarczyd

# Kto bierze udział w spotkaniu?

• Osoby, które będą wykonywad prace

# Jak często odbywa się spotkanie? • Przed rozpoczęciem prac nad kolejnym wydaniem

• W razie potrzeby w mniejszym gronie w trakcie trwania prac

Spotkanie rozpoczynające



www.bnsit.pl

# Przedstawiciel sponsora

• Określenie celu wydania

• Odpowiadanie na pytania

# Liderzy komponentów

• Analizowanie wpływu wymagania na architekturę komponentu

• Zgłaszanie sugestii

Spotkanie rozpoczynające: odpowiedzialności osób



www.bnsit.pl

# Lider architektury

• Analizowanie wpływu wymagania na architektury systemu


# Lider testerów

• Określenie zakresu testów akceptacyjnych





www.bnsit.pl

# Programista (opcjonalnie)

• Wykrywanie zagadnieo i niespójności, które mogą wyniknąd w trakcie implementacji


# Użytkownik (opcjonalnie)

• Zgłaszanie uwag nt. ergonomii interfejsu użytkownika i komfortu pracy





www.bnsit.pl

# Ustalanie architektury w trakcie Iteracji „0”

# Uaktualnianie architektury na początku iteracji

# Spontaniczne warsztaty w razie potrzeby (just-in-time)

# Narzędzia • Tablica ścieralna (im większa tym lepsza) • Folia elektrostatyczna (np. HandyChart) • Flamastry

Warsztaty projektowania



www.bnsit.pl

# Liderzy aranżują miniszkolenia dotyczące architektury systemu

# Wiedza jest naturalnie rozprzestrzeniana w zespołach (human infection)

# Istotniejsze fragmenty można przechowywad na wiki jako fotografie

# Również warsztaty międzyzespołowe

Warsztaty projektowania: rozprzestrzenianie wiedzy


A single conversation with a wise man is better than ten years of study


www.bnsit.pl

# Spójny język dziedziny • „Metryczka” to….

• „Odzysk” to…

• „Pudełko” to…

# Spójny język techniczny • „Użyjmy tu fabryki konfigurowanej przez fluent api”

• „Ten adpater nie powinien znajdowad się w warstwie serwisów, lecz niżej zaraz nad domeną

• Programiści posługują się konceptami – językiem na wyższym poziomie abstrakcji

Warsztaty projektowania: ujednolicanie języka



www.bnsit.pl

Dream Team



www.bnsit.pl

# Najlepsi ludzie, najbardziej zgrany zespół rozpędza projekt

# Czym kooczą się prace Dream Team? • Szkielet systemu • Ustalona architektura • Dokumentacja architektury systemu

# Co dalej? • Uczestnicy Dream Team organizują kolejne zespoły • Uczą programistów i rozprzestrzeniają wiedzę (human

infection) • Prowadzą Warsztaty projektowania

Dream Team



www.bnsit.pl

# Architekt, który nie dotyka kodu zaczyna fantazjowad

# Niektóre decyzje architektoniczne są już nieaktualne - uważaj na chorobliwą konsekwencję w ich podtrzymywaniu

# Jeśli możesz wybierad zmiany architektoniczne do wdrożenia, to wybieraj te, które mają największy wpływ na poprawę projektu

Architekci i architektura



www.bnsit.pl

# Możliwe problemy • Duży narzut czasu na przygotowanie

dokumentacji projektu

• Zespół długo oczekuje na odpowiedź Komitetu

• Projekt prawie na pewno zostanie zwrócony do poprawy

# Zamiast tego • Projekt (dokument) zostaje przygotowany i

zaakceptowany podczas warsztatów projektowych z liderem architektury

Ostrożnie z Komitetem Architektonicznym



www.bnsit.pl

# Polecamy szkolenie

Projektowanie architektury aplikacji biznesowych http://www.bnsit.pl/szkolenie,projektowanie-architektury-aplikacji-

biznesowych

Lider architektury


http://www.bnsit.pl/szkolenie,projektowanie-architektury-aplikacji-biznesowych










Technology

Ewolucyjna architektura (Spotkanie Strefy Wiedzy Liderów IT)