Elementy LAF

    LAF składa się z trzech głównych części:

• DEFINITION – jest to część, w której architekci wraz z innymi osobami w organizacji tworzą produkty będące podstawą do realizacji architektury:
  • REFERENCE ARCHITECTURE (RA) – oczekiwany kształt portfela aplikacji, który ma wspierać zmieniający się biznes; 
  • STANDARDS (ST) – standardy pozwalające utrzymać środowisko aplikacyjne w stanie pozwalającym na przewidywalne zarządzanie;
  • Zbiór COMPONENT PASSPORT (CP) – aktualny stan portfela aplikacji ułatwiający podejmowanie decyzji o tym, czy komponent nadaje się do rozwoju. Składa on się ze zbioru opisów stanu komponentów
• EXECUTION – w tej części architektura jest implementowana poprzez udział architektów w procesie budowy oprogramowania (SDLC). Architekci opisują wizję rozwiązania odpowiadającą na wymagania biznesu i jednocześnie ich zgodność  z wytycznymi dla architektury.
• IMPROVEMENT and MONITORING to najmniejsza część LAF mająca istotny wpływ na całość architektury w organizacji. Jej zadaniem jest obserwacja jakości architektury i procesów architektonicznych, a w kolejnym kroku usprawnienia w tych obszarach.

Częścią wspólną dla wszystkich elementów jest ARCHITECTURE REPOSITORY (REPO) – baza, w której umieszczane są poszczególne produkty. Stanowi ona także źródło informacji do podejmowania decyzji przy tworzeniu wizji rozwiązania.

Całością architektury zarządza i buduje grupa architektów zebranych w formalny zespół, który odbywa cykliczne spotkania zwane ARCHITECTURAL FORUM (FORUM). Efektywna praca tego zespołu jest najważniejszym czynnikiem wpływającym na jakość architektury. W związku z tym LAF wprowadza też praktyki związane z organizacją pracy.

Całość LAF została zobrazowana na poniższym diagramie.

Artefakty

Reference Architecture

Reference Architecture to długoterminowy, wysokopoziomowa wizja architektoniczna dla danego obszaru biznesowego, w oparciu o którą wszystkich dalszych rozwiązań (Solution Vision) będą tworzone. Jest to kierunek i wytyczne dla decyzji architektonicznych, stan „TO BE”, który najprawdopodobniej nigdy nie zostanie osiągnięty. Wynika to ze zmieniającego się biznesu, a co za tym idzie, zmieniającej się architektury referencyjnej. RA może być zmieniona przed jej realizacją lub  osiągnięciem. W pełni udostępnia potencjał biznesowy, realizując jego cele i potrzeby zapewnienia zgodności z misją i strategią firmy. Ustanawia podstawę techniczną dla dalszego rozwoju organizacji. Suma wszystkich architektur referencyjnych tworzy architekturę referencyjną dla całej organizacji.

Jest to lekka architektoniczna wizja pożądanego stanu środowiska aplikacji, do którego będzie się dążyć w dłuższej perspektywie. Zwykle zawiera schemat z komponentami, capabilities i interakcjami między nimi. Powinna również zawierać krótki opis każdego komponentu oraz korzyści wynikających z jej implementacji. Podczas jej tworzenia nie są przyjmowane żadne założenia dotyczące zasobów. Nie obejmuje żadnego stanu pośredniego ani informacji o tym, jak zostanie to osiągnięte. 

Jest tworzony w ścisłej współpracy z jednostką biznesową i innymi zainteresowanymi stronami, w pierwszej kolejności odpowiada na ich potrzeby. Dlatego ważne jest aby była utworzona za pomocą  łatwo zrozumiałego języka, oraz posiadała spójną formę. AR uwzględnia trendy biznesowe, a także trendy technologiczne i może stworzona w odniesieniu do architektury branżowej, jeśli taka jest dostępna. Uwzględnia pełny potencjał biznesowy, realizując jego cele i potrzeby, zapewniając zgodność z misją i strategią firmy. Stanowi techniczną podstawę dla dalszego rozwoju organizacji. Agregacja wszystkich architektur referencyjnych tworzy widok architektury całej organizacji.

REFERENCE ARCHITECTURE jako zbiór capabilities środowiska aplikacyjnego stanowi cel dla zmian architektonicznych. Każde wdrożenie aplikacji powinno zbliżać całość środowiska do osiągnięcia tego celu. RA ulega zmianom ze względu na zmiany rynkowe i wewnętrzne organizacji. Ciągłe zmiany w dążeniu do zmieniającego się celu są sednem Continuous Transformation. Całość została zobrazowana na poniższym diagramie. 

Tworzenie REFERENCE ARCHITECTURE zwykle koncentruje się na konkretnej jednostce biznesowej. Architekt jest odpowiedzialny za tworzenie RA w ścisłej współpracy z jednostką biznesową odpowiadając na ich potrzeby w pierwszej kolejności poprzez , organizację serii warsztatów, aby dogłębnie zrozumieć potrzeby dziedziny  biznesowej. 

Podczas tworzenia RA architekci mają możliwość a nawet więcej – są zobowiązani do proponowania innowacyjnych rozwiązań i wsparcia biznesu przy wdrażaniu nowoczesnych rozwiązań.

Tworzenie i utrzymywanie architektury referencyjnej to ciągła praca, która może zależeć od różnych czynników, takich jak nauka płynąca z jej implementacji, zmiany strategii biznesowych i technologicznych, zmiany warstwy technologicznej lub przepisów prawnych lub presji rynku itp. Dlatego RA powinna być dostosowywana w zależności od wystąpienia powyższych czynników, niezależnie od ich wystąpienia RA powinna zostać poddana przeglądowi oraz aktualizacji nie rzadziej niż raz w roku   celem zachowania  aktualności.

Standards

Wydajne i przewidywalne zarządzanie środowiskiem IT wymaga aby architektura aplikacji była spójna na wielu płaszczyznach. Utrzymanie ujednoliconych elementów w środowisku aplikacyjnym pozwala nie tylko ograniczyć chaos w architekturze, ale też przyspieszyć podejmowanie decyzji w obszarach objętych standaryzacją. Standardy tworzą bezpieczną przestrzeń do eksperymentów dla zespołów zaangażowanych w rozwój i utrzymanie oprogramowania.

Narzędziem utrzymania tego porządku są formalne artefakty, np. dokumenty czy strony Wiki opisujące te standardy, ograniczenia i wymagane modele realizacji funkcjonalności w środowisku IT. 

Standaryzacja ta powinna być zrealizowana na minimalnym potrzebnym poziomie i ograniczać się do najważniejszych wymagań. Celem jest znalezienie takiego zestawu standardów, który wytworzy spójne środowisko, a jednocześnie nie ograniczy innowacyjności.

Najważniejsze  typy standardów które należy opracować  to:

• spójność technologii – ograniczenie ilości technologii w organizacji do zdefiniowanej listy i utrzymanie spójności co do wersji wszystkich jej elementów,
• spójność integracji – ujednolicenie i zdefiniowanie dobrych praktyk integracji międzysystemowej, 
• spójność monitorowania i logowania – ujednolicenie procesu logowania i monitorowania zdarzeń systemowych i biznesowych w środowisku aplikacyjnym, 
• spójność w zarządzaniu danymi – ujednolicenie sposobu zarządzania danymi w zakresie budowy modeli, ich spójności i odpowiedzialności za to systemów.

Tworzenie

Budowa i uaktualnianie standardów powinno być oparte na cyklicznych działaniach, np. raz na rok, w którym zespół złożony z architektów przygotowuje treść standardu, później uzgadnianą z zainteresowanymi stronami. Na przykład szczegóły standardu technologicznego, dotyczące używanego języka programowania, powinny być ustalone z zespołami deweloperskimi, które używają tej technologii. Standardy powinny być dostępne i komunikowane wszystkim zainteresowanym stronom łącznie z dostawcami.

Component Portfolio Assement(CPA)

Kolejną bardzo ważną praktyką jest gromadzenie i ocena informacji o aktualnym stanie Komponentów oraz przechowywanie ich w Paszporcie Komponentu.

Component Passport(CP)  zawiera wszystkie istotne informacje o stanie komponentu, jest syntetyczną informacją potrzebną architektowi do szybkiego poznania podstawowych informacji o nim, w szczególności powinien zawierać krótki opis funkcjonalności oraz podstawowe informacje techniczne. Należy go wypełniać i odświeżać podczas każdej iteracji CPA, która zbiera dane w 3 podstawowych kategoriach: biznesowa, techniczna i finansowa. Informacje te są gromadzone w celu określenia, jaka powinna być przyszłość Komponentu. Wszystkie zebrane informacje są przechowywane w Component Passport (CP)

W perspektywie biznesowej aplikacja oceniana jest pod kątem znaczenia w procesach biznesowych. W kategorii technicznej oceniana jest jakość kodu, jakość procesów dostarczania i  zgodność technologii ze standardami. 

Perspektywa finansowa to ocena kosztów komponentu w zakresie licencji, infrastruktury, utrzymania i kosztów rozwoju. Im niższe koszty, tym komponent jest lepiej oceniany. Kontekst finansowy oceny powinien oprzeć się na uśrednionych wartościach występujących w organizacji. Przy obliczaniu oceny wynik może być oparty na przykład na 5-stopniowej skali, niekoniecznie  na rzeczywistych wartościach.

          Ostatecznie każda z aplikacji powinna trafić do jednej z czterech grup przeznaczenia:

•  inwestycja – komponent oceniony technicznie bardzo dobrze i mający duże znaczenie biznesowe. Komponenty te przeznaczone są do rozwoju.
•  migracja – komponent oceniony technicznie źle i mający duże znaczenie biznesowe. W komponentach tych niezbędne jest przeniesienie funkcjonalności do innych aplikacji.
•  tolerowanie – komponent oceniony technicznie bardzo dobrze, ale mający małe znaczenie biznesowe. Komponenty te ze względu na niski koszt i dobry stan techniczny utrzymuje się w środowisku.
•  eliminacja – komponenty w złym stanie technicznym, z funkcjonalnościami, które są nieistotne lub pokryte przez inne aplikacje, powinny być przeznaczone do wygaszenia.

Przydział do kategorii jest istotny w przypadku porównania, w której z dwóch aplikacji powinien nastąpić rozwój jeśli dwie aplikacje mają redundantne funkcjonalności.

Uzupełnianie bazy powinno być cykliczne.  Zaleca się, by jednym ze składników oceny była ocena użytkowników końcowych uzyskana poprzez ankiety oceniające zadowolenie z  pracy z daną aplikacją. Dobrą praktyką jest zastosowanie Net Promoter Score (NPS) w ich ocenie.

Ostateczna ocena krytycznych biznesowo aplikacji powinna być szczegółowo omówiona, uzgodniona i zaakceptowana przez stronę biznesową. Zespół techniczny powinien zadbać o regularną aktualizację  komponentów

Cechy techniczne komponentu powinny być na bieżąco uzupełniane przez zespół deweloperski.

Ocena powinna zawierać następujące kolejne kroki:

• ocena techniczna aplikacji przez architekta,
• ocena użytkownika aplikacji,
• ocena finansowa, 
• ocena biznesowa aplikacji przez właściciela biznesowego,
• kategoryzacja aplikacji, 
• komunikacja o zmianie przypisania aplikacji do kategorii, jeśli dotyczy

Solution Vision

Solution Vision (SV) wysokopoziomowy projekt architektoniczny, który odpowiada na bieżące potrzeby biznesowe. Zmiany w warstwie architektonicznej są ich integralną częścią. Solution Vision jest  zawsze  powiązany z wartość biznesową, ponieważ zmiany w architekturze nigdy nie są celem samym w sobie. Solution Vision krok po kroku wprowadza zmiany dążąc do  architektury referencyjnej. To prawdziwe serce stopniowej, ciągłej transformacji organizacji w zakresie architektury aplikacji. W niektórych przypadkach może zawierać zmiany, takie jak wdrożenie nowego komponentu lub aplikacji, przeniesienie Capabilities z jednego komponentu do drugiego, wycofywanie aplikacji lub komponentu, technologii lub Capabilities, migracje itp.

Jednym z najważniejszych elementów dobrego SV jest zaangażowanie programistów w jego tworzenie. Skuteczna współpraca architekta z programistami / devopsami / administratorami jest kluczowa dla zapewnienia wysokiej jakości architektury i jej efektywnego wdrożenia. Zrozumienie założeń przedstawionych przez architekta powinno być budowane poprzez udział architekta w codziennym życiu zespołu deweloperskiego.

W kontekście budowanie SV  architekt wraz biznesem  jest odpowiedzialny za tworzenie wysokiej jakości wymagań niefunkcjonalnych (NFR), w tym wymagań bezpieczeństwa. Architekt powinien mieć pewność, że budowane przez niego rozwiązanie bazuje na dobrym NFR.

Tworzenie SV 

Tworzenie Solution Vision jest wbudowane w SDLC organizacji i zawsze jest wyzwalane przez bieżące wymagania biznesowe. Przekształca inicjatywę biznesową w projekt architektoniczny jednej lub większej liczby aplikacji, pokazując je jako logiczne komponenty z ich capabilities i interakcją między nimi. Powinien obejmować wszelkie zmiany w warstwie sprzętowej i określać wymagania niefunkcjonalne dla inicjatywy biznesowej, które są istotnym elementem dla dobrego projektu architektonicznego. 

Kluczem do prawidłowego wdrożenia jest dokonywanie stopniowych zmian w  warstwie architektonicznej, wprowadzając stopniowo nowe komponenty, interakcje między nimi i capabilities w pełnej zgodności z Reference Architecture, informacją z CPD i standardami architektonicznymi. Dzięki takiemu podejściu organizacje osiągają szybciej korzyści oraz  mają szansę sprawdzić  korzyści, które były początkowo zakładane  , dostając  możliwość szybszej adaptacji i uczenia się z ich implementacji, oszczędzając pieniądze w porównaniu z dużym projektem transformacyjnymi (projekty typu big bang).

Celem przedsiębiorstwa nie jest wprowadzanie zmian w warstwie architektury samych w sobie, ale wprowadzanie tych zmian, które przynoszą wartość dla organizacji. Dlatego w organizacjach powinniśmy wprowadzać tylko tyle zmian, które zapewniają właściwy wynik ekonomiczny i zapewnieniają technologiczny rozwoju przedsiębiorstwa. Proces architektoniczny musi być zatem ściśle połączony z cyklem dostarczania oprogramowania dla przedsiębiorstw. 

Na przykład Solution Vision może być wprowadzony w środowisko wytwarzania oprogramowania oparte o metodykę SCRUM w modelu, w którym dokument ten jest daną wejściową dla poszczególnych zespołów. Architekt buduje wizję całości rozwiązania dla całej inicjatywy i jest ona przekazywana poszczególnym zespołom rozwijających aplikacje. Zostało to zobrazowane na poniższym diagramie.

Repository

Produkty poszczególnych elementów LAF powinny znaleźć się w jednym centralnym repozytorium architektury. Baza ta powinna zawierać informacje o aplikacji w kontekście:

• przyszłości – miejsce w RA wraz z oczekiwanymi capabilities,
• capabilities jakich dostarcza – zespół wymagań i opracowań SV związanych z tym,
• jej aktualnego stanu – cechy aplikacji oraz zebrane w postaci paszportu.

Ref. Reprezentacja graficzna REPOSITORY

Kształt repozytorium, w tym lista cech aplikacji, sposób prezentacji capabilities czy sposób zapisu SV zależy od organizacji i powinien być zoptymalizowany w procesie udoskonalania. Repozytorium powinno być zbudowane w sposób pozwalający na dokonywanie w nim zmian. Zawartość repozytorium powinna stanowić minimalny zestaw danych potrzebny do klasyfikacji komponentu lub przedstawienia architektury referencyjnej. Jest to niezbędne ze względu na potrzebę posiadania aktualnych danych w REPO. Zbyt wysoki koszt ich pozyskania będzie miał ogromny wpływ na ich jakość.

Metrics

Podczas gdy prawdziwa transformacja w kierunku architektury referencyjnej odbywa się w modelu przyrostowym przez „Solution Vision”, potrzebne są mierniki, które zapewnią, że organizacja pozostanie na właściwej drodze. Proponowane wskaźniki są dobrą bazą do monitorowania tego postępu oraz doskonałym źródłem do retrospekcji dla organizacji i architektów. Zazwyczaj dane te są zbierane co kwartał; czas ten może być dostosowywany w zależności od potrzeb organizacji. 

Monitoring wskaźników architektonicznych umożliwi nam:

• Uzyskanie informacji  czy organizacja naprawdę się zmienia w warstwie architektonicznej
• Uzyskanie  wiedzy jak decyzje biznesowe wpływają na architekturę
• Podejmowanie świadomych decyzji dotyczących kompromisów między szybkością, wartością biznesową i zmianami architektury

Każdy z proponowanych wskaźników powinien mieć ustalony poziom bazowy i oczekiwany w celu lepszego monitorowania postępu, a każde naruszenie ustalonego poziomu bazowego lub oczekiwanego powinno prowadzić do otwartej dyskusji, retrospekcji i dostosowań.

Reference Implementation Metric (RIM) – każdy projekt implementacji (SV) powinien być dostosowany i zgodny ze standardami oraz oceną w CPD i zmierzać w kierunku spełnienia AR, ale w niektórych przypadkach nie można tego osiągnąć ze względu na krytyczne czasowo projekty, regulacje prawne itp. Dlatego każdy SV powinien zawierać atrybuty określające jego całkowitą zgodność z architekturą referencyjną. Zwykle ten atrybut może przyjąć jedną z trzech wartości:

• „Zgodny” – oznacza, że ​​projekt implementacji jest w pełni kompatybilny z architekturą referencyjną, a jego implementacja będzie stopniowo przekształcać krajobraz aplikacji do pożądanego stanu, zaprojektowanego w architekturze referencyjnej, szczególnie pod względem używanych komponentów, ich możliwości i interakcji między nimi.
• „Neutralny” – jego wdrożenie nie wpływa na krajobraz aplikacji, szczególnie pod względem standardów, używanych komponentów, interakcji między nimi i ich możliwości. Zwykle jest to niewielka zmiana lub zmiana UX.
• „Niezgodny” – występuje wtedy, gdy projekt implementacji nie może spełnić wymogu zgodności z architekturą referencyjną. Taka sytuacja ma miejsce szczególnie wtedy, gdy niektóre starsze komponenty są używane i aktualizowane, jest wykorzystywana niechciana  technologia, dodane są nowe komponenty lub dodatkowe interakcje, albo stwierdzono jakiekolwiek inne naruszenia architektury referencyjnej.

Tak może wyglądać wzór na obliczenie wskaźnika:

CV= Liczba Spolution Vision zgodnych z architektura ref i standardami

AV= Liczba wszystkich Solution Vision

RIM jest jednym z kluczowych wskaźników używanych do śledzenia kierunków zmian, określanym jako procent każdej wartości atrybutu w określonym czasie, np. raz na kwartał. Z poniższego wykresu można odczytać trend opracowanych zmian. Na tej podstawie organizacja może dostosować tempo transformacji inwestując więcej czasu i środków w „zgodne” projekty wdrożeniowe.

Przykład raportowania stanu metryki RIM

Application Reference Metric (ARM) – to wskaźnik aplikacji używanych w bieżącym środowisku aplikacyjnym organizacji do aplikacji w CPD o statusie „Inwestycja” i „Tolerancja”. 

Dzięki zastosowaniu tej metryki jesteśmy w stanie sprawdzić jakość komponentu w naszym portfolio. Możemy sprawdzić, czy powstają aplikacje warte inwestycji, a te słabe biznesowo i technologicznie są eliminowane.

AP =Liczba  wszystkich komponentów w CPD

IA = Liczba  komponentów w CPD w statusie Inwestycja i Tolerancja

Na przykład, jeśli wszystkich aplikacji jest  w środowisku 100, a tych o statusie „Inwestycja” i „Tolerancja” 50, to wskaźnik ARM wynosi 2. W dłuższej perspektywie wskaźnik ten powinien dążyć do wartości 1.

Przykład raportowania stanu metryki ARM

Implemented Capabilities Redundancy Metric (ICRM) – jest to miara nadmiarowości zaimplementowanych capabilities. Miarą jest liczba wystąpień capabilities w istniejących aplikacjach w stosunku do docelowej liczby capabilities.

Ta miara służy do monitorowania, czy funkcje nie są budowane nadmiarowo powyżej oczekiwanego poziomu. Wartość docelowa nie zawsze powinna wynosić jeden. Czasami warto mieć kilka instancji capabilities.

EC= Liczba instancji wszystkich capabilities

TC= Oczekiwana liczba instancji capabilities we wdrożonych aplikacjach

 Przykładowo, jeśli w naszym uproszczonym środowisku jest zaimplementowanych 6 capabilities „send SMS to Customer”, a powinny być tylko 2, to współczynnik ICRM dla takiego teoretycznego środowiska wynosi 3. Wartość współczynnika powinna dążyć do 1. 

Przykład raportowania stanu metryki ICRM

Capability Reference Metric (CRM) – jest to stosunek  capabilities wykorzystanych w bieżącym środowisku aplikacyjnym organizacji do tych zaproponowanych w architekturze referencyjnej (RA) organizacji. 

Ta miara służy do monitorowania, czy organizacja dąży do spodziewanego zbioru capabilities. Możemy regularnie sprawdzać, czy projekty / inicjatywy dodają nowe capability

UC= Liczba typów capabilities  będących aktualnie w środowisku

TC= Liczba capabilities proponowane w architekturze referencyjnej organizacji (AR)

Przykładowo, jeśli w organizacji jest zaimplementowanych 46 capabilities, a w RA jest ich 100, to współczynnik CRM wynosi 0,46. Metryka powinna być mierzona w określonym interwale czasowym, np. raz na kwartał. W dłuższej perspektywie liczba posiadanych capabilities powinna dążyć do poziomu z architektury referencyjnej, a wskaźnik do poziomu 1.

Przykład raportowania stanu metryki CRM

Architectural Forum

Dla efektywnej realizacji architektury LAF wymaga doskonałej komunikacji pomiędzy wszystkimi architektami. Aby pozostać niezależni, muszą oni poznać wpływ swojej pracy na innych architektów i ich obszary, a także zrozumieć całościowy obraz przedsiębiorstwa, dlatego LAF wprowadza Forum Architektoniczne jako główną platformę komunikacji. Spotkanie to powinno odbywać się co najmniej raz w tygodniu i trwać od 2 do 4 godzin. Są to nieformalne spotkania dla architektów w celu przedstawienia dokonanych przez nich głównych odkryć, uzgodnienia używanego języka i kształtu repozytorium architektury, omówienia wyników architektury referencyjnej, uzgodnienia nowych komponentów i nowych capabilities wprowadzonych do organizacji. Architekci mają okazję do przedstawienia i omówienia swoich wątpliwości w odniesieniu do „projektów wdrożeniowych”. W trakcie spotkań należy omawiać wprowadzenie i zmodyfikowanie standardów stosowanych w organizacji oraz wszelkie inne ważne kwestie, które pojawią się w procesach realizacyjnych.

 Spotkanie to służy również jako sesja planowania zadań architektonicznych, takich jak utrzymanie repozytorium, przeprowadzenie oceny komponentów, zarządzanie obszarami objętymi architekturą referencyjną, odświeżenie standardów przedsiębiorstwa lub wprowadzenie nowych. 

Forum architektoniczne nie zostało stworzone w celu zaplanowania prac związanych z „projektowaniem implementacji”, ponieważ jest to zadaniem SDLC. To spotkanie prowadzi do lepszego zrozumienia całej organizacji przez poszczególnych architektów i ponownego wykorzystania komponentów, możliwości, usług oraz technologii.

Zespół

The Architects team (zespół architektów) ma płaską strukturę, składa się z ludzi z głęboką wiedzą technologiczną, a także z głębokim zrozumieniem kontekstu biznesowego, architekci powinni i mogą pełnić różne role związane z podziałem technologicznym i biznesowym. Jest to samoorganizujący się zespół, który optymalizuje swoją wydajność i zapewnia wysoki poziomu komunikacji, ponieważ jest on kluczowym czynnikiem sukcesu. Członkowie zespołu mają dużą autonomię i pełną odpowiedzialność za dostarczanie artefaktów LAF. Dzielą te same normy, zasady i standardy. 

Są wspierani przez Master Architect, jest to rola odpowiedzialny za zapewnienie, że zespół architektoniczny postępuje zgodnie z procesem i praktykami LAF. Wspiera współpracę między członkami zespołu, zapewniając otwarte środowisko do otwartej dyskusji, prowadząc do wymiany wiedzy i obaw, pomaga usuwać przeszkody i zapewniać odpowiednią jakość praktyk architektonicznych i repozytorium. Odgrywa specjalną rolę w sytuacjach trudnych, takich jak brak komunikacji w zespole lub niemożność znalezienia szybkiego kompromisu, jaki często jest potrzebny.Rola Master Architect jest analogiczna do roli Scrum Mastera

Master Architect zapewnia, że ​​organizacja przestrzega zasad LAF poprzez coaching i nauczanie na temat frameworku. Pomaga organizacji w odpowiednim umiejscowieniu zespołu architektów tak, aby ich produkty znalazły się w SDLC, a opracowane standardy były respektowane.

Master Architect powinien również zwrócić szczególną uwagę na współpracę z innymi jednostkami, w szczególności zespołami deweloperskimi i jednostkami biznesowymi, zapewniając, aby współpraca ta opierała się na wzajemnym szacunku, wspólnych celach i partnerstwie.

W dużych organizacjach, w których liczba architektów jest większa niż 8, dobrze jest wydzielić mniejsze zespoły skoncentrowane na jakimś obszarze biznesowym . Te zespoły mają własne spotkania architektoniczne i sesje doskonalenia. Każdy zespół powinien wybrać swoich przedstawicieli, w tym Mistrza Architekta, do udziału w spotkaniu poświęconym całej architekturze. Przy takim podziale warto wyznaczyć Lead Master Architect odpowiedzialnego za współpracę zespołów architektonicznych.

Wielkość zespołu architektonicznego zależy od wielkości organizacji, jej złożoności i dojrzałości procesu dostarczania oprogramowania. Celem jest osiągnięcie minimalnego składu, który zapewni płynną realizację procesu dostarczania oprogramowania.