Ewolucyjna architektura (Spotkanie Strefy Wiedzy Liderów IT)

Ewolucyjna architektura

www.bnsit.pl
www.sxc.hu/photo/850368

Imię i nazwisko
Firma
3 słowa o sobie

Poznajmy się!
www.bnsit.pl

Strefa Wiedzy Lidera IT

# 1. spotkanie 16 września

# W prasie
• Artykuły w czasopiśmie Programista
• Strefa Wiedzy Lidera IT na portalu czasopisma
• Napisz do nas liderit@bnsit.pl

# Kolejne spotkanie: 19 kwietnia 2012

www.bnsit.pl Strefa Wiedzy Lidera IT 3

Tylko dla uczestników tego spotkania

# 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


Po co się spotkaliśmy?

# 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?

Agenda

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


Harmonogram

# 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

Jak powstaje architektura?


Najczęściej...

# Architektura jest tworzona na początku

# Opór przed zmianą architektury
• Duży wpływ na resztę systemu
• Duży koszt
• Duże ryzyko
www.bnsit.pl

Dlaczego tak się dzieje?

# Na początku będzie szybciej



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



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

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


# Ludzie sobie jakoś poradzą


A z tego wynika...

www.bnsit.pl

Problem 1

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

www.bnsit.pl

Problem 2

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


Problem 3

# Demotywacja zespołu


Problem 4

# Coraz trudniej odnajdowad błędy


Problem 5

# Brak powtarzalnych rozwiązao i powielanie
pracy


Problem 6

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


Podejścia do rozwoju architektury

www.bnsit.pl

Na razie hasłowo

# 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…

Idea ewolucji architektury
Ewolucja architektury

www.bnsit.pl

Idea ewolucji architektury

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

Korzyści z ewolucji

www.bnsit.pl

Korzyść najważniejsza

# Przetrwanie

www.bnsit.pl

Korzyść 2

# Architektura będzie się upraszczad


Korzyść 3

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


Korzyść 4

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


Korzyść 5

# Nie będą potrzebni zewnętrzni konsultanci


ale...


Jakie „ale”?

# Nie jest istotne ulepszenie architektury jako
takiej, lecz rozwiązanie problemów

# Dla konkretnego przypadku potrzeba analizy
biznesowej

# Konsultacje dla uczestników tego
spotkania


Oczekiwanie: żeby było szybko

# Rozwiązania architektoniczne powinny szybko
zaradzid problemom

# Brak zdefiniowanego procesu pracy nad
architekturą

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



Oczekiwanie: ewolucyjnie nie rewolucyjnie

# 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: Dużo magicznych sztuczek

# Sprytny trik architektoniczny rozwiąże
problemy

# Nie zmieniad zbyt wiele, a jedynie
nieznacznie zmodyfikowad

# Nie potrzeba na to zbyt wiele wysiłku


Modele organizacyjne

www.bnsit.pl


Trywialny model

# Lider architektury wyłania się
samoczynnie

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

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


Złożony model organizacyjny

Architekt Korporacyjny
(Enterprise Architect)

Architekt Aplikacji
(Software Architect)



Architekt Korporacyjny

# Przygotowywanie mapy
systemów dla organizacji
# Opracowywanie infrastruktury
programowej dla organizacji

# Szacowanie kosztu usunięcia/dodania systemu
do/z infrastruktury
# Opracowywanie polityki i harmonogramu
wdrożeo



Architekt aplikacji

# Dobieranie technologii do
wymagao funkcjonalnych
# Zaprojektowanie sposobu
działania, przechowywania
i prezentacji danych
w systemie
# Opracowanie sposobu egzekwowania zasad
bezpieczeostwa przez system
# etc.



Jeszcze bardziej złożony model organizacyjny



Odpowiedzialności architektów

# 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


Architekt: stanowisko czy rola?

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



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


Skalowanie roli lidera architektury



Stanowisko może mieć znaczenie

# Daje możliwośd awansu

# Uatrakcyjnia CV

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



Możliwe rozwiązania

# 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


Zasady zwinnej architektury

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.

Proces ewolucji architektury

www.bnsit.pl

Proces rozwoju architektury

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 ewolucji architektury


Najprostsza implementacja


Szczegóły procesu

www.bnsit.pl


Koszyk

# 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: pomysły (architectural epics)

# 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: Ocena pomysłu

# 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




# 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




# 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?


Rejestr (backlog)

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

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

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


Rejestr: Analiza Rejestru

# 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


Analiza

# 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


Zasada wartości biznesowej

# 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

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

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



Analiza: Zrąb raportu biznesowego

# 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?


KRYTYCZNE cechy procesu

www.bnsit.pl

Minimalizuj liczbę jednocześnie wykonywanych zadań

# Widoczne konsekwencje wprowadzanych
zmian

# Kontrolowane ryzyko
www.bnsit.pl

Koncentracja wysiłków

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

www.bnsit.pl

Wizualizuj postępy prac

# W widocznych miejscach

# Co wizualizowad?
• Koszyk, Rejestr, zadania w toku
• Prosty diagram HLD
www.bnsit.pl

Wdrażanie – dodatkowe iteracje

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


Iteracja „0”

Wstępne określenie Wstępne określenie
wymagao architektury
(dni) (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


Iteracja „0”: Wstępne modelowanie

# Szkic technologii
# Ekrany użytkownika
# Model konceptualny
# Przypadki zmian



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



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ę



Iteracje i wydania

# 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

Wdrażanie – alokacja zasobów

www.bnsit.pl

Alokacja czasu na prace architektoniczne

# W ramach przydzielania zasobów częśd prac
przewiduje się na rozwój architektury
# Początkowo można przyjąd 10-15% OD

www.bnsit.pl

Wdrażanie – DUŻA refaktoryzacja

www.bnsit.pl

Duża refaktoryzacja

# 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
www.bnsit.pl

Wdrażanie – przepisanie systemu

www.bnsit.pl

Przepisanie systemu

# 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
www.bnsit.pl

Wdrażanie – usuwanie wąskich gardeł

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

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ń

www.bnsit.pl

Arkusz pytań – definiowanie procesu

www.bnsit.pl

Praktyki

www.bnsit.pl


Spotkanie rozpoczynające



Spotkanie rozpoczynające

# 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: odpowiedzialności osób

# Przedstawiciel sponsora
• Określenie celu wydania
• Odpowiadanie na pytania

# Liderzy komponentów
• Analizowanie wpływu wymagania na architekturę
komponentu
• Zgłaszanie sugestii




# Lider architektury
• Analizowanie wpływu wymagania na architektury
systemu

# Lider testerów
• Określenie zakresu testów akceptacyjnych




# 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



Warsztaty projektowania

# 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: rozprzestrzenianie wiedzy

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

# 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: ujednolicanie języka

# 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



Dream Team



Dream Team

# 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



Architekci i architektura

# 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



Ostrożnie z Komitetem Architektonicznym

# 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

Lider architektury

# Polecamy szkolenie

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


Ewolucyjna architektura (Spotkanie Strefy Wiedzy Liderów IT)

Recommandé

Recommandé

Contenu connexe

Similaire à Ewolucyjna architektura (Spotkanie Strefy Wiedzy Liderów IT)

Similaire à Ewolucyjna architektura (Spotkanie Strefy Wiedzy Liderów IT) (20)

Ewolucyjna architektura (Spotkanie Strefy Wiedzy Liderów IT)