Najlepsze praktyki
Wspólny język
Jednym z najważniejszych czynników sukcesu wdrożenia LAF, a co za tym idzie, uzyskania dobrej jakości architektury, jest wypracowanie wraz z biznesem i programistami wspólnego języka. Odpowiednio zbudowany język pozwala na prowadzenie dyskusji o architekturze przedstawicieli biznesu między sobą lub z ludźmi z działu IT.
Język ten powinien być prosty i opierać się na prostej definicji tego, czym są komponent i capabilities oraz w jaki sposób określamy przyszłość danego obszaru biznesowego.
Zalecamy stosowanie koncepcji DD (projektowanie oparte na domenie) jako metody tworzenia odpowiedniego języka komunikacji
Podział
Większość dużych organizacji ma złożony model biznesowy, oparty na mnogości produktów, usług lub procesów. W takich organizacjach warto, by architektura referencyjna była przygotowywana dla danego obszaru biznesowego. Całość architektury referencyjnej należy podzielić, najlepiej zgodnie z podziałem struktury organizacyjnej lub na różne strumienie wartości (value stream), i każdą z części opracowywać oddzielnie. W ten sposób powstają dla danej domeny biznesowe architektury referencyjne.
Architecture Log
W związku z tym, że organizacja się zmienia, a w szczególności następuje rotacja pracowników, bardzo ważne jest, żeby istniała baza wiedzy o uzasadnieniu podjętych decyzjach. Pozwala to na utrzymanie ciągłości działań i konsekwentne dążenie do celu. Architecture Log jest bazą, w której powinny być przechowywane między innymi tak ważne decyzje jak:
- decyzja o wyborze zakupu nowej technologii lub aplikacji,
- akceptacja wyjątku od Architektury Referencyjnej lub Standardu,
- publikacja AR lub standardów,
- eliminacja aplikacji ze środowiska.
Continuous improvement sessions
Co 2-4 tygodnie powinna odbywać się sesja ciągłego doskonalenia dla architektów. Spotkanie powinno trwać od 1,5 godziny do 3 godzin. Sesja retrospekcji jest dobrze znana w Agile Ways Of Working i bardzo dobrze opisana w publicznie dostępnych materiałach, dlatego właśnie konkretna technika powinna zostać zaadoptowana z tego świata i nie będzie omawiana w tym materiale. Jeśli organizacja stosuje już zwinne podejście, zaleca się sięgnięcie po techniki dobrze jej znane. Ważne jest aby zauważyć, że architekci powinni brać udział w retrospekcjach dotyczących dostarczania oprogramowania niezależnie od Architektonicznych sesji ciągłego doskonalenia wnosząc wszelkie globalne wnioski na to spotkanie.
Przykładowym wynikiem sesji może być: zmiana w modelu oceny komponentów, zmiana w szablonie SV.
Szybka ścieżka
Nie w każdej inicjatywie powinna być tworzona Solution Vision. Inicjatywy w ramach jednej istniejącej aplikacji, które nie zmieniają jej capabilities, powinny być realizowane szybką ścieżką.
Antywzorce
Architektura docelowa
Głównym problemem prowadzącym do nieudanej implementacji LAF jest niezrozumienie, czym jest Architektura Referencyjna. Bardzo często zostaje ona zinterpretowana jako duża wizja zmiany transformacyjnej, nazywana programem wraz z harmonogramem, szacowaniem budżetu i innymi elementami projektowymi. Staje się celem bardzo odległym, w większości wieloletnim. Pociąga to za sobą wszystkie konsekwencje projektowania środowiska aplikacyjnego w zmieniającym się równolegle biznesie. W większości przypadków program transformacji jest porzucany przy pierwszym dużym problemie w procesie dostarczania. Wtedy też porzucana jest cała architektura. LAF wspiera stopniowe dążenie do architektury referencyjnej, która zmienia się wraz ze zmieniającą się sytuacją biznesową.
Projektowanie aplikacji
Architekci niebędący deweloperami danej aplikacji i niepracujący bezpośrednio przy implementacji nie powinni projektować implementacji funkcjonalności w danej aplikacji. Za projekt techniczny odpowiedzialne są zespoły, które poszczególne funkcjonalności uzgadniają z biznesem i w sposób odpowiedni dla nich je implementują. Architekci powinni zbudować podstawy do realizacji funkcjonalności w postaci wytycznych co do API, sposobu integracji i dużych zmian technologicznych. Najbardziej efektywnym modelem wdrażania architektury jest udział architektów w życiu zespołów programistycznych. Udział ten zależy od rodzaju projektu i jego etapu. Na początku projektu zalecamy ścisłą współpracę Architekta z zespołem deweloperskim. Na późniejszych etapach Architekt powinien w razie potrzeby wspierać zespół.
Architektura poza procesem dostarczania zmian biznesowych
Jeśli architekci nie są umieszczeni w procesie dostarczania oprogramowania i nie pracują z biznesem ani deweloperami, to w konsekwencji izolowani są od wiedzy, która wpływa na środowisko aplikacyjne i od wiedzy o stanie tego środowiska. W praktyce nie jest wtedy możliwe śledzenie ani realizacja architektury referencyjnej. Zespoły aplikacyjne będą kształtować środowisko w sposób odpowiedni z punktu widzenia aplikacji, którą tworzą, nie widząc szerszego kontekstu. Z kolei biznes pracujący z konkretnymi wymaganiami skupi się na realizacji celów krótkoterminowych. Architekci muszą pracować w procesie rozwoju aplikacji, by móc je kreować i nadzorować zmiany.
Architektura jako wąskie gardło
Zbyt obszerne dokumentowanie procesów i elementów, a w konsekwencji ogromny nakład pracy architektów spowoduje, że architektura stanie się wąskim gardłem. proje Bardzo szybko następstwem tego faktu będzie pominięcie aspektów architektonicznych. Wszystkie repozytoria powinny być budowane na poziomie minimalnego spełnienia wymagań i zawierać tylko informacje potrzebne interesariuszom praktyk architektonicznych oraz SDLC
Narzędzia
LAF jest zbiorem dobrych praktyk niezależnym od narzędzi lub ich braku. LAF można zaimplementować, używając jedynie Excela. Bardzo dobrym pomysłem jest jednak automatyzacja niektórych procesów i przechowanie danych w repozytoriach posiadających większe możliwości analizy. Rekomendujemy budowę i posiadanie:
- repozytorium w postaci centralnej bazy danych dającego możliwość pracy wielu osobom, w tym zespołom aplikacyjnym;
- portalu architektury zawierającego informacje o standardach, architecture log i architekturze referencyjnej;
- aplikacji automatyzującej zbieranie ankiet od użytkowników końcowych aplikacji;
- narzędzia do automatyzacji zbierania informacji o aplikacji, np. z systemów statycznej analizy kodu czy bug trackerów;
- narzędzi do automatyzacji zbierania metryk.